Andreas,
thanks for getting back. Easiest way to reproduce this is probably by
importing the jdk patch directly :
http://cr.openjdk.java.net/~coffeys/webrev.8080102.jdk9.v2/webrev/
http://cr.openjdk.java.net/~coffeys/webrev.8080102.jdk9.v2/webrev/jdk.patch
and then : gmake jdk.crypto.pkcs11
Regards,
Sean.
On 16/06/2015 09:04, Andreas Lundblad wrote:
On Mon, Jun 15, 2015 at 02:30:41PM +0100, Seán Coffey wrote:
Hi,
I had a security library fix reviewed last week [1] and all was ok
with builds back then. Today, I found that my build is broken and I
think it's down to the changes introduced from the 8054717 fix.
The build error (snippet) is :
/opt/jprt/T/P1/081059.scoffey/s/jdk/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11ECUtil.java:74:
error: ECPublicKeyImpl(byte[]) is not public in ECPublicKeyImpl; cannot be
accessed from outside package
return new ECPublicKeyImpl(x509Spec.getEncoded());
^
/opt/jprt/T/P1/081059.scoffey/s/jdk/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11ECUtil.java:77:
error: constructor ECPublicKeyImpl in class ECPublicKeyImpl cannot be applied
to given types;
return new ECPublicKeyImpl(
^
required: byte[]
found: ECPoint,ECParameterSpec
reason: actual and formal argument lists differ in length
I've confirmed that I do have the correct access type modifications
in the ECPublicKeyImpl constructor (moved to public)
The build system appears to be picking up the older ECPublicKeyImpl
class in the bootstrap JDK and not the newly built classes. 8054717
appears to have modified bootclasspath settings.
Is this an issue with my security fix or a build issue ? I've tried
the build on my local system and an JPRT.
This could very well be related to 8054717.
It's strange that it picks up ECPublicKeyImpl from the boostrap JDK though. We
changed the build so that the bootclasspath is empty when compiling the JDK.
What's the easiest way for me to reproduce this? Could I get a JPRT id and
download your files somehow? (Sorry, I'm still learning JPRT.)
-- Andreas
