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
--add-exports=javafx.graphics/com.sun.glass.events=ALL-UNNAMED
--add-exports=javafx.graphics/com.sun.glass.ui=ALL-UNNAMED

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/project.properties 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.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)

Reply via email to