Looks fine to me too.
The isEquivalent() method name is not very precise IMHO, maybe hasSame()? Of
course, if has same is what isEquivalent means then it's OK. :-)
Thanks
Max
On Mar 21, 2015, at 06:00, Jamil Nimeh jamil.j.ni...@oracle.com wrote:
Hi Xuelei, this looks good to me.
--Jamil
I see no problem now.
Would you like me to push it for you? Please provide me the changeset comment
you want to use.
Thanks
Max
On Mar 20, 2015, at 14:49, Artem Smotrakov artem.smotra...@oracle.com wrote:
Hi Max,
Please see inline.
On 03/19/2015 05:33 PM, Wang Weijun wrote
/~asmotrak/8048147/webrev.02/
Artem
On 03/18/2015 06:08 PM, Wang Weijun wrote:
On Mar 18, 2015, at 19:31, Artem Smotrakov artem.smotra...@oracle.com
wrote:
The tests can be updated to start a new process with ProcessTools, or use a
script.
Choose anyone you like.
Maybe you can a few
Hi Jason
I was thinking about changing all set/get calls to using OID so inside
CertificateExtensions and CRLExtensions you won't need to care about name
conversions. Is that possible?
Also I see you adding some IOException throwing and catching. Is there any case
you actually see them? I
not.
--Max
On Mar 19, 2015, at 07:40, Jason Uh jason...@oracle.com wrote:
Hi Max,
On 03/18/2015 04:09 PM, Wang Weijun wrote:
Hi Jason
I was thinking about changing all set/get calls to using OID so inside
CertificateExtensions and CRLExtensions you won't need to care about name
Hi All
I discussed with my colleagues on the stream-based methods and we think they
are not well-designed:
1. A library should not define a wire protocol and assume the peer is using the
same. http://tools.ietf.org/html/draft-ietf-kitten-gss-loop-05 requires the
application to define it.
2.
Hi All
Please review the change at
http://cr.openjdk.java.net/~weijun/8074836/webrev.00/
Thanks
Max
One disadvantage of enum to constant is that third-party library will not be
able to extend it. I noticed this when I was trying to extend TLS to use
non-certificate-based ciphersuites by providing more KeyExchange values. That
work is stalled now but if we want to do it later this should be
if they are non-public APIs.
Here it is with that change; please take a look:
http://cr.openjdk.java.net/~juh/8073430/02/
Thanks,
Jason
On 03/05/2015 09:32 PM, Wang Weijun wrote:
What is the policy for deprecating a non-public-API method?
On Mar 6, 2015, at 13:30, Wang Weijun weijun.w...@oracle.com
在 2015年3月6日，19:49，Vincent Ryan vincent.x.r...@oracle.com 写道：
If it helps then the PKCS12 implementation could be modified to use the empty
password (“”)
when a null password is supplied.
I'm not suggesting this. It's just the behavior change might break some
existing codes. When I try to
Hi Vinnie
I noticed that without providing a storepass, all certificates in a pkcs12
keystore is invisible, i.e. no TrustedCertEntry and PrivateKeyEntry has no
cert. This is quite different from the jks storetype. Is this avoidable?
Thanks
Max
On Mar 6, 2015, at 01:55, Mandy Chung mandy.ch...@oracle.com wrote:
For this review request, are you okay with this patch moving policytool and
jarsigner tools to the new home?
Yes.
--Max
Instead of adding @SupressWarnings to a method, can we add @Deprecated to it?
If I understand correctly, there should be no warning if a deprecated method
calls another deprecated method. And by deprecating the caller we will get
warnings if they are called by more methods and we can evaluate
What is the policy for deprecating a non-public-API method?
On Mar 6, 2015, at 13:30, Wang Weijun weijun.w...@oracle.com wrote:
Instead of adding @SupressWarnings to a method, can we add @Deprecated to it?
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
Hi Jason
I noticed several @SuppressWarnings(deprecation) in some sun.* or com.sun.*
classes and it makes me feel uncomfortable. The usage of this annotation, if I
understand correctly, means we know we should not use it but we have to use it
because we are lazy or there are no better
http://cr.openjdk.java.net/~zailiu/8048610/webrev.01/webrev/
Empty:
- line 48 and 49 can be fit in one line, throw - thrown
and you don't need + anymore.
bug4901658:
I reread the original bug and think it's not worth adding this test.
The original bug complains byte[].toString() is
Sure.
Are you an OpenJDK author? If yes, the changset will have
Author: amanda
Otherwise, it will be
Author: weijun
Contributed-by: amanda.ji...@oracle.com
--Max
On Mar 4, 2015, at 01:27, Amanda Jiang amanda.ji...@oracle.com wrote:
Hi Max,
Thanks for reviewing this changeset,
Done at http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4503bd758762.
Hi Sean
Please review the fix at
http://cr.openjdk.java.net/~weijun/8074018/webrev.00/
This is a regression of my code change for 8073182.
Thanks
Max
On Feb 20, 2015, at 20:46, Sean Mullan sean.mul...@oracle.com wrote:
On 02/20/2015 07:21 AM, Weijun Wang wrote:
Yes, that line has 354 chars. There are quite a lot of long lines there,
maybe because keytool command is usually long. In fact, 43 lines are
longer than 150 chars, 345 lines
Should the providers link in the 2nd method also be linkplain?
--Max
On Feb 10, 2015, at 08:28, Joseph D. Darcy joe.da...@oracle.com wrote:
Hello,
As the final purge of doclint warnings from the java.base module approaches,
please review the changes for
JDK-8069277: Doclint
Hi All
Please review the code change at
http://cr.openjdk.java.net/~weijun/8055045/webrev.00/
The old code has an error is the value is a single or '.
Thanks
Max
Hi All
Please review the fix at
http://cr.openjdk.java.net/~weijun/8071313/webrev.00
On a Mac OS X, when Open Directory is installed but disabled, Java should be
able to use other Kerberos settings.
Noreg-hard but I added a comment [1] to describe how to test the change.
Thanks
Max
[1]
On Jan 22, 2015, at 19:40, Artem Smotrakov artem.smotra...@oracle.com wrote:
I am not sure if I understand updateJar correctly. It looks like srcJarFile
is opened multiple times so its entries are duplicated a lot in the
destination. Or is there a secret break?
There is no any secret,
Thanks for adding so many tests. Some suggestions:
- JarUtils.java
You can use the new InputStream.transferTo() method.
I am not sure if I understand updateJar correctly. It looks like srcJarFile is
opened multiple times so its entries are duplicated a lot in the destination.
Or is there a
Hi All
Please review the code changes at
http://cr.openjdk.java.net/~weijun/8022582/webrev.00
Sometimes a forwardable ticket request is sent but KDC returns a
non-forwardable one. For example, in Windows, an account can be set as
sensitive and cannot be delegated. While it's possible to
Looks fine.
Thanks
Max
On Dec 30, 2014, at 08:40, Valerie Peng valerie.p...@oracle.com wrote:
Can someone please help review this change? The fix is straightforward -
remove the key length check inside the code for DSA related signatures.
Bug:
On Dec 18, 2014, at 22:12, Vincent Ryan vincent.x.r...@oracle.com wrote:
Thanks for reviewing, Max.
On 18 Dec 2014, at 06:52, Wang Weijun weijun.w...@oracle.com wrote:
On Dec 18, 2014, at 07:58, Vincent Ryan vincent.x.r...@oracle.com wrote:
FYI I’ve updated the webrev to include
On Dec 17, 2014, at 07:32, Matthew Hall mh...@mhcomputing.net wrote:
Many StackOverflows exist of people doing it manually to work around this
limitation.
In fact, I searched for create empty keystore on stackoverflow and didn't
notice such a requirement.
The ones I ran across were
On Dec 18, 2014, at 07:58, Vincent Ryan vincent.x.r...@oracle.com wrote:
FYI I’ve updated the webrev to include the changes below:
http://cr.openjdk.java.net/~vinnie/805/webrev.05/
PKCS12KeyStore.PKCS12_HEADER_PATTERNS.
Is there a possibility for this?
30 82 -- -- 02 01 03 30 81 --
around this
limitation.
In fact, I searched for create empty keystore on stackoverflow and didn't
notice such a requirement.
--Max
I've done it myself especially when working on an identity management
appliance.
Matthew.
On Mon, Dec 15, 2014 at 09:54:53AM +0800, Wang Weijun wrote:
How
Unfortunately it does not contain the aliases, say, there is SHA but no
SHA-1.
--Max
On Dec 14, 2014, at 05:12, Peter Levart peter.lev...@gmail.com wrote:
Even simpler:
java.security.Security.getAlgorithms(MessageDigest).contains(SHA-256)
Regards, Peter
How is this useful?
On the other hand, you can always import a cert and remove it to get an empty
keystore.
--Max
On Dec 15, 2014, at 04:24, Rich Midwinter rich.midwin...@gmail.com wrote:
Hi
I'd like to see a new switch added to keytool to initialise an empty
keystore, for which I've
Hi Brad
Is this the same as your Non-blocking SecureRandom? They have a webrev at
http://cr.openjdk.java.net/~plevart/jdk9-dev/SystemRandom/webrev.01/
Thanks
Max
Begin forwarded message:
Date: December 3, 2014 at 00:42:41 GMT+8
From: Peter Levart peter.lev...@gmail.com
To: Paul
Hi All
I am comparing the difference of SHA-1 and SHA-256. First I wrote a JMH
benchmark:
@Benchmark
public void sig1(Blackhole bh) throws Exception {
bh.consume(sig(SHA-1));
}
@Benchmark
public void sig2(Blackhole bh) throws Exception {
bh.consume(sig(SHA-256));
}
byte[] sig(String
Are you OK with this difference?
Thanks
Max
On Nov 18, 2014, at 15:02, Wang Weijun weijun.w...@oracle.com wrote:
On Nov 18, 2014, at 07:43, Valerie Peng valerie.p...@oracle.com wrote:
The default value 0 for the renew_lifetime is documented in MIT's Kerberos
conf documentation
Max,
Please help to check this
update:http://sqeweb.us.oracle.com/net/sqenfs-1/export1/comp/jsn/users/kevin1/webrev/8048619/webrev/
Thanks
Kevin
于 2014/9/22 17:10, Wang Weijun 写道:
On Sep 22, 2014, at 16:11, zaiyao liu zaiyao@oracle.com wrote:
Hi Max,
Thanks for review. please
I am benchmarking security manager and notice this
protected synchronized InetAddress getHostAddress(URL u) {
if (u.hostAddress != null)
return u.hostAddress;
String host = u.getHost();
if (host == null || host.equals()) {
return null;
} else {
try {
, x - );
}
private int next(ThreadState state) {
return state.rand.nextInt(num);
}
}
--Max
-Pavel
On 25 Nov 2014, at 12:02, Wang Weijun weijun.w...@oracle.com wrote:
I am benchmarking security manager and notice this
protected synchronized InetAddress getHostAddress
On Nov 25, 2014, at 20:55, Tom Hawtin tom.haw...@oracle.com wrote:
On 25/11/2014 12:02, Wang Weijun wrote:
I am benchmarking security manager and notice this
protected synchronized InetAddress getHostAddress(URL u) {
[...]
Is there any reason why the method is synchronized? Why
On Nov 19, 2014, at 22:10, Sean Mullan sean.mul...@oracle.com wrote:
On 11/18/2014 02:47 AM, Wang Weijun wrote:
Re-request for code review at
http://cr.openjdk.java.net/~weijun/8061253/webrev.01/
* Principal:
This should also be included in the @implSpec, is it? You might need
On Nov 19, 2014, at 22:10, Sean Mullan sean.mul...@oracle.com wrote:
On 11/18/2014 02:47 AM, Wang Weijun wrote:
Re-request for code review at
http://cr.openjdk.java.net/~weijun/8061253/webrev.01/
* Principal:
This should also be included in the @implSpec, is it? You might need
is included in krb5.conf (see KDCOptions::setDefault),
so by default java kinit gets a non-renewable ticket.
Thanks
Max
Valerie
On 11/17/2014 12:23 AM, Wang Weijun wrote:
On Nov 15, 2014, at 09:25, Valerie Pengvalerie.p...@oracle.com wrote:
Max,
Most looks fine, just some questions
suitable in this call.
*Jamil*: I usually don't touch copyright years and let RE handle it. You might
say this is not a good habit.
Thanks
Max
On Nov 15, 2014, at 08:05, Wang Weijun weijun.w...@oracle.com wrote:
Webrev withdrawn. I'd like to make more changes.
Thanks
Max
On Nov 14
The last label has a trailing semicolon. Otherwise good.
--Max
On Nov 14, 2014, at 18:58, Vincent Ryan vincent.x.r...@oracle.com wrote:
Please review this fix to check for pending exceptions in JNI:
Bug: https://bugs.openjdk.java.net/browse/JDK-8034031
Webrev:
Webrev withdrawn. I'd like to make more changes.
Thanks
Max
On Nov 14, 2014, at 10:38, Wang Weijun weijun.w...@oracle.com wrote:
Hi All
This is a doc change only bug. Fix at
http://cr.openjdk.java.net/~weijun/8061253/webrev.00/
Please take a review.
Thanks
Max
Hi All
This is a doc change only bug. Fix at
http://cr.openjdk.java.net/~weijun/8061253/webrev.00/
Please take a review.
Thanks
Max
On Nov 11, 2014, at 15:06, Xuelei Fan xuelei@oracle.com wrote:
On 11/11/2014 1:31 PM, Wang Weijun wrote:
A subclass of Exception would also return true when using instanceof, where
I think the class name is still informational.
Got it. But Exception is still informational
A subclass of Exception would also return true when using instanceof, where I
think the class name is still informational.
--Max
On Nov 11, 2014, at 11:14, Xuelei Fan xuelei@oracle.com wrote:
Why not use instanceof?
Xuelei
On 11/11/2014 10:58 AM, Wang Weijun wrote:
Please review
Ping ping...
On Oct 20, 2014, at 13:22, Wang Weijun weijun.w...@oracle.com wrote:
Anyone can take a look?
On Sep 25, 2014, at 18:54, Wang Weijun weijun.w...@oracle.com wrote:
Hi All
Please review the code change at
http://cr.openjdk.java.net/~weijun/8044500/webrev.00
It adds
Hi All
Please review the code change at
http://cr.openjdk.java.net/~weijun/8057810/webrev.00/
Now DSA keys use 2048 bit key size and SHA256withDSA as defaults for keytool
and jarsigner.
A new test added. Several existing tests updated since the new defaults are not
supported by NSS.
Vote: Yes
--Weijun
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
the shared secret
---changeCipherSpec---
---Finished---
...
---
Thanks,
Xuelei
On 9/17/2014 1:58 PM, Xuelei Fan wrote:
On 9/17/2014 1:49 PM, Wang Weijun wrote:
I would prefer we do it now. If I did not miss
Anyone can take a look?
On Sep 25, 2014, at 18:54, Wang Weijun weijun.w...@oracle.com wrote:
Hi All
Please review the code change at
http://cr.openjdk.java.net/~weijun/8044500/webrev.00
It adds support for ticket_lifetime and renew_lifetime in krb5.conf, and add
-r -l -R to kinit
://cr.openjdk.java.net/~ascarpino/8057141/webrev.02
JDK 9: http://cr.openjdk.java.net/~ascarpino/8032573/webrev.03
Thanks,
--Jamil
On 10/14/2014 08:24 PM, Jamil Nimeh wrote:
Thank you for the reviews and I will go make the comment changes as you
suggest.
--Jamil
On 10/14/2014 7:11 PM, Wang
Jamil
Both code changes look fine.
One suggestion: you might want to mention that the first character in
invalidcert.pem in the test was M. It is modified to X to be invalid. This
would help maintainers understand where it comes from.
Thanks
Max
On Oct 15, 2014, at 1:42, Jamil Nimeh
On Oct 8, 2014, at 23:30, Sean Mullan sean.mul...@oracle.com wrote:
This enhancement could then be useful for more than just jssecacerts. For
example, in my JavaOne presentation, I gave an example of creating a Domain
KeyStore that encompasses two root stores:
This means we will need to
On Oct 11, 2014, at 0:24, Vincent Ryan vincent.x.r...@oracle.com wrote:
BTW, I see that DomainKeyStore#load(stream,pass) is designed to load a
keystore of JKS (or another default storetype). Why didn't we load a DKS
config file (with common passwords or all null)?
The DKS
Hi Xuelei
Please review the code change at
http://cr.openjdk.java.net/~weijun/8029659/webrev.00/
Keytool.html has not specified the exact output and no example touched.
Therefore no need to request for a external export change.
Thanks
Max
Vinnie
I switched to your lib, please review
http://cr.openjdk.java.net/~weijun/8060007/webrev.00/
Thanks
Max
On Oct 6, 2014, at 23:54, Vincent Ryan vincent.x.r...@oracle.com wrote:
JDK-8059627 now bundles NSS with our PKCS11 testsuite (just like on Windows)
I know you have
Code change looks fine.
Thanks
Max
On Oct 8, 2014, at 16:27, Seán Coffey sean.cof...@oracle.com wrote:
Ping.
regards,
Sean.
On 02/10/2014 17:34, Seán Coffey wrote:
I'm looking to backport this fix to JDK 7u code line. The fix applies pretty
much as is with the JDK 8 fix with the
On Oct 8, 2014, at 16:01, Xuelei Fan xuelei@oracle.com wrote:
It looks strange to me now that this keytool command cannot specify the
customized trusted anchor sources. Normally, the key store of the trust
anchor should be customizable so that users can use the trust anchor
other than
Ping again.
--Max
On Sep 28, 2014, at 16:55, Wang Weijun weijun.w...@oracle.com wrote:
Please review the fix at
http://cr.openjdk.java.net/~weijun/8044215/webrev.00
If a service is using constrained delegation to act as a client, it should
not be able to request for a traditional
On Oct 8, 2014, at 23:00, Sean Mullan sean.mul...@oracle.com wrote:
I agree that we should not read jssecacerts by default. My vote would be to
extend -trustcacerts to take an optional path to a cacerts file but fallback
on lib/security/cacerts if not specified.
No keytool option takes an
Hi, SSL/TLS experts
A bug was recently filed at
https://bugs.openjdk.java.net/browse/JDK-8059818
The reporter requests for keytool -importcert to pre-trust certs in
jre/lib/security/jssecacerts. The command only recognizes
jre/lib/security/cacerts now.
It is always possible to import a
On Oct 8, 2014, at 10:43, Xuelei Fan xuelei@oracle.com wrote:
I think Keytool should be independent of JSSE.
Yes.
However, I can think of adding a new system property called
jdk.keytool.cacerts so that people can point it to a file not
jre/lib/security/cacerts. This would be useful for
On Oct 8, 2014, at 11:10, Xuelei Fan xuelei@oracle.com wrote:
However, I can think of adding a new system property called
jdk.keytool.cacerts so that people can point it to a file not
jre/lib/security/cacerts. This would be useful for the bug reporter and we
can now finally testing
I'll use your libs.
Why is DYLD_LIBRARY_PATH not needed here? Some different linking method?
Thanks
Max
On Oct 6, 2014, at 23:54, Vincent Ryan vincent.x.r...@oracle.com wrote:
JDK-8059627 now bundles NSS with our PKCS11 testsuite (just like on Windows)
I know you have implemented a
Change looks good. I think it can labelled noreg-trivial.
Thanks
Max
On Sep 30, 2014, at 18:46, Vincent Ryan vincent.x.r...@oracle.com wrote:
Please review this correction to a key used by the keytool utility to access
its L10N strings:
Webrev:
On Oct 1, 2014, at 0:05, Seán Coffey sean.cof...@oracle.com wrote:
Iris is correct. This fix is in JDK 9 only. I'm not sure why you think it's
fixed in jdk8u.
Max - are you willing to pull this fix into the JDK 8u code line or shall I ?
Public holiday here. Can you do it? Hopefully the
X509Factory.java:
502 data = readOneBlock(is);
Should it be pbis?
Actually I would suggest reusing the variable name is to prevent any such
error.
Also, I am not sure if using a PushbackInputStream will hurt the performance.
The readOneBlock() method already includes the
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
Please review the fix at
http://cr.openjdk.java.net/~weijun/8044215/webrev.00
If a service is using constrained delegation to act as a client, it should not
be able to request for a traditional delegation to another service (on behalf
of the client). Otherwise it automatically elevate
Hi Vinnie
Can you review the fix at
http://cr.openjdk.java.net/~weijun/8059313/webrev.00/
The test will try several places to look for NSS libs. If the machine has no
Firefox or Thunderbird installed the NSS part won't run. At least this enables
myself running NSS-related tests on my
Hi All
Please review the code change at
http://cr.openjdk.java.net/~weijun/8044500/webrev.00
It adds support for ticket_lifetime and renew_lifetime in krb5.conf, and add -r
-l -R to kinit (on Windows).
Thanks
Max
On Sep 19, 2014, at 11:04, zaiyao liu zaiyao@oracle.com wrote:
Hi Max,
Can you help to review it?
Thanks
Kevin
于 2014/9/1 13:25, Wang Weijun 写道:
On vacation now. Can you look for someone else? I will be back in Sep 17 if
you are not in a hurry.
--Max
On Sep 1, 2014, at 9:37
Hi Jason
The change looks quite straightforward, but have you checked if our codes
actually comply with RFC 5280 especially for those areas where RFC 5280 is
different from RFC 3280? http://tools.ietf.org/html/rfc5280#page-5 lists the
differences. For example, there is an item:
*
and generation, and the generation of
pre-master secret.
3. don't need Krb5Helper any more, call the new interface directly.
After the update, the SunJSSE provider would only known the algorithm
name of the KRB5 key exchange.
What do you think?
Thanks,
Xuelei
On 9/16/2014 9:31 AM, Wang
I would prefer we do it now. If I did not miss something, the new design
should be more simple
and straightforward.
Maybe, but I am not sure since this would surely touch more TLS side codes. If
you want to be totally separated, we also need to move the ciphersuites
definitions outside
Hi Xuelei
Please review the latest code change at
http://cr.openjdk.java.net/~weijun/8038089/webrev.04/
Compared with webrev.03, only the way the provider is loaded is changed, which
is the static block on lines 50-71 of Krb5Helper.java.
Thanks
Max
The change looks good.
Thanks
Max
On Sep 10, 2014, at 20:02, Seán Coffey sean.cof...@oracle.com wrote:
Sounds reasonable Max. I've made those changes and sec3 and sec4 test groups
seem to be averaging out to ~15 mins each now.
On Sep 9, 2014, at 6:25, Valerie Peng valerie.p...@oracle.com wrote:
Max,
Mostly look fine. Just some comments, questions (see below):
src/java.security.jgss/share/classes/com/sun/security/jgss/ExtendedGSSContext.java
1) line 71 - 76 was done in Krb5Context.java. Is it really necessary
On Sep 9, 2014, at 18:45, Wang Weijun weijun.w...@oracle.com wrote:
test/sun/security/krb5/auto/Context.java
1) line 364: move it inside the if-block? Seems no value calling xstatus()
when x is null.
Correct.
2) line 401: move it inside the if-block? Since if x is null
On vacation now. Can you look for someone else? I will be back in Sep 17 if you
are not in a hurry.
--Max
On Sep 1, 2014, at 9:37, zaiyao liu zaiyao@oracle.com wrote:
Hi Max,
Please review the code change,the purpose of this fix is implement tests that
convert PKCS12 keystores to
for automatic regression tests.
--Max
On Aug 28, 2014, at 16:54, Alan Bateman alan.bate...@oracle.com wrote:
On 27/08/2014 08:17, Wang Weijun wrote:
Hi All
Please review the code change at
http://cr.openjdk.java.net/~weijun/8042900/webrev.00/
The purpose of this fix is to move
This is the sub-task of 8042900: Allow com.sun.security.jgss to be in
different module than org.ietf.jgss that actually moves the files.
Code changes include 2 parts:
1. For jdk9/dev repo:
http://cr.openjdk.java.net/~weijun/8056141/webrev.00/
2. For jdk9/dev/jdk. It's just moving
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
On Aug 28, 2014, at 21:06, Alan Bateman alan.bate...@oracle.com wrote:
On 28/08/2014 14:02, Wang Weijun wrote:
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
Hi All
Please review the code change at
http://cr.openjdk.java.net/~weijun/8042900/webrev.00/
The purpose of this fix is to move com.sun.security.jgss (where the
ExtendedGSSXXX classes reside) out of the java.security.jgss module, since it
is openjdk-specific and not defined in Java SE.
On Aug 27, 2014, at 10:07, Wang Weijun weijun.w...@oracle.com wrote:
Webrev updated again, this time include more changes.
http://cr.openjdk.java.net/~weijun/8055723/client/webrev.02/
http://cr.openjdk.java.net/~weijun/8055723/core/webrev.02/
The core part is updated again at
http
OK, I'll remember that. So you will include the StringBuilder changes into your
fix?
--Max
On Aug 28, 2014, at 2:10, Ivan Gerasimov ivan.gerasi...@oracle.com wrote:
Hi Max!
The core part is updated again at
http://cr.openjdk.java.net/~weijun/8055723/core/webrev.03/
Can you please
Can you ask Vinnie to look at them? He designed and implemented DKS. Although I
know about the concept but I've never really used it.
--Max
On Aug 28, 2014, at 13:22, raghu k.nair raghu.k.n...@oracle.com wrote:
Hi Max,
Could you please help me in reviewing the following Domain Keystore
I guess you were looking for Xuelei, the other Andrew in our team focusing on
SSL/TLS. Normally we use Drew when talking about Andrew Gross.
--Max
On Aug 28, 2014, at 13:27, raghu k.nair raghu.k.n...@oracle.com wrote:
Hi Andrew,
Could you please help in me in reviewing the following
:
Hi Max,
please review again:
http://cr.openjdk.java.net/~tyan/kevin/JDK-8050370/webrev03/
Thanks
Kevin
于 2014/8/25 14:55, Wang Weijun 写道:
lines 76 and 80, useless at the end of string.
Otherwise looks fine.
Thanks
Max
On Aug 25, 2014, at 14:41, zaiyao liu zaiyao@oracle.com
Vinnie
I'm reviewing a test fix including a lot of binary pkcs12 files. Do you think
we can directly support PEM format pkcs12 files in our own PKCS12KeyStore?
Thanks
Max
Begin forwarded message:
Several comments:
1. openjdk does not like binary files. I would store them in BASE64.
string =\n)
StringBuilder sb = new StringBuilder(\ + ti.getThreadName() + \ +
tagBuffer.append(tr bgcolor=\+ color[selColorIndex] + \);
...
Thanks
Max
On Aug 26, 2014, at 11:28, Wang Weijun weijun.w...@oracle.com wrote:
New webrevs available at
http://cr.openjdk.java.net/~weijun/8055723
(c) instead of append((int)c). Here c
is already an integer and this redundant cast will be treated as an error when
-Werror specified.
--Max
On Aug 27, 2014, at 10:07, Wang Weijun weijun.w...@oracle.com wrote:
Webrev updated again, this time include more changes.
http://cr.openjdk.java.net
Done at http://hg.openjdk.java.net/jdk9/dev/jdk/rev/785858138c56.
--Max
On Aug 27, 2014, at 11:23, zaiyao liu zaiyao@oracle.com wrote:
Hi Max,
Can you help to push this code for me?
Full comments:
8048617: Tests for PKCS12 read operations
Reviewed-by: weijun
Contributed-by: Zaiyao
401 - 500 of 669 matches
Mail list logo
