Question around the 8054717 fix

[Andreas Lundblad]

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