Am 23.09.2017 um 17:22 schrieb Mark Thomas:
On 23/09/17 16:10, Rainer Jung wrote:
Thanks Mark!
You might also want to look at r1809434 as a candidate and check whether
that workaround looks OK for you.
Looks good to me. I've added to the list of J9 back-port candidates. It
does beg the question whether or not we want to look at switching to
multi-release JARs for all of the compatibility code. WDYT?
Indeed, I ran my first multi-release Jar experiment (successfully)
today. For those who haven't yet seen it: starting with Java 9 one can
include instances of a class in a jar file that will only get used when
a specific JVM (major) version is detected at runtime. You can e.g. have
a default one as usual plus additional ones for specific Java runtime
versions. For Java 9 one would add a class at
META-INF/versions/9/org/apache/juli/... which would then be picked when
the runtime Java version is 9.
The enable the feature, one simply has to add the attribute
Multi-Release: true
to the Manifest file of the jar.
Thinks that come to my mind:
- you can have multiple versions of the same class. If we would use it
like that, we would have to slightly reorganize our svn layout to
reflect that, e.g. java/org/... plus new java9/org/....
- accordingly we would need e.g. a directory output/classes9 or similar.
- If we need Java 9 for compilation of the Java 9 classes, we would
mimic the Java 7 lines from the TC 7 build.xml.
- To add the Java 9 classes to one of our jars it would suffice in
build.xml to do something like
<jar jarfile="${somefile.jar}" update="true">
<manifest>
<attribute name="Multi-Release" value="true"/>
</manifest>
<zipfileset prefix="META-INF/versions/9/" dir="${tomcat.classes}9"/>
</jar>
- to reduce redundant maintenance it would be good to factor out JVM
dependent code, so that the classes we have to maintain multiply mostly
contain the code that's really version-dependent.
For instance when using the feature for my Java 9 change in Juli
http://svn.apache.org/viewvc?rev=1809434&view=rev one could use e.g. a
small but version dependent Constants.java which would provide the
correct directory name ("lib" versus "conf"). Or more easily a one line
properties file available in two versions providing the directory name.
I have not made any check on performance implications for the slightly
more complex class loading. What I did see, is that -verbose:class does
not indicate, which of the versions was chosen.
I currently do not have a real insight on how our most important JVM
version dependencies look. I guess how useful multi-release is, might
depend on the type of code dependencies we have.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
