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.4.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-08-20 07:04 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
Comment 4 Sven Gothel 2019-08-20 07:04:34 CEST
This work is currently intensively progress
and visible in the java11 branches of our modules.

Compatibility matrix is:
Build + Runtime: Java >= 11
Runtime: Java 8, Java >= 11 (Should be Java >= 8)

Meaning we build the Java 8 compliant jar files
using Java 11, to defuse and simplify the operation.

In the future, we might play with jlink etc,
but this has no priority as of now.

gluegen/make/jogamp-env.xml:

<!-- Current runtime requirements are:
        - Java 1.8 (Level 8.0)
        - Android SDK API level 24 (Version 7.0 Nougat, released August 2016)

     Official production builds are performed _for_ Java 1.8.
        - Java 1.8 (Level 8.0)
        - Android SDK API level 24 (Version 7.0 Nougat, released August 2016)

     Official production builds are performed _on_ OpenJDK 11
     and a Java JDK 11 or greater is required!

     Android 7 API level 24 supports Java 1.8, 
     see https://developer.android.com/studio/write/java8-support

     Target Java 8 baseline is chosen today, June 2019, 
     since OpenJDK 1.8 is well supported on desktop, 
     mobile support is given w/ OpenJDK 9 and 
     Android also support these language features for almost 3 years.