Question around the 8054717 fix
sean.coffey at oracle.com
Tue Jun 16 08:28:31 UTC 2015
thanks for getting back. Easiest way to reproduce this is probably by
importing the jdk patch directly :
and then : gmake jdk.crypto.pkcs11
On 16/06/2015 09:04, Andreas Lundblad wrote:
> On Mon, Jun 15, 2015 at 02:30:41PM +0100, Seán Coffey wrote:
>> I had a security library fix reviewed last week  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
More information about the build-dev