From erik.joelsson at oracle.com Mon Mar 2 08:34:40 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 02 Mar 2015 09:34:40 +0100 Subject: RFR 8073596 : Add jdk.management.cmm in boot.modules that needs sun.management.spi be exported to it In-Reply-To: <54F0D9C2.8090306@oracle.com> References: <54F0D9C2.8090306@oracle.com> Message-ID: <54F420A0.4040702@oracle.com> Looks good to me. /Erik On 2015-02-27 21:55, Brent Christian wrote: > Hi, > > Please review a small update to the module config files for a new > jdk.management.cmm module. > > Webrev: http://cr.openjdk.java.net/~bchristi/8073596/webrev/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8073596 > > I also found a needed hook missing from Gensrc-java.management.gmk > > FWIW, Erik Joelsson and Magnus Ihse Bursie have already seen and > approved this build change. > > (Note that I am not on either of these aliases, so please include me > directly in any responses. :) > > Thanks, > -Brent From brent.christian at oracle.com Mon Mar 2 20:24:29 2015 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 02 Mar 2015 12:24:29 -0800 Subject: RFR 8073596 : Add jdk.management.cmm in boot.modules that needs sun.management.spi be exported to it In-Reply-To: <54F187E9.5070500@oracle.com> References: <54F0D9C2.8090306@oracle.com> <54F187E9.5070500@oracle.com> Message-ID: <54F4C6FD.9000506@oracle.com> On 2/28/15 1:18 AM, Alan Bateman wrote: > Just a minor comment, we've been keeping the *.modules files in sorted > order. Not a big deal but would be good to continue that if you can. Will do. Thanks, Alan -Brent From mandy.chung at oracle.com Thu Mar 5 01:13:50 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 04 Mar 2015 17:13:50 -0800 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules Message-ID: <54F7ADCE.50900@oracle.com> As listed in an open issue in JEP 200: The jdk.dev and jdk.runtime modules contain miscellaneous tools that do not obviously belong to any other module; these modules will eventually be either renamed or refactored. Currently there are jdk.javadoc, jdk.jconsole, jdk.jcmd modules in the JDK that are organized around its primary tool. Such organization is easy to name, document and understand. This patch proposes to move tools from jdk.runtime and jdk.dev to jdk.pack200, jdk.jartool, jdk.policytool modules. Overall Webrev that will be convenient to review the build change and modules.xml change. http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/webrev.00/ Separate webrevs for each issue: 1. pack200, unpack200 to jdk.pack200 http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ 2. jar, jarsigner to jdk.jartool http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074429/webrev.00/ 3. policytool to jdk.policytool http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074430/webrev.00/ There are remaining tools in jdk.dev that will be handled separately. jdk.dev will disappear when all of the remaining tools find its home. Mandy From weijun.wang at oracle.com Thu Mar 5 02:55:26 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 5 Mar 2015 10:55:26 +0800 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F7ADCE.50900@oracle.com> References: <54F7ADCE.50900@oracle.com> Message-ID: I am about to introduce 2 APIs into jdk.dev so that people can call functions of keytool and jarsigner directly. So what I am suggesting is - Create jdk.security.util - Move jarsigner, policytool to jdk.security.util - Create the new APIs in this module - Move keytool to jdk.security.util, it's now in java.base but keytool is not part of Java SE spec (Of course, if that means keytool will be in JDK instead of JRE please stop. But will there will the name difference anymore? I am thinking of an installer like cygwin that you can choose anything except that java.base is checked grayed). Or, we can break it into jdk.security.tools and jdk.security.util. Put the executables into tools and APIs into util. --Max > On Mar 5, 2015, at 09:13, Mandy Chung wrote: > > As listed in an open issue in JEP 200: > > The jdk.dev and jdk.runtime modules contain miscellaneous tools that do > not obviously belong to any other module; these modules will eventually > be either renamed or refactored. > > Currently there are jdk.javadoc, jdk.jconsole, jdk.jcmd modules in > the JDK that are organized around its primary tool. Such organization > is easy to name, document and understand. This patch proposes to > move tools from jdk.runtime and jdk.dev to jdk.pack200, jdk.jartool, > jdk.policytool modules. > > Overall Webrev that will be convenient to review the build change > and modules.xml change. > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/webrev.00/ > > Separate webrevs for each issue: > 1. pack200, unpack200 to jdk.pack200 > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ > > 2. jar, jarsigner to jdk.jartool > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074429/webrev.00/ > > 3. policytool to jdk.policytool > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074430/webrev.00/ > > There are remaining tools in jdk.dev that will be handled separately. > jdk.dev will disappear when all of the remaining tools find its home. > > Mandy > From mandy.chung at oracle.com Thu Mar 5 03:25:16 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 04 Mar 2015 19:25:16 -0800 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: References: <54F7ADCE.50900@oracle.com> Message-ID: <54F7CC9C.2020500@oracle.com> On 3/4/2015 6:55 PM, Wang Weijun wrote: > I am about to introduce 2 APIs into jdk.dev so that people can call functions of keytool and jarsigner directly. Are you referring to these 2 RFEs? https://bugs.openjdk.java.net/browse/JDK-8056174 https://bugs.openjdk.java.net/browse/JDK-8058778 We have to see the details and webrev to comment on your proposed jdk.security.tools and jdk.security.util modules. There is no issue in keeping a CLI like keytool in java.base. What is your concern? policytool is a GUI app that depends on java.desktop module. If you move jarsigner, policytool and keytool, this new module would require java.desktop to be present to be used. Mandy > So what I am suggesting is > > - Create jdk.security.util > - Move jarsigner, policytool to jdk.security.util > - Create the new APIs in this module > - Move keytool to jdk.security.util, it's now in java.base but keytool is not part of Java SE spec (Of course, if that means keytool will be in JDK instead of JRE please stop. But will there will the name difference anymore? I am thinking of an installer like cygwin that you can choose anything except that java.base is checked grayed). > > Or, we can break it into jdk.security.tools and jdk.security.util. Put the executables into tools and APIs into util. > > --Max > >> On Mar 5, 2015, at 09:13, Mandy Chung wrote: >> >> As listed in an open issue in JEP 200: >> >> The jdk.dev and jdk.runtime modules contain miscellaneous tools that do >> not obviously belong to any other module; these modules will eventually >> be either renamed or refactored. >> >> Currently there are jdk.javadoc, jdk.jconsole, jdk.jcmd modules in >> the JDK that are organized around its primary tool. Such organization >> is easy to name, document and understand. This patch proposes to >> move tools from jdk.runtime and jdk.dev to jdk.pack200, jdk.jartool, >> jdk.policytool modules. >> >> Overall Webrev that will be convenient to review the build change >> and modules.xml change. >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/webrev.00/ >> >> Separate webrevs for each issue: >> 1. pack200, unpack200 to jdk.pack200 >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ >> >> 2. jar, jarsigner to jdk.jartool >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074429/webrev.00/ >> >> 3. policytool to jdk.policytool >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074430/webrev.00/ >> >> There are remaining tools in jdk.dev that will be handled separately. >> jdk.dev will disappear when all of the remaining tools find its home. >> >> Mandy >> From weijun.wang at oracle.com Thu Mar 5 03:33:12 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 5 Mar 2015 11:33:12 +0800 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F7CC9C.2020500@oracle.com> References: <54F7ADCE.50900@oracle.com> <54F7CC9C.2020500@oracle.com> Message-ID: > On Mar 5, 2015, at 11:25, Mandy Chung wrote: > > > On 3/4/2015 6:55 PM, Wang Weijun wrote: >> I am about to introduce 2 APIs into jdk.dev so that people can call functions of keytool and jarsigner directly. > > Are you referring to these 2 RFEs? > https://bugs.openjdk.java.net/browse/JDK-8056174 > https://bugs.openjdk.java.net/browse/JDK-8058778 > > We have to see the details and webrev to comment on your > proposed jdk.security.tools and jdk.security.util modules. Still in design, but you can look at it at http://cr.openjdk.java.net/~weijun/8058778/webrev.00. Or you can read the CCCs. > > There is no issue in keeping a CLI like keytool in java.base. > What is your concern? I just think keytool and jarsigner should stay together. :-) > > policytool is a GUI app that depends on java.desktop module. > If you move jarsigner, policytool and keytool, this new module > would require java.desktop to be present to be used. Correct. Put it in its own module. --Max > > Mandy From Alan.Bateman at oracle.com Thu Mar 5 08:23:50 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 05 Mar 2015 08:23:50 +0000 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: References: <54F7ADCE.50900@oracle.com> Message-ID: <54F81296.5080006@oracle.com> On 05/03/2015 02:55, Wang Weijun wrote: > - Move keytool to jdk.security.util, it's now in java.base but keytool is not part of Java SE spec (Of course, if that means keytool will be in JDK instead of JRE please stop. But will there will the name difference anymore? I am thinking of an installer like cygwin that you can choose anything except that java.base is checked grayed). > > The reason that keytool is in java.base is so that keys and certificates can be managed on a small runtime. It's the same reason that it is in our compact1 builds too. I wasn't aware of JDK-8058778 but it can't result in java.base exporting a JDK-specific API. -Alan From Alan.Bateman at oracle.com Thu Mar 5 08:31:31 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 05 Mar 2015 08:31:31 +0000 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F7ADCE.50900@oracle.com> References: <54F7ADCE.50900@oracle.com> Message-ID: <54F81463.7000903@oracle.com> On 05/03/2015 01:13, Mandy Chung wrote: > : > > Separate webrevs for each issue: > 1. pack200, unpack200 to jdk.pack200 > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ > I think this looks okay. In the unshuffle_list (for back/forward porting patches) then it lists specific files, I wonder if we can move that to directories. I also see remnants of the tracing API in that file, I assume they can be removed. -Alan. From Alan.Bateman at oracle.com Thu Mar 5 08:35:11 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 05 Mar 2015 08:35:11 +0000 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F7ADCE.50900@oracle.com> References: <54F7ADCE.50900@oracle.com> Message-ID: <54F8153F.9060301@oracle.com> On 05/03/2015 01:13, Mandy Chung wrote: > > 3. policytool to jdk.policytool > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074430/webrev.00/ > > This part looks good to me. -Alan From chris.hegarty at oracle.com Thu Mar 5 09:05:31 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 5 Mar 2015 09:05:31 +0000 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F81463.7000903@oracle.com> References: <54F7ADCE.50900@oracle.com> <54F81463.7000903@oracle.com> Message-ID: On 5 Mar 2015, at 08:31, Alan Bateman wrote: > On 05/03/2015 01:13, Mandy Chung wrote: >> : >> >> Separate webrevs for each issue: >> 1. pack200, unpack200 to jdk.pack200 >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ > I think this looks okay. In the unshuffle_list (for back/forward porting patches) then it lists specific files, I wonder if we can move that to directories. It should be possible to reduced the following set down from: jdk/src/jdk.pack200/share/native/common-unpack/bands.cpp : jdk/src/share/native/com/sun/java/util/jar/pack/bands.cpp jdk/src/jdk.pack200/share/native/common-unpack/bands.h : jdk/src/share/native/com/sun/java/util/jar/pack/bands.h jdk/src/jdk.pack200/share/native/common-unpack/bytes.cpp : jdk/src/share/native/com/sun/java/util/jar/pack/bytes.cpp jdk/src/jdk.pack200/share/native/common-unpack/bytes.h : jdk/src/share/native/com/sun/java/util/jar/pack/bytes.h jdk/src/jdk.pack200/share/native/common-unpack/coding.cpp : jdk/src/share/native/com/sun/java/util/jar/pack/coding.cpp jdk/src/jdk.pack200/share/native/common-unpack/coding.h : jdk/src/share/native/com/sun/java/util/jar/pack/coding.h jdk/src/jdk.pack200/share/native/common-unpack/constants.h : jdk/src/share/native/com/sun/java/util/jar/pack/constants.h jdk/src/jdk.pack200/share/native/common-unpack/defines.h : jdk/src/share/native/com/sun/java/util/jar/pack/defines.h jdk/src/jdk.pack200/share/native/common-unpack/unpack.cpp : jdk/src/share/native/com/sun/java/util/jar/pack/unpack.cpp jdk/src/jdk.pack200/share/native/common-unpack/unpack.h : jdk/src/share/native/com/sun/java/util/jar/pack/unpack.h jdk/src/jdk.pack200/share/native/common-unpack/utils.cpp : jdk/src/share/native/com/sun/java/util/jar/pack/utils.cpp jdk/src/jdk.pack200/share/native/common-unpack/utils.h : jdk/src/share/native/com/sun/java/util/jar/pack/utils.h jdk/src/jdk.pack200/share/native/common-unpack/zip.cpp : jdk/src/share/native/com/sun/java/util/jar/pack/zip.cpp jdk/src/jdk.pack200/share/native/common-unpack/zip.h : jdk/src/share/native/com/sun/java/util/jar/pack/zip.h to jdk/src/jdk.pack200/share/native/common-unpack : jdk/src/share/native/com/sun/java/util/jar/pack ...since the script attempts to match the full path, before reducing. I did mean to do further reductions on this shuffle list, but it just doesn?t seem worth it now, and care needs to be taken to ensure both shuffling and unshuffling work correctly. -Chris. > I also see remnants of the tracing API in that file, I assume they can be removed. > > -Alan. From weijun.wang at oracle.com Thu Mar 5 09:13:19 2015 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 05 Mar 2015 17:13:19 +0800 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F81296.5080006@oracle.com> References: <54F7ADCE.50900@oracle.com> <54F81296.5080006@oracle.com> Message-ID: <54F81E2F.7010000@oracle.com> There is no problem the new API be in a separate module. It is independent of keytool now. Said that, I've been thinking about rewriting keytool to use this new API. --Max On 3/5/2015 16:23, Alan Bateman wrote: > On 05/03/2015 02:55, Wang Weijun wrote: >> - Move keytool to jdk.security.util, it's now in java.base but keytool >> is not part of Java SE spec (Of course, if that means keytool will be >> in JDK instead of JRE please stop. But will there will the name >> difference anymore? I am thinking of an installer like cygwin that you >> can choose anything except that java.base is checked grayed). >> >> > The reason that keytool is in java.base is so that keys and certificates > can be managed on a small runtime. It's the same reason that it is in > our compact1 builds too. I wasn't aware of JDK-8058778 but it can't > result in java.base exporting a JDK-specific API. > > -Alan From erik.joelsson at oracle.com Thu Mar 5 09:25:06 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 05 Mar 2015 10:25:06 +0100 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F7ADCE.50900@oracle.com> References: <54F7ADCE.50900@oracle.com> Message-ID: <54F820F2.8070009@oracle.com> Hello Mandy, The build changes look ok to me. /Erik On 2015-03-05 02:13, Mandy Chung wrote: > As listed in an open issue in JEP 200: > > The jdk.dev and jdk.runtime modules contain miscellaneous tools that do > not obviously belong to any other module; these modules will eventually > be either renamed or refactored. > > Currently there are jdk.javadoc, jdk.jconsole, jdk.jcmd modules in > the JDK that are organized around its primary tool. Such organization > is easy to name, document and understand. This patch proposes to > move tools from jdk.runtime and jdk.dev to jdk.pack200, jdk.jartool, > jdk.policytool modules. > > Overall Webrev that will be convenient to review the build change > and modules.xml change. > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/webrev.00/ > > Separate webrevs for each issue: > 1. pack200, unpack200 to jdk.pack200 > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ > > > 2. jar, jarsigner to jdk.jartool > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074429/webrev.00/ > > > 3. policytool to jdk.policytool > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074430/webrev.00/ > > > There are remaining tools in jdk.dev that will be handled separately. > jdk.dev will disappear when all of the remaining tools find its home. > > Mandy > From Alan.Bateman at oracle.com Thu Mar 5 16:07:04 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 05 Mar 2015 16:07:04 +0000 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F7ADCE.50900@oracle.com> References: <54F7ADCE.50900@oracle.com> Message-ID: <54F87F28.2080904@oracle.com> On 05/03/2015 01:13, Mandy Chung wrote: > : > > 2. jar, jarsigner to jdk.jartool > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074429/webrev.00/ > > It seems reasonable to have both jar and jarsigner in the same module so I think this is good. This will also work if Max adds an API to the jarsigner tool as he mentioned in one of the mails. -Alan From mandy.chung at oracle.com Thu Mar 5 16:19:23 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 05 Mar 2015 08:19:23 -0800 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F81463.7000903@oracle.com> References: <54F7ADCE.50900@oracle.com> <54F81463.7000903@oracle.com> Message-ID: <54F8820B.2050201@oracle.com> On 3/5/2015 12:31 AM, Alan Bateman wrote: > On 05/03/2015 01:13, Mandy Chung wrote: >> : >> >> Separate webrevs for each issue: >> 1. pack200, unpack200 to jdk.pack200 >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ >> > I think this looks okay. In the unshuffle_list (for back/forward > porting patches) then it lists specific files, I wonder if we can move > that to directories. I also see remnants of the tracing API in that > file, I assume they can be removed. I also notice the tracing API left in unshuffle_list should be removed. At some point the entire jdk.dev should go away and so I'm thinking to leave this cleanup for the removal of jdk.dev. Mandy From mandy.chung at oracle.com Thu Mar 5 17:55:44 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 05 Mar 2015 09:55:44 -0800 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F81E2F.7010000@oracle.com> References: <54F7ADCE.50900@oracle.com> <54F81296.5080006@oracle.com> <54F81E2F.7010000@oracle.com> Message-ID: <54F898A0.90707@oracle.com> Max, Since the new APIs you're working on are still in design phase, I think it's a bit early to discuss where these new APIs should be in. Just one thing to say about the new JarSigner API from your webrev. com.sun.jarsigner is an existing exported package that you should consider whether the new APIs should be added there rather than a new package. Anyway, we can discuss that when your work is further along. For this review request, are you okay with this patch moving policytool and jarsigner tools to the new home? Mandy [1] http://hg.openjdk.java.net/jdk9/dev/jdk/file/85b61f4eee66/src/jdk.dev/share/classes/com/sun/jarsigner/package-info.java On 3/5/15 1:13 AM, Weijun Wang wrote: > There is no problem the new API be in a separate module. It is > independent of keytool now. > > Said that, I've been thinking about rewriting keytool to use this new > API. > > --Max > > On 3/5/2015 16:23, Alan Bateman wrote: >> On 05/03/2015 02:55, Wang Weijun wrote: >>> - Move keytool to jdk.security.util, it's now in java.base but keytool >>> is not part of Java SE spec (Of course, if that means keytool will be >>> in JDK instead of JRE please stop. But will there will the name >>> difference anymore? I am thinking of an installer like cygwin that you >>> can choose anything except that java.base is checked grayed). >>> >>> >> The reason that keytool is in java.base is so that keys and certificates >> can be managed on a small runtime. It's the same reason that it is in >> our compact1 builds too. I wasn't aware of JDK-8058778 but it can't >> result in java.base exporting a JDK-specific API. >> >> -Alan From weijun.wang at oracle.com Fri Mar 6 01:16:46 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 6 Mar 2015 09:16:46 +0800 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F898A0.90707@oracle.com> References: <54F7ADCE.50900@oracle.com> <54F81296.5080006@oracle.com> <54F81E2F.7010000@oracle.com> <54F898A0.90707@oracle.com> Message-ID: <8BCFD039-161B-42EE-9638-6E81E3B62F0C@oracle.com> > On Mar 6, 2015, at 01:55, Mandy Chung wrote: > > For this review request, are you okay with this patch moving policytool and jarsigner tools to the new home? Yes. --Max From magnus.ihse.bursie at oracle.com Fri Mar 6 14:33:28 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 06 Mar 2015 15:33:28 +0100 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54F820F2.8070009@oracle.com> References: <54F7ADCE.50900@oracle.com> <54F820F2.8070009@oracle.com> Message-ID: <54F9BAB8.1070601@oracle.com> On 2015-03-05 10:25, Erik Joelsson wrote: > Hello Mandy, > > The build changes look ok to me. Build changes are OK for me too. /Magnus > > /Erik > > On 2015-03-05 02:13, Mandy Chung wrote: >> As listed in an open issue in JEP 200: >> >> The jdk.dev and jdk.runtime modules contain miscellaneous tools that do >> not obviously belong to any other module; these modules will eventually >> be either renamed or refactored. >> >> Currently there are jdk.javadoc, jdk.jconsole, jdk.jcmd modules in >> the JDK that are organized around its primary tool. Such organization >> is easy to name, document and understand. This patch proposes to >> move tools from jdk.runtime and jdk.dev to jdk.pack200, jdk.jartool, >> jdk.policytool modules. >> >> Overall Webrev that will be convenient to review the build change >> and modules.xml change. >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/webrev.00/ >> >> >> Separate webrevs for each issue: >> 1. pack200, unpack200 to jdk.pack200 >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ >> >> >> 2. jar, jarsigner to jdk.jartool >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074429/webrev.00/ >> >> >> 3. policytool to jdk.policytool >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074430/webrev.00/ >> >> >> There are remaining tools in jdk.dev that will be handled separately. >> jdk.dev will disappear when all of the remaining tools find its home. >> >> Mandy >> > From mandy.chung at oracle.com Fri Mar 13 18:37:36 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 13 Mar 2015 11:37:36 -0700 Subject: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules In-Reply-To: <54FF28A4.9080303@oracle.com> References: <54F7ADCE.50900@oracle.com> <54FF28A4.9080303@oracle.com> Message-ID: <55032E70.1040302@oracle.com> This module contains both pack200 and unpack200 tools although it only contains the native implementation of unpacker. Naming it as jdk.unpack200 would give an impression that it contains the unpacker only which isn't the case. Like the API java.util.jar.Pack200 class, it's about Pack200 format and it has both Pack200.Packer and Pack200.Unpacker nested interfaces jdk.pack200 represents the tools for Pack200 format that sounds fine to me. Mandy On 3/10/2015 10:23 AM, Kumar Srinivasan wrote: > The changes look ok to me, however I am wondering if the module > could be called jdk.unpack200 and not jdk.pack200 ? since it > contains only the unpacker, and the bin utilities are pack200 and > unpack200. > > Kumar > > On 3/4/2015 5:13 PM, Mandy Chung wrote: >> As listed in an open issue in JEP 200: >> >> The jdk.dev and jdk.runtime modules contain miscellaneous tools that do >> not obviously belong to any other module; these modules will eventually >> be either renamed or refactored. >> >> Currently there are jdk.javadoc, jdk.jconsole, jdk.jcmd modules in >> the JDK that are organized around its primary tool. Such organization >> is easy to name, document and understand. This patch proposes to >> move tools from jdk.runtime and jdk.dev to jdk.pack200, jdk.jartool, >> jdk.policytool modules. >> >> Overall Webrev that will be convenient to review the build change >> and modules.xml change. >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/webrev.00/ >> >> >> Separate webrevs for each issue: >> 1. pack200, unpack200 to jdk.pack200 >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/ >> >> >> 2. jar, jarsigner to jdk.jartool >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074429/webrev.00/ >> >> >> 3. policytool to jdk.policytool >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074430/webrev.00/ >> >> >> There are remaining tools in jdk.dev that will be handled separately. >> jdk.dev will disappear when all of the remaining tools find its home. >> >> Mandy >> > From somerealquestion at gmail.com Thu Mar 19 22:42:44 2015 From: somerealquestion at gmail.com (Edward Nigma) Date: Thu, 19 Mar 2015 23:42:44 +0100 Subject: Modular soruce code resolving Message-ID: Hi all, I have concern about Jigsaw project skipping some problems with source binding. I think that modular source code distribution may be overlooked and raise into issue. OSGi solves this partially with per bundle directory: OSGI-OPT/src. With introduction of jimage, source archive may contain ambiguous entries (multiple version). If jimage allow distribution of multiple module versions then sources in zip should too. Remember also that there is still no standard way to distribute encoding info with sources archive. Are there any plans to specify this with Jigsaw? With regards. From Alan.Bateman at oracle.com Fri Mar 20 08:13:03 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Mar 2015 08:13:03 +0000 Subject: Modular soruce code resolving In-Reply-To: References: Message-ID: <550BD68F.6020709@oracle.com> On 19/03/2015 22:42, Edward Nigma wrote: > With introduction of jimage, source archive may contain > ambiguous entries (multiple version). If jimage allow distribution of > multiple module versions then sources in zip should too. > Just on this comment, are you specifically talking about src.zip in the top-level directory of the JDK? JDK-8062810 is tracking whether this should be re-examined. We know at least some IDEs open it so we've been slow to change the layout. -Alan From weijun.wang at oracle.com Fri Mar 20 14:39:04 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 20 Mar 2015 22:39:04 +0800 Subject: RFR 8047789: auth.login.LoginContext needs to be updated to work with modules Message-ID: <83DE38C5-ED13-46A4-A75E-7D8748B2EFC9@oracle.com> Please review the code changes at http://cr.openjdk.java.net/~weijun/8047789/webrev.03/ LoginContext is updated to use ServiceLoader to load configured LoginModules, and fallback to reflection if it cannot find one. Please notice that the fix does not include configuration of existing LoginModules since the current jdk9/dev module system does not support multiple modules implementing the same interface. Suppose it does, these 2 extra files will do the configuration: src/jdk.security.auth/META-INF/services/javax.security.auth.spi.LoginModule com.sun.security.auth.module.Krb5LoginModule com.sun.security.auth.module.UnixLoginModule com.sun.security.auth.module.JndiLoginModule com.sun.security.auth.module.KeyStoreLoginModule com.sun.security.auth.module.LdapLoginModule com.sun.security.auth.module.NTLoginModule src/java.management/META-INF/services/javax.security.auth.spi.LoginModule com.sun.jmx.remote.security.FileLoginModule I am hearing that jigsaw will provide a new way for service configuration. Compatibility issue: Before this code change, any class that includes the necessary methods (initialize, login, logout, abort, commit) can be configured as a login module, which does not necessarily implement the LoginModule interface itself. After this code change, it must implement the interface. We might need to update the JAAS programming guide in Java SE documentation to describe the new loading mechanism. Thanks Max From Alan.Bateman at oracle.com Fri Mar 20 15:38:35 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 20 Mar 2015 15:38:35 +0000 Subject: RFR 8047789: auth.login.LoginContext needs to be updated to work with modules In-Reply-To: <83DE38C5-ED13-46A4-A75E-7D8748B2EFC9@oracle.com> References: <83DE38C5-ED13-46A4-A75E-7D8748B2EFC9@oracle.com> Message-ID: <550C3EFB.50401@oracle.com> On 20/03/2015 14:39, Wang Weijun wrote: > Please review the code changes at > > http://cr.openjdk.java.net/~weijun/8047789/webrev.03/ > > LoginContext is updated to use ServiceLoader to load configured LoginModules, and fallback to reflection if it cannot find one. Please notice that the fix does not include configuration of existing LoginModules since the current jdk9/dev module system does not support multiple modules implementing the same interface. Suppose it does, these 2 extra files will do the configuration: > > Just to clarify this, there isn't a module system in JDK 9 yet. The issue here is just having several resources named META-INF/services/javax.security.auth.spi.LoginModule as the build needs to concatenate the entries to create one services configuration file. This is a temporary issue of course and same named resources won't be an issue once all resources in the jimage container are keyed on module. Also as you said, we don't expect services configuration files will be needed anyway. -Alan. From mandy.chung at oracle.com Fri Mar 20 20:12:39 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 20 Mar 2015 13:12:39 -0700 Subject: RFR 8047789: auth.login.LoginContext needs to be updated to work with modules In-Reply-To: <83DE38C5-ED13-46A4-A75E-7D8748B2EFC9@oracle.com> References: <83DE38C5-ED13-46A4-A75E-7D8748B2EFC9@oracle.com> Message-ID: <550C7F37.8050206@oracle.com> On 3/20/15 7:39 AM, Wang Weijun wrote: > Please review the code changes at > > http://cr.openjdk.java.net/~weijun/8047789/webrev.03/ It looks okay to me. Removing some use of reflection seems a good thing. One observation: invoke(String methodName) now calls the method statically and the implementation has conditional code depending on which of the four methods. It seems that you could do some refactoring to define 4 different methods for example: 571 invokePriv(LOGIN_METHOD) -> invokeLoginMethod This is an separate issue. Just to mention for future cleanup to consider. Mandy From Alan.Bateman at oracle.com Sat Mar 21 10:54:19 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 21 Mar 2015 10:54:19 +0000 Subject: RFR 8047789: auth.login.LoginContext needs to be updated to work with modules In-Reply-To: <83DE38C5-ED13-46A4-A75E-7D8748B2EFC9@oracle.com> References: <83DE38C5-ED13-46A4-A75E-7D8748B2EFC9@oracle.com> Message-ID: <550D4DDB.6080303@oracle.com> On 20/03/2015 14:39, Wang Weijun wrote: > Please review the code changes at > > http://cr.openjdk.java.net/~weijun/8047789/webrev.03/ > > : > > Compatibility issue: Before this code change, any class that includes the necessary methods (initialize, login, logout, abort, commit) can be configured as a login module, which does not necessarily implement the LoginModule interface itself. After this code change, it must implement the interface. > > We might need to update the JAAS programming guide in Java SE documentation to describe the new loading mechanism. > I think the changes look reasonable too. A minor suggestion is to change the existing comment "instantiate the LoginModule" to "locate and instantiate ...". On the compatibility issue then someone creating a JAAS configuration file that lists a that is not a LoginModule will cause CCE but this pops out as a LoginException with the CCE as cause now - right? This may be something for release notes. It would be good to get the JAAS documentation updated too. -Alan From peter.firmstone at zeus.net.au Sat Mar 21 12:12:44 2015 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sat, 21 Mar 2015 22:12:44 +1000 Subject: Policy providers in Java 9 Message-ID: <1426939964.1666.8.camel@Nokia-N900> Just wondering, with the removal of the extensions directory, what's the correct way of specifying a policy provider? We currently have a number of nested policy providers that are loaded by the extension classloader. Thanks, Peter. From mandy.chung at oracle.com Sun Mar 22 00:48:40 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 21 Mar 2015 17:48:40 -0700 Subject: Policy providers in Java 9 In-Reply-To: <1426939964.1666.8.camel@Nokia-N900> References: <1426939964.1666.8.camel@Nokia-N900> Message-ID: <550E1168.7040203@oracle.com> On 3/21/2015 5:12 AM, Peter Firmstone wrote: > Just wondering, with the removal of the extensions directory, what's the correct way of specifying a policy provider? > > We currently have a number of nested policy providers that are loaded by the extension classloader. Do you set the custom policy provider by setting -Dpolicy.provider system property? One suggested way is to put the providers on -classpath and loaded by the application class loader. There are some SPIs that need adjustment to support loading the providers by the application class loader and the policy SPI should also be updated in JDK 9. I'm including the security lead Sean Mullan to recommend other ways. Mandy From peter.firmstone at zeus.net.au Sun Mar 22 02:07:11 2015 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Sun, 22 Mar 2015 12:07:11 +1000 Subject: Policy providers in Java 9 In-Reply-To: <550E1168.7040203@oracle.com> References: <1426939964.1666.8.camel@Nokia-N900> <550E1168.7040203@oracle.com> Message-ID: <1426990031.2869.5.camel@Nokia-N900> Thanks Mandy, replies inline... ----- Original message ----- > > > On 3/21/2015 5:12 AM, Peter Firmstone wrote: > > Just wondering, with the removal of the extensions directory, what's > > the correct way of specifying a policy provider? > > > > We currently have a number of nested policy providers that are loaded > > by the extension classloader. > > Do you set the custom policy provider by setting -Dpolicy.provider > system property? Yes, and also defining the extension dirs property. Our providers pre date the SPI mechanism; they have additional methods for dynamic permission grants, so can't use the spi unfortunately. > > One suggested way is to put the providers on -classpath and loaded > by the application class loader. I haven't tried it yet; our providers were written by Sun, the same people that worked on the JVM. I suspect the reason for using the extension classloader was to avoid circular execution paths that cause stack overflow errors. I'll give the application classloader a shot and get back to you. P.S. Our providers don't use CodeSource.implies, we have other mechanisms that use RFC3986 compliant URI; so we already have compatibility with the new jrt URL scheme. The new jrt scheme will also benefit our software by removing local file paths from class resolution. > > There are some SPIs that need adjustment to support loading the > providers by the application class loader and the policy SPI > should also be updated in JDK 9.? I'm including the security lead > Sean Mullan to recommend other ways. > > Mandy > From Alan.Bateman at oracle.com Mon Mar 23 11:30:10 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 23 Mar 2015 11:30:10 +0000 Subject: Policy providers in Java 9 In-Reply-To: <550E1168.7040203@oracle.com> References: <1426939964.1666.8.camel@Nokia-N900> <550E1168.7040203@oracle.com> Message-ID: <550FF942.9040705@oracle.com> On 22/03/2015 00:48, Mandy Chung wrote: > : > > There are some SPIs that need adjustment to support loading the > providers by the application class loader and the policy SPI > should also be updated in JDK 9. Right, there are a few areas that need to be updated. In the case of java.security.Policy then it appears to have never specified how the policy provider is located. From what I can tell then it used to only load it via the boot loader but was relaxed later to allow for policy providers that are "installed" into the run-time image and loaded by the extension loader. This needs to be re-examined now and also re-examined to see how it will work with modules going forward. -Alan From weijun.wang at oracle.com Tue Mar 24 10:13:32 2015 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 24 Mar 2015 18:13:32 +0800 Subject: RFR 8047789: auth.login.LoginContext needs to be updated to work with modules In-Reply-To: <550D4DDB.6080303@oracle.com> References: <83DE38C5-ED13-46A4-A75E-7D8748B2EFC9@oracle.com> <550D4DDB.6080303@oracle.com> Message-ID: <310D4B79-8ABF-4656-A246-6710B69EB65A@oracle.com> > On Mar 21, 2015, at 18:54, Alan Bateman wrote: > > On the compatibility issue then someone creating a JAAS configuration file that lists a that is not a LoginModule will cause CCE but this pops out as a LoginException with the CCE as cause now - right? This may be something for release notes. Correct. Added. --Max From sean.mullan at oracle.com Wed Mar 25 19:17:18 2015 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 25 Mar 2015 15:17:18 -0400 Subject: RFR 8047789: auth.login.LoginContext needs to be updated to work with modules In-Reply-To: <550D4DDB.6080303@oracle.com> References: <83DE38C5-ED13-46A4-A75E-7D8748B2EFC9@oracle.com> <550D4DDB.6080303@oracle.com> Message-ID: <551309BE.6050108@oracle.com> On 03/21/2015 06:54 AM, Alan Bateman wrote: > On 20/03/2015 14:39, Wang Weijun wrote: >> Please review the code changes at >> >> http://cr.openjdk.java.net/~weijun/8047789/webrev.03/ >> This looks good to me too. > It would be good to get the JAAS documentation updated too. Yes, we should update the specification of the JavaLoginConfig type and the relevant JAAS tutorials and programming guides to describe the use of ServiceLoader to find LoginModule implementations. Can you file a followon issue in the docs/guides component and add a "securitydocs" label? --Sean