Modular build: understanding addExports

David Hill David.Hill at
Tue Nov 8 19:30:47 UTC 2016

There are times when you just have to break the rules.... :-)

And when it comes to module package internals visibility, we have to at least bend the rules a bit, particularly for testing.

In comes the 'addExports" file. These files in the FX tree are actually 'argfiles' passed to javac and/or the java command.

Lets look at an example.... apps/tests/Robot

This test application uses non public/internal FX API, but is valuable to visually test that functionality.

To get around the visibility issue, we use --add-exports arguments to explicitly allow access. Looking at the file we see:

$ cat apps/tests/Robot/addExports

As the Robots.jar is an "un-named" automatic module, we export to the magic ALL-UNNAMED.

Nothing in the tool chain knows about this addExports file, so we do a small amount of Ant magic in nbproject/ to add it to the compile and run paths. All of this means that 'ant clean run' just works :-) (But of course manually launching Robot.jar does not unless we add to the command line).

There are other uses worth mentioning.

Most of our unit tests have cases that need special access. These are handled in modules/*/src/test/addExports, and might need to be touched if you are adding a test case with new needs.

Lastly there are some really special cases in build.gradle that don't quite fit the pattern. The Decora build for example has the --add-exports explicitly in build.gradle.

David Hill<David.Hill at>
Java Embedded Development

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

More information about the openjfx-dev mailing list