Add Java 11 support - Initial Phase

[JimClarke5]

This PR adds support for compiling with a JDK 11 compiler and producing JDK 11 class files. This does not fully modularize the system per the specs in the Java Platform Module System (JPMS), but merely allows the existing jar files to play nicely in a JDK 11 environment as Automatic Modules.

I added a profile to compile to Java 11 classes. To use it, you need a JDK 11 installation and use the maven profile jdk11,
e.g. mvn -Pjdk11 install. This profile will change the compile source and target from 1.8 to 11.

In addition, I added an Automatic-Module-Name entry into each jar's manifest. The was done in each POM that generates a jar and allows JDK 11 environments to clearly define Automatic Modules. In each POM that generates jars, I created a property, java.module.name, to hold the name. Then I modified the maven-jar-plugin in each POM to include the Manfiest Entry similar to the following:

      <manifestEntries>
              <Automatic-Module-Name>${java.module.name}</Automatic-Module-Name>
     </manifestEntries>

Here are the names I selected for the modules. These are easy to change if needed, and this follows the suggested reverse Internet domain-name convention for modules. See Proposal: #AutomaticModuleNames (revised)

• <java.module.name>org.tensorflow.core.platform.gpu</java.module.name>
  

• <java.module.name>org.tensorflow.core.platform.mkl</java.module.name>
  

• <java.module.name>org.tensorflow.core.api</java.module.name>
  

• <java.module.name>org.tensorflow.core.generator</java.module.name>
  

• <java.module.name>org.tensorflow.core.platform.mkl</java.module.name>
  

• <java.module.name>org.tensorflow.core.platform</java.module.name>
  

• <java.module.name>org.tensorflow.framework</java.module.name>
  

• <java.module.name>org.tensorflow.ndarray</java.module.name>
  

NOTE: This does not fully modularize the system, but merely allows the jar files to play nicely in an JDK 11 environment.
To modularize the Jars, we would need to create a module-info.java for each Jar. The module-info.java file is only recognized by JDK versions 9 and higher, so this creates some issues with our current development environment.
There is a way to to create a Jar that supports multi-versions, so we could create a Jar that supports both 8 and 11. However, this requires JDK 9 or higher to build the system. In a nutshell, to fully go JPMS, we would have to require JDK 11 for all compilation, though we could issue Java 8 and Java 11 combined jars. We need to discuss this before making that requirement. Also, modularizing the jars will probably not be a trivial task, as JPMS enforces stricter encapsulation rules.

[Craigacp]

Is it worth moving the CI over to use Java 11 and then set the release flag to 8 or 11 in the profile? That'll be better at preventing us from using Java 11 language features before we're ready.

[saudet]

BTW, if the reason to use Java 11 is solely for modules, we can do that with Java SE 8 and ModiTect: https://github.com/moditect/moditect Check, for example, JavaCPP: https://github.com/bytedeco/javacpp

[JimClarke5]

Is it worth moving the CI over to use Java 11 and then set the release flag to 8 or 11 in the profile? That'll be better at preventing us from using Java 11 language features before we're ready.

I thought about this after I created this PR. The goal of this exercise was to see if we could play nicely with JDK 11 developers. I think if we set the source and target to 8, while keeping the Automatic Module names, accomplishes that. Without fully embracing JPMS, I think this is enough for now. Should we take out the jdk11 profile until we are ready to make the move to Java 11 specific features? You can still compile using JDK 11, or even later, if you want, as these later releases already handle Java 8 sources and targets.

[JimClarke5]

BTW, if the reason to use Java 11 is solely for modules, we can do that with Java SE 8 and ModiTect: https://github.com/moditect/moditect Check, for example, JavaCPP: https://github.com/bytedeco/javacpp

The goal here was to see if we could play nicely with JDK 9+ developers. It wasn't to fully modularize, though that should be done at a later time. There are still a significant number of Java 8 projects to support, and that will probably be the case for some time. I would think we would want to keep the project as simple as could be for now and support standard Java features as much as we can.

[saudet]

Ah, if it's for testing with Java 11, we could add a job to the CI for that. Or the other way around may work as well, deploy with Java 11 and test using Java 8 with the CI.

[Craigacp]

Is it worth moving the CI over to use Java 11 and then set the release flag to 8 or 11 in the profile? That'll be better at preventing us from using Java 11 language features before we're ready.

I thought about this after I created this PR. The goal of this exercise was to see if we could play nicely with JDK 11 developers. I think if we set the source and target to 8, while keeping the Automatic Module names, accomplishes that. Without fully embracing JPMS, I think this is enough for now. Should we take out the jdk11 profile until we are ready to make the move to Java 11 specific features? You can still compile using JDK 11, or even later, if you want, as these later releases already handle Java 8 sources and targets.

I think the release flag is better than setting source and target as it prevents us from using method calls not present in versions after release, though it's only available on 9+ (but you can use -release 8 on 9+). I'm fine with the existence of the jdk11 profile, but I'm not sure of the value of it given everything should be upwards compatible. I use the latest JDK as my dev environment and I've not had any TF-java issues. Admittedly I've not tried to modularise anything beyond adding automatic module names yet.

[Craigacp]

Ah, if it's for testing with Java 11, we could add a job to the CI for that. Or the other way around may work as well, deploy with Java 11 and test using Java 8 with the CI.

I agree with this. I test Tribuo on 8, 11 and latest using the CI, and we could at least run the quick CI on all of them, even if we don't do the full ops regeneration & build.

[karllessard]

In the CI, we only need to build that last step (deploy) or the quick build (triggered by PRs) with JDK 8 and/or 11. I like the idea of giving a try to multi-version jars but we can do that at a later step. It could also be possible in the quick build for PRs to build both versions, to validate that we don't break anything and that no JDK11 features are being used yet.

Am I right to assume that it does not matter which JDK we use for the native builds as we only distributes native binaries in the org.tensorflow:tensorflow-core-api:*? Is there any incompatible differences in the JNI layer or the auto-generated JavaCPP native code that would require us to provide different builds as well?

[saudet]

No, there's nothing in JavaCPP or JNI that breaks with Java 11. Right now, OpenJDK 8 gets used to compile all the classes except module-info.class, which ModiTect creates and places under META-INF so they get ignored by versions of the JDK less than 9. The resulting JAR files work fine with both Java 8 and 11, including with the module path.

[Craigacp]

I came across this blog post via JetBrains' monthly Java roundup and it's got a nice succinct explanation of why we should try to use the release flag when building on newer JDKs but targeting 8. I'd seen this ByteBuffer issue mentioned in various places on Github but this writeup captures everything - https://www.morling.dev/blog/bytebuffer-and-the-dreaded-nosuchmethoderror/.

[karllessard]

@JimClarke5 , can you add maven.compiler.release=11 as well, as suggested by @Craigacp ? Then we'll be good to merge it

[JimClarke5]

Just pushed it.