Cleanly starting apps on Java 9 and earlier

[Mark Thomas]

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

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.

What is the recommended approach for applications that need to use one
or more of the options above and need to start cleanly on multiple Java
versions including 9 and earlier using a single, common start-up script?

To date, Tomcat has always been Java version agnostic as long as at
least the minimum Java version as specified by the Java EE spec has been
used. We really don't want to have to change that.

Suggestions welcome.

Mark

[Alan Bateman]

Post by Mark Thomas
Hi,
--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.

Post by Mark Thomas
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?

Post by Mark Thomas
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

[Enrico Olivelli]

Post by Alan Bateman

Post by Mark Thomas
Hi,
--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,
Can you give some poonters to this page?
Thank you

Enrico Olivelli

Post by Alan Bateman

Post by Mark Thomas
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?

Post by Mark Thomas
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

[Alan Bateman]

Post by Enrico Olivelli
Alan,
Can you give some poonters to this page?
Thank you

There isn't a page to point at yet, mostly we are waiting for
javaee.github.io to be updated to list stable Maven coordinates or
download links for each of the standalone technologies.

-Alan.

[Stephen Felts]

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-***@openjdk.java.net
Subject: Re: Cleanly starting apps on Java 9 and earlier

Post by Mark Thomas
Hi,
--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.

Post by Mark Thomas
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?

Post by Mark Thomas
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

[Mark Thomas]

Post by Stephen Felts
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.

Thanks for the tip.

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

Good to know. I was leaning towards JDK_JAVA_OPTIONS anyway. This point
confirms that choice.

Post by Stephen Felts
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).

Tomcat won't officially support Java 9 until there is a GA release.
Anything before then is on the basis that is should work, but it might not.

Thanks again for the additional info.

Mark

Post by Stephen Felts
-----Original Message-----
From: Alan Bateman
Sent: Saturday, July 1, 2017 5:53 AM
Subject: Re: Cleanly starting apps on Java 9 and earlier

Post by Mark Thomas
Hi,
--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.

Post by Mark Thomas
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?

Post by Mark Thomas
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

[Mark Thomas]

Post by Alan Bateman

Post by Mark Thomas
Hi,
--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.

Post by Alan Bateman

Post by Mark Thomas
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.

Post by Alan Bateman
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.

Post by Alan Bateman

Post by Mark Thomas
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