JDK 9 support

[mokun]

In order to test for java 9 support on mars-sim in eclipse, we need to use a special Eclipse SDK build available at http://download.eclipse.org/eclipse/updates/4.7-Y-builds/

see https://wiki.eclipse.org/Java9 and https://marketplace.eclipse.org/content/java-9-support-beta-oxygen for details.

I suppose it will be easier to extend mars-sim to support openjdk 9 versus openjdk8/openjfx 8.

Let me know if you guys are interested in pursuing java 9.

[larsnaesbye]

The question is if we will release before or after the advent of Java 9. I would prefer before, but if we know it's going to take longer, then maybe it's good to prep for 9.

[mokun]

Since java 9 will bring a number of major changes (the import paths for some java API will change), there's a good chance that we will need to maintain a separate branch just to make mars-sim compiled under java 9. Does it worth the extra effort ?

Note: it's good that the support of openjdk/openjfx is no longer an issue .

[larsnaesbye]

Note: it's good that the support of openjdk/openjfx is no longer an issue .

I agree. Let us see about it - Java 9 isn't due until July and our tools most certainly will not be optimized for quite some time.

Is there anything in Java 9 that will give us significant improvements with regards to MSP? If not, then I suggest we wait with pursuing it until it's at least in Golden Master, since changes happen all the time like in any major release project....

[larsnaesbye]

It seems that Eclipse Oxygen now has support for Java 9. So we are good for moving to JDK 9.0.1 :-)

[mokun]

Because of Project Jigsaw in Java 9, according to this spec page and the quick-start page, we'll have to define the dependency explicitly by creating a module-info.java for each maven sub-module in the source root directory, namely, src/main/java since mars-sim is multi-module. When compiled, so it will be turned into a module descriptor, namely, module-info.class.

Question : Do we have to manually put together a list of maven artifacts and/or class file that each jar file (one for each of the sub-module) depends on ? Is there an automatic way of generating the module-info.java ?

[mokun]

Also, each maven artifact (the third party library) will need to support JDK 9 according to this page.

See this page that shows a list of open source library that "support JDK 9".

[mokun]

This page https://cwiki.apache.org/confluence/display/MAVEN/Java+9+-+Jigsaw shows the Java 9 compatibility of various maven plugins.

[larsnaesbye]

JDK 10 is even out now :-P

[mokun]

I suppose we should look into reducing the dependence on maven artifact from now on so as to make mars-sim easier to port from one java version to the next 😀

[larsnaesbye]

I hope that each new version will break fewer things than before :P

[mokun]

@shirishag75 @larsnaesbye , the way I understand is that there are currently at least two obstacles that we'll need to work out.

(1) Transitioning mars-sim to go beyond Java 8 or OpenJDK 8 requires the changing the codes to make it compatible with the modular system introduced in Project Jigsaw. See http://openjdk.java.net/projects/jigsaw/ This affects both Oracle Java or OpenJDK.

(2) JavaFX is bundled with Oracle Java 8 but not with OpenJDK. Therefore, if someone uses OpenJDK 8, he will need to install OpenJFK separately in his machine. Beginning Java 9, Oracle introduce breaking changes in the import statement that call for JavaFX UI elements. According to Oracle, they want to give away JavaFX to the open source community one day so that its development is faster.

It looks like we will need to maintain you separate versions of mars-sim, one for supporting the use of Java 8, one for Java 9 and beyond. Do we want that ?

Also, should we quit using JavaFX UI ?

[shirishag75]

right now both openjdk-jre and openjfx are uninstallable in Debian testing so can't move anywhere. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874132 for instance.

Also see https://lists.debian.org/debian-java/2018/04/msg00001.html to see how it's been talked there. So at least on Debian and deb-based distributions it seems will take time to resolve.

A bit more into the thread, it seems for openjfx the only reality would be openjdk 11 and openjfx 11, see https://lists.debian.org/debian-java/2018/04/msg00002.html

It's already under unstable/sid -

~$ apt-cache policy openjdk-11-jdk
openjdk-11-jdk:
  Installed: (none)
  Candidate: 11~11-2
  Version table:
     11~11-2 100
        100 http://cdn-fastly.deb.debian.org/debian unstable/main amd64 Packages

Also see https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-other-java-client-roadmap-updates

[larsnaesbye]

