> On Jul 31, 2015, at 1:45 AM, Alan Bateman <[email protected]> wrote: > > > This Swing LAF is the java.desktop module. The module can't have any > dependences on anything that isn't also in the run-time image so you can be > sure that this Swing LAF doesn't dependent on anything beyond the > java.desktop, java.base and a few other standard/JDK modules. Is that what > you are concerned about?
My first concern was how do I use jdeps to know what dependencies my application code has on the l&f. If this doesn’t work I can just enumerate the l&f from java.desktop and determine what dependencies there are from that. All probably runtime as you mention. I was hoping jdeps would sort of indicate to me the same object tree that might be followed by serialization. The complete absence of l&f modules being listed when run against the application jar does seems like it could be a concern if the purpose is to modularize the applications use of the runtime itself. There would be no indication given by jdeps for the l&f that java.desktop is needed by the application. This is probably dynamic and not static to the application jar, I can’t say I know exactly how the laf linkage works, so if dynamic jdeps wouldn’t pick up on it. The person modularizing their runtime would just have to know they need to include java.desktop in their modularized runtime to get the l&f and would be able to add it manually, correct? I’m not that concerned that jrt:// usage doesn’t work but nio seems to be leaning in the url/uri direction so I sort of vaguely wondered if the command line tools might start reflecting that at some point and allow url type path specifications. Michael Hall
