This bug entry acts as a parent node for all bugs related
to Java compatibility issues beyond Java-8.
W/o writing the book about this again, I leave references for this issue:
Related Reading / Overview
- http://openjdk.java.net/jeps/220 Modular JRE
- http://openjdk.java.net/jeps/260 Encapsulation
- http://openjdk.java.net/jeps/238 Multi-Release JAR Files
- http://openjdk.java.net/jeps/282 jlink (the Java linker)
- http://openjdk.java.net/jeps/261 Module System
Please note that:
- Both, Java-8 and Java-11 have LTS (long time support)
- We will not test against Java-9 nor Java-10: Already outdated
- Oracle's Java build's are no more licensed for commercial use beyond Java-8
- We will only test & use OpenJDK builds starting with Java-11
Now the trick question for JogAmp will be mostly:
How to provide a Java-6 backward compatible build using Java-11 toolchain,
while also supporting the Java-11 runtime and beyond?
A first trial could be starting adding a Java-11 branch for all JogAmp modules, while trying to be sensitive to [Java-6 .. Java-8] backward compatibility.
For future reference (already known via email, but for others), my initial cut at a Java 11 build is at:
These commits are a combination of:
- Build fixes: mostly to XML files, though a few to Java to fix deprecated or removed functionality
- Warning removals: removing accesses to Java internal APIs that now cause runtime warnings and will shortly be disallowed. Removal is only done where it's possible to do without removing JOGL functionality. I only removed warnings that showed up along the path to the SWT canvas, so there are still more left, I'm sure :)
(In reply to Wade Walker from comment #1)
> For future reference (already known via email, but for others), my initial
> cut at a Java 11 build is at:
> These commits are a combination of:
> - Build fixes: mostly to XML files, though a few to Java to fix deprecated
> or removed functionality
> - Warning removals: removing accesses to Java internal APIs that now cause
> runtime warnings and will shortly be disallowed. Removal is only done where
> it's possible to do without removing JOGL functionality. I only removed
> warnings that showed up along the path to the SWT canvas, so there are still
> more left, I'm sure :)
Wade, your java-11 branch commits are a great source.
Great work, thank you.
I will look through it and read a bit more in the next days
then come back to you merging things somehow.
I see, the canonical preached path forward is to
package every little app with one target platform's JRE.
Crazy if you think about it. 'Docker' everywhere :)
Right, they call it micro-services these days.
The only real issue might be the Android system
when jumping towards java-11, but whatever.
I have to differentiate compatibility into:
1) runtime java language (bytecode etc)
2) runtime java classes (namespace, location, existence)
3) compile time / tooling 'makefile' stuff
I also need to see which of your commits is generic not java-11
related and which are strict for java-11.
Over the course of next 'periods', I probably need to add a java-11
branch to all our modules and work on these.
I will probably refrain from simply cutting off Java <= 8 support,
as I don't like the idea of dropping the wide range of
these target platforms.
Therefor I can only use your related patches as inspiration in this regard.
(In reply to Sven Gothel from comment #2)
> I also need to see which of your commits is generic not java-11
> related and which are strict for java-11.
Getting rid of the call to findLibrary would be helpful even before switching to Java 11: http://forum.jogamp.org/GL-ARB-vertex-buffer-object-not-available-on-Mac-tp4039309p4039367.html