Mark,
On 1/10/22 11:46, Mark Thomas wrote:
I thought it would be a good idea to start a new thread for this.
The previous discussion started here:
https://markmail.org/message/e7rsryympb2cephp
I've done some testing with Tomcat 8.5.x
For the Java 7 to Java 8 transition, the problematic code is
ConcurrentHashMap.keySet()
To test things I introduced a change to ApplicationContext that would
trigger this issue on web application stop.
Compile with Java 8, run with Java 7 and the logs fill with the expected
stack traces on shutdown.
Compile with Java 11 + release=7 and a slightly tweaked build.xml), run
with Java 7 - everything works.
Therefore, this basic testing confirms that release=7 does what we
expected it to.
A slight complication is that release=... only works with the public
API. That means we would need to remove the JmxLifecycleListener since
that uses classes in sun.rmi.*. This has been deprecated since December
2019 with a warning it may be removed after 2020-12-31.
So, as a first step, I intend to completely remove the
JMXLifecycleListener.
Are all those various system properties available in recent releases of
Java 7? I wouldn't want to trap users of Tomcat 8.5 on Java 7 into a
situation where they cannot upgrade to Tomcat 8.5.latest because they
still need the capability to control the JMX ports.
I then want to do a little more testing to see if we can build with Java
7 or Java 11. However, my concern with that approach is that we'll also
be able to build with Java 8 - the results of which would be problematic.
To Remy's point, it would be useful to still be able to run the unit
tests with Java 8. Assuming we can disable building with Java 8, maybe
we need a special flag that enables building and testing with Java 8 but
has a name like:
do-not-use-for-release-builds-enable-java-8
It's also possible to have an ant target which doesn't show up in
-projecthelp.
I don't think we'll get this all sorted for this release round. We
should be able to remove the JmxLifecycleListener though.
It's been documented to be removed for a long time, but I'd like to know
if we are "stranding" any users by removing it.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
