Bug 1363 - Support Java 11+ (Warnings, Module Encapsulation, jlink, ..)
Summary: Support Java 11+ (Warnings, Module Encapsulation, jlink, ..)
Status: IN_PROGRESS
Alias: None
Product: General
Classification: JogAmp
Component: builds (show other bugs)
Version: 2.5.0
Hardware: All all
: P1 critical
Assignee: Sven Gothel
URL:
Depends on: 1317 1374
Blocks:
  Show dependency treegraph
 
Reported: 2019-03-28 17:42 CET by Sven Gothel
Modified: 2019-04-04 23:53 CEST (History)
2 users (show)

See Also:
Type: FEATURE
SCM Refs:
Workaround: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Gothel 2019-03-28 17:42:13 CET
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
- https://blog.joda.org/2018/09/from-java-8-to-java-11.html
- https://blog.joda.org/search/label/modules

Related JEPs
- 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.
Comment 1 Wade Walker 2019-03-29 01:27:15 CET
For future reference (already known via email, but for others), my initial cut at a Java 11 build is at:

https://github.com/WadeWalker/gluegen/tree/java-11-fixes
https://github.com/WadeWalker/jogl/tree/java-11-fixes https://github.com/WadeWalker/joal/tree/java-11-fixes

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 :)
Comment 2 Sven Gothel 2019-03-29 16:29:13 CET
(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:
> 
> https://github.com/WadeWalker/gluegen/tree/java-11-fixes
> https://github.com/WadeWalker/jogl/tree/java-11-fixes
> https://github.com/WadeWalker/joal/tree/java-11-fixes
> 
> 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.
Comment 3 Julien Gouesse 2019-03-29 21:58:18 CET
(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