Re: Does jlink work on exploded build?

Ah, when I said exploded build, I meant jdk/modules/java/base/.../*.classes. There is no native files there so I guess not supported. --Max > On Jan 11, 2560 BE, at 1:12 AM, Mandy Chung <mandy.ch...@oracle.com> wrote: > > >> On Jan 10, 2017, at 6:29 AM, Wang Weijun &l

Does jlink work on exploded build?

$ jlink --module-path ../build/windows-x64-debug/jdk/modules/ --add-modules jdk.jartool --output /tmp/jartool Error: java.lang.RuntimeException: Module jdk.jartool's descriptor returns inconsistent package set --Max

Re: Code review for jigsaw/jake -> jdk9/dev sync up

test/java/security/testlibrary/Proc.java: if (hasModules) { Stream.of(jdk.internal.misc.VM.getRuntimeArguments()) -.filter(arg -> arg.startsWith("--add-exports=")) +.filter(arg -> arg.startsWith("--add-exports=") || +

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

cle) <james.las...@oracle.com> 写道： > > 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 <weijun.w...@oracle.

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

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,

Re: How to check for an internal class in another module from java.base?

> On Nov 1, 2016, at 11:18 PM, Wang Weijun <weijun.w...@oracle.com> wrote: > > >> On Nov 1, 2016, at 11:10 PM, Alan Bateman <alan.bate...@oracle.com> wrote: >> >> >> >> On 01/11/2016 15:02, Wang Weijun wro

Re: How to check for an internal class in another module from java.base?

> On Nov 1, 2016, at 11:10 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > > > > On 01/11/2016 15:02, Wang Weijun wrote: >> HTTP Negotiate uses >> >> Class.forName("sun.net.www.protocol.http.spnego.NegotiatorImpl", true,

How to check for an internal class in another module from java.base?

HTTP Negotiate uses Class.forName("sun.net.www.protocol.http.spnego.NegotiatorImpl", true, null); to check if the implementation in java.security.jgss module is provided. It looks like this call is throwing a ClassNotFoundException now. Shall I export the package to java.base or is there any

RFR 8167181: Exported elements referring to inaccessible types in jdk.security.jgss

Please review the code change for jdk9/dev/jdk repo at http://cr.openjdk.java.net/~weijun/8167181/webrev.00 and for jdk9/dev which is simply diff --git a/make/CompileJavaModules.gmk b/make/CompileJavaModules.gmk --- a/make/CompileJavaModules.gmk +++ b/make/CompileJavaModules.gmk @@ -452,10

Re: RFR: 8163126 Wrong @modules in some of jdk/* tests

> On Aug 17, 2016, at 9:26 AM, Alexandre (Shura) Iline > wrote: > > Before the suggested fix, the test in question would fail on a system with no > jdk.crypto.pkcs11. That could be emulated by: > $ jtreg ... -javaoptions:"-limitmods jdk.jartool" >

Re: RFR 8161102: Regression test for JDK-8161101 (Recursive update error when a SecurityManager references a permission defined in a non-privileged module)

Ok, that's simpler. Code and error added as a comment to JDK-8161101. I also changed the synopsis a little because error is different when run standalone. Thanks Max > On Jul 11, 2016, at 2:15 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 11/07/2016 02:14, Wa

RFR 8161102: Regression test for JDK-8161101 (Recursive update error when a SecurityManager references a permission defined in a non-privileged module)

Hi All I filed a bug [1] on my recent finding [2] of a bug in SecurityManager. While I cannot find a fix, I'm able to provide a regression test, Therefore I created a sub-task [2] for the test. Please take a review at http://cr.openjdk.java.net/~weijun/8161102/webrev.00/ Whoever is able to

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

SecurityManager is in force, so the jvm won't lazy > load any classes that require permission checks, during the test permission > check as that will happen during the first permission check call. > > Cheers, > > Peter. > > Sent from my Samsung device. > >

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

> On Jul 7, 2016, at 4:37 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 07/07/2016 09:27, Wang Weijun wrote: > >> Like this? >> >> https://gist.github.com/wangweij/6992aaf9617b9e2f242ddf9e391ea5f6 >> >> The horizontal line is

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

Like this? https://gist.github.com/wangweij/6992aaf9617b9e2f242ddf9e391ea5f6 The horizontal line is printed on line 706 of the gist. --Max > On Jul 7, 2016, at 12:57 PM, Peter Firmstone > wrote: > > Can you change the test to call checkPermission prior to

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

I run the program directly (not from jtreg) and the result is different: Exception in thread "main" java.lang.BootstrapMethodError: call site initialization exception at SSL.checkPermission(SSL.java:21) at

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

> On Jul 7, 2016, at 5:04 AM, Sean Mullan wrote: > > 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. My local SSL.java still contains the GPL comments and I didn't paste them here.

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

> On Jul 5, 2016, at 11:53 AM, Wang Weijun <weijun.w...@oracle.com> wrote: > > The exception is at the end of this mail. The test passes if I change X.go() > to calling a method inside this class Update: any call that triggers a permission check will do. For

Re: Questions on deprivileging a module

> On Jul 5, 2016, at 2:52 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 04/07/2016 07:03, Wang Weijun wrote: > >> I am working on >> >>JDK-8159528 Deprivilege java.security.jgss, jdk.security.jgss and >> jdk.security.auth >>

Strange test failure when referencing a class in a deprivileged module

This test fails: import java.security.Permission; import java.sql.SQLPermission; public class SSL extends SecurityManager { @Override public void checkPermission(Permission perm, Object context) { checkPermission(perm); } public void checkPermission(Permission perm) {

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

ve a provider inside java.base that requires an argument, this would be useful. If you are OK with this, I will send out a webrev.04 soon. Thanks Max > On Feb 23, 2016, at 11:28 AM, Wang Weijun <weijun.w...@oracle.com> wrote: > > Webrev updated at http://cr.openjdk.java.n

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

> On Feb 26, 2016, at 1:03 AM, Sean Mullan wrote: > > 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

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

AM, Wang Weijun <weijun.w...@oracle.com> wrote: > > >>> >>> You mean not supporting all pre-loaded providers in modules, but only one >>> or two popular ones? >>> >> >> I meant not support -providerClass for arbitrary providers

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

>> >> You mean not supporting all pre-loaded providers in modules, but only one or >> two popular ones? >> > > I meant not support -providerClass for arbitrary providers loaded via service > loader. The only exception is SunPKCS11. In other words, -providerClass can > only be used to load

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

feedback from you. Please respond. Thanks Max > On Feb 19, 2016, at 6:47 PM, Wang Weijun <weijun.w...@oracle.com> wrote: > > Updated at the same URL > > http://cr.openjdk.java.net/~weijun/8130302/webrev.01 > > The help looks like this now: > > -provide

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

> On Feb 19, 2016, at 6:58 PM, Alan Bateman wrote: > > One other thing is whether we should add a section to JEP 261 on these tool > updates. I had originally assumed that the updates to these tools would > follow the module system into JDK 9 but you've turned up

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

> On Feb 19, 2016, at 5:36 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > > > On 19/02/2016 09:07, Wang Weijun wrote: >> : >> I don't want the line to be too long. Is the preferred terminal width still >> 80 now? I noticed the java help outpu

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

> On Feb 19, 2016, at 4:42 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 19/02/2016 08:22, Wang Weijun wrote: >> A new webrev at >> >>http://cr.openjdk.java.net/~weijun/8130302/webrev.01/ >> >> The options for keytool have >> &

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

A new webrev at http://cr.openjdk.java.net/~weijun/8130302/webrev.01/ The options for keytool have -provider [-providerArg ]add a provider by name -providerclass [-providerArg ] add a provider by classname (omit some words because line is too long) for jarsigner [-provider

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

> On Feb 18, 2016, at 9:21 AM, Mandy Chung <mandy.ch...@oracle.com> wrote: > >> >> On Feb 17, 2016, at 4:46 PM, Wang Weijun <weijun.w...@oracle.com> wrote: >> >> >>> On Feb 18, 2016, at 5:15 AM, Mandy Chung <mandy.ch...@oracle.com&g

Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs

I have no more comment. --Max > On Jan 3, 2016, at 3:48 PM, Sibabrata Sahoo <sibabrata.sa...@oracle.com> > wrote: > > Updated the bug title and description. > > Thanks, > Siba > > -----Original Message- > From: Wang Weijun > Sent: Sunday, January

Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs

> Thanks, > Siba > > -Original Message- > From: Wang Weijun > Sent: Monday, December 21, 2015 7:20 AM > To: Sibabrata Sahoo > Cc: Mandy Chung; Valerie Peng; jigsaw-dev@openjdk.java.net; > security-...@openjdk.java.net > Subject: Re: [9] RFR:8130360: Add tes

Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs

Then you don't need to include the "signed/unsigned" words in the bug description. --Max > On Jan 3, 2016, at 2:30 PM, Sibabrata Sahoo > wrote: > > Hi Max, > > The test is for verifying 3rd party security provider in > classpath/modulepath. I am using an empty

Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs

Tests are good. Several comments: 1. Try run something like "hg mv -A" to let Mercurial knows that you are renaming files (SecurityUtils.java and those in login/modules/src) instead of removing some old and creating some new. The current webrev does not show this. 2. It's not a good practice

Re: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs

Some comments: 1. Maybe use jdk/testlibrary/JDKToolLauncher.java to launch jarsigner? 2. You mentioned it's difficult to set a security provider in java.security file. Have you tried "-Djava.security.properties=="? It is described at the beginning of java.security. Thanks Max > On Nov 23,

Re: About 8056174: New APIs for jar signing

> On Nov 20, 2015, at 9:46 AM, Mandy Chung wrote: > > This looks okay. We will push this fix once we pull down your changeset to > jake. > > One question: is “altsignerpath” and “altsigner” properties are only for the > existing jarsigner -altsigner option to work?

About 8056174: New APIs for jar signing

I've just push the code change for this enhancement to jdk9/dev: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce33c780cfbd http://hg.openjdk.java.net/jdk9/dev/rev/882c782d7d5a In order to work with jake, these changes are needed: diff --git a/src/jdk.jartool/share/classes/module-info.java

Re: JOSM feedback on Java 7,8,9, including Jigsaw EA

> On Nov 11, 2015, at 3:24 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > > > On 11/11/2015 03:20, Wang Weijun wrote: >> Ping again. >> >> Will the future JRE only include java.se? In other words, what will the >> java.com download for non-d

Re: JOSM feedback on Java 7,8,9, including Jigsaw EA

> On Nov 11, 2015, at 5:03 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 11/11/2015 09:54, Wang Weijun wrote: >> : >> >> Here comes the question: How do I request a new module to be included in it? >> The CCC for the new module/API? >

Re: JOSM feedback on Java 7,8,9, including Jigsaw EA

Ping again. Will the future JRE only include java.se? In other words, what will the java.com download for non-developers contain? Thanks Max > On Nov 5, 2015, at 10:07 AM, Wang Weijun <weijun.w...@oracle.com> wrote: > > I was talking with Vincent off the list, but it seems be

Re: [9] RFR:8078813:Test JAAS with modules

Looks fine, and very interesting. Just some questions: 1. expectedResult is PASS in all test runs. Do you think it would be something else? Maybe compiler error and jar creation error? Could that happen? 2. Are the .class files always the same? If so, is it possible to compile them once, and

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

On Mar 21, 2015, at 18:54, Alan Bateman alan.bate...@oracle.com wrote: On the compatibility issue then someone creating a JAAS configuration file that lists a LoginModule that is not a LoginModule will cause CCE but this pops out as a LoginException with the CCE as cause now - right? This

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

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

Re: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules

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

Re: Review Request: 8074428, 8074429, 8074430 jdk.pack200, jdk.jartool, jdk.policytool modules

On Mar 5, 2015, at 11:25, Mandy Chung mandy.ch...@oracle.com 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

The future of policytool?

Hi All We are defining fine details of JDK module graph and encounter the policytool program. It is now included in JRE and depends on the java.desktop module. Our understanding is that very few people is using the tool but we are not sure how it is used. Therefore I am writing this mail

RFR 8058657: Add @jdk.Exported to com.sun.jarsigner APIs

Hi All Please review the code change at http://cr.openjdk.java.net/~weijun/8058657/webrev.00/ It includes both the dev repo and dev/jdk repo. While the change in dev/jdk is useless with today's modules environment, it is included here and will be backported into jdk8u. Thanks Max

Re: RFR 8056141: Move com.sun.security.jgss into a new module

On Aug 28, 2014, at 18:52, Alan Bateman alan.bate...@oracle.com wrote: http://cr.openjdk.java.net/~weijun/8056141/webrev.00/ Max - the main thing is that is missing in this is the update to modules.xml, this is temporary document that is checked into the top-level repo until there