IMO:

1. You should avoid `--add-modules java.se.ee' unless you need all of those 
modules.  You should bring in only those modules that you need.  The choices 
are java.activation, java.corba, java.transaction, java.xml.bind, java.xml.ws, 
java.xml.ws.annotation.  So use --add-modules java.xml.ws.

2. You can't use -XX:+IgnoreUnrecognizedVMOptions as a general solution because 
that isn't available in JDK6 JRockit for example.

3. Setting JDK_JAVA_OPTIONS is good because only JDK9 recognizes it and it is 
inherited by all nested invocations (unless there is an exec that excludes the 
environment).  You might want to use
export JDK_JAVA_OPTIONS="-XX:+IgnoreUnrecognizedVMOptions --add-modules 
java.xml.ws"

4. --add-opens is not needed starting in b175 so require that as a base.  It 
will still be noisy (a 3-line WARNING will be printed to the standard error).


-----Original Message-----
From: Alan Bateman 
Sent: Saturday, July 1, 2017 5:53 AM
To: Mark Thomas; jigsaw-dev@openjdk.java.net
Subject: Re: Cleanly starting apps on Java 9 and earlier

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.


>
> 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.

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


> 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.

-Alan

Reply via email to