[PATCH] Enable Multi-Release Jars (MRJAR AKA JEP 238)

[taylor.smock]

From comment:15:ticket:21498 and comment:16:ticket:21498, it would be useful to be able to use new Java features while still maintaining backwards compatibility with Java 8.

JEP 238 allows for this. Java 8 reads the class files from the traditional package directories (e.g., org/openstreetmap/.. while Java9+ attempts to read class files first from META-INF/versions/${version}, with ${version} starting at the java version (e.g., 11) and decrementing until it finds a class file or it reaches 8, at which point it reads it from the traditional package directory.

Pros:

• We can have version specific implementations for items, instead of having classes where each method has a check for the java version.
• We can try out newer Java features
  • Specific to 360 imagery, we can try out the vectors (incubating) available in Java 17 (​JEP 338 for Java 16, ​JEP 414 for Java 17, and ​JEP 417 for Java 18, ​JEP 426 for Java 19)

Cons:

• Testing -- each class file is essentially a duplicate, so we may have duplicated code when the class only has one or two methods that can or should be version specific
• The source code layout we have right now isn't very good for this use case. I've worked around it in the attached patch for build.xml, but IDEs are going to take a bit more work.
  • We may want to move the Java 8 source directories to src/main/java to make things easier. I was originally trying to have the source for Java{version} in the same source directory, but that didn't work well.

What the attached patch does:

• Creates new macros: call-javac-compile and call-javac-compile-mrjar (the latter calls the former with some additional checks)
• Checks for Java 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, and 21 source directories. These are expected to be src/main/java-${version}. If that directory exists, it compiles the files in that directory using the release target. The mrjar also checks that the compiler can compile for that version (isJava@{version} is set).
  • I'll be attaching an additional patch without Java 9, 10, 12, 13, 14, 15, and 16, as all of those are no longer supported (OpenJDK) and are not LTS releases. While Java 18-21 are not yet released, they will remain as new features will be introduced in them. Java 18-20 should be removed as support is dropped for them.

EDIT: I tested that the build works by copying the Vector3D class and adding a Logging.error with a unique message for the non-JEP 238 class and one for the JEP 238 class.

[taylor.smock]

MRJAR support for all Java releases (Java 8 - Java 21)

[taylor.smock]

Same as attachment:21510.patch​ except without unsupported Java releases (still has future Java releases)

[Don-vip]

In 18308/josm:

fix #21510 - Enable Multi-Release Jars (MRJAR - JEP 238 - patch by taylor.smock)

[Don-vip]

In 18309/josm:

see #21510 - fixup, forgot to delete one part (patch didn't apply nicely)

[Don-vip]

Thanks! Agreed in the long term I'd like to switch to conventional tree src/main|test/java|resources too, but that's another story :)

[taylor.smock]

Replying to Don-vip:

Thanks! Agreed in the long term I'd like to switch to conventional tree src/main|test/java|resources too, but that's another story :)

Yep. Looks at all the patches.

[taylor.smock]

Replying to Don-vip:

In 18309/josm:

see #21510 - fixup, forgot to delete one part (patch didn't apply nicely)

Sorry about that -- I had some changes to build.xml for use with my gitlab ci (mostly for codeclimate/source navigation).

EDIT: See semanticdb sections.

[Don-vip]

Milestone renamed

[Don-vip]

I'm going to investigate MRJAR support for #2372, I'd like to implement GeoTIFF support without waiting for Java 11/17 migration.