Re: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied

[Sean Mullan]

Couple of comments:

- jdk.vm.ci is already loaded by the boot loader so it is implicitly 
granted AllPermission and does not need an entry in default.policy.


- all internal APIs in the jdk.vm.compiler module will now be restricted 
by default by SecurityManager::checkPackageAccess(), so if you have any 
code or tests running with a SecurityManager that are accessing internal 
APIs in the jdk.vm.compiler module, you will need to grant them an 
appropriate "accessClassInPackage" RuntimePermission in addition to any 
--add-exports option you are using to break through encapsulation.


--Sean

On 2/1/17 6:07 AM, Doug Simon wrote:

I’ve reworked the webrev as requested to make jdk.vm.compiler a non-upgradeable 
platform module, this allowing it to be mentioned in default.policy:

http://cr.openjdk.java.net/~dnsimon/8145337/

-Doug


On 30 Jan 2017, at 22:53, Mandy Chung  wrote:



On Jan 30, 2017, at 1:36 PM, Doug Simon  wrote:



On 30 Jan 2017, at 21:55, Mandy Chung  wrote:



On Jan 30, 2017, at 10:38 AM, Doug Simon  wrote:

I’ve extended the webrev with that change - please re-review:

http://cr.openjdk.java.net/~dnsimon/8145337_make/webrev



+1


Thanks. Is that a “Reviewed”?



Sorry. I only noticed now that you added this to UPGRADEABLE_MODULE.   Please 
add it only to PLATFORM_MODULES list instead.

Making it an upgradeable module is a separate issue.  I suggest you reopen 
JDK-8171448.  Specifically, since upgradeable modules are not tied with 
java.base, our goal for JDK 9 is to eliminate qualified exports from JDK 
modules to upgradeable modules, e.g. JDK-8170116, JDK-8166745, JDK-8161549.


I think I should get at least one sign-off from the security team.



Hope Sean will review this one.  Please send an updated webrev.


Also, since this is effectively making jdk.vm.compiler an upgradeable module,


No it does not.


what’s the implication for it being a hash-checked module?


When a module M is recorded in the ModuleHashes attribute of java.base, the 
runtime will check if module M resolved in the graph matches the one tied with 
java.base when created at build time; if not, it will fail.  If an upgradeable 
module


It seems like these changes effectively achieve what I was requesting with 
https://bugs.openjdk.java.net/browse/JDK-8171448.


JDK-8145337 is about the security permission.  It’s better to separate this 
review from JDK-8171448.

Mandy



-Doug




Strangely, there was no existing declaration of jdk.vm.compiler in Modules.gmk.



Default is to be defined by the application class loader.  The build will find 
all modules from the source. There is no need to list all modules.


BTW, I never answered your question:

"How does JVMCI call out to jdk.vm.compiler?  does it load classes using 
Class::forName with the system class loader?”

It uses JVMCIServiceLocator[1] which is a mechanism built on the standard 
ServiceLoader.


Thanks for the pointer. That confirms my understanding that loads the service 
providers using the system class loader.

Mandy

Re: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied

[Sean Mullan]

On 2/1/17 4:27 PM, Doug Simon wrote:

Can I now consider this change reviewed and integrate it?


Yes.

--Sean

Re: JPMS Access Checks, Verification and the Security Manager

[Sean Mullan]

On 5/23/17 10:44 AM, Volker Simonis wrote:

The other question is if '--add-exports' should implicitly grant the
corresponding security permissions? I understand that package/class
visibility and security checks are somewhat orthogonal concepts so I
tend to agree with the current functionality (and a part of this
problem is now tracked by JDK-8174766). Nevertheless it is probably
wise to document these differences so people won't get surprised.


We considered it but the SecurityManager checks all callers (and not 
just the target module) on the stack for the appropriate 
accessClassInPackage RuntimePermission. Also, 
SecurityManager.checkPackageAccess does not know what the target module 
is, all it has is the package name. It is possible however that we could 
respect the module access rights when loading classes in the internal 
ClassLoader.checkPackageAccess method. I will be looking more into this 
in the JDK 10 timeframe.


The current javadoc of SecurityManager.checkPackageAccess [1] does 
document this behavior:


"This implementation also restricts all non-exported packages of modules 
loaded by the platform class loader or its ancestors. A "non-exported 
package" refers to a package that is not exported to all modules. 
Specifically, it refers to a package that either is not exported at all 
by its containing module or is exported in a qualified fashion by its 
containing module."


--Sean

