Should this work?

[Michael Hall]

> On Aug 2, 2015, at 5:25 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> 
> On 01/08/2015 21:57, Michael Hall wrote:
>> 
>> I can’t tell from that though what produced the requirement for java.desktop. -module options didn’t seem to show this either on a class by class basis. 
> Have you tried -verbose:class to print class-level dependences?

Running the code I posted in my last…
java -verbose:class JdepLAF | grep laf

Normal Swing laf…
[Loaded javax.swing.plaf.ComponentInputMapUIResource from /usr/local/jvm/openjdk-1.9.0-internal/lib/modules/bootmodules.jimage]
[Loaded javax.swing.plaf.basic.BasicRootPaneUI$RootPaneInputMap from /usr/local/jvm/openjdk-1.9.0-internal/lib/modules/bootmodules.jimage]

Aqua LAF classes…
[Loaded com.apple.laf.AquaFonts$5 from /usr/local/jvm/openjdk-1.9.0-internal/lib/modules/bootmodules.jimage]
[Loaded com.apple.laf.AquaFonts$6 from /usr/local/jvm/openjdk-1.9.0-internal/lib/modules/bootmodules.jimage]
[Loaded com.apple.laf.AquaFonts$7 from /usr/local/jvm/openjdk-1.9.0-internal/lib/modules/bootmodules.jimage]

Some do not seem to identify modules…
[Loaded com.apple.laf.AquaLookAndFeel$$Lambda$86/1836643189 from com.apple.laf.AquaLookAndFeel]
[Loaded com.apple.laf.AquaLookAndFeel$$Lambda$87/1355316001 from com.apple.laf.AquaLookAndFeel]

So jimage and not Desktop?

Though if I use package lookup like recently mentioned on list…
java -cp . JRTLister -p com.apple.laf.AquaMenuBarUI
/modules/java.desktop/com/apple/laf/AquaMenuBarUI.class

java.desktop.

Following my own suggestion and jar’ing my test class and using jdeps on that…
jdeps -v jdeplaf.jar
jdeplaf.jar -> java.base
jdeplaf.jar -> java.desktop
   JdepLAF                                            -> java.io.PrintStream                                
   JdepLAF                                            -> java.lang.Exception                                
   JdepLAF                                            -> java.lang.Object                                   
   JdepLAF                                            -> java.lang.String                                   
   JdepLAF                                            -> java.lang.System                                   
   JdepLAF                                            -> javax.swing.JFrame                                 
   JdepLAF                                            -> javax.swing.UIManager   

No laf related. The java.desktop dependency is probably from…
java -cp . JRTLister -p  javax.swing.UIManager
/modules/java.desktop/javax/swing/UIManager.class

For that -verbose:class shows…
[Loaded javax.swing.UIManager from /usr/local/jvm/openjdk-1.9.0-internal/lib/modules/bootmodules.jimage]

The same as the LAF classes.  Double checked -jdkinternals on jdeps of test jar still shows nothing so laf not missed because of that.

So verbose loading does not seem to actually indicate the correct module and doesn’t seem to show a reason why normal Swing would be included but system laf classes wouldn’t.
I might still suspect linkage and wonder if there is some other way to do that which might allow jdeps to pick it up? 

Since normal Swing classes like UIManager do include the java.desktop dependency you would probably not have a problem in people missing it while putting together reduced modular runtimes. They’ll get the classes but not know that they were classes included that didn’t show as a dependency. 

A little moot?

Michael Hall