[WIP] Move to Java 9

[lenhard]

One part of getting JabRef compatible with Java 9 and the module system (see JabRef/jabref#3421 ) is getting this library ready for Java 9.

This might seem straight-forward, but I am hitting some road bumps. The required modules and exports are quickly specified, but two classes we use com.sun.javafx.collections.ObservableListWrapper and com.sun.javafx.scene.input.ExtendedInputMethodRequests are not exported by the respective JavaFX modules, which means we can't use them in a Java 9 build.

I am not sure how to best get around this restriction.

[koppor]

If someone with java8 wants to debug without changing his whole system setup:

 docker run --rm -v "d:\git-repositories\jabref\org.jabref.gui.customjfx.support:/usr/src/myapp" -w /usr/src/myapp openjdk:9-jdk-slim ./gradlew jar

[koppor]

I would not update the whole library to Java9 only. Why not using something like moditect to inject module-info.java at compile time into the target JAR?

Refs moditect/moditect#3

[lenhard]

Thanks! No matter which way we are building the module-info.java, we still have the problem that the code is accessing classes from javafx which are no longer visible with the module system.

[koppor]

Since the fix why this library exists will be included in Java 10 AKA 18.3 and that will be released in March 2018, we should not spend much effort in supporting Java 9 should we? Better we support Java 18.3 in JabRef.

[lenhard]

@koppor You are 100% correct on that of course. I've just taken this as an opportunity to get more familiar with the module system.

For the record, this branch now contains a Java 9 compatible version of the library. I have bypassed the compile errors regarding the internal libraries by exporting them explicitly during (gradle) compilation (not in intellj). This is a fix that is not guaranteed to work for all eternity. Ultimately, we would have to rewrite the code.

I expect similar road-blocks for JabRef, but there the current main problem are still the split packages.

[tobiasdiez]

What is the solution of the OpenJFX team for this problem, given that the code in version 9 looks almost identical (it still contains the two problematic imports)?

[lenhard]

@tobiasdiez I don't know, but I assume they have a way to circumvent all that. OpenJFX is part of the JDK, they're more likely to be able to use JDK-internal classes. But as I said, I don't know how / if they do that given the module system.