uot;really a problem", but if --patch-module can be used to patch a
module, I do hope the new classes are treated exactly the same as those
existing classes.
This is similar to the case of exploded build.
--Max
> On Dec 11, 2017, at 3:20 PM, Alan Bateman wrote:
>
> On 11/12/2017
I modified a class inside the jdk.crypto.cryptoki module, compiled it with
"javac -d /tmp", and then ran a small program with
java --patch-module jdk.crypto.cryptoki=/tmp -Djava.security.manager MyProg
and it fails with
TEST RESULT: Failed. Execution failed: `main' threw exception:
java.secu
> On Sep 14, 2017, at 5:07 PM, Alan Bateman wrote:
>
> On 13/09/2017 23:12, Greg Wilkins wrote:
>> I hope this is the right group for this question. please redirect me if not.
> Probably core-libs-dev as this isn't anything to do with modules but in any
> case ...
A related question:
I know a
I don't like this default value, but I also know some people wanting it.
Is it possible to provide the default value in a file inside the conf
directory and also make it overwrite-able on the command line? Maybe
RedHat Linux can make it "permit" out-of-box and other vendors can
choose differen
Disclaimer: I am not a jigsaw expert.
The provides/uses mechanism is certainly more formal, but you can also
do http://hg.openjdk.java.net/jdk9/dev/jdk/rev/d282c1a8d20b.
--Max
On 02/15/2017 04:36 PM, Langer, Christoph wrote:
Hi Jigsaw experts,
as you might or might not know, we have an own
Sorry, wrong subject, resending.
On 01/16/2017 09:41 AM, Weijun Wang wrote:
Please review the code change at
http://cr.openjdk.java.net/~weijun/8172529/webrev.02
The validator is updated to be a PKIXValidator of the
Validator.VAR_CODE_SIGNING variant. In order to have the same output
Please review the code change at
http://cr.openjdk.java.net/~weijun/8172529/webrev.02
The validator is updated to be a PKIXValidator of the
Validator.VAR_CODE_SIGNING variant. In order to have the same output
message and exit code as before, the ValidatorException thrown when
validation fa
Hi Shura
I am looking at test/jdk/security/jarsigner/Spec.java.
IMHO, even on a Solaris, without the SunPKCS11 provider at runtime, this
test should be able to find Signature and MessageDigest implementations
from the SunRsaSign and SUN provider.
Is the new @modules dependency necessary? In
Mystery solved or problem solved? Have you fixed it somewhere else?
Thanks
Max
On 7/7/2016 17:00, Peter Firmstone wrote:
Problem solved, even though it didn't occur on Java 8, the potential for
it to occur still exists there, it's simply that Java 9 seems to have
hit this execution path, it wa
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).
--Max
OK, but with -providerClass I'd like to support a class name even if it
is already defined in a module as a service and has its own name. This
makes sure old commands still work.
The existing -providerClass takes a class name and works as before. The
-provider takes the name of a security prov
In keytool help, we will write
-providerAdd a security provider with its name
“Add a security provider by the provider’s name”
-providerArgOptional argument for -provider above
-providerClass Add a security provider with its class name
“Add a security provider b
On 2/17/2016 18:33, Alan Bateman wrote:
On 17/02/2016 01:20, Weijun Wang wrote:
:
Technically they are independent.
With -providerClass/-providerArg, the provider is added into system
and getInstance() calls (of keyStore, KeyPairGenerator, etc) can use it.
On the other hand, -providerName
On 2/16/2016 22:54, Alan Bateman wrote:
On 16/02/2016 14:44, Weijun Wang wrote:
Please review the code change at
http://cr.openjdk.java.net/~weijun/8130302/webrev.00/
I didn't abandon -providerClass and go all the way to -provideName
because -providerClass has a sub-option -provid
Please review the code change at
http://cr.openjdk.java.net/~weijun/8130302/webrev.00/
I didn't abandon -providerClass and go all the way to -provideName
because -providerClass has a sub-option -providerArg that can be used to
further configure the provider. Also I think we still need to su
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
Hi All
Please review this change at
root: http://cr.openjdk.java.net/~weijun/8071338/root/webrev.00/
jdk: http://cr.openjdk.java.net/~weijun/8071338/jdk/webrev.00/
No actual java code change, just move everything inside the
s.s.t.policytool into another module. There are other make/test chang
We have a lot of tests accessing internal classes inside sun.*. Is there
still a way to do that?
This is closed jake.
Thanks
Max
"modules.xml... Changes to this file will require review by Committers
to Project Jigsaw".
Shouldn't it be "Reviewers"?
"there is still a minor risk that the relationship between the new and
old locations of a file will not properly be recorded".
Could this happen?
--Max
On 8/6/2014 0:49,
19 matches
Mail list logo
