David M. Lloyd

Moving!

2010-09-10T10:48:00.000-05:00

As of today, my blog is officially moving to a new home at in.relation.to.

Safely downgrading a write lock with ReadWriteLock

2010-02-23T14:45:00.003-06:00

A simple pattern to downgrade a write lock to a read lock safely:

    ReadWriteLock rwl = getLock();
   Lock lock = rwl.writeLock();
   lock.lock();
   try {
       ... Perform write operation ...
       // downgrade lock safely
       final Lock readLock = rwl.readLock();
       readLock.lock(); // Possible failure #1
       try {
           lock.unlock(); // Possible failure #2
       } finally {
           lock = readLock;
       }
   } finally {
       lock.unlock();
   }

The reason this works is as follows:

1. Anything which fails before possible failure #1 will cause the original lock to unlock, due to the finally block.
2. If possible failure #1 occurs, the read lock is never locked, thus the write lock is still unlocked in the outer finally block.
3. If possible failure #2 occurs, the now-locked read lock is stashed into lock thanks to the inner finally block, thus the read lock is released in the outer finally block. At this point, no matter what, the write lock is released.
4. Any failure after possible failure #2 will cause the outer finally block to release the read lock.

The nice thing about this approach is that you can even downgrade the lock inside of a conditional and the structure is not broken.

XNIO 2.0.2 Bugfix Release

2010-01-25T14:21:00.003-06:00

A new release of XNIO is available which fixes several bugs. For more information about XNIO 2.0, see this previous post. Users of XNIO 2.0.0 and 2.0.1 are encouraged to update to 2.0.2 to take advantage of these bug fixes:

[XNIO-82] - Remove jboss-classloading.xml from artifact
[XNIO-83] - Getting an option from a string fails due to typo
[XNIO-84] - Enable all supported SSL cipher suites if none are explicitly enabled
[XNIO-85] - Possible deadlock in SSL negotiation phase
[XNIO-86] - CCE produced when casting a null option value
[XNIO-87] - XNIO log messages don't preserve the source class/method name
[XNIO-88] - Open listener specification is now optional; do not throw NPE if it is not provided

The release is available from the downloads page.

JBoss Marshalling 1.2.0 Released, Website Upgraded

2010-01-05T14:28:00.003-06:00

Some of you may have noticed that JBoss Marshalling 1.2.0.GA has been present in the maven repository for some time. Now that the website upgrade is complete, I'm happy to announce that it is now available from the downloads page as well.

JBoss Marshalling is a framework which wholly replaces Java Serialization with a new API and optional optimized wire format. The standard wire format can also be used as well - giving compatibility with applications using standard serialization, but without the various bugs present therein, and with a potentially significant performance advantage.

Other features that JBoss Marshalling provides which are missing from the Java Object*Stream API include:

Pluggable class resolvers, making it easy to customize classloader policy, by implementing a small interface (rather than having to subclass the Object*Stream classes)
Pluggable object replacement (also without subclassing)
Pluggable predefined class tables, which can dramatically decrease stream size and serialization time for stream types which frequently use a common set of classes
Pluggable predefined instance tables, which make it easy to handle remote references
Pluggable externalizers which may be used to serialize classes which are not Serializable, or for which an alternate strategy is needed
Customizable stream headers
Each marshaller instance is highly configurable and tunable to maximize performance based on expected usage patterns
A generalized API which can support many different protocol implementations, including protocols which do not necessarily provide all the above features
Inexpensive instance creation, beneficial to applications where many short-lived streams are used
Support for separate class and instance caches, if the protocol permits; useful for sending multiple messages or requests with a single stream, with separate object graphs but retaining the class cache

The 1.2.0 release features many more optimizations to the River protocol implementation, enhanced error reporting (the object stack is included with the exception stack trace), run-time detection of implementations via the ServiceLoader mechanism, and helper classes to simplify integration with NIO-based applications.

JSR 294/277: Why don't we have standard Java modularity?

2009-12-09T21:33:00.006-06:00

Why is it so difficult to write a modularity specification for Java? The requirements appear to be relatively simple:

Provide an API whereby a user can load a module and link to it (in other words, get a classloader which can be used to load exported classes), possibly with a mechanism to "run" a module, similar to how one can execute "java -jar foo.jar" today
Support a per-module access control level, in the Java language and JVM
Provide a way to specify what other modules are required/optional, and whether they are imported or imported and exported (in other words, "metadata")
Provide a way to recursively locate, load, register, and link referenced modules in an efficient manner (in other words, "resolution")

So what would it take to implement this? Not much from what I can see.

The user API would amount to a new ModuleLoader class which has API elements to load a module and return an instance of a new Module class, which has the ability to either access the exported classes therein directly, or get at a ClassLoader which can do so.

A per-module access control level can be implemented by one simple rule: If a class is loaded from a module's ClassLoader, change "package-private" to mean "module-private" instead. Otherwise, stick to the old rules. Very straightforward.

Metadata can be implemented very simply as plain data objects which are read by the appropriate ModuleLoader, or even as an implementation detail of ModuleLoader itself.

Resolution could (and should) be a pluggable thing within a ModuleLoader. This would enable customized handling like the ability to load modules right out of Maven, or the ability to download modules on demand from a trusted remote repository.

So what's the deal? Wouldn't this small group of classes (and one small JLS/JVM change) be sufficient to solve the problem?

XNIO 2.0.1 Bugfix Release

2009-12-04T12:44:00.003-06:00

I've uploaded a minor bugfix release for XNIO 2.0.0. It fixes a selector wakeup bug, as well as a minor API bug and a minor optimization for blocking I/O with the NIO-based provider.

All users of 2.0.0 are encouraged to update to 2.0.1. The release is available on the download page.

XNIO 2.0.0 has landed

2009-11-25T16:58:00.004-06:00

XNIO is a simplified low-level I/O layer which can be used anywhere you are using NIO today. It frees you from the hassle of dealing with Selectors and NIO's poor support for SSL, multicast sockets and non-socket I/O, while still maintaining all the capabilities present in NIO. The XNIO 2.0.0 release includes all of the features of the 1.x series, including:

API compatibility with NIO channels and APIs which consume them
Powerful callback-based API for channel status changes
Very simple API for data transfer on channels
Enhanced NIO buffer support, with many convenience methods to make traditionally difficult buffer manipulation tasks easier
TCP and UDP client and server support
API support for other socket types (such as UNIX domain sockets)
The ability to intermix blocking and non-blocking I/O operations freely and easily
JMX management for all channels
Powerful IoFuture interface and support classes simplify asynchronous I/O operation support in XNIO as well as in your application

And these new features:

SSL channel types for easy SSL support - vastly simpler than the NIO-targeted SSLEngine API
New channel listener interface which makes implementing clients and servers even simpler
Runtime-switchable event listener registration for easy support of "state pattern"-based protocol implementations
Support for JMX-managed old-I/O SocketFactory and ServerSocketFactory instances to retrofit legacy applications with management capabilities
Service location API which frees users from a compile-time dependency on an implementation JAR
A new User Guide
Simplified channel API makes custom channel implementation easy
Improved generic configuration API via immutable OptionMap class
Improved API to allow user applications to easily provide IoFuture implementations
Improved zero-copy integration with NIO's FileChannel
And many more...

The project page is at http://www.jboss.org/xnio. Download the release from the download page, or in the JBoss Maven repository under the org.jboss.xnio group ID. The documentation, including Javadoc and the user manual, are available on the docs page. Issues can be filed in the project's JIRA bug tracker.

XNIO 2.0.0.CR4 Released

2009-11-02T14:30:00.003-06:00

XNIO 2.0 is getting very close to completion. The latest CR, 2.0.0.CR4, is now available from the downloads page.

The main change since CR3 is the introduction of a new "Result" interface which acts as feed-in to an IoFuture. This makes it easy for developers to create an API which exposes IoFuture results to the user, without worrying as much about implementation details. Various support classes have also been added for this purpose. In addition, the implementation classes have been ported to use the new API.