I don't like the idea of two separate versions of our code, not when it's as complex and voluminous as it is today. It won't be long until Java 8 isn't supported anymore (http://www.oracle.com/technetwork/java/eol-135779.html) anyway.

[mokun]

It seems there is a couple of issues we are dealing with here. Let's break them down and separate them apart.

1. We need a way-forward plan to support mars-sim fans who have installed only java 9 and above (not java 8).

2. We need to determine if supporting java 8 (or openjdk with openjfx 8) still have any merit.

3. If Debian is unable to resolve bugs under openjdk and openjfx 9, how would this affect our fan base ?

....

[larsnaesbye]

We could supply a JRE 8 with our distribution, but @shirishag75 is right: Java 11 is going to be LTS and since we haven't made a 'real' release for some time we might as well go down that path(?).

[shirishag75]

Just to share, as I'm on Debian testing, we just got java 10 in testing which means the next release of Ubuntu whenever they release would have java 10 as default and not java 8 .

$ sudo aptitude safe-upgrade -y
Resolving dependencies...                
The following NEW packages will be installed:
  openjdk-10-jre{a} openjdk-10-jre-headless{a} 
The following packages will be upgraded:
  default-jre default-jre-headless java-common snipped rest 
15 packages upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 109 MB of archives. After unpacking 184 MB will be used.

I just snipped the rest of the package updates as they aren't the point of discussion herein.

I am open to testing with openjdk 10

$ java --version
openjdk 10.0.1 2018-04-17
OpenJDK Runtime Environment (build 10.0.1+10-Debian-4)
OpenJDK 64-Bit Server VM (build 10.0.1+10-Debian-4, mixed mode)

I do know it's a big breaking change, but modularization should make things easier rather than harder going forward, of course it would mean even for a non-programmer like me, lot of rewriting of code, lot of loosening of things perhaps .

As far javafx is concerned, the only library I could find in Debian is -

~$ aptitude show libjavafxsvg-java
Package: libjavafxsvg-java               
Version: 1.2.1-1
State: not installed
Priority: optional
Section: java
Maintainer: Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>
Architecture: all
Uncompressed Size: 36.9 k
Depends: libbatik-java, libxmlgraphics-commons-java
Description: CenterDevice JavaFxSVG library
 JavaFxSVG is a simple library adding SVG support to JavaFX. It allows use of SVG graphics just like any other image
 type.
Homepage: https://github.com/codecentric/javafxsvg

But nothing about javafx directly as a separate library.

[larsnaesbye]

I seem to recall that JavaFX will be separated in version 11.

[mokun]

@larsnaesbye, that's true. JavaFX won't be included in Oracle's Official Java 11.

But the confusing part is that, for the open source community, OpenJDK 8 does NOT include OpenJFX since the beginning. One always has to install OpenJFX separately. The same thing goes with OpenJDK 9, 10 and 11.

I just updated our Development Environment wiki page. Now it shows the links for downloading JavaFX's binaries. See "A. Compiled Java Binaries".

@shirishag75, in short, you may want to try out an OpenJFX 8 build from https://chriswhocodes.com/ or an OpenJFX 11 ea build from http://jdk.java.net/openjfx/

[mokun]

@shirishag75, for debian, I'll rely on what they post on this page at https://packages.qa.debian.org/o/openjfx.html

Do let me know if you can run mars-sim on top of openjdk 8 with openjfx 8.

As for openjdk 9 and above, we have yet incorporated the modular system in our codebase and I'll look into the code change it requires.

If you default to using openjdk & openjfx 9/10/11 as your java vm in your machine, it probably won't be able to run mars-sim.

[shirishag75]

The problem is I'm running Debian testing and the default-jre is now openjdk-10 as shared above and the sense I get from reading the mails in the debian-java team they wanna put all their energies in getting openjdk 11 transitioned in Debian as fast as possible. The reason being simple, while Oracle hasn't talked about openjdk apparently but JDK 11 is supposed to be supported for 5 years and the openjdk team is probably thinking along similar lines.

This is probably the craziest time to do anything on mars-sim till java 11 and openjfx 11 don't become a reality, sometime late October, November 2018 .

A bit of comic relief I found on the upstream mailing list see http://mail.openjdk.java.net/pipermail/discuss/2018-April/004741.html - please see the date :)

[shirishag75]

@mokun see bugs.debian.org/850921 . So from what Emmanuel has shared and from what I had already guessed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850921#64 the libopenjfx-java version 8 is just a placeholder to be used for faster processing when libopenjfx-java 11 comes in 3-4 months in now. It probably would have a huge diff. but still would be easily reviewed by Debian ftpmasters and then pushed in either experimental or unstable what the maintainer thinks would be best. The idea would then be to see if there are any RC bugs (release-candidate bugs) and if not, have a quick transition and let people try it out on testing before Debian freeze i.e. Feb 2019.

We anyways can't do anything till default-jdk doesn't move to 11 so the best would be to lie quietly till openjdk does become the default-jdk .

[mokun]

@shirishag75 @larsnaesbye, yes it will be too troublesome to maintain two separate branches (one on Java 8, one on Java 9 and beyond).

As of today, Oracle has Java 8u171/172 and Java 10.0.1 as the general availability release. They no longer advertised Java 9 on their download page.

Since they have moved on from Java 9 to Java 10, I agree that we are to simply move our codebase from supporting Java 8 to only Java 9+ from now on.

See this commit for my first shot at module-info.java that I've been removing incompatibilities with Java 9 in the recent builds.

But as of this moment the master branch is still Java 8 based. To test Java 9, I actually have to change the compiler version from Java 8 to Java 9+ and back and forth each time.

So in the next build, I'll update some maven dependencies to supporting Java 9/10 only and there will be no going back :) Our codebase will be based on Java 9+ and the development environment must have jdk 9+ installed at the minimum.

Having said that, we do have the choice in manually compiling mars-sim into two separate binaries-- one will be good for users running in Java 8 VM in their machine and one for users with Java 9+ VM installed. It's cumbersome but still doable.

[shirishag75]

I am just going to wait till java 11 comes in Debian repositories along with a compatible openjfx release before trying any more things. This will take some time.

[mokun]

@larsnaesbye @shirishag75 ,

As of r4268, we are reasonably done with converting our master branch to supporting Java 9. Closing this issue for now.

[shirishag75]

Hi all, just to update few things, seems Java 11 release is about a month away according to the schedule -

http://openjdk.java.net/projects/jdk/11/#Schedule

I do have the latest openjdk-jre that is there is in testing -

$ apt-cache policy openjdk-11-jre
openjdk-11-jre:
  Installed: 11~24-1
  Candidate: 11~24-1
  Version table:
     11~27-1 100
        100 http://deb.debian.org/debian unstable/main amd64 Packages
 *** 11~24-1 500
        500 http://deb.debian.org/debian buster/main amd64 Packages

The one in sid/unstable will probably come down to testing in a day or two if there are no pending issues.

For openjfx there seems to be still some issues -

https://lists.debian.org/debian-java/2018/08/msg00068.html

Specifically -

There are blocking issues to resolve first, OpenJFX 11 requires a more recent version of Gradle than the one in sid currently.

• Emmanuel Borg .

Also saw this https://tomsondev.bestsolution.at/2018/08/04/supporting-openjfx-11-from-jdk11-onwards-in-efxclipse/

and saw that quite a few things have moved out of openjdk to their own respective packages or are being deprecated features.

I am looking to see when the new gradle comes in debian sid/testing and hence openjfx so then can try building and let you know what happens -

Java at my end for the moment -

$ java --version
openjdk 11 2018-09-25
OpenJDK Runtime Environment (build 11+24-Debian-1)
OpenJDK 64-Bit Server VM (build 11+24-Debian-1, mixed mode, sharing)

[mokun]

@shirishag75 , can you run v3.1.0-b1 on the machine that has openjdk/jfx 11 on it ?

Do you have openjfx 11 installed ?

The gui and headless versions in v3.1.0-b1 are separate binaries and must be downloaded separately, as you know.

[shirishag75]

Nope, do not have. I am waiting for the DD's to solve the issues and help them (if possible) if everything is in working order. I do not want to risk using a binary or making/compiling openjfx 11 because I don't know the switches they use for enhanced protection. I will update the bug when I have more news.

[mokun]

@shirishag75 , can you open a new ticket for openjdk/jfx 11 support ? Chances are new issues will be uncovered with running mars-sim under openjdk/jfx 11. Thanks!

[shirishag75]

just made a new bug-report at https://github.com/mars-sim/mars-sim/issues/74, this is with the headless mode now.

[mokun]

Java 9 is being supported since v3.1.0-preview 9. Closing this issue now.