Software Engineer at Red Hat, Inc.
In our JBoss MSC project, it has become necessary to introduce a multiple-readers/single-writer style of lock, however the JDK’s ReadWriteLock APIs are too heavy for the job. Our solution is to implement such a thing using only an int field and synchronization.
Java 9 is diverging from Java 8 in more and more ways - including changes which are not strictly compatible (in contrast to previous major version transitions). Recognition of this reality has lead to the development of JEP 238: Multi-Release JAR Files, which allows some or all of a JAR file to utilize overlays on newer JDK versions. However, as of the date of this publication, Maven does not yet have an official solution for this problem. Some complex approaches have been tried, including using the assembly plugin with submodules, but as of yet I have found no simple approach described. Thus I have come up with an approach of my own.
Yup, I’ve moved again. Old posts and comments should be imported pretty soon.
I’ve been spending really a lot of time over the last 18 months or so trying to come up with some kind of sane, interoperable, and performant way to provide a uniform WildFly security layer that allows the many features that have been requested of us (remote authentication, authorization propagation, etc.). Over this slow road to madness, I’ve come to realize that we’re at the mercy of a truly awful piece of technology: JAAS. And there’s no escape from it, for you or me.
In a somewhat recent discussion on the jigsaw-dev mailing list, the issue of circular dependencies during compile time versus run time came up again (previously discussed way back in March 2012) without apparent resolution. At run time, systems like JBoss Modules can take advantage of the JDK’s lazy class loading behavior in order to lazily link modules, even circularly, as required to link module classes. Introducing support for circular runtime dependencies was relatively simple using a multi-phase resolution strategy. This is (uncoincidentally) very similar, in fact, to the mechanism (and reasoning behind the mechanism) of JDK class loaders themselves. However, things become uglier at compile time. The compiler must have a complete picture: any symbol referenced from any source file must be defined in either a class file on the class path or another source file, otherwise the compiler can’t tell if your Foo.Bar is a field on class Foo or a nested class called Bar inside of Foo or a top-level class Bar in a package named Foo. But what do you do when you have two modules that have requirements on one another? The current javax.tools API only has a notion of a single source and target, hence the March 2012 discussion. If you want to compile two interdependent modules today, you can either build them as one (which, if you’re using Maven like 90% of the world, results in one JAR unless you do some trickery) or you hack javax.tools with some scheme to map the class files to their proper output directories - in both cases building the two modules at the same time.
It sounds like a simple problem: if I want JBoss Modules to choose a directory to read a Java native (JNI) library from, such that each platform (which is comprised of OS, CPU architecture, and ABI variations) gets a separate directory, I should just be able to probe a system property and thus know right where to go, right? Wrong. Until Java 8, the JDK only defines “os.arch” and “os.name” to go on; and these names are far from uniform or standardized. CPU names for equivalent architectures can vary (e.g. “x86_64” versus”AMD64”); CPUs may evolve linearly (e.g. “i586” becomes “i686”) or non-linearly (e.g. ARM instruction set offshoots and extended instruction sets like Wireless MMX). In the end you might be able to load, say, a linux-i386 native library on linux-i686, or linux-armv6 on linux-armv7a. And detecting ABI variation is (at least until Java 8) a black art. In the end I’ve wound up with this monstrosity. Without a doubt, I will have to fiddle with it as more weird variations are reported. (By the way, if you discover more weird variations, please reportthem!)
Yes, I have once again found a new home for this tripe. Enjoy!
A simple pattern to downgrade a write lock to a read lock safely:
Why is it so difficult to write a modularity specification for Java? The requirements appear to be relatively simple:
Today I ran across a problem that I’ve hit frequently in the past, this time while designing an extension to JBoss Marshallingwhich 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).
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.
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.
Truly pluggable locking strategies:
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?
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.
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.
If you haven’t heard of JSR-308, take a few minutes to read the specificationand familiarize yourself with it. This JSR is designed “permit annotations to appear in more places than Java 6 permits”.
For those who aren’t aware, the AIO read idiom works something like this pseudocode:
For those of you who aren’t aware, JSR-310is 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.