New XNIO, JBoss Marshalling, and More...

2009-09-22T11:44:00.003-05:00

Since my last post several months ago, I've been quite busy with a number of project releases.

JBoss Marshalling version 1.2.0.CR3 - download here, JIRA here. Includes a much more efficient River protocol implementation, and the Java-compatible Serial implementation, both of which have been measured to outperform Java serialization by 50% or more in some cases, while retaining compliance with the Serialization specification.
XNIO 2.0.0.CR2 - download here, JIRA here. Includes an improved API, as well as SSL support, which I think will be quite appreciated by anyone who has ever tried to use SSLEngine with NIO.
JBoss LogManager 1.1.0.GA - available from the JBoss Maven Repository. A complete re-implementation of the bug-ridden JDK LogManager implementation, with additional handler types (including log4j compatibility), designed specifically to provide a highly efficient and cleanly implemented logging layer for JBossAS.
JBoss Logging 2.2.0.CR1 - available from the JBoss Maven Repository. An improved version of the logging facade historically used by JBoss projects which run within JBossAS. This new version improves memory usage by providing the ability for backend implementations to cache and reuse instances in a way that is not subject to the classical ClassLoader issues of other similar frameworks. Also provides logging methods which take advantage of the JDK5 java.util.Formatter class.

There are a number of other projects in the works as well, so stay tuned!

Class-local data

2009-02-25T17:48:00.004-06:00

Today I ran across a problem that I've hit frequently in the past, this time while designing an extension to JBoss Marshalling which allows users to annotate classes which are to be specially externalized. The problem is that one wants to "remember" what Externalizer instances go with what classes on a semi-permanent basis; however, one does not wish to leak class references (which can lead to the permanent generation filling up, and your application crashing with an OutOfMemoryError, especially if you're frequently loading and unloading classes).

The traditional solution to keep a leak-resistant cache is to employ a WeakHashMap like so (usually in conjunction with some concurrency strategy, like a Lock):


  private static final Map<Class<?>, Externalizer> cache = new WeakHashMap<Class<?>, Externalizer>();

The WeakHashMap retains a weak reference to the key values (in this case, the Class instance), so if no strong references remain, the Class is unloaded, and all is well. However, in this particular use case, the Externalizer instance very likely will itself hold a strong reference to the Class. Why? Because in JBoss Marshalling, Externalizer instances may be custom-designed with a single class in mind; thus, it might have a field or a constructor call of that class' type, which means strong reference. Since WeakHashMap retains a strong reference to its value, this means that there is a strong reference from my cache to the class after all, so all is for naught.

