FX Modular build - FIVE Shocking things you need to know about the new build....

[David Hill]

What do you need to know about the new modular build (or how does this affect me ?)

I have covered the need for a new Gradle 3.1+, JDK 9 build 142+ already, so moving beyond that....

FIVE Shocking things you need to know about the new build.... !!!!!!!  :-)

FIRST:

There is NO jfxrt.jar anymore. This quite a change, but the new practice has already been talked about before. The build produces:
     rt/build/run.args
     rt/build/compile.args
(Note: run.args was renamed from xpatch.args as the java command line arguments changed)
These are "argfiles" which is a way of batching up command line option for ease of use. Fyi, argfiles work with javac in JDK8, and were added to the java command in JDK9.

Assuming you have reset JDK_HOME to point to JDK 9 ea build 142+, then building an running an FX application from the command lines would look like this:
     $JDK_HOME/bin/javac @_path_to_/compile.args -d build src/mytest/MyTestApp.java
     $JDK_HOME/bin/java   @_path_to_/run.args -cp build mytest.MyTestApp

Please note that these arg files contain absolute paths to your repository artifacts. If you want to copy the artifacts (rt/build/modular-sdk) to another location, then there is a script (rt/tools/scripts/make_runargs.sh) to generate a new run.args file

There is a corresponding set of argfiles that contain the test "shim" classes as well as the full modules. These are testrun.args and testcompile.args. Because the test modules modules contain a module-info.class (it is filtered out when we copy to rt/build/modular-sdk) it is quite likely that you will see one or more:
WARNING: module-info.class not allowed in patch: (path to the module)
These are annoying and harmless, and there is nothing we can do to suppress them.

SECOND:
    The FX built class files are "target=1.9". This is required by javac when we are building modules. If you have an existing netbeans project, you may need to edit it to update the value. This also means that any application like an IDE that parses class files may have a problem with the newer version.

THIRD:
   Module test classes are now split apart. Before we had the "shim" classes and the unit test classes all in one hierarchy. This does not work so well with the modular build, and so the shim classes have been separated into a new hierarchy.

before:
    modules/javafx.base/src/test/...
now:
    unit tests in modules/javafx.base/src/test/...
    shims in modules/javafx.base/src/shims/java/

For unit tests, we rebuild the modules that needs shims again, but this time add in the shim sources. The resulting module is then passed into the unit test run using -patch-module.

FOURTH:
   In the past we often used jfxrt.jar via a bootclasspath. One side effect of this was "all permissions" for the FX classes, which matched how the bundled FX classes are treated in the JDK. This does not work with JDK9 and -patch-module.

If you run into security issues with a test application, then you will need to use a java.security.manager, and a policy file that starts with the one we generate during the test task of our build: rt/build/test.java.policy (again, one that contains absolute paths). It is reasonably easy to add to an ant file an action that will start with this file, and add in any test application specific additions, and the resulting file can then be used for the application run.

FIFTH:
   There are early access editions of IDEs. Let us know if you find ways to get these to work :-)
     Netbeans: http://wiki.netbeans.org/JDK9Support <http://bits.netbeans.org/download/trunk/nightly/latest/>
     Intellij: https://confluence.jetbrains.com/display/IDEADEV/EAP


-- 
David Hill<David.Hill at Oracle.com>
Java Embedded Development

"A man's feet should be planted in his country, but his eyes should survey the world."
-- George Santayana (1863 - 1952)