JDK 9 configuration options

[Stephen Felts]

It’s common in enterprise applications to have multiple frameworks running in the same JVM.  For example, and application server might have Spring or Birt used in the application.  There are even cases where part of one application server might be used as a library running in the same JVM as another application server (e.g., for foreign JMS queues).

 

In JDK 8 and earlier, merging two frameworks together into the same JVM meant putting the appropriate jar files in a single classpath.  Some products even add their jar files to the CLASSPATH environment variable transparently.  So although there may be ordering problems, the problem is pretty well understood.

 

In the case of JDK 9, there are a lot of new options related to Jigsaw.  The likely scenario is that frameworks will try to hide these options using the new argument file feature.  There are a number of problems related to doing this.

 

1. Argument files support relative pathnames for things like module path, upgrade path, and patch files.  However, they are relative to the working directory.  You can’t use environment variables.  That means that the argument file needs to be programmatically generated (just unzipping an argument file won’t work).   Supporting path names relative to the containing file is the common practice of many system like ant, gradle, etc.

 

2. With the new argument syntax in JDK 9 build 132, the launcher arguments now match the command line arguments.  That’s a big step in the right direction.  However, duplicates are a fatal error.  So doing 

export _JAVA_OPTIONS=-XX:VMOptionsFile=/mydir/jdk9args
java @/mydir/jdk9args something

fails.  

If one framework needs java.xml.bind and another framework uses the same module, that should just work.  If one needs bind and another needs jdk.rmic, I shouldn’t have to concatenate the two framework argument files together and manually merge the add-modules arguments together.  It seems conceptually simple to add the required lists together in java or javac.  The same is true for other things like exports, module path, upgrade module path, patch module, etc.

Assuming that all legacy usages are fixed, exports, patch module, and upgrade module path go away leaving module path.  Unlike CLASSPATH, there is no equivalent MODULEPATH to get the option off of the command line.

 

In general, it’s not clear how to manage JDK 9 options for multiple frameworks in the same JVM.  At this point, our project has banned the use of all JDK 9 options including module path. 

 

I understand that some of these things were discussed two years ago.  That doesn’t fix the problem that there isn’t a good way to merge options for our customers.  Requiring a customer to cat a bunch of argument files together and then merge them manually isn’t a good solution.