Magnus:
Looks good to me as well.
Tim
On 03/04/15 05:31, Erik Joelsson wrote:
Hello,
Really nice to finally see this patch getting done!
Only one comment:
flags.m4:
In the grep expression, could you move the extra [] outside of the
actual command line options to grep so that the command
On 04/03/2015 15:03, Magnus Ihse Bursie wrote:
I believe all warnings are important to check! Unfortunately, this has
not been done for a lot of warnings for a lot of time. :(
Right, although in the past we had some areas close to be cleared of
warnings, it's just that we didn't keep up the
On 03/02/2015 09:24 AM, Florian Weimer wrote:
On 02/20/2015 11:23 PM, Sean Mullan wrote:
On 02/17/2015 09:30 AM, Florian Weimer wrote:
On 02/16/2015 11:13 PM, Sean Mullan wrote:
Based on that, PolicyQualifierInfo should have implemented value-based
equals() and hashCode(), and the
webrev: http://cr.openjdk.java.net/~juh/8073430/00/
jbs: https://bugs.openjdk.java.net/browse/JDK-8073430
Please review this change, which deprecates the classes in
java.security.acl and javax.security.cert. These packages have been
superseded by replacements for a long time.
For
Hello there!
Please review this patch disabling deprecated, broken, or, insecure crypto
algorithms. I think it is fair to say that these should be sane defaults by now,
similar to what main web browser vendors do.
AFAIKT, JDK 8 ships with only one legacy MD5withRSA signed certificate which
I like the overall approach.
We can then attack the warnings lib by lib and/or platform by platform.
I do want to mention that some libs like liblcms are 3rd party open
source libraries
and it may not always be possible to convince upstream to change their code.
-phil.
On 03/04/2015 08:30
One more round of updates. Only the test code and the test inputs have
changed. Test input is now Base64 format, with comment headers that
display the OCSP response pretty-print (or an asn1parse of the
BasicOCSPResponse for malformed response test cases).
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
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
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
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
On 3/4/2015 1:40 PM, zaiyao liu wrote:
Hi Xuelei,
Thanks for review, Can you help to push it?
Pushed.
Thanks,
Xuelei
Full comments:
8050371: MessageDigest tests
Reviewed-by: xuelei
Contributed-by: Zaiyao Liu zaiyao@oracle.com
Thanks again.
Kevin
在 2015/3/4 13:34, Xuelei Fan
Hi,
Please review the fix for:
https://bugs.openjdk.java.net/browse/JDK-8072385
In SunJSSE implementation, during endpoint identification, there is a
bug in SubjectAlternativeName matching that only the fist DNSName are
checked. As may impact some business where host-name alias are used.
The
Hello,
Really nice to finally see this patch getting done!
Only one comment:
flags.m4:
In the grep expression, could you move the extra [] outside of the
actual command line options to grep so that the command line could be
copied to the shell for debugging in the future? Also, how hard
On 04/03/2015 13:17, Magnus Ihse Bursie wrote:
:
I intend to file individual bugs to handle these remaining warnings,
so the net result will be a completely warning free build.
I also intend to file individual bugs on all the libraries that has
had warnings disabled. I expect the outcome of
When building the native code in the jdk repo, a lot of warnings are
generated. So many that it's hard to spot any new issues.
While the ultimate goal must be to address and fix these warnings
individually, this bug is about disabling these warnings where they
occur, so that it is easier to
On 2015-03-04 14:48, Alan Bateman wrote:
On 04/03/2015 13:17, Magnus Ihse Bursie wrote:
:
I intend to file individual bugs to handle these remaining warnings,
so the net result will be a completely warning free build.
I also intend to file individual bugs on all the libraries that has
had
18 matches
Mail list logo
