Cleanly starting apps on Java 9 and earlier

[Mark Thomas]

On 01/07/17 10:53, Alan Bateman wrote:
> On 01/07/2017 10:18, Mark Thomas wrote:
>> Hi,
>>
>> Apache Tomcat needs to add the following options when running on Java 9:
>>
>> --add-modules=java.se.ee
>> --add-opens=java.base/java.lang=ALL-UNNAMED
>> --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
>>
>> The first is because it depends on javax.xml.ws.WebServiceRef and
>> javax.xml.ws.WebServiceRefs.
>> We could work around this by shipping our own implementations but that
>> sort of duplication should not be necessary.
> The java.xml.ws module is deprecated for removal (along with the other
> modules shared with Java EE) so expect these modules to not be included
> in the JDK some day (exactly when is TBD as it depends on when Java SE
> drops them).
> 
> In the short term then `--add-modules java.se.ee` will resolve the EE
> modules included in the JDK but it may bring complications, it all
> depends on whether you have the EE java.transaction module or JAR files
> with annotations in the javax.annotation package in your environment. An
> important page for the JDK 9 docs is a page with instructions and
> deployments options for those using these APIs.

Alan,

Thanks for the info. Tomcat only recently dropped its own implementation
of those classes so the simplest thing to do is reinstate them.

>> The second and third are required by Tomcat's memory leak detection and
>> prevention code. In an ideal world, web applications wouldn't have
>> memory leaks. Unfortunately, the world isn't ideal and the memory leak
>> detection and prevention code has proven immensely valuable over the
>> years.
> Both of these packages are open since jdk-9+175 so the hacks to null
> fields will continue to work.

Yep. Partly I want to avoid the warnings entirely - for some users
start-up warnings are errors that MUST be resolved.

> That said, I thought the issue with TCCL in sun.rmi.transport.GC was
> fixed via JDK-8157570. Have you tested that?

Yes that bug is fixed. The RMI leaks in this case are application bugs,
not JRE bugs. They are typically caused by applications registering
stuff for RMI and then failing to de-register it. Tomcat needs to poke
around in the internals to find out if such a memory leak is present.

>> The problem we have is that Tomcat needs to run on Java 9 though 6. If
>> the above options aren't provided, Java 6 through 8 are fine but on Java
>> 9 at best the users see a bunch of errors and at worst Tomcat won't
>> start. If the above options are included, Java 9 is fine but then Tomcat
>> fails to start on Java 6 though 8.
>>
> The launch script could examine the JAVA_VERSION property in the
> `release` file. Another approach is to set the JDK_JAVA_OPTIONS
> environment variable as that is new 9 and so will be ignored by older
> releases. There is also -XX:+IgnoreUnrecognizedVMOptions to ignore
> unrecognized options.

Excellent. JDK_JAVA_OPTIONS is exactly what I need.

Many thanks for the response.

Kind regards,

Mark