Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multi-release jar support (Java 9 to start) #348

Closed
wants to merge 2 commits into from

Conversation

rnett
Copy link
Contributor

@rnett rnett commented Jul 5, 2021

Adds support for multi-release jars. Only Java 9 to start with, but it's easy to extend.

Adam or Karl, can you add the CI build tag? I need to check that native artifacts are still built correctly.

TODO:

Signed-off-by: Ryan Nett <JNett96@gmail.com>
@Craigacp
Copy link
Collaborator

Craigacp commented Jul 5, 2021

You should start with Java 11, there aren't any supported releases of Java 9. Plus the CI is already set up with Java 11 support.

@@ -0,0 +1,31 @@
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you creating a new module to avoid errors in the IDE? Because I think there is a way to add java9+ source files in the same module (tensorflow-core-api) but in a separate folder, I'd personally prefer that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it's for IDE issues.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should design our project based on IDE's "bugs", they might come up with a fix later (if none already exists?).

I'd be curious to give it a try if you place the JDK9 sources in, let say, src/java9

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, in theory, but I think this one was pretty severe. If I remember right @JimClarke5 tried this (w/ source folders) but put it off because of the IDE issues? I'm going to try it.

This is also fully supported by maven (see https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html) so it's not like it's a hack.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maven handles them nicely, but InteliJ complains of duplicate classes for those classes with different implementations as it doesn't seem to understand the difference between the 2 Java versions.

There is an open issue at:
Add support for building Java 9 multi-release jars

and
IntelliJ support to multi-release jars

As of Feb 2021, these still seems to be an open issues.

Copy link
Contributor Author

@rnett rnett Jul 6, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Testing it, it seems like you only get that error on the declarations, it's not that bad to just ignore. It keeps everything in the same module and has less maven configuration. There's no way to allow the source folder to use Java 9+ (or whatever) though, so using any 9+ APIs there will result in false positive errors. I'd prefer the multi-module solution, at least until those issues are fixed.

Copy link
Collaborator

@karllessard karllessard Jul 7, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I personally find the solution with multiple directories in the same module way cleaner, it requires almost no additional Maven configuration, nor any inter-module manual assembly, and it works like a charm outside the IDE.

I think it depends on how much code we want to put in these version-specific classes. If we just add the code that differs between JDK versions, then I'd be comfortable to just leave the src/main/java9 as a non-source directory by default and there will be no error. Of course the IDE won't be as efficient to assist you writing the code under that folder but it should be rare cases. But if we are heading to do full duplicates of the core classes (e.g. EagerSession), then it may become more painful. I would not recommend doing that though.

@Craigacp , any thoughts on this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only thing I had planed to put in there was some sort of Cleaner for resource scopes, so that should be fine.

Signed-off-by: Ryan Nett <JNett96@gmail.com>
@rnett
Copy link
Contributor Author

rnett commented Jul 12, 2021

Moved to #351.

@rnett rnett closed this Jul 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants