From Alan.Bateman at oracle.com Sat Aug 1 19:59:51 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 01 Aug 2015 20:59:51 +0100 Subject: Should this work? In-Reply-To: <2E11BAF0-294E-4812-B78C-E241EFB948E8@gmail.com> References: <6D26E571-4640-48EF-B52C-E13688ACE0BE@gmail.com> <55BB1984.5000201@oracle.com> <70EE0FDF-B3D7-489A-A217-678F45D6FB42@gmail.com> <2E11BAF0-294E-4812-B78C-E241EFB948E8@gmail.com> Message-ID: <55BD2537.3080205@oracle.com> On 31/07/2015 22:16, Michael Hall wrote: > Fwiw, I have tried -R recursive, and even -jdkinternals. Neither gave me the laf dependenciies for my application jar. > I was not successful in using -M for module information to see if anything else identified java.desktop as a required module, it just didn?t work for me. > Neither did -p to try and go directly after the package, or -filter:package. > Either these are not in place or my build or usage is incorrect. > But, having been unable to get jdeps to indicate java.desktop as a module dependency for the Aqua laf I still might consider this a concern if someone was trying to determine required modules for a OS X swing application. I haven?t tried other platforms. > Maybe I should at least wait on doc before having concerns but this still seems one. > So is jdeps printing anything? If you are directly make use of anything in the java.desktop module then I would expect it to be printed. There are two UIManager.setLookAndFeel methods. One takes a String with the class name of the LAF. The other is a concert LookAndFeel implementation. Which method are you using? -Alan From mik3hall at gmail.com Sat Aug 1 20:57:28 2015 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 1 Aug 2015 15:57:28 -0500 Subject: Should this work? In-Reply-To: <55BD2537.3080205@oracle.com> References: <6D26E571-4640-48EF-B52C-E13688ACE0BE@gmail.com> <55BB1984.5000201@oracle.com> <70EE0FDF-B3D7-489A-A217-678F45D6FB42@gmail.com> <2E11BAF0-294E-4812-B78C-E241EFB948E8@gmail.com> <55BD2537.3080205@oracle.com> Message-ID: <48FB1340-2889-488D-B5F4-6C7C3CF151F2@gmail.com> > On Aug 1, 2015, at 2:59 PM, Alan Bateman wrote: > > > On 31/07/2015 22:16, Michael Hall wrote: > >> Fwiw, I have tried -R recursive, and even -jdkinternals. Neither gave me the laf dependenciies for my application jar. >> I was not successful in using -M for module information to see if anything else identified java.desktop as a required module, it just didn?t work for me. >> Neither did -p to try and go directly after the package, or -filter:package. >> Either these are not in place or my build or usage is incorrect. >> But, having been unable to get jdeps to indicate java.desktop as a module dependency for the Aqua laf I still might consider this a concern if someone was trying to determine required modules for a OS X swing application. I haven?t tried other platforms. >> Maybe I should at least wait on doc before having concerns but this still seems one. >> > > So is jdeps printing anything? If you are directly make use of anything in the java.desktop module then I would expect it to be printed. > Yes, most of the dependencies I think are showing up. The laf code wasn?t. I did notice that when run this way? jdeps -v halfpipe.jar At the front it listed modules including? halfpipe.jar -> java.desktop 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. > There are two UIManager.setLookAndFeel methods. One takes a String with the class name of the LAF. The other is a concert LookAndFeel implementation. Which method are you using? Generally I have used something like? try { if (System.getProperty("os.name").equals("Mac OS X")) UIManager.setLookAndFeel("ch.randelshofer.quaqua.QuaquaLookAndFeel"); else UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()); } catch (Exception e) { } Which means it wouldn?t use Aqua since I started doing pointing to the 3rd party laf. But I have been unable to find where I do that for this particular application. So you?d think I?d be getting default laf. What is that metal? It would surprise me if that?s what I?m using. I did find one application where I do use the above code. The jdeps output didn?t show l&f classes but did show some Apple. "org.bjb.OSXApplication" -> "com.apple.eawt.Application (JDK internal API (java.desktop))"; "org.bjb.OSXApplication" -> "com.apple.eawt.ApplicationListener (JDK internal API (java.desktop))"; (Those are in a different launcher jar for the app I?m currently testing but run against that jar they also show up). I haven?t been into that code for a while but I?ll try to change it to force system look and feel and see if aqua turns up in the jdeps output. Should be a little simpler than the current application I?m testing with. Michael Hall From mik3hall at gmail.com Sat Aug 1 21:31:42 2015 From: mik3hall at gmail.com (Michael Hall) Date: Sat, 1 Aug 2015 16:31:42 -0500 Subject: Should this work? In-Reply-To: <48FB1340-2889-488D-B5F4-6C7C3CF151F2@gmail.com> References: <6D26E571-4640-48EF-B52C-E13688ACE0BE@gmail.com> <55BB1984.5000201@oracle.com> <70EE0FDF-B3D7-489A-A217-678F45D6FB42@gmail.com> <2E11BAF0-294E-4812-B78C-E241EFB948E8@gmail.com> <55BD2537.3080205@oracle.com> <48FB1340-2889-488D-B5F4-6C7C3CF151F2@gmail.com> Message-ID: > UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()); This alone didn?t seem to get jdeps showing the aqua laf. Is there some other way I should test setting the laf? Otherwise I think just testing with this? import javax.swing.JFrame; public class JdepLAF { public static void main(String[] args) { try { javax.swing.UIManager.setLookAndFeel(javax.swing.UIManager.getSystemLookAndFeelClassName()); JFrame tester = new JFrame("Test jdeps on Aqua LAF"); tester.pack(); tester.setVisible(true); } catch (Exception ex) { ex.printStackTrace(); } System.out.println("exiting..."); } } Then jar the class and see what jdeps shows, would work as a valid test case. Michael Hall From Alan.Bateman at oracle.com Sun Aug 2 10:25:02 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 02 Aug 2015 11:25:02 +0100 Subject: Should this work? In-Reply-To: <48FB1340-2889-488D-B5F4-6C7C3CF151F2@gmail.com> References: <6D26E571-4640-48EF-B52C-E13688ACE0BE@gmail.com> <55BB1984.5000201@oracle.com> <70EE0FDF-B3D7-489A-A217-678F45D6FB42@gmail.com> <2E11BAF0-294E-4812-B78C-E241EFB948E8@gmail.com> <55BD2537.3080205@oracle.com> <48FB1340-2889-488D-B5F4-6C7C3CF151F2@gmail.com> Message-ID: <55BDEFFE.7040609@oracle.com> 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? > > Generally I have used something like? > try { > if (System.getProperty("os.name").equals("Mac OS X")) > UIManager.setLookAndFeel("ch.randelshofer.quaqua.QuaquaLookAndFeel"); > else > UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()); > } catch (Exception e) { > } > Which means it wouldn?t use Aqua since I started doing pointing to the > 3rd party laf. But I have been unable to find where I do that for this > particular application. So you?d think I?d be getting default laf. > What is that metal? It would surprise me if that?s what I?m using. > "ch.randelshofer.quaqua.QuaquaLookAndFeel" is a String so the static analysis that jdeps does isn't going to report this as a dependency. The Aqua LAF is in the java.desktop module and hopefully with -verbose:class you will be able to see if you directly make use of the com.apple.laf classes. -Alan From mik3hall at gmail.com Sun Aug 2 11:25:46 2015 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 2 Aug 2015 06:25:46 -0500 Subject: Should this work? In-Reply-To: <55BDEFFE.7040609@oracle.com> References: <6D26E571-4640-48EF-B52C-E13688ACE0BE@gmail.com> <55BB1984.5000201@oracle.com> <70EE0FDF-B3D7-489A-A217-678F45D6FB42@gmail.com> <2E11BAF0-294E-4812-B78C-E241EFB948E8@gmail.com> <55BD2537.3080205@oracle.com> <48FB1340-2889-488D-B5F4-6C7C3CF151F2@gmail.com> <55BDEFFE.7040609@oracle.com> Message-ID: <912BD04D-DDC1-4574-842B-9F9EB4F740CA@gmail.com> > On Aug 2, 2015, at 5:25 AM, Alan Bateman 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 From Alan.Bateman at oracle.com Sun Aug 2 11:31:49 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 02 Aug 2015 12:31:49 +0100 Subject: Should this work? In-Reply-To: <912BD04D-DDC1-4574-842B-9F9EB4F740CA@gmail.com> References: <6D26E571-4640-48EF-B52C-E13688ACE0BE@gmail.com> <55BB1984.5000201@oracle.com> <70EE0FDF-B3D7-489A-A217-678F45D6FB42@gmail.com> <2E11BAF0-294E-4812-B78C-E241EFB948E8@gmail.com> <55BD2537.3080205@oracle.com> <48FB1340-2889-488D-B5F4-6C7C3CF151F2@gmail.com> <55BDEFFE.7040609@oracle.com> <912BD04D-DDC1-4574-842B-9F9EB4F740CA@gmail.com> Message-ID: <55BDFFA5.3050306@oracle.com> On 02/08/2015 12:25, Michael Hall wrote: >> : >> >> 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? >> I should have been clearer, the -verbose:class is an option that you specify to jdeps (-verbose:package is another, use jdeps -help to see all the other options). -Alan. From mik3hall at gmail.com Sun Aug 2 11:37:08 2015 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 2 Aug 2015 06:37:08 -0500 Subject: Should this work? In-Reply-To: <55BDFFA5.3050306@oracle.com> References: <6D26E571-4640-48EF-B52C-E13688ACE0BE@gmail.com> <55BB1984.5000201@oracle.com> <70EE0FDF-B3D7-489A-A217-678F45D6FB42@gmail.com> <2E11BAF0-294E-4812-B78C-E241EFB948E8@gmail.com> <55BD2537.3080205@oracle.com> <48FB1340-2889-488D-B5F4-6C7C3CF151F2@gmail.com> <55BDEFFE.7040609@oracle.com> <912BD04D-DDC1-4574-842B-9F9EB4F740CA@gmail.com> <55BDFFA5.3050306@oracle.com> Message-ID: <5A4DDB14-560E-4FB9-8A03-0E52261D04F4@gmail.com> > On Aug 2, 2015, at 6:31 AM, Alan Bateman wrote: > >>> > I should have been clearer, the -verbose:class is an option that you specify to jdeps (-verbose:package is another, use jdeps -help to see all the other options). Sorry, I thought I checked to see if this was a jdeps option but missed it. However, jdeps -verbose:class jdeplaf.jar jdeplaf.jar -> java.base jdeplaf.jar -> java.desktop JdepLAF (jdeplaf.jar) -> java.io.PrintStream -> java.lang.Exception -> java.lang.Object -> java.lang.String -> java.lang.System -> javax.swing.JFrame -> javax.swing.UIManager Like some of the other options adding it doesn?t seem to show anything extra. Would some of this be in jigsaw specific builds and not in the main branch jdk9 ones? Michael Hall From Alan.Bateman at oracle.com Sun Aug 2 11:46:24 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 02 Aug 2015 12:46:24 +0100 Subject: Should this work? In-Reply-To: <5A4DDB14-560E-4FB9-8A03-0E52261D04F4@gmail.com> References: <6D26E571-4640-48EF-B52C-E13688ACE0BE@gmail.com> <55BB1984.5000201@oracle.com> <70EE0FDF-B3D7-489A-A217-678F45D6FB42@gmail.com> <2E11BAF0-294E-4812-B78C-E241EFB948E8@gmail.com> <55BD2537.3080205@oracle.com> <48FB1340-2889-488D-B5F4-6C7C3CF151F2@gmail.com> <55BDEFFE.7040609@oracle.com> <912BD04D-DDC1-4574-842B-9F9EB4F740CA@gmail.com> <55BDFFA5.3050306@oracle.com> <5A4DDB14-560E-4FB9-8A03-0E52261D04F4@gmail.com> Message-ID: <55BE0310.5010002@oracle.com> On 02/08/2015 12:37, Michael Hall wrote: > > Sorry, I thought I checked to see if this was a jdeps option but missed it. > However, > jdeps -verbose:class jdeplaf.jar > jdeplaf.jar -> java.base > jdeplaf.jar -> java.desktop > JdepLAF (jdeplaf.jar) > -> java.io.PrintStream > -> java.lang.Exception > -> java.lang.Object > -> java.lang.String > -> java.lang.System > -> javax.swing.JFrame > -> javax.swing.UIManager > > Like some of the other options adding it doesn?t seem to show anything extra. Would some of this be in jigsaw specific builds and not in the main branch jdk9 ones? > The jdeps in JDK 9 builds is up to date and the above output here looks right. Since the LAF is specified as a String then it means that there isn't a static dependency on the com.apple.laf.* or ch.randelshofer.quaqua.* classes. Is there a quaqua.jar or other JAR with the Quaqua LAF that you could run jdeps on? That might be more interesting to see if it depends on Swing internal classes or com.apple.eawt APIs. -Alan. From mik3hall at gmail.com Sun Aug 2 11:58:50 2015 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 2 Aug 2015 06:58:50 -0500 Subject: Should this work? In-Reply-To: <55BE0310.5010002@oracle.com> References: <6D26E571-4640-48EF-B52C-E13688ACE0BE@gmail.com> <55BB1984.5000201@oracle.com> <70EE0FDF-B3D7-489A-A217-678F45D6FB42@gmail.com> <2E11BAF0-294E-4812-B78C-E241EFB948E8@gmail.com> <55BD2537.3080205@oracle.com> <48FB1340-2889-488D-B5F4-6C7C3CF151F2@gmail.com> <55BDEFFE.7040609@oracle.com> <912BD04D-DDC1-4574-842B-9F9EB4F740CA@gmail.com> <55BDFFA5.3050306@oracle.com> <5A4DDB14-560E-4FB9-8A03-0E52261D04F4@gmail.com> <55BE0310.5010002@oracle.com> Message-ID: <25623A1E-920A-448D-8BA8-06EE77355B5A@gmail.com> > On Aug 2, 2015, at 6:46 AM, Alan Bateman wrote: > >> > The jdeps in JDK 9 builds is up to date and the above output here looks right. > > Since the LAF is specified as a String then it means that there isn't a static dependency on the com.apple.laf.* or ch.randelshofer.quaqua.* classes. > > Is there a quaqua.jar or other JAR with the Quaqua LAF that you could run jdeps on? That might be more interesting to see if it depends on Swing internal classes or com.apple.eawt APIs. You may of missed here that I had switched to testing with the trivial test class I posted earlier. Shown below. That simply does? javax.swing.UIManager.setLookAndFeel(javax.swing.UIManager.getSystemLookAndFeelClassName()); No QuaQua involved. I could try running with the quaqua jar in class path and this again? try { if (System.getProperty("os.name").equals("Mac OS X")) UIManager.setLookAndFeel("ch.randelshofer.quaqua.QuaquaLookAndFeel"); else UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()); } catch (Exception e) { } But I?m not sure how that would improve the chances of seeing the Aqua java.desktop dependencies? ---------------------------------------------------------------------------------------------------------------------- Current Test Class: (Running it java -verbose:class does show it loading com.apple.laf) import javax.swing.JFrame; public class JdepLAF { public static void main(String[] args) { try { javax.swing.UIManager.setLookAndFeel(javax.swing.UIManager.getSystemLookAndFeelClassName()); JFrame tester = new JFrame("Test jdeps on Aqua LAF"); tester.pack(); tester.setVisible(true); } catch (Exception ex) { ex.printStackTrace(); } System.out.println("exiting..."); } } Michael Hall From Alan.Bateman at oracle.com Sun Aug 2 20:40:15 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 02 Aug 2015 21:40:15 +0100 Subject: Should this work? In-Reply-To: <25623A1E-920A-448D-8BA8-06EE77355B5A@gmail.com> References: <6D26E571-4640-48EF-B52C-E13688ACE0BE@gmail.com> <55BB1984.5000201@oracle.com> <70EE0FDF-B3D7-489A-A217-678F45D6FB42@gmail.com> <2E11BAF0-294E-4812-B78C-E241EFB948E8@gmail.com> <55BD2537.3080205@oracle.com> <48FB1340-2889-488D-B5F4-6C7C3CF151F2@gmail.com> <55BDEFFE.7040609@oracle.com> <912BD04D-DDC1-4574-842B-9F9EB4F740CA@gmail.com> <55BDFFA5.3050306@oracle.com> <5A4DDB14-560E-4FB9-8A03-0E52261D04F4@gmail.com> <55BE0310.5010002@oracle.com> <25623A1E-920A-448D-8BA8-06EE77355B5A@gmail.com> Message-ID: <55BE802F.2000902@oracle.com> On 02/08/2015 12:58, Michael Hall wrote: > You may of missed here that I had switched to testing with the trivial test class I posted earlier. Shown below. > > That simply does? > javax.swing.UIManager.setLookAndFeel(javax.swing.UIManager.getSystemLookAndFeelClassName()); > > No QuaQua involved. > > I could try running with the quaqua jar in class path and this again? > try { > if (System.getProperty("os.name").equals("Mac OS X")) > UIManager.setLookAndFeel("ch.randelshofer.quaqua.QuaquaLookAndFeel"); > else > UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()); > } catch (Exception e) { > } > > But I?m not sure how that would improve the chances of seeing the Aqua java.desktop dependencies? > ---------------------------------------------------------------------------------------------------------------------- > Current Test Class: (Running it java -verbose:class does show it loading com.apple.laf) > > import javax.swing.JFrame; > > public class JdepLAF { > > public static void main(String[] args) { > try { > javax.swing.UIManager.setLookAndFeel(javax.swing.UIManager.getSystemLookAndFeelClassName()); > JFrame tester = new JFrame("Test jdeps on Aqua LAF"); > tester.pack(); > tester.setVisible(true); > } > catch (Exception ex) { ex.printStackTrace(); } > System.out.println("exiting..."); > } > } > The com.apple.laf.* classes are in the java.desktop module and are selected and used on your behalf then you select the system LAF. Your code isn't directly linking to these classes so this is why jdeps doesn't report them as a dependency. Hopefully I can convince you that jdeps is doing the right thing. -Alan. From mik3hall at gmail.com Sun Aug 2 21:34:31 2015 From: mik3hall at gmail.com (Michael Hall) Date: Sun, 2 Aug 2015 16:34:31 -0500 Subject: Should this work? In-Reply-To: <55BE802F.2000902@oracle.com> References: <6D26E571-4640-48EF-B52C-E13688ACE0BE@gmail.com> <55BB1984.5000201@oracle.com> <70EE0FDF-B3D7-489A-A217-678F45D6FB42@gmail.com> <2E11BAF0-294E-4812-B78C-E241EFB948E8@gmail.com> <55BD2537.3080205@oracle.com> <48FB1340-2889-488D-B5F4-6C7C3CF151F2@gmail.com> <55BDEFFE.7040609@oracle.com> <912BD04D-DDC1-4574-842B-9F9EB4F740CA@gmail.com> <55BDFFA5.3050306@oracle.com> <5A4DDB14-560E-4FB9-8A03-0E52261D04F4@gmail.com> <55BE0310.5010002@oracle.com> <25623A1E-920A-448D-8BA8-06EE77355B5A@gmail.com> <55BE802F.2000902@oracle.com> Message-ID: <76F5E71F-A2AA-4B06-8749-C4DAB931FA89@gmail.com> > On Aug 2, 2015, at 3:40 PM, Alan Bateman wrote: > The com.apple.laf.* classes are in the java.desktop module and are selected and used on your behalf then you select the system LAF. Your code isn't directly linking to these classes so this is why jdeps doesn't report them as a dependency. Hopefully I can convince you that jdeps is doing the right thing. I think in this case jdeps is missing the dependencies. It works out here because the missed dependencies get a free ride along with the other java.desktop swing classes. So you will get the classes you need which is what matters. If for whatever reason you are interested in analyzing the laf dependencies I don?t think jdeps will do much for you. Except going directly after a class by name will probably indicate what other laf classes it has dependencies on. jdeps is, as advertised, a static analysis tool. I am not saying it isn?t doing what it is supposed to do. There is no problem unless you have a lot of dynamic dependencies that it misses which you don?t pick up somehow through some other classes. Michael Hall From mark.reinhold at oracle.com Tue Aug 4 14:48:39 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 04 Aug 2015 07:48:39 -0700 Subject: Encapsulating internal APIs in JDK 9 (sun.misc.Unsafe, etc.) Message-ID: <20150804074839.57022@eggemoggin.niobe.net> As part of the overall modularization effort [1] we're going to encapsulate most of the JDK's internal APIs within the modules that define and use them so that, by default, they are not accessible to code outside the JDK. This change will improve the integrity of the platform, since many of these internal APIs define privileged, security-sensitive operations. In the long run it will also reduce the costs borne by the maintainers of the JDK itself and by the maintainers of libraries and applications that, knowingly or not, make use of these non-standard, unstable, and unsupported internal APIs. It's well-known that some popular libraries make use of a few of these internal APIs, such as sun.misc.Unsafe, to invoke methods that would be difficult, if not impossible, to implement outside of the JDK. To ensure the broad testing and adoption of the release we propose to treat these critical APIs as follows: - If it has a supported replacement in JDK 8 then we will encapsulate it in JDK 9; - If it does not have a supported replacement in JDK 8 then we will not encapsulate it in JDK 9, so that it remains accessible to outside code; and, further, - If it has a supported replacement in JDK 9 then we will deprecate it in JDK 9 and encapsulate it, or possibly even remove it, in JDK 10. The critical internal APIs proposed to remain accessible in JDK 9 are listed in JEP 260 [2]. Suggested additions to the list, justified by real-world use cases and estimates of developer and end-user impact, are welcome. - Mark [1] http://openjdk.java.net/jeps/200 [2] http://openjdk.java.net/jeps/260 From jeroen at sumatra.nl Tue Aug 4 15:06:02 2015 From: jeroen at sumatra.nl (Jeroen Frijters) Date: Tue, 4 Aug 2015 15:06:02 +0000 Subject: Encapsulating internal APIs in JDK 9 (sun.misc.Unsafe, etc.) In-Reply-To: <20150804074839.57022@eggemoggin.niobe.net> References: <20150804074839.57022@eggemoggin.niobe.net> Message-ID: <2decee78482649a8b7b53f4b5aeb7098@mane.sumatrasoftware.com> Hi Mark, Thanks. This looks like a solid plan. It will put us on track to get rid of the internal API usage without making it needlessly dificult for people to adopt JDK 9. Regards, Jeroen > -----Original Message----- > From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net] On Behalf > Of mark.reinhold at oracle.com > Sent: Tuesday, August 4, 2015 16:49 > To: jigsaw-dev at openjdk.java.net > Subject: Encapsulating internal APIs in JDK 9 (sun.misc.Unsafe, etc.) > > As part of the overall modularization effort [1] we're going to > encapsulate most of the JDK's internal APIs within the modules that > define and use them so that, by default, they are not accessible to code > outside the JDK. > > This change will improve the integrity of the platform, since many of > these internal APIs define privileged, security-sensitive operations. > In the long run it will also reduce the costs borne by the maintainers > of the JDK itself and by the maintainers of libraries and applications > that, knowingly or not, make use of these non-standard, unstable, and > unsupported internal APIs. > > It's well-known that some popular libraries make use of a few of these > internal APIs, such as sun.misc.Unsafe, to invoke methods that would be > difficult, if not impossible, to implement outside of the JDK. To > ensure the broad testing and adoption of the release we propose to treat > these critical APIs as follows: > > - If it has a supported replacement in JDK 8 then we will encapsulate > it in JDK 9; > > - If it does not have a supported replacement in JDK 8 then we will > not > encapsulate it in JDK 9, so that it remains accessible to outside > code; and, further, > > - If it has a supported replacement in JDK 9 then we will deprecate it > in JDK 9 and encapsulate it, or possibly even remove it, in JDK 10. > > The critical internal APIs proposed to remain accessible in JDK 9 are > listed in JEP 260 [2]. Suggested additions to the list, justified by > real-world use cases and estimates of developer and end-user impact, are > welcome. > > - Mark > > > [1] http://openjdk.java.net/jeps/200 > [2] http://openjdk.java.net/jeps/260 From martijnverburg at gmail.com Tue Aug 4 16:29:40 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 4 Aug 2015 17:29:40 +0100 Subject: Encapsulating internal APIs in JDK 9 (sun.misc.Unsafe, etc.) In-Reply-To: <2decee78482649a8b7b53f4b5aeb7098@mane.sumatrasoftware.com> References: <20150804074839.57022@eggemoggin.niobe.net> <2decee78482649a8b7b53f4b5aeb7098@mane.sumatrasoftware.com> Message-ID: +1 to this - it's a really good compromise. Christoph from Hazelcast (and some other folks from popular projects that use Unsafe) have been compiling a list of use cases and a gap analysis of sorts. I'll let him respond here with the gory details to add to the JEP. Cheers, Martijn On Tuesday, 4 August 2015, Jeroen Frijters wrote: > Hi Mark, > > Thanks. This looks like a solid plan. It will put us on track to get rid > of the internal API usage without making it needlessly dificult for people > to adopt JDK 9. > > Regards, > Jeroen > > > -----Original Message----- > > From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net > ] On Behalf > > Of mark.reinhold at oracle.com > > Sent: Tuesday, August 4, 2015 16:49 > > To: jigsaw-dev at openjdk.java.net > > Subject: Encapsulating internal APIs in JDK 9 (sun.misc.Unsafe, etc.) > > > > As part of the overall modularization effort [1] we're going to > > encapsulate most of the JDK's internal APIs within the modules that > > define and use them so that, by default, they are not accessible to code > > outside the JDK. > > > > This change will improve the integrity of the platform, since many of > > these internal APIs define privileged, security-sensitive operations. > > In the long run it will also reduce the costs borne by the maintainers > > of the JDK itself and by the maintainers of libraries and applications > > that, knowingly or not, make use of these non-standard, unstable, and > > unsupported internal APIs. > > > > It's well-known that some popular libraries make use of a few of these > > internal APIs, such as sun.misc.Unsafe, to invoke methods that would be > > difficult, if not impossible, to implement outside of the JDK. To > > ensure the broad testing and adoption of the release we propose to treat > > these critical APIs as follows: > > > > - If it has a supported replacement in JDK 8 then we will encapsulate > > it in JDK 9; > > > > - If it does not have a supported replacement in JDK 8 then we will > > not > > encapsulate it in JDK 9, so that it remains accessible to outside > > code; and, further, > > > > - If it has a supported replacement in JDK 9 then we will deprecate it > > in JDK 9 and encapsulate it, or possibly even remove it, in JDK 10. > > > > The critical internal APIs proposed to remain accessible in JDK 9 are > > listed in JEP 260 [2]. Suggested additions to the list, justified by > > real-world use cases and estimates of developer and end-user impact, are > > welcome. > > > > - Mark > > > > > > [1] http://openjdk.java.net/jeps/200 > > [2] http://openjdk.java.net/jeps/260 > -- Cheers, Martijn (Sent from Gmail Mobile) From chris at hazelcast.com Tue Aug 4 17:10:33 2015 From: chris at hazelcast.com (Christoph Engelbert) Date: Tue, 4 Aug 2015 19:10:33 +0200 Subject: Encapsulating internal APIs in JDK 9 (sun.misc.Unsafe, etc.) In-Reply-To: References: <20150804074839.57022@eggemoggin.niobe.net> <2decee78482649a8b7b53f4b5aeb7098@mane.sumatrasoftware.com> Message-ID: <2CEB578E-D022-4321-B523-FA1B6969964B@hazelcast.com> Hey Mark, Martijn, First of all a more official way than twitter: I really appreciate this step, it is the perfect way. Unsafe has to disappear but with a good migration path and I think this compromise will achieve exactly that. I?ll compile the list in a more readable format over the next days. Unfortunately I most probably can only give use cases about sun.misc.Unsafe (and some less important tricks on other classes, that are not necessary from my point of view), however I guess there might be other classes used by other projects like sun.reflect.ReflectionFactory which is used by Objenesis and couple of other frameworks. Christoph Engelbert Technical Evangelist / Senior Solutions Architect 350 Cambridge Ave Suite #50, Palo Alto, CA 94306 USA (based in Germany) chris at hazelcast.com +49 160 9648 2677 @noctarius2k skype: noctarius_ > Am 04.08.2015 um 18:29 schrieb Martijn Verburg : > > +1 to this - it's a really good compromise. Christoph from Hazelcast (and > some other folks from popular projects that use Unsafe) have been compiling > a list of use cases and a gap analysis of sorts. I'll let him respond here > with the gory details to add to the JEP. > > Cheers, > Martijn > > On Tuesday, 4 August 2015, Jeroen Frijters wrote: > >> Hi Mark, >> >> Thanks. This looks like a solid plan. It will put us on track to get rid >> of the internal API usage without making it needlessly dificult for people >> to adopt JDK 9. >> >> Regards, >> Jeroen >> >>> -----Original Message----- >>> From: jigsaw-dev [mailto:jigsaw-dev-bounces at openjdk.java.net >> ] On Behalf >>> Of mark.reinhold at oracle.com >>> Sent: Tuesday, August 4, 2015 16:49 >>> To: jigsaw-dev at openjdk.java.net >>> Subject: Encapsulating internal APIs in JDK 9 (sun.misc.Unsafe, etc.) >>> >>> As part of the overall modularization effort [1] we're going to >>> encapsulate most of the JDK's internal APIs within the modules that >>> define and use them so that, by default, they are not accessible to code >>> outside the JDK. >>> >>> This change will improve the integrity of the platform, since many of >>> these internal APIs define privileged, security-sensitive operations. >>> In the long run it will also reduce the costs borne by the maintainers >>> of the JDK itself and by the maintainers of libraries and applications >>> that, knowingly or not, make use of these non-standard, unstable, and >>> unsupported internal APIs. >>> >>> It's well-known that some popular libraries make use of a few of these >>> internal APIs, such as sun.misc.Unsafe, to invoke methods that would be >>> difficult, if not impossible, to implement outside of the JDK. To >>> ensure the broad testing and adoption of the release we propose to treat >>> these critical APIs as follows: >>> >>> - If it has a supported replacement in JDK 8 then we will encapsulate >>> it in JDK 9; >>> >>> - If it does not have a supported replacement in JDK 8 then we will >>> not >>> encapsulate it in JDK 9, so that it remains accessible to outside >>> code; and, further, >>> >>> - If it has a supported replacement in JDK 9 then we will deprecate it >>> in JDK 9 and encapsulate it, or possibly even remove it, in JDK 10. >>> >>> The critical internal APIs proposed to remain accessible in JDK 9 are >>> listed in JEP 260 [2]. Suggested additions to the list, justified by >>> real-world use cases and estimates of developer and end-user impact, are >>> welcome. >>> >>> - Mark >>> >>> >>> [1] http://openjdk.java.net/jeps/200 >>> [2] http://openjdk.java.net/jeps/260 >> > > > -- > Cheers, Martijn (Sent from Gmail Mobile) From simon at cjnash.com Tue Aug 4 18:34:48 2015 From: simon at cjnash.com (Simon Nash) Date: Tue, 04 Aug 2015 19:34:48 +0100 Subject: [SPAM?] Encapsulating internal APIs in JDK 9 (sun.misc.Unsafe, etc.) In-Reply-To: <20150804074839.57022@eggemoggin.niobe.net> References: <20150804074839.57022@eggemoggin.niobe.net> Message-ID: <55C105C8.9090602@cjnash.com> Mark, Thanks for this. In the list of broad categories, one is missing: x Those which are required to enable application code to work around bugs in the JDK such as leaked objects. When do you expect to be able to publish a detailed proposal for how the "last resort" mechanism will work? Simon mark.reinhold at oracle.com wrote: > As part of the overall modularization effort [1] we're going to > encapsulate most of the JDK's internal APIs within the modules that > define and use them so that, by default, they are not accessible to > code outside the JDK. > > This change will improve the integrity of the platform, since many of > these internal APIs define privileged, security-sensitive operations. > In the long run it will also reduce the costs borne by the maintainers > of the JDK itself and by the maintainers of libraries and applications > that, knowingly or not, make use of these non-standard, unstable, and > unsupported internal APIs. > > It's well-known that some popular libraries make use of a few of these > internal APIs, such as sun.misc.Unsafe, to invoke methods that would be > difficult, if not impossible, to implement outside of the JDK. To ensure > the broad testing and adoption of the release we propose to treat these > critical APIs as follows: > > - If it has a supported replacement in JDK 8 then we will encapsulate > it in JDK 9; > > - If it does not have a supported replacement in JDK 8 then we will not > encapsulate it in JDK 9, so that it remains accessible to outside > code; and, further, > > - If it has a supported replacement in JDK 9 then we will deprecate it > in JDK 9 and encapsulate it, or possibly even remove it, in JDK 10. > > The critical internal APIs proposed to remain accessible in JDK 9 are > listed in JEP 260 [2]. Suggested additions to the list, justified by > real-world use cases and estimates of developer and end-user impact, > are welcome. > > - Mark > > > [1] http://openjdk.java.net/jeps/200 > [2] http://openjdk.java.net/jeps/260 > From mark.reinhold at oracle.com Tue Aug 4 18:40:19 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 04 Aug 2015 11:40:19 -0700 Subject: [SPAM?] Encapsulating internal APIs in JDK 9 (sun.misc.Unsafe, etc.) In-Reply-To: <55C105C8.9090602@cjnash.com> References: <20150804074839.57022@eggemoggin.niobe.net>, <55C105C8.9090602@cjnash.com> Message-ID: <20150804114019.578179@eggemoggin.niobe.net> 2015/8/4 11:34 -0700, simon at cjnash.com: > Thanks for this. In the list of broad categories, one is missing: > > x Those which are required to enable application code to work around > bugs in the JDK such as leaked objects. That could be an awfully broad category. Do you have some specific examples in mind? > When do you expect to be able to publish a detailed proposal for how the > "last resort" mechanism will work? That will be an implementation-specific command-line flag, to be proposed in a forthcoming JEP. - Mark From simon at cjnash.com Tue Aug 4 19:07:17 2015 From: simon at cjnash.com (Simon Nash) Date: Tue, 04 Aug 2015 20:07:17 +0100 Subject: Encapsulating internal APIs in JDK 9 (sun.misc.Unsafe, etc.) In-Reply-To: <20150804114019.578179@eggemoggin.niobe.net> References: <20150804074839.57022@eggemoggin.niobe.net>, <55C105C8.9090602@cjnash.com> <20150804114019.578179@eggemoggin.niobe.net> Message-ID: <55C10D65.6030906@cjnash.com> mark.reinhold at oracle.com wrote: > 2015/8/4 11:34 -0700, simon at cjnash.com: >> Thanks for this. In the list of broad categories, one is missing: >> >> x Those which are required to enable application code to work around >> bugs in the JDK such as leaked objects. > > That could be an awfully broad category. Do you have some specific > examples in mind? > It is a broad category and it is an important one that deserves mention. I have come across a number of examples of leaked objects in Swing/AWT for which I have implemented workarounds by using internal APIs and reflection to locate the relevant fields and set them to null. At some point, I hope to create formal bug reports for these. The main impact is not memory consumption but the holding of references to my application classloader that prevents it from being garbage collected. This prevents any native libraries that were loaded by this classloader from being replaced with updated versions. >> When do you expect to be able to publish a detailed proposal for how the >> "last resort" mechanism will work? > > That will be an implementation-specific command-line flag, to be > proposed in a forthcoming JEP. > > - Mark > I look forward to seeing these details in the forthcoming JEP. Simon From mark.reinhold at oracle.com Tue Aug 4 21:12:56 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 04 Aug 2015 14:12:56 -0700 Subject: Encapsulating internal APIs in JDK 9 (sun.misc.Unsafe, etc.) In-Reply-To: <55C10D65.6030906@cjnash.com> References: <20150804074839.57022@eggemoggin.niobe.net>, <20150804114019.578179@eggemoggin.niobe.net>, <55C10D65.6030906@cjnash.com> Message-ID: <20150804141256.601596@eggemoggin.niobe.net> 2015/8/4 12:07 -0700, Simon Nash : > mark.reinhold at oracle.com wrote: >> 2015/8/4 11:34 -0700, simon at cjnash.com: >>> Thanks for this. In the list of broad categories, one is missing: >>> >>> x Those which are required to enable application code to work around >>> bugs in the JDK such as leaked objects. >> >> That could be an awfully broad category. Do you have some specific >> examples in mind? > > It is a broad category and it is an important one that deserves mention. > > I have come across a number of examples of leaked objects in Swing/AWT for > which I have implemented workarounds by using internal APIs and reflection > to locate the relevant fields and set them to null. At some point, I hope > to create formal bug reports for these. > > The main impact is not memory consumption but the holding of references > to my application classloader that prevents it from being garbage collected. > This prevents any native libraries that were loaded by this classloader > from being replaced with updated versions. I understand the problem you're solving, but the difficulty with this as a category is that it arguably includes every internal class, even those never intended to be even internal APIs, since pretty much any internal class can declare a field that winds up retaining some object, somewhere, unnecessarily. If we were to take this on as a category in the context of JEP 260 then we'd wind up encapsulating very little. A better approach here would be to fix the actual bugs, so bug reports would be most welcome (especially if they include suggested fixes). In the meantime you'll be able to use the last-resort command-line workaround to keep your existing code running. - Mark From richard.warburton at gmail.com Tue Aug 4 22:48:33 2015 From: richard.warburton at gmail.com (Richard Warburton) Date: Tue, 4 Aug 2015 23:48:33 +0100 Subject: Encapsulating internal APIs in JDK 9 (sun.misc.Unsafe, etc.) In-Reply-To: <20150804074839.57022@eggemoggin.niobe.net> References: <20150804074839.57022@eggemoggin.niobe.net> Message-ID: Hi, On Tue, Aug 4, 2015 at 3:48 PM, wrote: > As part of the overall modularization effort [1] we're going to > encapsulate most of the JDK's internal APIs within the modules that > define and use them so that, by default, they are not accessible to > code outside the JDK. > > This change will improve the integrity of the platform, since many of > these internal APIs define privileged, security-sensitive operations. > In the long run it will also reduce the costs borne by the maintainers > of the JDK itself and by the maintainers of libraries and applications > that, knowingly or not, make use of these non-standard, unstable, and > unsupported internal APIs. > > It's well-known that some popular libraries make use of a few of these > internal APIs, such as sun.misc.Unsafe, to invoke methods that would be > difficult, if not impossible, to implement outside of the JDK. To ensure > the broad testing and adoption of the release we propose to treat these > critical APIs as follows: > > - If it has a supported replacement in JDK 8 then we will encapsulate > it in JDK 9; > > - If it does not have a supported replacement in JDK 8 then we will not > encapsulate it in JDK 9, so that it remains accessible to outside > code; and, further, > > - If it has a supported replacement in JDK 9 then we will deprecate it > in JDK 9 and encapsulate it, or possibly even remove it, in JDK 10. > > The critical internal APIs proposed to remain accessible in JDK 9 are > listed in JEP 260 [2]. Suggested additions to the list, justified by > real-world use cases and estimates of developer and end-user impact, > are welcome. > Its great to hear that this pragmatic compromise is being adopted. I hope over time supported replacements can be found for all the use cases being addressed with internal APIs, but glad that in the meantime existing projects won't suffer. regards, Richard Warburton http://insightfullogic.com @RichardWarburto From simon at cjnash.com Wed Aug 5 10:29:22 2015 From: simon at cjnash.com (Simon Nash) Date: Wed, 05 Aug 2015 11:29:22 +0100 Subject: [SPAM?] Re: Encapsulating internal APIs in JDK 9 (sun.misc.Unsafe, etc.) In-Reply-To: <20150804141256.601596@eggemoggin.niobe.net> References: <20150804074839.57022@eggemoggin.niobe.net>, <20150804114019.578179@eggemoggin.niobe.net>, <55C10D65.6030906@cjnash.com> <20150804141256.601596@eggemoggin.niobe.net> Message-ID: <55C1E582.6010907@cjnash.com> mark.reinhold at oracle.com wrote: > 2015/8/4 12:07 -0700, Simon Nash : >> mark.reinhold at oracle.com wrote: >>> 2015/8/4 11:34 -0700, simon at cjnash.com: >>>> Thanks for this. In the list of broad categories, one is missing: >>>> >>>> x Those which are required to enable application code to work around >>>> bugs in the JDK such as leaked objects. >>> That could be an awfully broad category. Do you have some specific >>> examples in mind? >> It is a broad category and it is an important one that deserves mention. >> >> I have come across a number of examples of leaked objects in Swing/AWT for >> which I have implemented workarounds by using internal APIs and reflection >> to locate the relevant fields and set them to null. At some point, I hope >> to create formal bug reports for these. >> >> The main impact is not memory consumption but the holding of references >> to my application classloader that prevents it from being garbage collected. >> This prevents any native libraries that were loaded by this classloader >> from being replaced with updated versions. > > I understand the problem you're solving, but the difficulty with this > as a category is that it arguably includes every internal class, even > those never intended to be even internal APIs, since pretty much any > internal class can declare a field that winds up retaining some object, > somewhere, unnecessarily. If we were to take this on as a category in > the context of JEP 260 then we'd wind up encapsulating very little. > I wasn't suggesting that this is a reason for not doing encapsulation but rather that this requirement exists and implies the ongoing need for a "last resort" mechanism to bypass encapsulation. This mechanism shouldn't be regarded as a transitional requirement but as something that will still be needed after new public APIs have been created to replace the private APIs that are known to be required by application developers. > A better approach here would be to fix the actual bugs, so bug reports > would be most welcome (especially if they include suggested fixes). > In the meantime you'll be able to use the last-resort command-line > workaround to keep your existing code running. > > - Mark > I agree, but it is unrealistic to think that all such bugs will be fixed promptly and no new ones would ever appear. For example, bug 6575402 has been open since 2007 and bug 8029147 has been open since 2013. Just one leaked object causes the application classloader not to be garbage collected and its native DLLs not to be unloaded. This is why it will always be necessary to have some escape mechanism by which application developers can work around such issues. Simon From mark.reinhold at oracle.com Wed Aug 5 14:42:54 2015 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 05 Aug 2015 07:42:54 -0700 Subject: [SPAM?] Re: Encapsulating internal APIs in JDK 9 (sun.misc.Unsafe, etc.) In-Reply-To: <55C1E582.6010907@cjnash.com> References: <20150804074839.57022@eggemoggin.niobe.net>, <20150804141256.601596@eggemoggin.niobe.net>, <55C1E582.6010907@cjnash.com> Message-ID: <20150805074254.245194@eggemoggin.niobe.net> 2015/8/5 3:29 -0700, Simon Nash : > mark.reinhold at oracle.com wrote: >> I understand the problem you're solving, but the difficulty with this >> as a category is that it arguably includes every internal class, even >> those never intended to be even internal APIs, since pretty much any >> internal class can declare a field that winds up retaining some object, >> somewhere, unnecessarily. If we were to take this on as a category in >> the context of JEP 260 then we'd wind up encapsulating very little. > > I wasn't suggesting that this is a reason for not doing encapsulation but > rather that this requirement exists and implies the ongoing need for a > "last resort" mechanism to bypass encapsulation. Understood. > This mechanism shouldn't > be regarded as a transitional requirement but as something that will still > be needed after new public APIs have been created to replace the private > APIs that are known to be required by application developers. I don't think the "last resort" mechanism is in any way transitional. There will always be legitimate -- though hopefully rare -- reasons to break through encapsulation boundaries from the command line. - Mark From jean-francois.denise at oracle.com Mon Aug 17 13:21:40 2015 From: jean-francois.denise at oracle.com (Jean-Francois Denise) Date: Mon, 17 Aug 2015 15:21:40 +0200 Subject: Review for JDK-8132335 In-Reply-To: <55B337D7.2060205@oracle.com> References: <1B0488C0-6C82-4A19-9FBC-D37CC72610B3@oracle.com> <55B337D7.2060205@oracle.com> Message-ID: <7718DB50-E312-427F-A41C-C6A78AD3417D@oracle.com> Hi Alan, as JDK-8132527 shows, we also need to test that replacing the boot image by a recreated one is OK. Something that is straightforward in jake using jlink ( to generate a JDK image), more difficult with jdk9/dev. I propose to add the recreate unit test in jake. Does it makes sense? JF On 25 Jul 2015, at 09:16, Alan Bateman wrote: > On 24/07/2015 17:19, Jean-Francois Denise wrote: >> I forget to add details on the fix. The fileName formatting was not correct, the call to getRoot() was not right. I replaced it with getFileName() + removal of .jimage extension. >> JF >> >> > Are you planning to add a test for this? I realize "jimage recreate" is mostly just for tools doing static instrumentation but it's very easy to break this and would be good to have a test to exercise it and catch any issues. > > -Alan. From jean-francois.denise at oracle.com Tue Aug 18 08:34:36 2015 From: jean-francois.denise at oracle.com (Jean-Francois Denise) Date: Tue, 18 Aug 2015 10:34:36 +0200 Subject: Review for JDK-8132527 Message-ID: <78C6CBC1-19E0-49C8-8673-EC18B7B9589D@oracle.com> Hi, asking for review to fix jvm crashing when replacing jimage file with recreated one. The name of the module metadata resource was wrongly associated to the name of the recreated jimage file. The original name must be reused in the recreated jimage. This is what this fix is doing. In addition the jimage unit test has been extended to cover the case where the provided jimage path is relative. http://cr.openjdk.java.net/~jfdenise/8132527/ Thanks. JF From james.laskey at oracle.com Tue Aug 18 12:14:10 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 18 Aug 2015 09:14:10 -0300 Subject: Review for JDK-8132527 In-Reply-To: <78C6CBC1-19E0-49C8-8673-EC18B7B9589D@oracle.com> References: <78C6CBC1-19E0-49C8-8673-EC18B7B9589D@oracle.com> Message-ID: +1 > On Aug 18, 2015, at 5:34 AM, Jean-Francois Denise wrote: > > Hi, > asking for review to fix jvm crashing when replacing jimage file with recreated one. > > The name of the module metadata resource was wrongly associated to the name of the recreated jimage file. The original name must be reused in the recreated jimage. > This is what this fix is doing. In addition the jimage unit test has been extended to cover the case where the provided jimage path is relative. > > http://cr.openjdk.java.net/~jfdenise/8132527/ > > Thanks. > JF From mandy.chung at oracle.com Tue Aug 18 17:16:04 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 18 Aug 2015 10:16:04 -0700 Subject: Review for JDK-8132527 In-Reply-To: <78C6CBC1-19E0-49C8-8673-EC18B7B9589D@oracle.com> References: <78C6CBC1-19E0-49C8-8673-EC18B7B9589D@oracle.com> Message-ID: <55D36854.8000003@oracle.com> On 08/18/2015 01:34 AM, Jean-Francois Denise wrote: > Hi, > asking for review to fix jvm crashing when replacing jimage file with recreated one. > > The name of the module metadata resource was wrongly associated to the name of the recreated jimage file. The original name must be reused in the recreated jimage. > This is what this fix is doing. In addition the jimage unit test has been extended to cover the case where the provided jimage path is relative. > > http://cr.openjdk.java.net/~jfdenise/8132527/ This looks okay. For JimageTest.java test, after it recreates the image, can you add to launch "java -version" from the recreated image as a sanity test? Mandy From Alan.Bateman at oracle.com Wed Aug 19 08:37:37 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 19 Aug 2015 09:37:37 +0100 Subject: Review for JDK-8132335 In-Reply-To: <7718DB50-E312-427F-A41C-C6A78AD3417D@oracle.com> References: <1B0488C0-6C82-4A19-9FBC-D37CC72610B3@oracle.com> <55B337D7.2060205@oracle.com> <7718DB50-E312-427F-A41C-C6A78AD3417D@oracle.com> Message-ID: <55D44051.6030205@oracle.com> On 17/08/2015 14:21, Jean-Francois Denise wrote: > Hi Alan, > as JDK-8132527 shows, we also need to test that replacing the boot image by a recreated one is OK. Something that is straightforward in jake using jlink ( to generate a JDK image), more difficult with jdk9/dev. > > The jimage tool is separate to the upcoming linker tool and I think we should have a test for each of the jimage tool options. So I do think we need something specific for jimage recreate, otherwise we will now know when it breaks. -Alan From jean-francois.denise at oracle.com Wed Aug 19 08:43:16 2015 From: jean-francois.denise at oracle.com (Jean-Francois Denise) Date: Wed, 19 Aug 2015 10:43:16 +0200 Subject: Review for JDK-8132335 In-Reply-To: <55D44051.6030205@oracle.com> References: <1B0488C0-6C82-4A19-9FBC-D37CC72610B3@oracle.com> <55B337D7.2060205@oracle.com> <7718DB50-E312-427F-A41C-C6A78AD3417D@oracle.com> <55D44051.6030205@oracle.com> Message-ID: Alan, the image tool ?recreate? option is tested. The upcoming linker tool makes for a simpler test. On 19 Aug 2015, at 10:37, Alan Bateman wrote: > On 17/08/2015 14:21, Jean-Francois Denise wrote: >> Hi Alan, >> as JDK-8132527 shows, we also need to test that replacing the boot image by a recreated one is OK. Something that is straightforward in jake using jlink ( to generate a JDK image), more difficult with jdk9/dev. >> >> > The jimage tool is separate to the upcoming linker tool and I think we should have a test for each of the jimage tool options. So I do think we need something specific for jimage recreate, otherwise we will now know when it breaks. > > -Alan From james.laskey at oracle.com Thu Aug 20 15:39:12 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 20 Aug 2015 12:39:12 -0300 Subject: RFR: Hotspot jimage API Message-ID: <435C5C1C-ACAB-498B-8114-C19B404A69FB@oracle.com> This is a description of changes precipitated from https://bugs.openjdk.java.net/browse/JDK-8087181 https://wiki.se.oracle.com/display/JPG/Hotspot+jimage+API Cheers, ? Jim From james.laskey at oracle.com Thu Aug 20 17:16:23 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 20 Aug 2015 14:16:23 -0300 Subject: RFR: Hotspot jimage API In-Reply-To: <435C5C1C-ACAB-498B-8114-C19B404A69FB@oracle.com> References: <435C5C1C-ACAB-498B-8114-C19B404A69FB@oracle.com> Message-ID: <1838AD23-5934-4358-8163-553F0CC43407@oracle.com> External link is here http://cr.openjdk.java.net/~jlaskey/jake/HotSpotJImageAPI.pdf > On Aug 20, 2015, at 12:39 PM, Jim Laskey (Oracle) wrote: > > This is a description of changes precipitated from https://bugs.openjdk.java.net/browse/JDK-8087181 > > https://wiki.se.oracle.com/display/JPG/Hotspot+jimage+API > > Cheers, > > ? Jim From ydwchina at gmail.com Fri Aug 21 07:37:11 2015 From: ydwchina at gmail.com (deven you) Date: Fri, 21 Aug 2015 15:37:11 +0800 Subject: RFR: JDK-8080511 - Refresh of jimage support In-Reply-To: References: Message-ID: Hi Jim, I have one question. I see Hotspot already supports in decompressing compressed resource and there is a method newCompressedResource in jdk/src/java.base/share/classes/jdk/internal/jimage/ResourcePool.java for creating a compressed resource but I did not find any API uses this method and not find there is any compressed resource in bootmodules.jimage. What I want to know is 1. if I want to compress one resource in a certain module what are the steps? I assume I need write some code which first gets the plugin and compressed buffer and then pass to newCompressedResource? If there is some compressed zip or jar files in a certain module how the relevant code deals with this condition? 2. Any plan that bootmodules.jiamge or other jimage files will contain such compressed resources? Thanks a lot! 2015-06-18 8:08 GMT+08:00 Jim Laskey (Oracle) : > https://bugs.openjdk.java.net/browse/JDK-8080511 > > This is an long overdue refresh of the jimage support in the JDK9-dev > repo. This includes native support for reading jimage files, improved > jrt-fs (java runtime file system) support for retrieving modules and > packages from the runtime, and improved performance for langtools in the > presence of jrt-fs. > > http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top < > http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top> > http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk < > http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk> > http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-hotspot < > http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-hotspot> > http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools < > http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools> > > > Details: > > - jrt-fs provides access, via the nio FileSystem API, to the classes in a > .jimage file, organized by module or by package. > - Shared code for jimage support converted to native. Currently residing > in hotspot, but will migrate to it?s own jdk library > https://bugs.openjdk.java.net/browse/JDK-8087181 < > https://bugs.openjdk.java.net/browse/JDK-8087181> > - A new archive abstraction for class/resource sources. > - java based implementation layer for jimage reading to allow backport to > JDK8 (jrt-fs.jar - IDE support.) > - JNI support for jimage into hotspot. > - White box tests written to exercise native jimage support. > > From james.laskey at oracle.com Fri Aug 21 11:50:50 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 21 Aug 2015 08:50:50 -0300 Subject: RFR: JDK-8080511 - Refresh of jimage support In-Reply-To: References: Message-ID: <2D754821-84AE-453D-8626-8693F9943CEC@oracle.com> The API is still a work in progress. Stay tuned. > On Aug 21, 2015, at 4:37 AM, deven you wrote: > > Hi Jim, > > I have one question. I see Hotspot already supports in decompressing compressed resource and there is a method newCompressedResource in jdk/src/java.base/share/classes/jdk/internal/jimage/ResourcePool.java > for creating a compressed resource but I did not find any API uses this method and not find there is any compressed resource in bootmodules.jimage. > > What I want to know is 1. if I want to compress one resource in a certain module what are the steps? I assume I need write some code which first gets the plugin and compressed buffer and then pass to newCompressedResource? If there is some compressed zip or jar files in a certain module how the relevant code deals with this condition? > 2. Any plan that bootmodules.jiamge or other jimage files will contain such compressed resources? > > Thanks a lot! > > 2015-06-18 8:08 GMT+08:00 Jim Laskey (Oracle) >: > https://bugs.openjdk.java.net/browse/JDK-8080511 > > This is an long overdue refresh of the jimage support in the JDK9-dev repo. This includes native support for reading jimage files, improved jrt-fs (java runtime file system) support for retrieving modules and packages from the runtime, and improved performance for langtools in the presence of jrt-fs. > > http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top > > http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk > > http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-hotspot > > http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools > > > > Details: > > - jrt-fs provides access, via the nio FileSystem API, to the classes in a .jimage file, organized by module or by package. > - Shared code for jimage support converted to native. Currently residing in hotspot, but will migrate to it?s own jdk library https://bugs.openjdk.java.net/browse/JDK-8087181 > > - A new archive abstraction for class/resource sources. > - java based implementation layer for jimage reading to allow backport to JDK8 (jrt-fs.jar - IDE support.) > - JNI support for jimage into hotspot. > - White box tests written to exercise native jimage support. > > From Alan.Bateman at oracle.com Mon Aug 24 06:43:24 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 24 Aug 2015 07:43:24 +0100 Subject: RFR: Hotspot jimage API In-Reply-To: <1838AD23-5934-4358-8163-553F0CC43407@oracle.com> References: <435C5C1C-ACAB-498B-8114-C19B404A69FB@oracle.com> <1838AD23-5934-4358-8163-553F0CC43407@oracle.com> Message-ID: <55DABD0C.7070800@oracle.com> On 20/08/2015 18:16, Jim Laskey (Oracle) wrote: > External link is here http://cr.openjdk.java.net/~jlaskey/jake/HotSpotJImageAPI.pdf > > This mostly good except for JIMAGE_PackageToModule which assumes a unique mapping. So I think this needs to be dropped or re-examined. -Alan From james.laskey at oracle.com Mon Aug 24 13:06:12 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Mon, 24 Aug 2015 10:06:12 -0300 Subject: RFR: Hotspot jimage API In-Reply-To: <55DABD0C.7070800@oracle.com> References: <435C5C1C-ACAB-498B-8114-C19B404A69FB@oracle.com> <1838AD23-5934-4358-8163-553F0CC43407@oracle.com> <55DABD0C.7070800@oracle.com> Message-ID: I?ll see if I can float that balloon today > On Aug 24, 2015, at 3:43 AM, Alan Bateman wrote: > > > > On 20/08/2015 18:16, Jim Laskey (Oracle) wrote: >> External link is here http://cr.openjdk.java.net/~jlaskey/jake/HotSpotJImageAPI.pdf >> >> > This mostly good except for JIMAGE_PackageToModule which assumes a unique mapping. So I think this needs to be dropped or re-examined. > > -Alan From jeffhain at rocketmail.com Thu Aug 27 20:15:34 2015 From: jeffhain at rocketmail.com (Jeff Hain) Date: Thu, 27 Aug 2015 20:15:34 +0000 (UTC) Subject: jdeps and annotations parameters Message-ID: <637110204.2206308.1440706534455.JavaMail.yahoo@mail.yahoo.com> Hello. (adding surnumerary new lines because sometimes some disapear for some reason). It seems that jdeps ignores dependencies of annotations parameters. cmd: "C:/Program Files/Java/jdk1.8.0_60/bin/jdeps" -verbose:class -filter:none -cp "C:/Program Files/Java/jdk1.8.0_60/jre/lib/rt.jar" output: java.beans.ConstructorProperties ?? java.beans.ConstructorProperties (rt.jar) ????? -> java.lang.Object?????????????????????????????????? rt.jar ????? -> java.lang.String?????????????????????????????????? rt.jar ????? -> java.lang.annotation.Annotation??????????????????? rt.jar ????? -> java.lang.annotation.Documented??????????????????? rt.jar ????? -> java.lang.annotation.Retention???????????????????? rt.jar ????? -> java.lang.annotation.Target??????????????????????? rt.jar while I was also expecting dependencies to java.lang.annotation.ElementType and java.lang.annotation.RetentionPolicy An extract of ConstructorProperties code: // BEGIN package java.beans; import java.lang.annotation.*; import static java.lang.annotation.ElementType.*; import static java.lang.annotation.RetentionPolicy.*; @Documented @Target(CONSTRUCTOR) @Retention(RUNTIME) public @interface ConstructorProperties { /**

The getter names.

@return the getter names corresponding to the parameters in the annotated constructor. */ String[] value(); } // END Is that intended? -Jeff From mandy.chung at oracle.com Thu Aug 27 20:49:54 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 27 Aug 2015 13:49:54 -0700 Subject: jdeps and annotations parameters In-Reply-To: <637110204.2206308.1440706534455.JavaMail.yahoo@mail.yahoo.com> References: <637110204.2206308.1440706534455.JavaMail.yahoo@mail.yahoo.com> Message-ID: <55DF77F2.3010106@oracle.com> It looks like a bug. I have filed an issue to look into further: https://bugs.openjdk.java.net/browse/JDK-8134625 Mandy On 08/27/2015 01:15 PM, Jeff Hain wrote: > Hello. > (adding surnumerary new lines because sometimes some disapear for some reason). > > It seems that jdeps ignores dependencies of annotations parameters. > > cmd: > "C:/Program Files/Java/jdk1.8.0_60/bin/jdeps" -verbose:class -filter:none -cp "C:/Program Files/Java/jdk1.8.0_60/jre/lib/rt.jar" > output: > java.beans.ConstructorProperties > java.beans.ConstructorProperties (rt.jar) > -> java.lang.Object rt.jar > -> java.lang.String rt.jar > -> java.lang.annotation.Annotation rt.jar > -> java.lang.annotation.Documented rt.jar > -> java.lang.annotation.Retention rt.jar > -> java.lang.annotation.Target rt.jar > > > while I was also expecting dependencies to > java.lang.annotation.ElementType > and > java.lang.annotation.RetentionPolicy > > > > An extract of ConstructorProperties code: > // BEGIN > package java.beans; > > import java.lang.annotation.*; > import static java.lang.annotation.ElementType.*; > import static java.lang.annotation.RetentionPolicy.*; > > @Documented @Target(CONSTRUCTOR) @Retention(RUNTIME) > public @interface ConstructorProperties { > /** >

The getter names.

> @return the getter names corresponding to the parameters in the > annotated constructor. > */ > String[] value(); > } > // END > > Is that intended? > > -Jeff From jeffhain at rocketmail.com Thu Aug 27 21:24:53 2015 From: jeffhain at rocketmail.com (Jeff Hain) Date: Thu, 27 Aug 2015 21:24:53 +0000 (UTC) Subject: jdeps and annotations parameters In-Reply-To: <55DF77F2.3010106@oracle.com> References: <55DF77F2.3010106@oracle.com> Message-ID: <624136714.2257694.1440710693082.JavaMail.yahoo@mail.yahoo.com> >It looks like a bug.? I have filed an issue to look into further: >? https://bugs.openjdk.java.net/browse/JDK-8134625 >Mandy Ok. I was starting to check my jdeps-like library(an upgrade of sourceforge.net/projects/jcyclesto compute dependencies in various ways and with more info(deps byte size, classes causing packages dependencies, etc.))against jdeps on all rt.jar class files, and I'm starting to see a lot moredifferences. The idea was both:- to check correctness of libraries against each other,- and, where dependency-or-not would be conventional? (such as, should a nested class always depend on its? surrounding class, or not, or on all of them up to top level one? (since they are all in InnerClasses attributes), etc.) ? to use jdeps convention to keep things simple. I will send you details (off list?) when I got them (with and without -apionly) (test does Runtime.exec(jdeps) for each class, takes time :). Then you could tell me what looks like a bugand what looks like a convention. -Jeff From james.laskey at oracle.com Fri Aug 28 17:05:04 2015 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Fri, 28 Aug 2015 14:05:04 -0300 Subject: RFR: 8087181: Move native jimage code to its own library (maybe libjimage) (against hs-rt) Message-ID: <2D6069D1-9D31-4CF4-9A06-093B2548590F@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8087181 http://cr.openjdk.java.net/~jlaskey/hs-rt/webrev-top http://cr.openjdk.java.net/~jlaskey/hs-rt/webrev-jdk http://cr.openjdk.java.net/~jlaskey/hs-rt/webrev-hotspot