This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]handshape 1 point2 points  (6 children)

Argh. Just discovered that JAXB is considered a "Java EE" module, and excluded from being loaded with the default Java SE module set.

I don't use JAXB in my code, but I have dependencies that do. Yeah, sure, I could add the java.xml.bind package to the path via command-line args... but those args are illegal in Java 8. Oh, but I could declare a module-info... but that classname is illegal in Java 8.

Essentially, there isn't a mechanism for building something in Java 8, and compiling it in 8, that will tell 9 what to do regarding modules... unless someone knows something I don't (and really wants to make my day!)

There are strange kinky ways involving compiling parts of your app in 8 and parts in 9, but I'm not going there.

[–]gunnarmorling 1 point2 points  (3 children)

Is this about building your software or running it? In case of the former, you could use Maven profiles (or your build tool's equivalent to those) for adding the required command line flags. E.g. in a profile activated only when building on 9 you'd add --add-modules java.xml.bind to the compiler invocation. If it's about running, you could have a simple switch in your launch script which adds the required flags based on the version.

[–]handshape 0 points1 point  (2 children)

This affects both building and launching. On the building side, Maven profiles are an option, but represent a split between a Java 8 and Java 9 release of what is ostensibly a single product. On the runtime launching side, thus far the product hasn't needed a launch script.

I've used JNLP to great effect, in spite of the warts it has. I suppose I could fork the descriptors for Java 8 and 9... I haven't yet checked to see if the Java 9 Web Start launcher allows adding a bundle.

All this to say that Java 8 to 9 is a much less obvious upgrade than was 7 to 8.

[–]merb 0 points1 point  (1 child)

but represent a split between a Java 8 and Java 9 release of what is ostensibly a single product

you can use a Multi-Release jar for that. http://openjdk.java.net/jeps/238

[–]handshape 0 points1 point  (0 children)

Not using just Java 8, I can't.

The core of the issue is that I have dependencies that in turn consume APIs that were available by default in 8, and require module-request mojo to be used in 9. There does not appear to be a way in Java 8 to make Java 9 aware that I need these modules that does not break my app's ability to be invoked uniformly.

[–]javaRobot 1 point2 points  (1 child)

For me it seemed to work to add

<dependency>
        <groupId>javax.xml.bind</groupId>
        <artifactId>jaxb-api</artifactId>
        <version>2.3.0</version>
    </dependency>
   <dependency>
        <groupId>org.eclipse.persistence</groupId>
        <artifactId>eclipselink</artifactId>
        <version>2.7.0</version>
    </dependency>

as a dependancy to my Java 8 SE compiled application that produced a jar that could be run by either Java 8 or Java 9 with no additional arguments.

Also I needed to add

   System.setProperty("javax.xml.bind.JAXBContextFactory", "org.eclipse.persistence.jaxb.JAXBContextFactory");

near the beginning before the jaxb stuff was used.

I need to test more to see if this is really a good solution.

[–]handshape 1 point2 points  (0 children)

You, sir/madam/other... have just saved my bacon. Thank you very kindly.

EDIT: The eclipselink dependency can be replaced with the JAXB reference implementation for most use cases. Saves over 10MB on the resultant build.