[1] 
http://download.java.net/java/jdk9/docs/api/java/lang/SecurityManager.html#checkPackageAccess-java.lang.String-

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

[Sean Mullan]

On 02/18/2016 03:10 AM, Weijun Wang wrote:

There is another compatibility issue which is more important:

Today, we tell users to load their own PKCS11 provider with

   -providerClass sun.security.pkcs11.SunPKCS11 -providerArg some.cfg

and seems the new options should be

   -provider SunPKCS11 -providerArg some.cfg


I thought I had opened a docs bug for that, but I can't find it now. So 
I will add a comment to https://bugs.openjdk.java.net/browse/JDK-8075902 
that it should also be updated as part of that bug.


--Sean

Re: Initial webrev with changes for JDK 9

[Sean Mullan]

Myself (mullan), Tony (ascarpino), and Vinnie (vinnie) reviewed the 
security-libs and java.naming changes and did not find any issues. So 
it's good to go from our perspective.


--Sean

On 03/11/2016 04:39 AM, Alan Bateman wrote:


I've refreshed the webrevs here:
http://cr.openjdk.java.net/~alanb/8142968/2

so that we have a snapshot of what is currently in the jigsaw/jake
forest. The webrevs are against jdk-9+109.

As I said in the last mail, we would like to integrate this snapshot
into JDK 9 before the end of March. The proposal is to aim to integrate
during the week of March 21, with the the week of March 28 as fallback
in event of problems.

The related JEPs (JEP 200, JEP 260, JEP 261 and JEP 282) are now in
"Proposed to Target" state. Mark send mail to jdk9-dev with this list
and other proposals yesterday.

-Alan

Re: Strange test failure when referencing a class in a deprivileged module

[Sean Mullan]

On 07/06/2016 04:51 AM, Alan Bateman wrote:

On 06/07/2016 05:32, Weijun Wang wrote:



On 7/5/2016 23:50, Mandy Chung wrote:

Max - are you running the test with exploded image (see JDK-8155858
[1])?


No. The test also fails with recent promoted builds (ever since
java.sql is de-priveleged).

I assume this is a general issue with security manager implementations
where the checkPermission implementation triggers permission checks and
so leads to stack overflow (and depending on the area can surface with
different errors or exceptions). Do we have older issues on this?


Yes. Typically you can avoid these by either putting the custom SM on 
the bootclasspath or granting it AllPermission, or implementing a policy 
provider that checks if the caller's ProtectionDomain is the same as the 
custom SM.


This one is a little different though. I will need to look into it some 
more.


Does your SSL code match up with the stack trace? The test only has 27 
lines, but the stack trace says it was called from line 42.


--Sean

Re: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned

[Sean Mullan]

On 11/7/16 9:13 AM, Jim Laskey (Oracle) wrote:

The bug https://bugs.openjdk.java.net/browse/JDK-8159393
 is really about
warning developers that their image does not support signing.  If
they are okay with that then they can override with
--strip-signing-information.


I find the option name --strip-signing-information a little bit 
confusing. To me this implies jlink might remove the signature 
information from the original signed modular JAR, which is not what you 
are doing, correct? Why not call it "--ignore-signing-information"?


--Sean



— Jim




On Nov 7, 2016, at 10:11 AM, Jim Laskey (Oracle)
 wrote:

The security entries are (have been) ignored when building the
image.  At some future date (post-9), we need to decide how to sign
an image.

— Jim



On Nov 7, 2016, at 10:06 AM, Wang Weijun 
wrote:

The code block below checking if a jar file was signed is
correct.

There is one thing I don't understand, the
--strip-signing-information option. It looks like you will remove
the signature-related files if this option is set. But, where are
they stripped?

Thanks Max

On 11/7/2016 9:48 PM, Jim Laskey (Oracle) wrote:

Apologies for the poor links earlier.

http://cr.openjdk.java.net/~jlaskey/8159393/webrev/index.html
https://bugs.openjdk.java.net/browse/JDK-8159393



On Nov 7, 2016, at 9:26 AM, Jim Laskey (Oracle)
 wrote:

Revising to

String name = entry.name().toUpperCase(Locale.ENGLISH);

return name.startsWith("META-INF/") && name.indexOf('/', 9)
== -1 && ( name.endsWith(".SF") || name.endsWith(".DSA") ||
name.endsWith(".RSA") || name.endsWith(".EC") ||
name.startsWith("META-INF/SIG-") );



On Nov 7, 2016, at 9:17 AM, Jim Laskey (Oracle)
 wrote:

