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.h...@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)