So I got to thinking - what if I could stash my Externalizer instance on the Class itself? Then I wouldn't even need to keep a cache at all, and the only reference to the Class that I could cause to be would be from the Class itself. That would be awesome! Of course, we wouldn't want anyone else to be able to get at my data; it could be private to me, after all. And we wouldn't want it to leak the other way - the Class should not hold a direct strong reference to my class, yet we don't exactly want it to be a weak reference either (because then the data might disappear before I've had a chance to use it).

So my idea is to create a new type of storage: class-local data. You'd access it similarly to thread-local data, except instead of being keyed from the current thread, you'd give it a class:


  // The methods are similar to the corresponding methods on Map and ConcurrentMap
  public final class ClassLocal<T> {
     public T get(Class<?> clazz) { ... }
     public T put(Class<?> clazz, T value) { ... }
     public boolean hasData(Class<?> clazz) { ... }
     public T putIfAbsent(Class<?> clazz, T value) { ... }
     public T remove(Class<?> clazz) { ... }
     public boolean remove(Class<?> clazz, T oldValue) { ... }
     public T replace(Class<?> clazz, T newValue) { ... }
     public boolean replace(Class<?> clazz, T oldValue, T newValue) { ... }
  }


  private final ClassLocal<Externalizer> classLocal = new ClassLocal<Externalizer>();

  ...in some method...
  Externalizer externalizer = classLocal.get(SomeClass.class);

A ClassLocal instance looks and acts a lot like a map, but with one important difference: the data itself is stored on the Class instance, not in the ClassLocal. Implementation-wise this could be accomplished via a WeakHashMap or similar structure on the Class itself (with a concurrency strategy) similar to this:


  public final class Class<T> {
     ...
     final Map<ClassLocal<?>, Object> classLocalData = Collections.synchronizedMap(new WeakHashMap<ClassLocal<?>, Object>());
  }

...which could then be accessed directly by the ClassLocal implementation. Real JDK experts could probably think of a few ways to optimize this - e.g. avoid creating a map instance until someone puts data there, come up with a more clever locking strategy, etc.

Update: As I ought to have expected, I'm nowhere near the first person ever to let their mind wander down this path - there's a Sun bug (#6493635) about it, as well as articles by such clever folks as Crazy Bob and Jacob Hookom about this very topic.

New protocols in JBoss Marshalling

2009-02-06T14:35:00.004-06:00

It's official... I've checked in the first cut of the Java Serialization from-scratch implementation. ~~It's not complete yet - it doesn't even pass all the tests~~ (Update: everything works now - check it out from SVN and try it!) - but I expect that it will be fully functional by the 1.1.0 release (and, coincidentally, by the time I will be giving my JBoss Marshalling talk at TSSJS). Also in progress is Ron Sigal's JBoss Serialization implementation, which should be in 1.2.0 at the latest.

Look for the 1.1.0.GA release the week of February 23rd.

XNIO 1.2.0.GA Released

2009-01-13T18:09:00.003-06:00

The final GA release of XNIO 1.2.0 is available for download. This release represents a "settling in" to a 16-week release cycle that should continue from now on. Here's a complete changelog since 1.1.0.GA:

Bugs

[XNIO-56] - Xnio.create() fails for the default provider
[XNIO-57] - NioSocketChannelImpl suspendWrites method suspends reads instead of writes
[XNIO-58] - NPE bug in AllocatedMessageChannelStreamChannelHandler
[XNIO-60] - NIO: When pooled selectors are exhausted, an exception is thrown
[XNIO-65] - NioPipeTestCase.testOneWayPipeSinkClose fails under Java 5
[XNIO-67] - TCP tests fail under Java 5, not Java 6

Feature Request

[XNIO-19] - Add ability to switch a channel between blocking and non-blocking
[XNIO-50] - Mitigate the performance impact of Selector.wakeup()
[XNIO-54] - API for one-time servers
[XNIO-64] - IoFuture notifiers with attachments (see below)
[XNIO-66] - Add static blocking read/write methods to Channels

Task

[XNIO-17] - Add monitoring via JMX
[XNIO-39] - Remove deprecated Xnio.createNio() methods
[XNIO-48] - Create a UNIX domain socket API
[XNIO-64] - IoFuture notifiers with attachments

Links

Download: http://www.jboss.org/xnio/downloads
Javadoc: http://docs.jboss.org/xnio/1.2.0.GA/api
Project page: http://www.jboss.org/xnio
Bug tracker: https://jira.jboss.org/jira/browse/XNIO

Just a reminder that the 1.2.0.GA release is not 100% binary- and source-compatible with 1.1.x, so if you choose to move to 1.2.0.GA, make sure you do a clean build of your project to identify any potential problems with the changes surrounding the new IoFuture attachment feature.

XNIO 1.2.0.CR2 Released

2009-01-07T20:47:00.003-06:00

The XNIO 1.2.0.CR2 release is up on the project page. This release features cleaned up Javadoc, several bug fixes, and a few handy new features (in particular, static methods to perform blocking reads/writes for most common channel types).

The biggest change is the ability to pass an attachment in to an IoFuture instance, via the IoFuture.addNotifier() method. This allows users to reuse notifier instances, which is a very powerful capability. Unfortunately there was no clean way to add this feature without breaking compatibility in some way, so I went for the cleanest implementation possible, which means that XNIO 1.2.x is not 100% binary- and source-compatible with XNIO 1.1.x. I hope that this feature is useful enough that you will all forgive me for that change. Because of this change I will maintain the 1.1.x series for longer than I otherwise might, in case there are users out there who are committed to the old API.

Read the Javadoc here, download the release here, report bugs here.

Remoting 3.0.0.Beta2 Released

2008-12-18T21:23:00.002-06:00

This is the last Beta before the CR (candidate for release) series. As always, the download is available at the Remoting download page. This release differs from Beta1 in several ways, not the least of which is the more complete distribution, which includes source JARs and API Javadoc as well as the Remoting JARs themselves. View the release notes for the full list of differences.

The online Javadoc is available here. Also, there are a few code samples available in the Subversion repository. Please feel free to report bugs in the Remoting JIRA bug tracker, making sure to mark the proper version when doing so.

XNIO 1.2.0.CR1 Released

2008-12-16T18:56:00.002-06:00

XNIO 1.2.0.CR1 is available for download at the XNIO project download page, sporting lots of cool new features, like:

The ability to switch between blocking and non-blocking modes
Wrapper Input/OutputStreams for channels
JMX monitoring
A restructured API/SPI system
A one-time server API (for services like IRC DCC and FTP that need to create one-shot server sockets)
The ability to change a server's bind address(es) after it has been started

...not to mention several performance improvements and code and documentation cleanup changes as well. Check out the API Javadocs as well. Enjoy!

Remoting 3.0.0.Beta1 Released

2008-11-14T17:07:00.003-06:00

The download is available at the Remoting download page. The structure is similar to the milestone releases; though it may be changing slightly for the next Beta. I expect that there will be at most one more Beta, followed by a CR series.

Javadoc is available online at the docs site; bugs should be reported in the bug tracker (make sure you report the bug in the 3.0.0.Beta1 release). See the project page for more information.

JBoss Marshalling, River Protocol 1.0.0.GA Released

2008-11-14T14:20:00.003-06:00

JBoss Marshalling is an alternative serialization API that fixes many of the problems found in the JDK serialization API while remaining fully compatible with java.io.Serializable and its relatives, and adds several new tunable parameters and additional features, all of which are pluggable via factory configuration (externalizers, class/instance lookup tables, class resolution, and object replacement, to name a few).

This project doesn't yet have an official home, but you can view the online API documentation right here, and the project is available for download at this location within the JBoss repository.

XNIO 1.1.1.GA Released

2008-11-12T18:39:00.002-06:00

The release available on the downloads page. This is a bugfix release; I encourage all users of 1.1.0.GA to upgrade.

Here's the list of changes:

Fix a problem in the Xnio.create() method's default provider lookup

Fix a problem where thread interruption could cause a tight spinloop

Fix a minor problem in the logger init code

Merge the improved test log formatter from trunk

Enjoy!

Binding to privileged ports with XNIO

2008-10-23T10:58:00.003-05:00

A couple random ideas about how to bind privileged (<1024) port numbers using XNIO. It might be possible to utilize the UNIX domain socket API (slated for 1.2.0) and use the file descriptor-passing mechanism. A root-privileged server (written in C) could be started that binds to a UNIX domain socket on the filesystem, whose access permissions are limited. The XNIO-based application can use this domain socket to request bound ports and get the file descriptor back, which it would use to construct a server.

Another idea would be to turn it around, and have the XNIO process run a setuid root program (via ProcessBuilder) which binds the port and hands it back through a socket created by the Java program.

JBoss Marshalling Framework 1.0.0.Beta2 Released

2008-10-16T22:43:00.004-05:00

I'm pleased to announce that the second beta of the new marshalling framework has arrived. The API is pretty much final at this point; now it's just a bug quest before the first CR is released in a couple weeks. For more information about the features of the framework, please see the original Beta1 announcement.

Download the JARs from the repository. The documentation is available here at the JBoss docs site. Please report any bugs in the JBoss Marshalling bug tracker.

Many thanks to Ron Sigal, author of the Java serializaiton-compatible module, and the one who flushed out ~~some~~ ~~most~~ all of the bugs from the Beta1 River protocol implementation that were fixed in this version.

Minor XNIO re-org for 1.2.0

2008-10-16T12:17:00.002-05:00

For XNIO 1.2.0, I'm doing away with the separated API versus standalone JAR. My original notion was that the standalone JAR would contain the whole API, plus the Xnio bootstrapping class, plus at least one implementation (NIO right now, as that is currently the only complete implementation). But I think it will be simpler going forward to just add Xnio into the API itself, and ship an API JAR plus one JAR per implementation. So from now on (including any future snapshots), the JARs will follow this new structure instead.

XNIO 1.1.0.GA Released

2008-10-13T13:39:00.003-05:00

XNIO 1.1.0.GA is available on the XNIO downloads page. Not much change since 1.1.0.CR1. Just a Javadoc update, and one interface rename: TcpClient has been renamed to TcpChannelSource (see XNIO-55 for more information). Also see the online Javadocs for usage information.

Have fun!

Feedback about Dave's Dumb Closures

2008-10-08T08:04:00.003-05:00

I've gotten some feedback about my closure idea. Some of it bad, some of it... also bad. I thought I'd reply to all the comments in a new posting here rather than try to squeeze it all in to the crappy comment thing.

Rémi Forax said...

You can't get ride of exception transparency, at least if you want to keep checked exceptions.

Here is an interresting email from Neal Gafter:
http://mail.openjdk.java.net/pipermail/closures-dev/2008-July/000174.html

Do you have a way to write StringSwitch with your syntax/semantics ?

Rémi raises two separate points here, so I'll address them separately. Firstly, there's the question of "exception transparency". In response to this, please consider the following. First, in my proposal, the passed in code block may only be directly executed from within the receiving method. Therefore, the set of exceptions that may be thrown can be statically determined. The JVM can thus "safely" throw undeclared checked exceptions from the closure body as long as the calling method can handle it. The JVM would be able to verify this statically during bytecode validation.

Secondly, the question is whether one could use closures to write a StringSwitch as shown in Neal Gafter's email above. The short answer is: no. It is not possible to use closures in this way in Java. The reason is that Java has a linear stack; therefore a closure in Java may not outlive its lexical scope.

Now I know you're thinking, "Pfft, this is proof that BGGA closures are better". However this is where I point out that BGGA closures aren't closures, not in a JVM sense. They're just a syntax shortcut for anonymous inner classes. And the only way the so-called StringSwitch could possibly be implemented is basically as a syntactical wrapper around Map<String,Runnable>, with some magic to produce anonymous inner classes. This is not any different from what we have today; except possibly that today there is a rough correlation between amount of code written and efficiency of execution. With BGGA that all changes... it almost becomes easier to write bad code than good code.

Yardena said...

Hi,

In languages that have closures, they are often used for "delayed evaluation", wrapping a block of code in a closure and passing on to some other object makes the code execute when the other object needs it and not right now. So closure can be used as an event handler, command, etc.

Unless I missed something major in your proposal, it does not support such a usage, since you don't support references to closures (I think this is what Remi is implying too).

So to get the record straight - you propose something much less powerful than BGGA, and not equivalent to closures in other languages.

You can still have delayed execution; however the delayed execution must occur within the lifetime of the called method. This is, as I mentioned, a consequence of how lexical scoping works in Java. In languages that support "keeping" the closure past its declaration, the lexical scope is either not defined by the stack, or the stack is "forked" so that stack frames can be preserved even after they're out of scope. Java's stack is linear, and lexical scope is defined by the stack, so if you want closures, you're stuck with that. Of course BGGA does not have this limitation because BGGA isn't really closures. It's an abbreviated syntax over anonymous inner classes.

This all isn't to say that this problem is without solution. One could propose a JVM change to add support for forked stacks, for example. But I for one think that interfaces already solve this problem much more idiomatically (and honestly). Idiomatic because it's done that way today, and there's really nothing seriously wrong with the solution. Honest because you get what you pay for - you're saying you want to create an object, and that's what the JVM does - unlike BGGA in which you say you want to pass in a closure, and it goes ahead and creates an object anyway.

Ricky Clarkson said...

"Basically this translates to Java as two things: A lexically-scoped block of code, and a means to execute that code or pass it on to another method for delayed execution."

Your proposal seems not to fit that second part, the delayed execution.
Suppose we're using a closurific wrapper around SwingUtilities.invokeLater:

doLaterClosurely() {
. . some gui stuff;
}

How would your proposal work for this?

It would be handy if you suggested what Java 5 code your examples translate to.

Since I've answered the former question already, I'll jump right to the end: There is no Java 5 translation for my closure proposal. This is the whole point. Today the JVM does not have closures; after BGGA, the JVM still would not have closures. With my proposal, the JVM gets closures - real closures that really close over the actual lexical scope. This means support on a JVM level. My proposal simply assumes the minimum amount of change to make this so, which is limited to not adding support for forked stacks (which, by the way, would imply the need to deal with multiple threads accessing a single stack frame).

Again I need to emphasize that BGGA is moving away from the notion that what you write is what you get. Much like autoboxing, a mistake we continue to have to live with to this day, BGGA results in objects being automatically created on your behalf without your direct intention to do so. One end result of this is that brevity of code has a greatly reduced correlation to efficiency of bytecode or efficiency of execution. This is a mistake in my opinion. One reason that Java is considered to be so fast now is that the virtual machine maps very cleanly to a real machine, and the Java language maps cleanly to the virtual machine. So things that are easy to do in Java, by and large, can execute quickly on a real machine. Programmers who come from a C background, like myself, tend to find that things function and perform "as expected" on a real machine.

The advent of BGGA represents a departure in correlating language features with JVM capabilities, and thus the language no longer maps cleanly to a real machine. The natural side-effect of this is that you have to perform a lot of trickery (such as implicitly converting local variables to fields) to make it work. It is an undeniable fact that field accesses are slower than local variable accesses. It is an undeniable fact that a direct subroutine invocation (such as what you'd get with the JVM "jsr" instruction) is much faster than a virtual method lookup and invocation. Programs using BGGA closures are going to appear to be "slower" than programs that don't, because they will use more anonymous inner classes, and they will suffer from the implicit local variable-to-field conversion and virtual method invocation. I guarantee that this will be the case.

WarpedJavaGuy said...

Why are new language constructs so often perceived as mutilations? Is changing the semantics of existing keywords and constructs not a mutilation?

I actually have a fairly simple set of criteria here for Java. I have no problem with constructs that map to the virtual machine in simple, well-defined ways. Today, a local variable in Java means a local variable in the JVM. Even so-called "hacks" such as inner classes have a fairly clean JVM mapping when it comes down to it - they're still classes after all. Anonymous inner classes push things with their implicit copying of local variables into final fields. BGGA is over the line. With BGGA, you could measurably impede the performance of a method body (not to mention completely change 100% of the method bytecode) simply by putting a closure inside of it somewhere which accesses those local variables. This is what I call a "mutilation". You don't get what you pay for when you use BGGA closures.

All my proposal would require is either a way to define code blocks as an attribute of the calling method, with a way to correlate the lexical scope, or a way to jsr into other methods with parameters (see the "Nuts & Bolts" section of the original posting). This would make my closures a very simple mapping to JVM bytecode.

Thanks everyone for your questions - please feel free to send in more.

More uses for Dave's Dumb Closures

2008-10-07T10:42:00.002-05:00

Truly pluggable locking strategies:


    public interface Locker {
        void hold() for myBlock();
    }

    public class SynchLocker {
        private final Object lock;
        public SynchLocker(Object lock) { this.lock = lock; }
        public void hold() for myBlock() {
            synchronized (lock) {
                myBlock();
            }
        }
    }

    public class LockLocker {
        private final Lock lock;
        public LockLocker(Lock lock) { this.lock = lock; }
        public void hold() for myBlock() {
            lock.lock();
            try {
                myBlock();
            } finally {
                lock.unlock();
            }
        }
    }

    ...later...
    Locker l = ...take your pick...;
    l.hold() {
        ...do stuff...
    }

Let's see you do that efficiently with anonymous inner classes or BGGA.

JBoss Marshalling Framework 1.0.0.Beta1 Released

2008-10-06T19:46:00.005-05:00

As a part of the JBoss Remoting project (and hopefully several other projects as well), I've developed a separated marshalling (a.k.a. serialization) framework. This framework was inspired by the need for certain features unavailable with the standard Object*Stream classes:

Pluggable class resolvers, making it easy to customize classloader policy, by implementing a small interface (rather than having to subclass the Object*Stream classes)

Pluggable object replacement (also without subclassing)

Pluggable predefined class tables, which can dramatically decrease stream size and serialization time for stream types which frequently use a common set of classes

Pluggable predefined instance tables, which make it easy to handle remote references

Pluggable externalizers which may be used to serialize classes which are not Serializable, or for which an alternate strategy is needed

Customizable stream headers

Each marshaller instance is highly configurable and tunable to maximize performance based on expected usage patterns

A generalized API which can support many different protocol implementations, including protocols which do not necessarily provide all the above features

Inexpensive instance creation, beneficial to applications where many short-lived streams are used

Support for separate class and instance caches, if the protocol permits; useful for sending multiple messages or requests with a single stream, with separate object graphs but retaining the class cache

The default implementation, known as "River", is also available as a separate JAR.

This project does not have a home page, but the binaries have been uploaded to repositry.jboss.org and the Javadocs are available online at docs.jboss.org. The source code may be found in my sandbox repository for now, until it gets a permanent home.

Enjoy!

XNIO 1.1.0.CR1 Released

2008-10-01T17:56:00.002-05:00

As the title states - 1.1.0.CR1 is available at the XNIO project download page. The main list of changes:

Added API support for creating one-way and two-way pipes.

Improved separation of the NIO implementation by moving packages and moving the factory classes to a XnioNio class.

Add a java.util.concurrent.Future wrapper for IoFuture objects.

Fix a bug with IoFuture.get() so that it throws a more specific CancellationException when an operation is cancelled.

Replace SPI module with a more logical abstraction for provider implementations, including some abstract implementations.

Make IoFuture.await() parameter order consistent with other standard timed wait methods.

Servers changed to bind to 0.0.0.0 by default.

Added some handy util classes for dealing with Closeable resources.

Consolidated the IoFuture.Status value TIMED_OUT into WAITING, since the two are synonymous anyway, which will simplify IoFuture.Notifier implementation among other things.

Added an abstract base class to allow implementation of one-line IoFuture.Notifier implementations.

Java Language Support for Tail Recursion

2008-09-30T11:23:00.003-05:00

Everyone wants tail recursion. I've heard that some JVMs automatically detect tail recursion even. How about a simple syntax change to do it at a language level?


    public int factorial(int number) {
        if (number == 0) {
            return 1;
        } else {
            goto factorial(number, 1);
        }
    }

    private int factorial(int current, int sum) {
        if (current == 1) {
            return sum;
        } else {
            goto factorial(current - 1, sum * current);
        }
    }

Long live goto! In this example, goto means "replace the current stack frame with a call to this method", where the given method can be any method whose return value is compatible with, or equivalent to, the calling method's return value.

Dave's Dumb Closures

2008-09-30T02:12:00.009-05:00

Or: How to add closures to Java without mutilating the language

Those of you know have spoken with me via any media for more than about 45 seconds consecutively know that I am vehemently opposed to the various closure implementations for Java that have been proposed for inclusion in to Java 7. I'm not opposed to closures, mind you - I just really dislike the implementation options that are currently on the table. At one point I had visualized writing The Final Blog Post On The Subject, which would be so sharp of wit that any possible counterargument simply could not stand in the face of it. It would be eloquent, noble, and completely irrefutable - even the staunchest BGGA supporter would be won over.

Then reality sets in, and one is reminded that pretty much every such argument against the different closure ideas has been made, and promptly deflected. So rather than add to that particular category of noise, I thought I'd present a rough outline of a closure implementation that would sit much better with me, in the hopes that there are folks out there who have the same misgivings as I do about the current state of things.

What is a Closure?

A closure is defined in FOLDOC as "a data structure that holds an expression and an environment of variable bindings in which that expression is to be evaluated."

Basically this translates to Java as two things: A lexically-scoped block of code, and a means to execute that code or pass it on to another method for delayed execution.

The use cases for these things are numerous. Other imperative languages have used them for such things as customized control flow structures, continuations, resource management, and so on. Here in Javaland though, we are left out in the cold - the closest thing we get to these fun toys are anonymous inner classes. And while anonymous inner classes give the impression of being a sort of limited closure (with the caveat that it can only access local variables that were declared final - they're actually copied to fields transparently), they're obviously not the real deal.

The current leader, BGGA, takes the approach of taking the anonymous inner class notion a few steps farther - local variables aren't just copied to fields, they become fields (and thus read/write) - along with lots of language glue (magic dynamically-generated types, lots of new syntax and rules, some special annotations) to make it all work sanely. I'm not going to go into an exhaustive list of What's Wrong With BGGA; rather I'm going to demonstrate a completely different notion of a closure in Java from what you've seen in BGGA and the other competing specs.

A Closure is a Procedure

My view of a closure in Java is simply an inner method - or more accurately, an inner procedure. This differs from BGGA (and anonymous inner classes) in a few ways:

Local variables are local variables. They're all on the stack; the stack is still the regular linear LIFO we're all used to. This means no surprises with respect to concurrent access or comparatively slow field accesses behind the scenes.
No objects floating out on the heap represent the current lexical scope. No heap means no GC cost - exiting the calling method instantly cleans up the scope.
Exception handling is greatly simplified - the exception types can be inferred from the inner block.
Closures are (obviously) not inner classes anymore; they cannot be used outside of the lexical scope of the calling method.
The whole function-type interface hierarchy is gone. This means that calling your closure is no longer a virtual method dispatch. It becomes a simple pointer dereference.

These facts come about because the implementation I describe creates real closures (not closures emulated with objects) over real lexical scopes (not lexical scopes that are really collections of fields in a synthetic object class).

Since many people are visual in nature, allow me to demonstrate a possible syntax and usage for these things.

This first example would be a typical ARM (automatic resource management) scenario. Imagine a Lock interface with a method like this:


    public interface Lock {
        void hold() for theBlock();
    }

Notice the use of the "for" keyword. Yeah, I stole that idea from BGGA. Anyway, here's how you'd implement it:


    public class MyLock implements Lock {
        // ...stuff...
        public void hold() for theBlock() {
            ...acquire the lock using ninja CAS techniques...
            try {
                theBlock();
            } finally {
                ...release the lock unconditionally...
            }
        }
    }

Finally you'd use it like this:


    private final Lock lock = new MyLock();

    public void doStuff() throws TheException {
        // we need to access the shared resource!
        lock.hold() for() {
            // ok, let's do some test
            if (someConditionIsWrong) {
                throw new TheException("Failure...");
            }
        }

Or we could ditch the "for" on usage if there's no parameters:


    lock.hold() {
        // do stuff
    }

Niiiiice.

Now think about this for a moment. Not only does it look awesome, but we've removed the virtual method invocations you'd get with BGGA thereby making this potentially super-fast, eliminated an entire category of new magi-types from the language, and solved the Big Exception Conundrum.

Did I go too fast? Let me back up and cover those points.

First - it looks awesome, you can't deny it. No goofy arrows pointing from nothing to whatever, no weird ({()}) crap, etc. It reads easily in declaration, definition, and invocation, and it's not a lot of typing.

Next - consider what this closure structure does for performance. With one single method invocation, we are locking the resource, executing the user block, and unlocking the resource. You can't even beat that using try/finally today - at best you've got a method call to lock and a method call to unlock, with your code in between (I'll get into the mechanics of how the call to the block actually occurs down below, for you skeptics out there).

I won't cover the magical auto-created interface types in BGGA - if you know what I'm talking about, well, then you know what I'm talking about. If not - you don't want to know, believe me.

Finally, the Big Exception Conundrum. Due to the fact that the closure is really and truly lexically scoped - not fakey-lexical-scoping like anonymous inner classes and their big BGGA brother - all kinds of tricky issues about exception propagation simply disappear. The complete relevant part of the call stack is statically known at compile-time! Therefore there's no need to put in special plumbing for the closure to have some fancy dynamic throws list, or for the method which invokes the closure to have any knowledge or regard for what the closure may throw. It will throw whatever the closure's parent method can catch or propagate at the point that the closure is defined, just like a regular code block. And nonlocal returns can be trivially implemented using the same techniques.

Some More Lovely Examples

The oft-wished-for Map pairs iteration - interface:


    interface Map<K, V> {
        // ...
        void iterate() for block(K key, V value);
        // ...
    }

Implementation:


    public class FooMap<K, V> implements Map<K, V> {
        // ...
        // cheapo implementation just uses good old entrySet()
        public void iterate() for block(K key, V value) {
            Set<Entry<K, V>> entrySet = entrySet();
            for (Entry<K, V> e : entrySet) {
                block(e.getKey(), e.getValue());
            }
        }
        // ...
    }

Usage:


    Map<String, Thing> things = new FooMap<String, Thing>();
    // ...later...
    things.iterate() for (String key, Thing value) {
        System.out.println("The string " + key + " is for the thing " + value);
    }

Think how difficult it was for the BGGA crowd to get control structures in there! And they're still pretty ugly if you ask me (at least in v0.5 of the draft):


    // weird BGGA stuff...
    <R, T extends java.io.Closeable, throws E>
    R with(T t, {T=>R throws E} block) throws E {
        try {
            return block.invoke(t);
        } finally {
            try { t.close(); } catch (IOException ex) {}
        }
    }

This same safe-close control structure would be done like this (notice how absolutely no type parameters are needed):


    public static void with(Closeable resource) for block() {
        try {
            block();
        } finally {
            try {
                resource.close();
            } catch (Throwable t) {
                // log it, of course!
            }
        }
    }

Then the usage would be:


    InputStream is;
    with (is = new InputStream("foo.txt")) {
        // read me my bytes!
    }

Or how about slick user transaction management (usage only shown):


    txn.begin() {
        // do some JDBC or Hibernate or something!
    }
    // or keep a threadlocal with the context and you could do:
    transaction() {
        // do some JDBC or Hibernate or something!
    }

Or a nice way to handle streaming result sets from a file or database (usage only shown):


    data.fetch() for (String lastName, String firstName, BigDecimal balance) {
        // Take a hike, data objects.  These are all local variables!  Talk about cheap GC!
        System.out.println(lastName + ", " + firstName + " owes us $" + balance);
    }

Privileged actions get a performance boost (no object creation, no virtual method dispatch) - and say goodbye and good riddance to PrivilegedExceptionAction:


    AccessController.doPrivileged() {
        secretStuff.activate();
    }

Nuts & Bolts

The way I describe these closures is based on a few key technical ideas.

The code block, when it executes, maintains a "link" to the outer stack frame. This is what allows the outer variables to be accessed. All local variables continue to live on the stack.
As such, the actual internal value of the closure parameter is either a pair consisting of the parent stack frame address and the code block address, or a pointer to a trampoline - a small bit of machine code, generated at runtime, which resides on the stack and initializes the child stack frame with said pointer before passing execution to the inner code block.
A code block would probably have to have its own type designation, as a new primitive type (they're like methods, but without a return value and with no exception list).
I assume that all returns are nonlocal, though it is not required by this design. Nonlocal returns still pass through all the finally blocks that would be on the call stack.
A code block may implicitly throw any checked exception that is catchable at the point that the method (the one which accepts the closure) is implemented. This includes, of course, any checked exceptions declared on the (closure-accepting) method itself.
Variables may not be declared as a closure type. This helps keep the magic smoke inside the computer.
Closures only live for the duration of their lexical scope. Their REAL lexical scope, not a pretend scope that's really an object.
In fact, the implementation may not consist of an object to substitute for a lexical scope. Violators will get scowled at, and possibly called rude names.
No fancy parser acrobatics are needed - only the for epilogue to method declarations and the method-call postfix parameters and code block are needed. No additional operators are introduced.
The bytecode file format would be enhanced to include attribute sections for code blocks; these need only be indexed by number.

Other Ideas Based On Real Closures

Inner methods! For all those pesky private/private-static methods you have that only ever get called from one method. Inner methods can be referenced directly without looking them up by name, since they cannot be accessed outside of their lexical scope (not even through reflection).
Very cheap threadlocal storage. The lexical scope is guaranteed to be locked to a single thread's stack. This could be taken advantage of... somehow.

What other weird and wonderful stuff can you think of?

Proper resource management

2008-07-28T22:22:00.005-05:00

One of the most common problems that I see users having on the ##java IRC channel is improper resource management. By "resource management", I mean "things that need cleaning up after", such as streams, files, sockets, JDBC statements, etc. The tendency is not so much to ignore the problem, but to use an improper, unsafe, or just unnecessarily complex or ugly approach to solving it.

The problem is basically this. Suppose you open one or more resources, and some intermediate operation the middle of the code block fails. An exception is thrown, and without proper resource management, none of your files/sockets/database statements end up getting closed. This causes the reference to hang around until at least the next GC cycle, which can cause secondary problems like file descriptor exhaustion that are tough to diagnose.

To solve this problem, you don't need fancy closures or automatic resource management blocks. Java has a simple, rock-solid way to completely avoid this issue already built into the language: finally blocks. Proper usage of this mechanism can produce code that is very safe and just as readable and elegant as the more recent "trendy" language proposals.

Consider this (incorrect) example which reads a couple lines from a file:

// Example of INCORRECT code - DO NOT do this
try {
    InputStream is = new FileInputStream("file.txt");
    Reader r = new InputStreamReader(is);
    BufferedReader br = new BufferedReader(r);
    System.out.println("The first line is " + br.readLine());
    System.out.println("The second line is " + br.readLine());
    br.close();
    r.close();
    is.close();
} catch (IOException ex) {
    // it failed :(
    ex.printStackTrace();
}

It works perfectly as long as nothing fails. Of course if anything at all throws an exception in that block, then you may leak one or more resources (since the close() methods may not all be reached). There are many naive solutions to the problem, like this one that illustrates a couple different common errors:

// INCORRECT solution - DO NOT do this
InputStream is = null;
Reader r = null;
BufferedReader br = null;
try {
    is = new FileInputStream("file.txt");
    r = new InputStreamReader(is);
    br = new BufferedReader(r);
    System.out.println("The first line is " + br.readLine());
    System.out.println("The second line is " + br.readLine());
} finally {
    is.close();
    r.close();
    br.close();
}

The first problem is simply that the values of is, r, and br are not checked for null. The solution here could simply be to check for null before calling close.

The second problem is that any of those three close statements can also throw an exception; this causes two additional problems: throwing an exception from a finally block will obscure any earlier exception, and if an earlier close fails, the later one will never be called. Solve this one by giving each close its own little try/catch block.

And the third (and maybe most subtle) problem is that even if you solved the prior two issues you miss one important thing. With many resources, you cannot consider an operation to be a success unless the close is also successful. And in general it is a good idea to always assume this is the case, and take advantage of the idempotency of the close operation (in other words, you can safely call it more than once without any additional effects beyond the first call). The solution here is to put a call to close for each resource inside the try block as well, so that exceptions are propagated but resources are also cleaned up.

So implementing these suggestions might leave us with something like this monstrosity:

// Safe but very ugly example - I recommend against it
InputStream is = null;
Reader r = null;
BufferedReader br = null;
try {
    is = new FileInputStream("file.txt");
    r = new InputStreamReader(is);
    br = new BufferedReader(r);
    System.out.println("The first line is " + br.readLine());
    System.out.println("The second line is " + br.readLine());
    br.close();
    r.close();
    is.close();
} catch (IOException e) {
    e.printStackTrace();
} finally {
    if (is != null) try {
        is.close();
    } catch (IOException e) {
        e.printStackTrace();
    }
    if (r != null) try {
        r.close();
    } catch (IOException e) {
        e.printStackTrace();
    }
    if (br != null) try {
        br.close();
    } catch (IOException e) {
        e.printStackTrace();
    }
}

That's 30 lines of code to read and print two lines from a file - yuck! There is in fact a more elegant way to solve this problem. The first step is to restructure the code with separate try/finally blocks for each resource:

// Safe, but really just as ugly...
try {
    final InputStream is = new FileInputStream("file.txt");
    try {
        final Reader r = new InputStreamReader(is);
        try {
            final BufferedReader br = new BufferedReader(r);
            try {
                System.out.println("The first line is " + br.readLine());
                System.out.println("The second line is " + br.readLine());
                br.close();
                r.close();
                is.close();
            } finally {
                try {
                    br.close();
                } catch (IOException e) {
                    e.printStackTrace();
                }
            }
        } finally {
            try {
                r.close();
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    } finally {
        try {
            is.close();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
} catch (IOException e) {
    // failure
    e.printStackTrace();
}

Notice two things - first, I've switched to final variables to hold the resource. This really underlines the point that we do not need a null check anymore for each resource. That's one problem solved. Second, there's more of a structure to the resource management that emphasizes their lexical scoping. But look how huge it is - we're actually doing worse by about 7 lines!

The final enhancement is the addition of a static method to safely clean up a resource. It looks like this:

// put this anywhere you like in your common code.
public static void safeClose(Closeable c) {
    try {
        c.close();
    } catch (Throwable t) {
        // Resource close failed!  There's only one thing we can do:
        // Log the exception using your favorite logging framework
        t.printStackTrace();
    }
}

Now our code can be changed to look like this:

// Now this is more like it - readable and foolproof!
try {
    final InputStream is = new FileInputStream("file.txt");
    try {
        final Reader r = new InputStreamReader(is);
        try {
            final BufferedReader br = new BufferedReader(r);
            try {
                System.out.println("The first line is " + br.readLine());
                System.out.println("The second line is " + br.readLine());
                br.close();
                r.close();
                is.close();
            } finally {
                safeClose(br);
            }
        } finally {
            safeClose(r);
        }
    } finally {
        safeClose(is);
    }
} catch (IOException e) {
    // failure
    e.printStackTrace();
}

All of the original problems are solved, and in addition it is a lot easier to see what is going on in terms of resource cleanup. This is by no means the only solution to the problem, and certainly not the shortest, but I believe it is the cleanest and safest (in terms of human error).

The same kind of thing can be applied to JDBC handles (just write a safeClose() method for connections and statements) or just about anything else that needs cleaning up after.

XNIO 1.0.0.GA Released

2008-07-21T20:29:00.003-05:00

The first GA release of XNIO is now available. There is only one substantial fix in this release. The standalone API did not present a way to close ChannelSource and Connector instances that were created via an Xnio instance. This has been fixed, and I think the wait has been long enough.

Find the release at the downloads page of the XNIO project website. Also check out the online documentation.

XNIO 1.0.0.CR3 Released

2008-07-07T19:50:00.005-05:00

Well, I lied. I've found a couple more minor API issues which I've fixed for CR3 - a misspelling in a method name ("interruptible", not "interruptable"), a typo which prevented junit from being downloaded, one interface rename ("Client" becomes "ChannelSource"), and a few other minor fixes are included in this release. I think this one will become GA unless I find a glaring bug in the next week or so.

Once again, the release is available at the downloads page of the XNIO project website.

Release Notes - XNIO - Version 1.0.0.CR3

Bug

[XNIO-27] - "Interruptibly" is misspelled
[XNIO-28] - Streams classes do not belong in XNIO
[XNIO-30] - Build fails due to incorrect license name for junit
[XNIO-31] - Logging methods might throw exceptions

Task

[XNIO-14] - Use a service locator pattern to locate XNIO providers in the standalone API
[XNIO-29] - Rename org.jboss.xnio.Client to "ChannelSource"

A modified approach to asynchronous reads

2008-06-30T18:30:00.008-05:00

In a previous post, I talked about the impracticality of asynchronous reads in a scalable server situation. The problem I cited was that if there are large amounts of pending reads, each with its own preallocated buffer, a large quantity of resources can possibly be consumed, thus impeding scalability.

I've been thinking about the problem some more and I've come up with an alternate approach. Basically, the solution to the problem is to simply not allocate a buffer until the read takes place. This is made pretty simple by use of the BufferAllocator interface in XNIO.

Using this interface, the signature of the asynchronous read method would look like this:


IoFuture<ByteBuffer> asyncRead(BufferAllocator<ByteBuffer> allocator) throws IOException;

The buffer is allocated only when the channel is readable. And if an NIO.2-style (or similar) async read is used "under the covers" for whatever reason, then the allocation can simply happen right upfront.

Look for this feature in XNIO 1.1!

XNIO 1.0.0.CR2 Released

2008-06-23T19:55:00.009-05:00

This new version fixes several problems in CR1 and is closer to a final product now. I do not anticipate any further API changes, so this version is safe to develop against in anticipation for the final GA release (which I have marked for July 28 - not too far in the future, but hopefully far enough that any remaining bugs will be found and flushed out).

For those new to XNIO, it is a replacement for NIO that vastly simplifies the handling of non-blocking I/O. To quote my tag line from last time: XNIO gives you the full power of NIO channels while eliminating the headache of thread and Selector management.

The release is available at the downloads page of the XNIO project.

Release Notes - XNIO - Version 1.0.0.CR2

Bug

[XNIO-20] - Channel options support is incomplete
[XNIO-22] - No way to shut down server connections
[XNIO-23] - An exception in handleOpened should always close the connection
[XNIO-25] - Standalone API isn't locking properly

Feature Request

[XNIO-21] - Samples directory with a few simple examples

Task

[XNIO-18] - License files and file headers
[XNIO-26] - Options should be changed to typesafe constants

XNIO 1.0.0.CR1 Released

2008-06-11T12:10:00.002-05:00

I've released XNIO 1.0.0.CR1. XNIO is a replacement for NIO that vastly simplifies the handling of non-blocking I/O. XNIO gives you the full power of NIO channels while eliminating the headache of thread and Selector management. Also, it is dramatically simpler to implement an XNIO provider than it is to implement an NIO provider - opening the door to APR or other native implementations as well as non-network transport types such as serial ports, and platform-specific types like UNIX domain sockets.

The release is available from the XNIO project page.

A Closer Look at JSR-308

2008-05-22T20:58:00.005-05:00

If you haven't heard of JSR-308, take a few minutes to read the specification and familiarize yourself with it. This JSR is designed "permit annotations to appear in more places than Java 6 permits".

A number of blogs have popped up with negative reactions to this JSR, like this one and this one, recently featured on TSS. While I agree with the given opinions in many ways, it is unfortunate that there is not a great deal of technical depth or logical reasoning given in these posts (mostly it's statements to the effect of "makes Java too complex"), so I'd like to take this opportunity to explain in detail exactly why this JSR, as it stands right now, is bad for Java and its community, by citing specific examples.

I think the best place to start is to look at section B.2 of the working draft of JSR-308, which is the section that outlines the proposed uses for annotations on types. The justification for any change to Java (or to any language really) should be rooted in a valid use case, and many use cases are given in this section. Here's why few, if any, of the given use cases are valid justification for the changes outlined in this JSR.

Generics and arrays

There are multiple use cases given for applying type annotations to arrays and generic collections. Here's the very first one given:

The Titanium ... dialect of Java requires the ability to place the local annotation (indicating that a memory reference in a parallel system refers to data on the same processor) on various levels of an array, not just at the top level.

Fine, fine. Titanium sounds lovely. But, we're talking about Java here. You are implying that there is a need for such an annotation within Java itself. But how would Java ever be able to effectively make use of such an annotation, without substantial changes to the compiler and/or VM? Java solves concurrent problems quite well as it stands right now, especially since the introduction of the "java.util.concurrent" package in JDK5, and there is a very active sub-community, populated with some very smart people, focused around further improving concurrency in Java by expanding upon the proven model that exists now.

It's fine to explore other concurrency models, but in my opinion it would be a disservice to the Java community to do this in Java itself. How about providing a special-purpose language on top of the JVM for this? I've heard good things about Scala, for example.

There is no need or justification to re-solve a problem that has already been solved in a way that has been proven to be very effective. Therefore I believe this use case to be wholly invalid.

In a dependent type system [...], one wishes to specify the dimensions of an array type, such as Object[@Length(3)][@Length(10)] for a 3×10 array.

Java does not have a dependent type system as described here. So... how is this a valid use case? Are you proposing that Java's type system be changed? Are you sure you want to open that can of worms? What problem are you trying to solve here? The traditional way to enforce strict bounds on an array as proposed here is to wrap the array manipulation operations in a class. Compared to using annotations, using a wrapper class is potentially much easier to read, and I for one would certainly rather explain arrays as they exist today, rather than explain arrays plus all the annotations you can stick to them, and what they mean, to a clueless newbie.

An immutability type system [...] needs to be able to specify which levels of an array may be modified. Consider specifying a procedure that inverts a matrix in place.

See my previous point, because it applies equally well here. An array is not a matrix. I know lots of traditional computer scientists would love it if they were, but they simply are not - if you want a matrix, make a Matrix class and enforce your policy there. This is a solution that has served us well until now; there is no reason to reinvent this, especially at this late stage.

An ownership domain system [...] uses array annotations to indicate properties of array parameters, similarly to type parameters.

I took a few minutes and read through the paper referenced by this point, and I found that they demonstrate an implementation that is compatible with Java 5 annotations as they stand. The section (6.2) in which they expound upon the limitations of Java 5 annotations that they ran into, does not seem to mention any deficiencies that are solved by this JSR. So this one is a bit of a question mark for me.

The ability to specify the nullness of the array and its elements separately is so important that JML [...] includes special syntax \nonnullelements(a) for an array a with non-null elements.

In a type system for preventing null pointer errors, using a default of non-null, and explicitly annotating references that may be null, results in the fewest annotations and least user burden [...]. Array elements can often be null (both due to initialization, and for other reasons), necessitating annotations on them.

This is referring to JML and the principle of design by contract. And many will agree (myself included) that it is an interesting idea - you statically define your contract in great detail along side your method declarations or definitions, and users of that interface can perform extensive validation to verify that they conform to that contract at compile time.

But: does DBC belong in Java itself? In my opinion, no: it represents a fundamental change to the way that APIs are specified in Java. If JML-style constraints were introduced in to Java itself, you'd be taking away the language we know as Java, and replacing it with a new language. While I'm not against design by contract by any stretch of the imagination, I think that a DBC-based language is best implemented as a new language altogether.

That said, the specific use case given by these two points - a null and/or non-null annotation - is something that can be quite useful, and in fact can be comprehensively implemented using the annotation system that has existed since JDK5. In fact I'd love to see it - but the (major) caveat is that in order to be truly useful, pretty much the entire JDK would have to be retroactively annotated. There is a bit more to be said about this type of annotation in a moment.

I do NOT believe that it is worthwhile to extend this type of annotation to arrays. Arrays have always been and will always be a special case in Java. In my opinion, the rules for arrays are weird/different enough from a "regular" object that they're best left as is - they solve a relatively narrow problem domain quite well enough. Expanding the scope of arrays introduces more risk and/or complexity than benefit (again, my opinion).

Receivers

This is a weird one. The basic premise is that on a (non-static) method, in addition to your regular method parameters, you should be able to put an annotation on "this", because it's kinda-sorta a formal parameter. Sorta.

The problem is that no, it's not a formal parameter at all. You can't, for example, modify the actual "this" reference in your method. In fact the one single example that is given is a "@Readonly" annotation that applies to the method receiver, which means that the given method doesn't modify its receiver. This is of course ludicrous, because you can't modify "this". You can certainly dereference it, which is I guess (?) what they're getting at. However there is no reason why this is cannot a method-level annotation which basically means "this method does not mutate the object state".

By the way, on more than one occasion, the JSR implies that annotations on a method are associated with the method's return value. While true in some cases, this is absolutely untrue in general. Many, many annotation-based tools and frameworks use method-level annotations to indicate the method itself. And very seldom (in fact, never in my experience) is there confusion about whether an annotation applies to the method or the method's return value.

So I don't consider this use case valid at all.

Casts

This section, especially in combination with the null/not-null example, very much demonstrates a couple of key issues I have with this JSR.

The thing that really gets me about the whole nullability example is that this is a concept that does not even apply to types. Nope, not even a little. Nullability is relevant to variables (local variables, fields, parameters) and values (null is obviously always null; constants and many other types of expressions, like object construction, are safe to call non-null); but not types. It is a constraint on the value space of a variable which is completely orthogonal to the type system.

Let me give you an example. Pretend that we've got an annotation called "@NotNull", which can be applied to local variables, fields, methods (referring to the return value of the method), and method parameters. This is a horribly contrived snippet of a method that uses the hypothetical "@NotNull" annotation in various ways:


  ...
  Object bar = somePlainOldMethod();
  // Permissible because the JVM can prove that foo is not null
  @NotNull Object foo = new Object();
  // At this point, foo (the variable) may NOT contain null
  // So, this would be a compile-time error
  foo = null;
  // As would this (bar might be null)
  foo = bar;
  // Now it gets interesting:
  if (bar != null) {
      // Hmm, the compiler can easily prove that bar cannot be null here!
      // That makes this line a-ok - and without a big dumb (@NonNull Object) cast!
      foo = bar;
  }

Notice the inference in the "if" statement. Wouldn't it be nice if Java were always that smart? Do you see now how the nullness of a variable has no relation to its type? The variable "bar" was nullable, then provably non-null, then nullable again. The JSR adds this kind of inference as merely an optional footnote, preferring that you use the cast syntax instead.

Oh, and note that all this can be done with annotations as they exist today.

Type tests

OK, this one is even stranger. The idea is that an "instanceof" test becomes dual purpose. On the one hand, it's a runtime check of variable type. But it also becomes a compile-time annoyance generation mechanism. How so? It basically adds a useless constraint - you must specify all your local variable annotations in your "instanceof", or get a compile error. If you do so, you're rewarded with - wait for it - zero additional functionality; you're right where you started.

Plus, this opens the door to newbie programming errors like this (quoted directly from the actual working draft):


if (x instanceof @A1 T) { ... }
else if (x instanceof @A2 T) { ... }

Think about what that means. The second "if" is never true, because the annotation is evaluated at compile-time, while the "instanceof" is evaluated at runtime!

This change is not only useless and annoying, but it seems to bear little or no relationship to the other proposed use cases. It's a solution looking for a problem.

Summary

There are a few other smaller sections but there are really no other concrete examples worth commenting additionally on, so I'll leave the rest as an exercise for the reader.

This is how I see it. This JSR will add a much higher level of complexity to a language that has already greatly increased in complexity in the past few years. You are changing a language that many people use to a language that, in my opinion, many fewer people will use, because of the increased learning curve and large increase in complexity for what I see as very minimal gain. Many (including myself) feel that this JSR is crossing a threshold, beyond the so-called point of diminishing returns.

Many of the problems which this JSR intends to solve are important and relevant to those who have identified them. But you can't (and shouldn't) solve every problem in Java, and it is my belief that you will find that most of the problems which this JSR was introduced to solve are not important to most Java users.

One of Java's strengths is that it is a language that compiles to a portable bytecode. How about taking some of these ideas and applying them to new languages that target the JVM?

AIO versus network servers

2008-05-22T15:38:00.004-05:00

For those who aren't aware, the AIO read idiom works something like this pseudocode:


buffer = allocate_buffer();
future = aio_channel.read(buffer); // read takes place in the background; this call does not block
future.set_completion_handler(handler);
return;

And later on in handler:


void handler(Buffer buffer) {
 ... decode the received buffer ...
}

Why is this not right for high-connection-count network servers? Imagine your buffer size is 1K. Imagine you've got 10k concurrent connections. You need a buffer to be allocated before you can kick off an async read. That's an initial 10 megabytes in idle buffers, not to mention a *minimum* of 10k buffer allocations - even if the connection is never used or the channel never becomes readable.

This problem is similar to the problem that Jean-Francois Arcand is referring to in his NIO Tips & Tricks blog.

For this reason, I still believe that multiplexing/testing for readiness is still the best approach in terms of scalability. And multiplexing for socket channels obviates the need for AIO: if a channel is readable, then a read() will by definition not block (the data is already in the receive buffer). Therefore AIO is not useful for waiting for a socket to become ready for reading.

Writing is a different story. When you want to write to a socket channel, to minimize latency generally your write data is assembled in a buffer, and then write is invoked. In the worst case, with regular non-blocking IO, the write returns a 0 (in POSIX-ish C it would be an EAGAIN result) indicating that the write would have blocked (that is, the kernel write buffer has no space available, so no data can be sent right now). With non-blocking I/O, what you do at this point is register for writable events, and your handler gets notified when the channel is writable. At this stage you retry your write.

Note that even now, your entire buffer might not be written, especially if you're using a stream socket type such as TCP. The reason is that your buffer might still be larger than the kernel's send buffer. So in this case, you reregister your handler to be notified on writes again, repeating until your entire buffer was sent.

This is a lot of boilerplate for something that's fairly common. In this case, it's far easier to assemble your buffer, kick off an async write, and call it a day. You'll get a notification when your write is complete, without monkeying around with registering and re-registering your handler.

Date and Time in Java 5 & 6

2008-04-21T11:44:00.000-05:00

For those of you who aren't aware, JSR-310 is devoted to developing a (much-needed) new and improved replacement date and time API for Java. Since the spec lead, Stephen Colebourne (who is the author of the excellent JODA date and time library), has made the wise decision to make the process public for the JSR, you can read (and join) the discussions taking place around this effort.

One discussion I'd like to highlight is a bit of talk over the last few days regarding the final package in which the date and time API will finally reside. Currently the API is set to end up in the "javax.date" package. This should allow us (from a legal perspective) to be able to provide the date and time implementation as a standalone library. Great news for folks who, for whatever reason, are not going to be able to upgrade to Java 7 (which is the target for this JSR) the day it comes out. This would allow that (sizeable) population to use the new API in their existing systems.

Also, have a look at the latest API javadoc for a taste of what the API looks like currently.

Remoting 3.0.0-M2 Released

2008-04-21T10:04:00.000-05:00

Remoting 3.0.0-M2 is released. I've got the jars uploaded in a ZIP file, but you'll want to check out the project and look in the "samples/" for samples of using the standalone API. The Microcontainer integration is scheduled for M3, so standalone is pretty much all that you can really play with at the moment. Report bugs in JIRA as "found in: 3.0.0-M2" and "fix for: 3.0.0-M3" to make sure I see them.

The version "M2" means "Milestone 2". The API is more or less stable, but until the first Beta release it is possible that the API (and the basic protocols) will change in an incompatible way. I do, however, encourage you to download and play around with it.

You can download the JARs here, and as always the sources are available via anonymous SVN (and committer SVN).