Moving!

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

Safely downgrading a write lock with ReadWriteLock

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

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

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?

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

1. 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
   
2. Support a per-module access control level, in the Java language and JVM
   
3. Provide a way to specify what other modules are required/optional, and whether they are imported or imported and exported (in other words, "metadata")
4. 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

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

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.