Right.  From SignatureFileVerifier.java


/** * Utility method used by JarVerifier and JarSigner * to
determine the signature file names and PKCS7 block * files
names that are supported * * @param s file name * @return
true if the input file name is a supported *
Signature File or PKCS7 block file name */ public static
boolean isBlockOrSF(String s) { // we currently only
support DSA and RSA PKCS7 blocks return s.endsWith(".SF")
|| s.endsWith(".DSA") || s.endsWith(".RSA") ||
s.endsWith(".EC"); }

/** * Yet another utility method used by JarVerifier and
JarSigner * to determine what files are signature related,
which includes * the MANIFEST, SF files, known signature
block files, and other * unknown signature related files
(those starting with SIG- with * an optional [A-Z0-9]{1,3}
extension right inside META-INF). * * @param name file
name * @return true if the input file name is signature
related */ public static boolean isSigningRelated(String
name) { name = name.toUpperCase(Locale.ENGLISH); if
(!name.startsWith("META-INF/")) { return false; } name =
name.substring(9); if (name.indexOf('/') != -1) { return
false; } if (isBlockOrSF(name) ||
name.equals("MANIFEST.MF")) { return true; } else if
(name.startsWith("SIG-")) { // check filename extension //
see
http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Digital_Signatures



// for what filename extensions are legal

int extIndex = name.lastIndexOf('.'); if (extIndex != -1)
{ String ext = name.substring(extIndex + 1); // validate
length first if (ext.length() > 3 || ext.length() < 1) {
return false; } // then check chars, must be in [a-zA-Z0-9]
per the jar spec for (int index = 0; index < ext.length();
index++) { char cc = ext.charAt(index); // chars are
promoted to uppercase so skip lowercase checks if ((cc <
'A' || cc > 'Z') && (cc < '0' || cc > '9')) { return
false; } } } return true; // no extension is OK } return
false; }






On Nov 7, 2016, at 9:16 AM, Alan Bateman
 wrote:

On 07/11/2016 13:09, Jim Laskey (Oracle) wrote:


Thank you.  Regarding SIG- I was just followed the
spec.


I hope Sean or Max can jump in on this, the other
question is .EC as I believe the JDK allows this when
signing too.

-Alan

Re: RFR: 8159393 - jlink should print a warning that a signed modular JAR will be treated as unsigned

[Sean Mullan]

On 11/7/16 11:21 AM, Sundararajan Athijegannathan wrote:

Looks good to me.

PS. jmods, jars are not modified by jlink. Only a new image directory is
generated. So, strip-signing-info confusion is unlikely.


I still find it confusing. If I saw that option, I would hesitate to use 
it until I was sure it would not strip the signature from my JAR file. 
Best to rename it to avoid confusion.


--Sean



-Sundar


On 11/7/2016 9:36 PM, Sean Mullan wrote:

On 11/7/16 9:13 AM, Jim Laskey (Oracle) wrote:

The bug https://bugs.openjdk.java.net/browse/JDK-8159393
<https://bugs.openjdk.java.net/browse/JDK-8159393> is really about
warning developers that their image does not support signing.  If
they are okay with that then they can override with
--strip-signing-information.


I find the option name --strip-signing-information a little bit
confusing. To me this implies jlink might remove the signature
information from the original signed modular JAR, which is not what
you are doing, correct? Why not call it "--ignore-signing-information"?

--Sean



— Jim




On Nov 7, 2016, at 10:11 AM, Jim Laskey (Oracle)
 wrote:

The security entries are (have been) ignored when building the
image.  At some future date (post-9), we need to decide how to sign
an image.

— Jim



On Nov 7, 2016, at 10:06 AM, Wang Weijun 
wrote:

The code block below checking if a jar file was signed is
correct.

There is one thing I don't understand, the
--strip-signing-information option. It looks like you will remove
the signature-related files if this option is set. But, where are
they stripped?

Thanks Max

On 11/7/2016 9:48 PM, Jim Laskey (Oracle) wrote:

Apologies for the poor links earlier.

http://cr.openjdk.java.net/~jlaskey/8159393/webrev/index.html
https://bugs.openjdk.java.net/browse/JDK-8159393



On Nov 7, 2016, at 9:26 AM, Jim Laskey (Oracle)
 wrote:

Revising to

String name = entry.name().toUpperCase(Locale.ENGLISH);

return name.startsWith("META-INF/") && name.indexOf('/', 9)
== -1 && ( name.endsWith(".SF") || name.endsWith(".DSA") ||
name.endsWith(".RSA") || name.endsWith(".EC") ||
name.startsWith("META-INF/SIG-") );



On Nov 7, 2016, at 9:17 AM, Jim Laskey (Oracle)
 wrote:

Right.  From SignatureFileVerifier.java


/** * Utility method used by JarVerifier and JarSigner * to
determine the signature file names and PKCS7 block * files
names that are supported * * @param s file name * @return
true if the input file name is a supported *
Signature File or PKCS7 block file name */ public static
boolean isBlockOrSF(String s) { // we currently only
support DSA and RSA PKCS7 blocks return s.endsWith(".SF")
|| s.endsWith(".DSA") || s.endsWith(".RSA") ||
s.endsWith(".EC"); }

/** * Yet another utility method used by JarVerifier and
JarSigner * to determine what files are signature related,
which includes * the MANIFEST, SF files, known signature
block files, and other * unknown signature related files
(those starting with SIG- with * an optional [A-Z0-9]{1,3}
extension right inside META-INF). * * @param name file
name * @return true if the input file name is signature
related */ public static boolean isSigningRelated(String
name) { name = name.toUpperCase(Locale.ENGLISH); if
(!name.startsWith("META-INF/")) { return false; } name =
name.substring(9); if (name.indexOf('/') != -1) { return
false; } if (isBlockOrSF(name) ||
name.equals("MANIFEST.MF")) { return true; } else if
(name.startsWith("SIG-")) { // check filename extension //
see
http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Digital_Signatures




// for what filename extensions are legal

int extIndex = name.lastIndexOf('.'); if (extIndex != -1)
{ String ext = name.substring(extIndex + 1); // validate
length first if (ext.length() > 3 || ext.length() < 1) {
return false; } // then check chars, must be in [a-zA-Z0-9]
per the jar spec for (int index = 0; index < ext.length();
index++) { char cc = ext.charAt(index); // chars are
promoted to uppercase so skip lowercase checks if ((cc <
'A' || cc > 'Z') && (cc < '0' || cc > '9')) { return
false; } } } return true; // no extension is OK } return
false; }






On Nov 7, 2016, at 9:16 AM, Alan Bateman
 wrote:

On 07/11/2016 13:09, Jim Laskey (Oracle) wrote:


Thank you.  Regarding SIG- I was just followed the
spec.


I hope Sean or Max can jump in on this, the other
question is .EC as I believe the JDK allows this when
signing too.

-Alan

Re: CFV: New Jigsaw Committer: Mike Duigou

[Sean Mullan]

Vote: yes

--Sean

On 08/05/2014 07:14 PM, Mandy Chung wrote:

I hereby nominate Mike Duigou (aka mduigou) to Jigsaw Committer.

Mike has been a long time contributor to the JDK, making changes
and reviewing in jdk8, jdk9, lambda projects. Mike has also been
contributing many patches in the build infrastructure area and
the Code Tools.
   http://hg.openjdk.java.net/jdk9/jdk9/log?rev=mduigou
   http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?rev=mduigou

Votes are due by: Aug 19, 2014, 16:15 PDT.

Only current Jigsaw Committers [1] are eligible to vote on
this nomination.|Votes must be cast in the open by replying
to this mailing list.|

For Lazy Consensus voting instructions, see [2].

Mandy

[1] http://openjdk.java.net/census
[2] http://openjdk.java.net/projects/#committer-vote

Re: CFV: New Jigsaw Committer: Erik Joelsson

[Sean Mullan]

Vote: yes

--Sean

On 08/05/2014 07:13 PM, Mandy Chung wrote:

I hereby nominate Erik Joelsson (aka erikj) to Jigsaw Committer.

Erik is one of the main contributors to the new build system
in JDK 8 and he has reviewer role in jdk8, jdk8u, and jdk9 project.
Erik has already contributed many change sets in this project
modularizing the JDK source and enhancing the build system
to compile modules:
   http://hg.openjdk.java.net/jdk9/jdk9/log?rev=erijk
   http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?rev=erijk
   http://hg.openjdk.java.net/jigsaw/stage/log?rev=erijk

Votes are due by: Aug 19, 2014, 16:15 PDT.

Only current Jigsaw Committers [1] are eligible to vote on
this nomination.|Votes must be cast in the open by replying
to this mailing list.

|For Lazy Consensus voting instructions, see [2].

Mandy

[1] http://openjdk.java.net/census
[2] http://openjdk.java.net/projects/#committer-vote

Re: CFV: New Jigsaw Committer: Jim Laskey

[Sean Mullan]

Vote: yes

On 11/03/2014 09:02 AM, Alan Bateman wrote:

I hereby nominate Jim Laskey to Jigsaw Committer.

Jim is lead for Project Nashorn and a Reviewer on the jdk9 and jdk8u
projects. Jim has been contributing to Project Jigsaw by way of the
jimage container format that is currently prototyped in the jigsaw/m2
forest.

Votes are due by: Nov 17, 2014, 07.00 PST. Only current Jigsaw
Committers [1] are eligible to vote on this nomination. Votes must be
cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [2].

-Alan.

[1] http://openjdk.java.net/census
[2] http://openjdk.java.net/projects/#committer-vote

Re: CFV: New Jigsaw Committer: Sundar Athijegannathan

[Sean Mullan]

Vote: yes

On 11/03/2014 09:02 AM, Alan Bateman wrote:

I hereby nominate Sundar Athijegannathan to Jigsaw Committer.

Sundar is currently a Reviewer on the jdk9,  jdk8u and Nashorn projects.
Sundar has been contributing to Project Jigsaw by way of the compression
support in jimage container format and also the file system provider
implementation, both of which are prototyped in the jigsaw/m2 forest.

Votes are due by: Nov 17, 2014, 07.00 PST. Only current Jigsaw
Committers [1] are eligible to vote on this nomination. Votes must be
cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [2].

-Alan.

[1] http://openjdk.java.net/census
[2] http://openjdk.java.net/projects/#committer-vote

hg: jigsaw/m2/jdk: 8062346: Drop support for ${java.ext.dirs} from java.policy

[sean . mullan]

Changeset: 115d48bc46f9
Author:mullan
Date:  2014-11-12 10:23 -0500
URL:   http://hg.openjdk.java.net/jigsaw/m2/jdk/rev/115d48bc46f9

8062346: Drop support for ${java.ext.dirs} from java.policy
Reviewed-by: mchung

! src/java.base/share/classes/sun/security/provider/PolicyFile.java
! src/java.base/share/classes/sun/security/provider/PolicyParser.java
! test/ProblemList.txt
- test/lib/security/java.policy/Ext_AllPolicy.java
- test/lib/security/java.policy/Ext_AllPolicy.sh
- test/lib/security/java.policy/test.policy

hg: jigsaw/m2: 8059003: Oracle JCE build environment: Phase 3

[sean . mullan]

Changeset: 5e90096ee2b2
Author:wetmore
Date:  2014-11-13 13:25 -0800
URL:   http://hg.openjdk.java.net/jigsaw/m2/rev/5e90096ee2b2

8059003: Oracle JCE build environment: Phase 3
Reviewed-by: mullan, alanb, erikj, mchung

! common/autoconf/generated-configure.sh
! make/Main.gmk
! make/common/SetupJavaCompilers.gmk

hg: jigsaw/m2/jdk: 8059003: Oracle JCE build environment: Phase 3

[sean . mullan]

Changeset: 2dc9ed2c59d7
Author:wetmore
Date:  2014-11-13 13:04 -0800
URL:   http://hg.openjdk.java.net/jigsaw/m2/jdk/rev/2dc9ed2c59d7

8059003: Oracle JCE build environment: Phase 3
Reviewed-by: mullan, alanb, erikj, mchung

! make/gendata/GendataPolicyJars.gmk
! src/java.base/share/classes/com/sun/net/ssl/SSLSecurity.java
! src/jdk.crypto.ec/share/classes/sun/security/ec/SunEC.java
- test/javax/crypto/sanity/CheckManifestForRelease.java

Re: RFR [JEP 220] Modular Run-Time Images

[Sean Mullan]

The JDK security related changes look fine to me. The 
test/java/net/URLPermission/policy.* files only have copyright changes 
for some reason.


--Sean


On 11/20/2014 04:41 PM, Chris Hegarty wrote:



From: Chris Hegarty 
Subject: RFR [JEP 220] Modular Run-Time Images
Date: 20 November 2014 21:39:14 GMT
To: jigsaw-dev , jdk9-dev , build-dev , Alan Bateman , 
Alex Buckley , Chris Hegarty , Erik Joelsson , Jonathan Gibbons 
, Karen Kinnear , "Jim Laskey (Oracle)" , Magnus Ihse Bursie 
, Mandy Chung , Mark Reinhold , Paul Sandoz , "A. 
Sundararajan" 

This is a review request for the changes for JEP 220: Modular Run-Time Images 
[1].

There are a number of individuals responsible for these changes. Some, possibly 
not all, are explicitly listed in the 'To' section of this mail, and they will 
help address any comments arising from this review request.

The new run-time image structure is defined in JEP 220 [1], and can be seen as 
a result of building the staging forest [2], or in the early access builds [3].

Webrevs:
   http://cr.openjdk.java.net/~chegar/8061971/00/

Due to the significant impact of these changes, a JDK 9 promotion has been 
tentatively reserved for their integration. All comments are welcome, although 
given the nature of the changes then we might have to create separate issues in 
JIRA to address some of them later in jdk9/dev.

-Chris.

[1] http://openjdk.java.net/jeps/220
[2] http://hg.openjdk.java.net/jigsaw/m2/
[3] http://openjdk.java.net/projects/jigsaw/ea

Re: Review request 8069551: Move java.security.acl from compact3 to java.base

[Sean Mullan]

Looks fine to me.

--Sean

On 01/29/2015 03:58 PM, Mandy Chung wrote:

Webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8069551/webrev.00

java.security.acl is superceded by java.security package since 1.2.

This patch proposes to move java.security.acl package to java.base
module rather than complicating the module graph with a close-to-useless
dedicated module.

Mandy

Re: [9] Review Request: 8072663: Remove the sun.security.acl package which is not used in the JDK

[Sean Mullan]

Looks fine to me (pending CCC approval).

--Sean

On 02/17/2015 03:59 PM, Jason Uh wrote:

Please review this fix, which removes the sun.security.acl package.

webrev: http://cr.openjdk.java.net/~juh/8072663/00/
jbs: http://bugs.openjdk.java.net/browse/JDK-8072663

The sun.security.acl package is the default implementation of
java.security.acl but it's not used in JDK. The JCK tests for
java.security.acl only covers the three exception classes and there are
no JDK tests for the interfaces, implying that the spec does not require
the implementation of java.security.acl interfaces. This is likely
because java.security.acl package have been superseded by classes in the
java.security package since 1.2.

Removing the sun.security.acl implementation will help offset the
increase in size to the base module that was caused by moving
java.security.acl from a separate dedicated module to java.base (see
http://bugs.openjdk.java.net/browse/JDK-8069551).

Thanks,
Jason

Re: RFR 8047789: auth.login.LoginContext needs to be updated to work with modules

[Sean Mullan]

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

Re: CFV: New Jigsaw Committer: Harold Seigel

[Sean Mullan]

Vote: yes

--Sean

On 09/11/2015 12:31 PM, Karen Kinnear wrote:


I hereby nominate Harold Seigel to Jigsaw Committer.

Harold is a member of the hotspot runtime team and a Reviewer on the jdk9 
project.
Harold has been contributing to Project Jigsaw in the hotspot runtime for over a
year, including support for the JVM_* interfaces for modules, boot class loader
support for jigsaw and handling jvm bootstrapping issues relative to jigsaw 
that are
currently prototyped in the jigsaw/jake forest.

Votes are due by: September 25, 2105 8:00 PST. Only current Jigsaw
Committers [1] are eligible to vote on this nomination. Votes must be
cast in the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [2]

thanks,
Karen
[1] http://openjdk.java.net/census
[2] http://openjdk.java.net/projects/#committer-vote

Harold's changesets for jigsaw/jake:

http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/065aac05e267
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/0f0743393dcb
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/2779b74ac808
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4399b514d1f6
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4443dde8d089
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/46f34d9a3520
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/4c251362419a
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/52aa2e30e139
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5936cfa7957f
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5b987349098f
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5d446c5f5d87
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/5fde03772024
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6742fb545950
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/68fec4452b48
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/6be1b3b68758
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/7227b4dbf763
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/83b7f458698f
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9889c393adfb
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/990036fcd63d
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9959993748a1
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9be9f81cb8e8
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/9ddaf93af7e6
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a38181c2fc6d
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a3f86617d287
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/a68fdd75403a
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/b9882cb01d60
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ccd5acdfc183
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/dba44c406ceb
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/e49914e2c4ca
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/ef26f9d82c61
http://hg.openjdk.java.net/jigsaw/jake/hotspot/rev/fb43f332125d

http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/06c7768ed452
http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/0a4072287a82
http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/200d3d2c3f9e
http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/4feb32b92512
http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/585b5b96a990
http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8ed709fbba55
http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/8fe7c0be60a2

Re: CFV: New jigsaw Committer: Jean-Francois Denise

[Sean Mullan]

Vote: yes

--Sean