Hi,
On Sat, Sep 27, 2014 at 4:23 AM, Xuelei Fan wrote:
> I used to think it is better to have SSLExplorer as a public utility but
> not a part of JSSE, because the extract is not involved in TLS
> transactions.
I am not sure I understand this. Can you expand ?
A number of TLS Extensions are des
> I will try to come up with the list of necessary things for HTTP/2,
> but I would appreciate any thought on introducing a full fledged TLS
> extensions API available to applications to the JDK.
> I'd like to know in advance if this is not possible at all.
;-) Impossible is nothing. Thanks for t
I am out of the office until 10/09/2014.
If you have Java Security related issues, please kindly contact Tianyu
Tang/Singapore/IBM@IBMSG or Zhemin Feng/Singapore/IBM@IBMSG.
Note: This is an automated response to your message "security-dev Digest,
Vol 87, Issue 19" sent on 09/29/2014 17:30:45.
Hi,
Please review the below JEP for JVM Hardware Crypto Acceleration. The
focus is to use ISA crypto instructions available in x86 and sparc
platforms and to help access to use them.
https://bugs.openjdk.java.net/browse/JDK-8046943
Tony
Hello all,
This review fixes a small regression in the generateCertificates() and
generateCRLs() methods for the CertificateFactory class. At some point,
input consisting entirely of non-certificate data ceased to throw
CertificateException or CRLException and instead returned an empty
colle
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 rea
502: sigh, yes. It needs to be pbis. I thought I caught all those.
Thanks for catching that, I'll get that fixed up.
I had considered a similar alternate approach to using a
PushbackInputStream, but I thought passing the first byte in and
checking there seemed awkward (as you said as well).
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
On 9/29/2014 8:14 PM, Wang Weijun wrote:
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
On 29/09/2014 20:14, Wang Weijun wrote:
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
b
Hi,
could anyone merge the code of jdk9 into jdk8 as supposedly done in the
ticket.
I see the code in jdk9 forest, not in the jdk8 forest.
kind regards,
Koen Serry
Original Message
Subject:RE: Issue JDK-8048194 backport in jdk9 ?
Date: Mon, 22 Sep 2014 11:17:13 -0
11 matches
Mail list logo