Looking to backport this fix to jdk8u-dev. The bug report is not public
but the JDK 9 review thread captures the details. The fix is similar.
Some extra intrinsics work in jdk9 wasn't applicable for the jdk8u-dev
port.
On 8/15/2017 7:05 PM, Michael StJohns wrote:
On 8/15/2017 1:43 PM, Xuelei Fan wrote:
On 8/11/2017 7:57 AM, Adam Petcher wrote:
I'm also coming to the conclusion that using X.509 encoding for this
sort of interoperability is too onerous, and we should come up with
something better. Maybe we
On 8/15/2017 5:29 PM, Anders Rundgren wrote:
Does this mean that the following is correct?
EC public key:
public interface ECPublicKey
extends PublicKey, ECKey
CFRG/RFC 7748 public key:
public class TheActualImplememtationClass
extends PublicKey, ByteArrayKey
Basically, yes. My latest
On 8/16/2017 8:18 AM, Adam Petcher wrote:
I don't worry about this issue any more. At present, each
java.security.Key has three characters (see the API Java doc):
. an algorithm
. an encoded form
. a format
The format could be "X.509", and could be "RAW" (like
ByteArrayValue.getValue()).
On 8/16/2017 11:18 AM, Adam Petcher wrote:
On 8/15/2017 7:05 PM, Michael StJohns wrote:
On 8/15/2017 1:43 PM, Xuelei Fan wrote:
On 8/11/2017 7:57 AM, Adam Petcher wrote:
I'm also coming to the conclusion that using X.509 encoding for
this sort of interoperability is too onerous, and we
Thanks, can you also review the corresponding webrev:
http://cr.openjdk.java.net/~mullan/webrevs/8159544/
I'm also copying build-dev as there is one Makefile change in
jdk.webrev.00.
--Sean
On 8/10/17 9:38 PM, Weijun Wang wrote:
Done.
Thanks
Max
On Aug 10, 2017, at 11:36 PM, Sean
