Modularization

[wirew0rm]

Efforts to make chartfx usable from jigsaw modularized projects as proposed in #156.

Before merging this the following points will have to be addressed:

Jigsaw Compatibility

To make chartfx usable for modularized projects, there are some points which have to be considered according to this blogpost.

Addressing these concerns is a matter of good hygiene. If you encounter one of these issues and you can't address those, don't add the Automatic-Module-Name entry yet. For now, your library is better off on the classpath. It will only raise false expectations if you do add the entry.

So before meging this branch, these issues should probably be adressed.

internal JDK types

Make sure your library doesn't use internal types from the JDK (run jdeps --jdk-internals mylibrary.jar to find offending code). JDeps (as bundled with Java 9 and later) will offer publicly supported alternatives for any use of encapsulated JDK APIs. When your library runs from the classpath on Java 9 and later, you can still get away with this. Not so if your library lives on the module path as automatic module.

jdeps --jdk-internals chartfx-chart/target/chartfx-chart-11.1.0-SNAPSHOT.jar 
chartfx-chart-11.1.0-SNAPSHOT.jar -> JDK removed internal API
   de.gsi.chart.utils.SimplePerformanceMeter          -> com.sun.javafx.perf.PerformanceTracker             JDK internal API (JDK removed internal API)

jdeps --jdk-internals chartfx-dataset/target/chartfx-dataset-11.1.0-SNAPSHOT.jar 
chartfx-dataset-11.1.0-SNAPSHOT.jar -> jdk.unsupported
   de.gsi.dataset.serializer.spi.FastByteBuffer       -> sun.misc.Unsafe                                    JDK internal API (jdk.unsupported)

JDK Internal API                         Suggested Replacement
----------------                         ---------------------
sun.misc.Unsafe                          See http://openjdk.java.net/jeps/260

Unsafe replacement links to Variable Handles.

• com.sun.javafx.perf.PerformanceTracker (chartfx-chart: SimplePerformanceMeter)
• sun.misc.Unsafe (chartfx-datasets: FastByteBuffer)

unnamed packages

Your library can't have classes in the default (unnamed) package. This is a bad idea regardless, but when your library is used as automatic module, this rule is enforced by the module system.

• no problems here

split packages

Your library can't split packages (two or more JARs defining the types in the same package), nor can it redefine JDK packages (javax.annotation is a notorious example, being defined in the JDK's java.xml.ws.annotation module but also in external libraries).

Are our testcases affecting this? They are in the same package as the implementation but they are not shipped, so it might be ok?

META-INF/services

When your library's JAR has a META-INF/services directory to specify service providers, then the specified providers must exist in this JAR (as described in the ModuleFinder JavaDoc)

• check

[codecov]

Codecov Report

Merging #160 into dev-x.2.0 will increase coverage by 0.01%.
The diff coverage is n/a.

@@               Coverage Diff               @@
##             dev-x.2.0     #160      +/-   ##
===============================================
+ Coverage        45.48%   45.49%   +0.01%     
- Complexity        6273     6277       +4     
===============================================
  Files              372      372              
  Lines            40140    40137       -3     
  Branches          6415     6415              
===============================================
+ Hits             18257    18262       +5     
+ Misses           20711    20707       -4     
+ Partials          1172     1168       -4     

Impacted Files	Coverage Δ	Complexity Δ
...ava/de/gsi/chart/utils/SimplePerformanceMeter.java	89.70% <ø> (-0.23%)	37.00 <0.00> (ø)
.../main/java/de/gsi/chart/axes/spi/AbstractAxis.java	63.76% <0.00%> (+0.13%)	145.00% <0.00%> (+1.00%)
...src/main/java/de/gsi/chart/ui/ProfilerInfoBox.java	99.02% <0.00%> (+1.94%)	24.00% <0.00%> (+1.00%)
...ain/java/de/gsi/dataset/utils/CacheCollection.java	91.30% <0.00%> (+4.34%)	19.00% <0.00%> (+1.00%)
...in/java/de/gsi/dataset/utils/DoubleArrayCache.java	100.00% <0.00%> (+8.00%)	13.00% <0.00%> (+1.00%)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 24244b8...a72c406. Read the comment docs.

[ennerf]

Regarding the compatibility questions:

Split Packages
Test cases don't matter

Internal JDK Types
sun.misc.unsafe is still available for the time being, so it's probably not necessary to replace all references just to get the automatic module name in.

JEP 193: Variable Handles only replaces some of the on-heap use cases Unsafe. In case you're doing anything off-heap, you may need to take a look at the new JEP 370: Foreign-Memory Access API.

[wirew0rm]

We decided to target this for the next major release, so rebased against dev-x.2.0.

Also tried to go fully modularized. This removes the need for our custom launcher, but we still need some jvm arguments, mostly due to controlsfx using internal javafx api via reflection.

The serialisers also rely on reflection, so there are still some exports missing.
Also correctly structuring the tests is difficult, as they cannot be in a different module, because they are in the same package but we cannot require the test dependencies from the module-info because they are only in the maven testscope. Surefire seems to do some magic here by supplying some additional jvm parameters, but at least in combination with testFX it does not work out of the box.

On the bright side, we can now start some of our samles without any additional configuration or wrappers.

[wirew0rm]

Projects missing auto-moudule-name in manifest:

[WARNING] Can't extract module name from batik-script-1.12.jar: Provider class org.apache.batik.bridge.RhinoInterpreterFactory not in module
[WARNING] Can't extract module name from xalan-2.7.2.jar: Provider class org.apache.bsf.BSFManager not in module
[WARNING] * Required filename-based automodules detected: [JTransforms-3.1.jar, commons-math3-3.6.1.jar, javafxsvg-1.3.0.jar, pngj-2.1.0.jar]. Please don't publish this project to a public artifact repository! *

• JTransforms: no efforts yet
• apache commons-math: fixed in upstream but unreleased MATH-1486: Add Automatic-Module-Name to MANIFEST apache/commons-math#107
• javafxsvg: to be removed and replaced by iconli, also depends on internal api
• pngj: no efforts yet

[RalphSteinhagen]

OK