tag:blogger.com,1999:blog-1214048633682585732Fri, 03 Oct 2014 05:54:08 +0000javajbossi/omarshallingremotingriverclosuresjava jdkjsr-277jsr-294jsr-310modularityDavid M. Lloydhttp://dmlloyd.blogspot.com/noreply@blogger.com (David M. Lloyd)Blogger38125tag:blogger.com,1999:blog-1214048633682585732.post-2570803638416055397Fri, 10 Sep 2010 15:48:00 +00002010-09-10T10:48:12.528-05:00Moving!As of today, my blog is officially moving to a new home at&nbsp;<a href="http://in.relation.to/Bloggers/David">in.relation.to</a>.http://dmlloyd.blogspot.com/2010/09/moving.htmlnoreply@blogger.com (David M. Lloyd)tag:blogger.com,1999:blog-1214048633682585732.post-5569054252617157483Tue, 23 Feb 2010 20:45:00 +00002010-02-23T14:52:26.889-06:00javaSafely downgrading a write lock with ReadWriteLockA simple pattern to downgrade a write lock to a read lock safely:<br /><pre> ReadWriteLock rwl = getLock();<br /> Lock lock = rwl.writeLock();<br /> lock.lock();<br /> try {<br /> ... Perform write operation ...<br /> // downgrade lock safely<br /> final Lock readLock = rwl.readLock();<br /> readLock.lock(); // Possible failure #1<br /> try {<br /> lock.unlock(); // Possible failure #2<br /> } finally {<br /> lock = readLock;<br /> }<br /> } finally {<br /> lock.unlock();<br /> }<br /><br /></pre>The reason this works is as follows:<br /><br />1. Anything which fails before possible failure #1 will cause the original lock to unlock, due to the <code>finally</code> block.<br />2. If possible failure #1 occurs, the read lock is never locked, thus the write lock is still unlocked in the outer <code>finally</code> block.<br />3. If possible failure #2 occurs, the now-locked read lock is stashed into <code>lock</code> thanks to the inner <code>finally</code> block, thus the read lock is released in the outer <code>finally</code> block. At this point, no matter what, the write lock is released.<br />4. Any failure after possible failure #2 will cause the outer <code>finally</code> block to release the read lock.<br /><br />The nice thing about this approach is that you can even downgrade the lock inside of a conditional and the structure is not broken.http://dmlloyd.blogspot.com/2010/02/safely-downgrading-write-lock-with.htmlnoreply@blogger.com (David M. Lloyd)0tag:blogger.com,1999:blog-1214048633682585732.post-6539486713462844463Mon, 25 Jan 2010 20:21:00 +00002010-01-25T14:30:08.433-06:00i/ojavajbossXNIO 2.0.2 Bugfix ReleaseA new release of <a href="http://jboss.org/xnio">XNIO</a> is available which fixes several bugs. For more information about XNIO 2.0, see <a href="http://dmlloyd.blogspot.com/2009/11/xnio-200-has-landed.html">this previous post</a>. 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:<br /><ul><li>[<a href="https://jira.jboss.org/jira/browse/XNIO-82">XNIO-82</a>] - Remove jboss-classloading.xml from artifact</li><li>[<a href="https://jira.jboss.org/jira/browse/XNIO-83">XNIO-83</a>] - Getting an option from a string fails due to typo</li><li>[<a href="https://jira.jboss.org/jira/browse/XNIO-84">XNIO-84</a>] - Enable all supported SSL cipher suites if none are explicitly enabled</li><li>[<a href="https://jira.jboss.org/jira/browse/XNIO-85">XNIO-85</a>] - Possible deadlock in SSL negotiation phase</li><li>[<a href="https://jira.jboss.org/jira/browse/XNIO-86">XNIO-86</a>] - CCE produced when casting a null option value</li><li>[<a href="https://jira.jboss.org/jira/browse/XNIO-87">XNIO-87</a>] - XNIO log messages don't preserve the source class/method name</li><li>[<a href="https://jira.jboss.org/jira/browse/XNIO-88">XNIO-88</a>] - Open listener specification is now optional; do not throw NPE if it is not provided</li></ul>The release is available from the <a href="http://jboss.org/xnio/downloads">downloads page</a>.http://dmlloyd.blogspot.com/2010/01/xnio-202-bugfix-release.htmlnoreply@blogger.com (David M. Lloyd)0tag:blogger.com,1999:blog-1214048633682585732.post-1284709991522224541Tue, 05 Jan 2010 20:28:00 +00002010-01-05T14:34:51.381-06:00javajbossmarshallingriverJBoss Marshalling 1.2.0 Released, Website UpgradedSome of you may have noticed that JBoss Marshalling 1.2.0.GA has been present <a href="http://repository.jboss.org/maven2/org/jboss/marshalling/">in the maven repository</a> for some time. Now that <a href="http://www.jboss.org/jbossmarshalling">the website</a> upgrade is complete, I'm happy to announce that it is now available from <a href="http://www.jboss.org/jbossmarshalling/downloads">the downloads page</a> as well.<br /> <br /> 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.<br /> <br /> Other features that JBoss Marshalling provides which are missing from the Java Object*Stream API include:<br /> <div id="proj_checklist"> <ul><li>Pluggable class resolvers, making it easy to customize classloader policy, by implementing a small interface (rather than having to subclass the <code>Object*Stream</code> classes)</li><li>Pluggable object replacement (also without subclassing)</li><li>Pluggable predefined class tables, which can dramatically decrease stream size and serialization time for stream types which frequently use a common set of classes</li><li>Pluggable predefined instance tables, which make it easy to handle remote references</li><li>Pluggable externalizers which may be used to serialize classes which are not <code>Serializable</code>, or for which an alternate strategy is needed</li><li>Customizable stream headers</li><li>Each marshaller instance is highly configurable and tunable to maximize performance based on expected usage patterns</li><li>A generalized API which can support many different protocol implementations, including protocols which do not necessarily provide all the above features</li><li>Inexpensive instance creation, beneficial to applications where many short-lived streams are used</li><li>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</li></ul> </div>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 <a href="http://java.sun.com/javase/6/docs/api/index.html?java/util/ServiceLoader.html">ServiceLoader</a> mechanism, and helper classes to simplify integration with NIO-based applications.http://dmlloyd.blogspot.com/2010/01/jboss-marshalling-120-released-website.htmlnoreply@blogger.com (David M. Lloyd)0tag:blogger.com,1999:blog-1214048633682585732.post-906678225327663361Thu, 10 Dec 2009 03:33:00 +00002009-12-09T22:06:13.518-06:00javajava jdkjsr-277jsr-294modularityJSR 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:<br /><ol><li>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<br /></li><li>Support a per-module access control level, in the Java language and JVM<br /></li><li>Provide a way to specify what other modules are required/optional, and whether they are imported or imported and exported (in other words, "metadata")</li><li>Provide a way to recursively locate, load, register, and link referenced modules in an efficient manner (in other words, "resolution")</li></ol>So what would it take to implement this? Not much from what I can see.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />So what's the deal? Wouldn't this small group of classes (and one small JLS/JVM change) be sufficient to solve the problem?http://dmlloyd.blogspot.com/2009/12/jsr-294277-why-dont-we-have-standard.htmlnoreply@blogger.com (David M. Lloyd)3tag:blogger.com,1999:blog-1214048633682585732.post-4293118891827343888Fri, 04 Dec 2009 18:44:00 +00002009-12-04T12:47:02.272-06:00i/ojavajbossXNIO 2.0.1 Bugfix ReleaseI'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.<br /><br />All users of 2.0.0 are encouraged to update to 2.0.1. The release is available on <a href="http://www.jboss.org/xnio/downloads">the download page</a>.http://dmlloyd.blogspot.com/2009/12/xnio-201-bugfix-release.htmlnoreply@blogger.com (David M. Lloyd)0tag:blogger.com,1999:blog-1214048633682585732.post-8231283575347855972Wed, 25 Nov 2009 22:58:00 +00002009-12-08T10:49:20.359-06:00i/ojavajbossXNIO 2.0.0 has landedXNIO 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:<br /><ul><li>API compatibility with NIO channels and APIs which consume them</li><li>Powerful callback-based API for channel status changes</li><li>Very simple API for data transfer on channels</li><li>Enhanced NIO buffer support, with many convenience methods to make traditionally difficult buffer manipulation tasks easier</li><li>TCP and UDP client and server support</li><li>API support for other socket types (such as UNIX domain sockets)</li><li>The ability to intermix blocking and non-blocking I/O operations freely and easily</li><li>JMX management for all channels</li><li>Powerful <a href="http://docs.jboss.org/xnio/2.0/api/index.html?org/jboss/xnio/IoFuture.html"><code>IoFuture</code></a> interface and support classes simplify asynchronous I/O operation support in XNIO as well as in your application<br /></li></ul>And these new features:<br /><ul><li>SSL channel types for easy SSL support - vastly simpler than the NIO-targeted <a href="http://java.sun.com/javase/6/docs/api/index.html?javax/net/ssl/SSLEngine.html"><code>SSLEngine</code></a> API</li><li>New channel listener interface which makes implementing clients and servers even simpler</li><li>Runtime-switchable event listener registration for easy support of "state pattern"-based protocol implementations</li><li>Support for JMX-managed old-I/O <a href="http://java.sun.com/javase/6/docs/api/index.html?javax/net/SocketFactory.html"><code>SocketFactory</code></a> and <a href="http://java.sun.com/javase/6/docs/api/index.html?javax/net/ServerSocketFactory.html"><code>ServerSocketFactory</code></a> instances to retrofit legacy applications with management capabilities</li><li>Service location API which frees users from a compile-time dependency on an implementation JAR</li><li>A new <a href="http://www.jboss.org/xnio/docs">User Guide</a></li><li>Simplified channel API makes custom channel implementation easy</li><li>Improved generic configuration API via immutable <a href="http://docs.jboss.org/xnio/2.0/api/index.html?org/jboss/xnio/OptionMap.html"><code>OptionMap</code></a> class</li><li>Improved API to allow user applications to easily provide <a href="http://docs.jboss.org/xnio/2.0/api/index.html?org/jboss/xnio/IoFuture.html"><code>IoFuture</code></a> implementations</li><li>Improved zero-copy integration with NIO's <a href="http://java.sun.com/javase/6/docs/api/index.html?java/nio/channels/FileChannel.html"><code>FileChannel</code></a><br /></li><li>And many more...</li></ul>The project page is at <a href="http://www.jboss.org/xnio">http://www.jboss.org/xnio</a>. Download the release from the <a href="http://www.jboss.org/xnio/downloads">download page</a>, or in the <a href="http://repository.jboss.org/maven2">JBoss Maven repository</a> under the <a href="http://repository.jboss.org/maven2/org/jboss/xnio"><code>org.jboss.xnio</code></a> group ID. The documentation, including Javadoc and the user manual, are available on <a href="http://www.jboss.org/xnio/docs">the docs page</a>. Issues can be filed in the project's <a href="https://jira.jboss.org/jira/browse/XNIO">JIRA bug tracker</a>.http://dmlloyd.blogspot.com/2009/11/xnio-200-has-landed.htmlnoreply@blogger.com (David M. Lloyd)0tag:blogger.com,1999:blog-1214048633682585732.post-6028871423199557753Mon, 02 Nov 2009 20:30:00 +00002009-11-02T17:20:05.463-06:00i/ojavajbossXNIO 2.0.0.CR4 ReleasedXNIO 2.0 is getting very close to completion. The latest CR, 2.0.0.CR4, is now available from <a href="http://www.jboss.org/xnio/downloads">the downloads page</a>.<br /><br />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.http://dmlloyd.blogspot.com/2009/11/xnio-200cr4-released.htmlnoreply@blogger.com (David M. Lloyd)0tag:blogger.com,1999:blog-1214048633682585732.post-5547049894569913170Tue, 22 Sep 2009 16:44:00 +00002009-09-22T12:16:12.160-05:00i/ojavajbossmarshallingriverNew XNIO, JBoss Marshalling, and More...Since my last post several months ago, I've been quite busy with a number of project releases.<br /><ul><li>JBoss Marshalling version 1.2.0.CR3 - download <a href="http://jboss.org/jbossmarshalling/downloads/">here</a>, JIRA <a href="https://jira.jboss.org/jira/browse/JBMAR">here</a>. 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.<br /></li><li>XNIO 2.0.0.CR2 - download <a href="http://jboss.org/xnio/downloads/">here</a>, JIRA <a href="https://jira.jboss.org/jira/browse/XNIO">here</a>. Includes an improved API, as well as SSL support, which I think will be quite appreciated by anyone who has ever tried to use <a href="http://java.sun.com/javase/6/docs/api/index.html?javax/net/ssl/SSLEngine.html">SSLEngine</a> with NIO.</li><li>JBoss LogManager 1.1.0.GA - available from the <a href="http://repository.jboss.org/maven2/org/jboss/logmanager/jboss-logmanager/1.1.0.GA/">JBoss Maven Repository</a>. A complete re-implementation of the bug-ridden JDK <a href="http://java.sun.com/javase/6/docs/api/index.html?java/util/logging/LogManager.html">LogManager implementation</a>, with additional handler types (including log4j compatibility), designed specifically to provide a highly efficient and cleanly implemented logging layer for JBossAS.</li><li>JBoss Logging 2.2.0.CR1 - available from the <a href="http://repository.jboss.org/maven2/org/jboss/logging/">JBoss Maven Repository</a>. 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 <a href="http://java.sun.com/javase/6/docs/api/index.html?java/util/Formatter.html">java.util.Formatter</a> class.</li></ul>There are a number of other projects in the works as well, so stay tuned!http://dmlloyd.blogspot.com/2009/09/new-xnio-jboss-marshalling-and-more.htmlnoreply@blogger.com (David M. Lloyd)0tag:blogger.com,1999:blog-1214048633682585732.post-1641620366789550974Wed, 25 Feb 2009 23:48:00 +00002009-02-25T22:48:36.037-06:00java jdkClass-local data<p>Today I ran across a problem that I've hit frequently in the past, this time while designing an extension to <a href="http://www.jboss.org/jbossmarshalling">JBoss Marshalling</a> which allows users to annotate classes which are to be specially externalized. The problem is that one wants to "remember" what <tt>Externalizer</tt> 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 <tt>OutOfMemoryError</tt>, especially if you're frequently loading and unloading classes).<p>The traditional solution to keep a leak-resistant cache is to employ a <tt><a href="http://java.sun.com/javase/6/docs/api/java/util/WeakHashMap.html">WeakHashMap</a></tt> like so (usually in conjunction with some concurrency strategy, like a <tt><a href="http://java.sun.com/javase/6/docs/api/java/util/concurrent/locks/Lock.html">Lock</a></tt>):<pre><br /> private static final Map&lt;Class&lt;?&gt;, Externalizer&gt; cache = new WeakHashMap&lt;Class&lt;?&gt;, Externalizer&gt;();<br /></pre>The <tt>WeakHashMap</tt> retains a weak reference to the key values (in this case, the <tt><a href="http://java.sun.com/javase/6/docs/api/java/lang/Class.html">Class</a></tt> instance), so if no strong references remain, the <tt>Class</tt> is unloaded, and all is well. However, in this particular use case, the <tt>Externalizer</tt> instance very likely will itself hold a strong reference to the <tt>Class</tt>. Why? Because in JBoss Marshalling, <tt>Externalizer</tt> 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 <tt>WeakHashMap</tt> 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.<p>So I got to thinking - what if I could stash my <tt>Externalizer</tt> instance on the <tt>Class</tt> itself? Then I wouldn't even need to keep a cache at all, and the only reference to the <tt>Class</tt> that I could cause to be would be from the <tt>Class</tt> 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 <tt>Class</tt> 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).<p>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:<pre><br /> // The methods are similar to the corresponding methods on Map and ConcurrentMap<br /> public final class ClassLocal&lt;T&gt; {<br /> public T get(Class&lt;?&gt; clazz) { ... }<br /> public T put(Class&lt;?&gt; clazz, T value) { ... }<br /> public boolean hasData(Class&lt;?&gt; clazz) { ... }<br /> public T putIfAbsent(Class&lt;?&gt; clazz, T value) { ... }<br /> public T remove(Class&lt;?&gt; clazz) { ... }<br /> public boolean remove(Class&lt;?&gt; clazz, T oldValue) { ... }<br /> public T replace(Class&lt;?&gt; clazz, T newValue) { ... }<br /> public boolean replace(Class&lt;?&gt; clazz, T oldValue, T newValue) { ... }<br /> }<br /><br /><br /> private final ClassLocal&lt;Externalizer&gt; classLocal = new ClassLocal&lt;Externalizer&gt;();<br /><br /> ...in some method...<br /> Externalizer externalizer = classLocal.get(SomeClass.class);<br /></pre>A <tt>ClassLocal</tt> instance looks and acts a lot like a map, but with one important difference: the data itself is stored on the <tt>Class</tt> instance, not in the <tt>ClassLocal</tt>. Implementation-wise this could be accomplished via a <tt>WeakHashMap</tt> or similar structure on the <tt>Class</tt> itself (with a concurrency strategy) similar to this:<pre><br /> public final class Class&lt;T&gt; {<br /> ...<br /> final Map&lt;ClassLocal&lt;?&gt;, Object&gt; classLocalData = Collections.synchronizedMap(new WeakHashMap&lt;ClassLocal&lt;?&gt;, Object&gt;());<br /> }<br /></pre>...which could then be accessed directly by the <tt>ClassLocal</tt> 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.<p><b>Update:</b> 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 <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6493635">Sun bug (#6493635)</a> about it, as well as articles by such clever folks as <a href="http://crazybob.org/2006/12/caching-class-related-information.html">Crazy Bob</a> and <a href="http://weblogs.java.net/blog/jhook/archive/2006/12/class_metadata.html">Jacob Hookom</a> about this very topic.http://dmlloyd.blogspot.com/2009/02/class-local-data.htmlnoreply@blogger.com (David M. Lloyd)0tag:blogger.com,1999:blog-1214048633682585732.post-2714053744680632513Fri, 06 Feb 2009 20:35:00 +00002009-02-07T08:06:35.353-06:00javajbossmarshallingNew protocols in JBoss MarshallingIt's official... I've checked in the first cut of the Java Serialization from-scratch implementation. <strike>It's not complete yet - it doesn't even pass all the tests</strike> (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 <a href="http://javasymposium.techtarget.com/html/architecture.html?track=NL-476&ad=684048&Offer=JSemtssunsc112h&asrc=EM_UTC_5542644&uid=7850586#DLloydMarsh">my JBoss Marshalling talk at TSSJS</a>). Also in progress is Ron Sigal's JBoss Serialization implementation, which should be in 1.2.0 at the latest.<p>Look for the 1.1.0.GA release the week of February 23rd.http://dmlloyd.blogspot.com/2009/02/new-protocols-in-jboss-marshalling.htmlnoreply@blogger.com (David M. Lloyd)0tag:blogger.com,1999:blog-1214048633682585732.post-7276472392596985586Wed, 14 Jan 2009 00:09:00 +00002009-01-13T19:11:02.301-06:00i/ojavajbossXNIO 1.2.0.GA ReleasedThe final GA release of XNIO 1.2.0 is <a href="http://www.jboss.org/xnio/downloads">available for download</a>. 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:<p><h2>Bugs</h2><ul><li>[<a href='https://jira.jboss.org/jira/browse/XNIO-56'>XNIO-56</a>] - Xnio.create() fails for the default provider</li><li>[<a href='https://jira.jboss.org/jira/browse/XNIO-57'>XNIO-57</a>] - NioSocketChannelImpl suspendWrites method suspends reads instead of writes</li><li>[<a href='https://jira.jboss.org/jira/browse/XNIO-58'>XNIO-58</a>] - NPE bug in AllocatedMessageChannelStreamChannelHandler</li><li>[<a href='https://jira.jboss.org/jira/browse/XNIO-60'>XNIO-60</a>] - NIO: When pooled selectors are exhausted, an exception is thrown</li><li>[<a href='https://jira.jboss.org/jira/browse/XNIO-65'>XNIO-65</a>] - NioPipeTestCase.testOneWayPipeSinkClose fails under Java 5</li><li>[<a href='https://jira.jboss.org/jira/browse/XNIO-67'>XNIO-67</a>] - TCP tests fail under Java 5, not Java 6</li></ul><p><h2>Feature Request</h2><ul><li>[<a href='https://jira.jboss.org/jira/browse/XNIO-19'>XNIO-19</a>] - Add ability to switch a channel between blocking and non-blocking</li><li>[<a href='https://jira.jboss.org/jira/browse/XNIO-50'>XNIO-50</a>] - Mitigate the performance impact of Selector.wakeup()</li><li>[<a href='https://jira.jboss.org/jira/browse/XNIO-54'>XNIO-54</a>] - API for one-time servers</li><li>[<a href='https://jira.jboss.org/jira/browse/XNIO-64'>XNIO-64</a>] - IoFuture notifiers with attachments (<b>see below</b>)</li><li>[<a href='https://jira.jboss.org/jira/browse/XNIO-66'>XNIO-66</a>] - Add static blocking read/write methods to Channels</li></ul><p><h2>Task</h2><ul><li>[<a href='https://jira.jboss.org/jira/browse/XNIO-17'>XNIO-17</a>] - Add monitoring via JMX</li><li>[<a href='https://jira.jboss.org/jira/browse/XNIO-39'>XNIO-39</a>] - Remove deprecated Xnio.createNio() methods</li><li>[<a href='https://jira.jboss.org/jira/browse/XNIO-48'>XNIO-48</a>] - Create a UNIX domain socket API</li><li>[<a href='https://jira.jboss.org/jira/browse/XNIO-64'>XNIO-64</a>] - IoFuture notifiers with attachments</li></ul><p><h2>Links</h2><p>Download: <a href="http://www.jboss.org/xnio/downloads">http://www.jboss.org/xnio/downloads</a><br>Javadoc: <a href="http://docs.jboss.org/xnio/1.2.0.GA/api">http://docs.jboss.org/xnio/1.2.0.GA/api</a><br>Project page: <a href="http://www.jboss.org/xnio">http://www.jboss.org/xnio</a><br>Bug tracker: <a href="https://jira.jboss.org/jira/browse/XNIO">https://jira.jboss.org/jira/browse/XNIO</a><p>Just a reminder that the 1.2.0.GA release is <b>not 100% binary- and source-compatible with 1.1.x</b>, 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 <code>IoFuture</code> attachment feature.http://dmlloyd.blogspot.com/2009/01/xnio-120ga-released.htmlnoreply@blogger.com (David M. Lloyd)2tag:blogger.com,1999:blog-1214048633682585732.post-4714323323280886153Thu, 08 Jan 2009 02:47:00 +00002009-01-07T21:04:24.128-06:00i/ojavajbossXNIO 1.2.0.CR2 ReleasedThe XNIO 1.2.0.CR2 release is up on <a href="http://www.jboss.org/xnio">the project page</a>. 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).<p>The biggest change is the ability to pass an attachment in to an <code>IoFuture</code> instance, via the <a href="http://docs.jboss.org/xnio/1.2.0.CR2/api/org/jboss/xnio/IoFuture.html#addNotifier(org.jboss.xnio.IoFuture.Notifier,%20A)"><code>IoFuture.addNotifier()</code></a> 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 <b>XNIO 1.2.x is not 100% binary- and source-compatible with XNIO 1.1.x</b>. 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.<p>Read the Javadoc <a href="http://docs.jboss.org/xnio/1.2.0.CR2/api">here</a>, download the release <a href="http://www.jboss.org/xnio/downloads/">here</a>, report bugs <a href="http://jira.jboss.org/jira/browse/XNIO">here</a>.http://dmlloyd.blogspot.com/2009/01/xnio-120cr2-released.htmlnoreply@blogger.com (David M. Lloyd)0tag:blogger.com,1999:blog-1214048633682585732.post-8222611585744880005Fri, 19 Dec 2008 03:23:00 +00002008-12-18T21:35:26.493-06:00javajbossremotingRemoting 3.0.0.Beta2 ReleasedThis is the last Beta before the CR (candidate for release) series. As always, the download is available at <a href="http://www.jboss.org/jbossremoting/downloads">the Remoting download page</a>. 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 <a href="http://jira.jboss.com/jira/secure/ReleaseNote.jspa?version=12312965&styleName=Text&projectId=10031&Create=Create">release notes</a> for the full list of differences.<p>The online Javadoc is <a href="http://docs.jboss.org/remoting/3.0.0.Beta2/api/">available here</a>. Also, there are <a href="http://anonsvn.jboss.org/repos/jbossremoting/remoting3/tags/3.0.0.Beta2/samples/src/main/java/org/jboss/remoting/samples/simple/">a few code samples</a> available in the Subversion repository. Please feel free to report bugs in <a href="http://jira.jboss.com/jira/browse/JBREM">the Remoting JIRA bug tracker</a>, making sure to mark the proper version when doing so.http://dmlloyd.blogspot.com/2008/12/remoting-300beta2-released.htmlnoreply@blogger.com (David M. Lloyd)0tag:blogger.com,1999:blog-1214048633682585732.post-3354772759198764660Wed, 17 Dec 2008 00:56:00 +00002008-12-16T19:06:18.819-06:00i/ojavajbossXNIO 1.2.0.CR1 ReleasedXNIO 1.2.0.CR1 is available for download at <a href="http://www.jboss.org/xnio/downloads/">the XNIO project download page</a>, sporting lots of cool new features, like:<ul><li>The ability to switch between blocking and non-blocking modes</li><li>Wrapper Input/OutputStreams for channels</li><li>JMX monitoring</li><li>A restructured API/SPI system</li><li>A one-time server API (for services like IRC DCC and FTP that need to create one-shot server sockets)</li><li>The ability to change a server's bind address(es) after it has been started</li></ul>...not to mention several performance improvements and code and documentation cleanup changes as well. Check out the <a href="http://docs.jboss.org/xnio/1.2.0.CR1/api/">API Javadocs</a> as well. Enjoy!http://dmlloyd.blogspot.com/2008/12/xnio-120cr1-released.htmlnoreply@blogger.com (David M. Lloyd)0tag:blogger.com,1999:blog-1214048633682585732.post-1287628729788908690Fri, 14 Nov 2008 23:07:00 +00002008-11-14T17:57:26.530-06:00javajbossremotingRemoting 3.0.0.Beta1 ReleasedThe download is available at <a href="http://www.jboss.org/jbossremoting/downloads/">the Remoting download page</a>. 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.<p>Javadoc is available online at <a href="http://docs.jboss.org/remoting/3.0.0.Beta1/api/">the docs site</a>; bugs should be reported <a href="https://jira.jboss.org/jira/secure/project/ViewProject.jspa?pid=10031">in the bug tracker</a> (make sure you report the bug in the 3.0.0.Beta1 release). See <a href="http://www.jboss.org/jbossremoting/">the project page</a> for more information.http://dmlloyd.blogspot.com/2008/11/remoting-300beta1-released.htmlnoreply@blogger.com (David M. Lloyd)2tag:blogger.com,1999:blog-1214048633682585732.post-1318971048837975634Fri, 14 Nov 2008 20:20:00 +00002008-11-14T14:30:11.437-06:00javajbossmarshallingremotingriverJBoss Marshalling, River Protocol 1.0.0.GA ReleasedJBoss Marshalling is an alternative serialization API that fixes many of the problems found in the JDK serialization API while remaining fully compatible with <code>java.io.Serializable</code> 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).<p/>This project doesn't yet have an official home, but you can view the <a href="http://docs.jboss.org/river/1.0.0.GA/api/">online API documentation right here</a>, and the project is available for download at <a href="http://repository.jboss.org/jboss/marshalling/1.0.0.GA/lib/">this location within the JBoss repository</a>.http://dmlloyd.blogspot.com/2008/11/jboss-marshalling-river-protocol-100ga.htmlnoreply@blogger.com (David M. Lloyd)0tag:blogger.com,1999:blog-1214048633682585732.post-7217900821442788757Thu, 13 Nov 2008 00:39:00 +00002008-11-12T18:47:01.093-06:00i/ojavajbossXNIO 1.1.1.GA ReleasedThe release available on <a href="http://www.jboss.org/xnio/downloads/">the downloads page</a>. This is a bugfix release; I encourage all users of 1.1.0.GA to upgrade.<p>Here's the list of changes:<ul><br /><li>Fix a problem in the <code>Xnio.create()</code> method's default provider lookup</li><br /><li>Fix a problem where thread interruption could cause a tight spinloop</li><br /><li>Fix a minor problem in the logger init code</li><br /><li>Merge the improved test log formatter from trunk</li><br /></ul><p>Enjoy!http://dmlloyd.blogspot.com/2008/11/xnio-111ga-released.htmlnoreply@blogger.com (David M. Lloyd)1tag:blogger.com,1999:blog-1214048633682585732.post-5165047736222031558Thu, 23 Oct 2008 15:58:00 +00002008-10-23T11:06:00.376-05:00i/ojavajbossBinding to privileged ports with XNIOA 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.<p/>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.http://dmlloyd.blogspot.com/2008/10/binding-to-privileged-ports-with-xnio.htmlnoreply@blogger.com (David M. Lloyd)2tag:blogger.com,1999:blog-1214048633682585732.post-4209399981956928023Fri, 17 Oct 2008 03:43:00 +00002008-12-19T18:54:31.764-06:00javajbossmarshallingremotingriverJBoss Marshalling Framework 1.0.0.Beta2 ReleasedI'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 <a href="/2008/10/jboss-marshalling-framework-100beta1.html">the original Beta1 announcement</a>.<p>Download the JARs from <a href="http://repository.jboss.org/jboss/marshalling/1.0.0.Beta2/">the repository</a>. The documentation is available <a href="http://docs.jboss.org/river/1.0.0.Beta2/api">here at the JBoss docs site</a>. Please report any bugs <a href="https://jira.jboss.org/jira/browse/JBMAR">in the JBoss Marshalling bug tracker</a>.<p>Many thanks to Ron Sigal, author of the Java serializaiton-compatible module, and the one who flushed out <strike>some</strike> <strike>most</strike> all of the bugs from the Beta1 River protocol implementation that were fixed in this version.http://dmlloyd.blogspot.com/2008/10/jboss-marshalling-framework-100beta2.htmlnoreply@blogger.com (David M. Lloyd)0tag:blogger.com,1999:blog-1214048633682585732.post-7161686457740599621Thu, 16 Oct 2008 17:17:00 +00002008-10-16T12:27:35.426-05:00i/ojavajbossMinor XNIO re-org for 1.2.0For 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 <code>Xnio</code> 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 <code>Xnio</code> 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.http://dmlloyd.blogspot.com/2008/10/minor-xnio-re-org-for-120.htmlnoreply@blogger.com (David M. Lloyd)0tag:blogger.com,1999:blog-1214048633682585732.post-2473407533474328380Mon, 13 Oct 2008 18:39:00 +00002008-10-13T13:49:08.797-05:00i/ojavajbossXNIO 1.1.0.GA ReleasedXNIO 1.1.0.GA is available <a href="https://www.jboss.org/xnio/downloads/">on the XNIO downloads page</a>. Not much change since 1.1.0.CR1. Just a Javadoc update, and one interface rename: <code>TcpClient</code> has been renamed to <code>TcpChannelSource</code> (see <a href="https://jira.jboss.org/jira/browse/XNIO-55">XNIO-55</a> for more information). Also see the <a href="http://docs.jboss.org/xnio/1.1.0.GA/api/index.html">online Javadocs</a> for usage information.<p>Have fun!http://dmlloyd.blogspot.com/2008/10/xnio-110ga-released.htmlnoreply@blogger.com (David M. Lloyd)1tag:blogger.com,1999:blog-1214048633682585732.post-1555980646451618939Wed, 08 Oct 2008 13:04:00 +00002008-10-08T09:09:24.223-05:00closuresjavaFeedback about Dave's Dumb ClosuresI've gotten some feedback about <a href="/2008/09/daves-dumb-closures.html">my closure idea</a>. 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.<br /><blockquote><br />Rémi Forax said...<br /><br />You can't get ride of exception transparency, at least if you want to keep checked exceptions.<br /><br />Here is an interresting email from Neal Gafter:<br />http://mail.openjdk.java.net/pipermail/closures-dev/2008-July/000174.html<br /><br />Do you have a way to write StringSwitch with your syntax/semantics ?<br /></blockquote><br />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.<br /><p><br />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.<br /><p><br />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 <code>Map&lt;String,Runnable&gt;</code>, 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.<br /><blockquote><br />Yardena said...<br /><br /> Hi,<br /><br /> 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.<br /><br /> 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).<br /><br /> So to get the record straight - you propose something much less powerful than BGGA, and not equivalent to closures in other languages.<br /></blockquote><br />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.<br /><p><br />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.<br /><blockquote><br />Ricky Clarkson said...<br /><br /> "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."<br /><br /> Your proposal seems not to fit that second part, the delayed execution.<br /> Suppose we're using a closurific wrapper around SwingUtilities.invokeLater:<br /><br /> doLaterClosurely() {<br /> . . some gui stuff;<br /> }<br /><br /> How would your proposal work for this?<br /><br /> It would be handy if you suggested what Java 5 code your examples translate to.<br /></blockquote><br />Since I've answered the former question already, I'll jump right to the end: There <b>is</b> 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).<br /><p><br />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.<br /><p><br />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.<br /><blockquote><br />WarpedJavaGuy said...<br /><br /> Why are new language constructs so often perceived as mutilations? Is changing the semantics of existing keywords and constructs not a mutilation?<br /></blockquote><br />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. <b>This</b> is what I call a "mutilation". You don't get what you pay for when you use BGGA closures.<br /><p><br />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.<br /><p><br />Thanks everyone for your questions - please feel free to send in more.http://dmlloyd.blogspot.com/2008/10/feedback-about-daves-dumb-closures.htmlnoreply@blogger.com (David M. Lloyd)5tag:blogger.com,1999:blog-1214048633682585732.post-5979366311763447409Tue, 07 Oct 2008 15:42:00 +00002008-10-07T10:47:44.163-05:00closuresjavaMore uses for Dave's Dumb ClosuresTruly pluggable locking strategies:<br /><pre><br /> public interface Locker {<br /> void hold() for myBlock();<br /> }<br /><br /> public class SynchLocker {<br /> private final Object lock;<br /> public SynchLocker(Object lock) { this.lock = lock; }<br /> public void hold() for myBlock() {<br /> synchronized (lock) {<br /> myBlock();<br /> }<br /> }<br /> }<br /><br /> public class LockLocker {<br /> private final Lock lock;<br /> public LockLocker(Lock lock) { this.lock = lock; }<br /> public void hold() for myBlock() {<br /> lock.lock();<br /> try {<br /> myBlock();<br /> } finally {<br /> lock.unlock();<br /> }<br /> }<br /> }<br /><br /> ...later...<br /> Locker l = ...take your pick...;<br /> l.hold() {<br /> ...do stuff...<br /> }<br /></pre><br />Let's see you do that efficiently with anonymous inner classes or BGGA.http://dmlloyd.blogspot.com/2008/10/more-uses-for-daves-dumb-closures.htmlnoreply@blogger.com (David M. Lloyd)4tag:blogger.com,1999:blog-1214048633682585732.post-3208700276245880274Tue, 07 Oct 2008 00:46:00 +00002008-10-07T08:50:42.990-05:00javajbossmarshallingremotingriverJBoss Marshalling Framework 1.0.0.Beta1 ReleasedAs 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 <code>Object*Stream</code> classes:<br /><ul><br /><li>Pluggable class resolvers, making it easy to customize classloader policy, by implementing a small interface (rather than having to subclass the <code>Object*Stream</code> classes)</li><br /><li>Pluggable object replacement (also without subclassing)</li><br /><li>Pluggable predefined class tables, which can dramatically decrease stream size and serialization time for stream types which frequently use a common set of classes</li><br /><li>Pluggable predefined instance tables, which make it easy to handle remote references</li><br /><li>Pluggable externalizers which may be used to serialize classes which are not <code>Serializable</code>, or for which an alternate strategy is needed</li><br /><li>Customizable stream headers</li><br /><li>Each marshaller instance is highly configurable and tunable to maximize performance based on expected usage patterns</li><br /><li>A generalized API which can support many different protocol implementations, including protocols which do not necessarily provide all the above features</li><br /><li>Inexpensive instance creation, beneficial to applications where many short-lived streams are used</li><br /><li>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</li><br /></ul><br />The default implementation, known as "River", is also available as a separate JAR.<p>This project does not have a home page, but the binaries have been uploaded to <a href="http://repository.jboss.org/jboss/marshalling/1.0.0.Beta1/lib/">repositry.jboss.org</a> and the Javadocs are available online at <a href="http://docs.jboss.org/river/1.0.0.Beta1/api/">docs.jboss.org</a>. The source code may be found in <a href="http://anonsvn.jboss.org/repos/sandbox/david.lloyd/jboss-marshalling/trunk/">my sandbox repository</a> for now, until it gets a permanent home.<p>Enjoy!http://dmlloyd.blogspot.com/2008/10/jboss-marshalling-framework-100beta1.htmlnoreply@blogger.com (David M. Lloyd)3