> On Aug 2, 2015, at 5:25 AM, Alan Bateman <[email protected]> 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
