[11u]: Backport of RFR 8211122: Reduce the number of internal classes made accessible to jdk.unsupported (and JDK-8205537 and JDK-8211121)

[Langer, Christoph]

Hi,

after Alan's input and contemplating a bit more about this I think we really should not pull the removals to 11.

I explored amending the backport of JDK-8211122 to keep the applet classes and the ReflectionFactory method working and found out it's quite trivial. So I'll go that route. Will post a new webrev after all tests pass.

Thanks,
Christoph

> -----Original Message-----
> From: Andrew Haley <aph at redhat.com>
> Sent: Dienstag, 25. Juni 2019 10:18
> To: Alan Bateman <Alan.Bateman at oracle.com>; Langer, Christoph
> <christoph.langer at sap.com>
> Cc: AWT-DEV Mailing List <awt-dev at openjdk.java.net>; Java Core Libs
> <core-libs-dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net
> Subject: Re: [11u]: Backport of RFR 8211122: Reduce the number of internal
> classes made accessible to jdk.unsupported (and JDK-8205537 and JDK-
> 8211121)
> 
> On 6/24/19 4:12 PM, Alan Bateman wrote:
> > On 24/06/2019 15:23, Langer, Christoph wrote:
> >> :
> >> The original issues didn't have CSRs attached but it really feels CSRish. Let
> me know whether I shall create CSRs as you're still sorting out the process.
> > The sun.applet package was JDK internal so no CSR required to change or
> > remove anything in that package. That said, we've historically been
> > cautious about changing internal classes too much in update releases,
> > mostly because it was never clear what/who might be using them directly.
> 
> Yes, exactly. There are indeed people providing applet support.
> I don't know if any of it works on 11, though.
> 
> > It's a bit easier since we moved the platform to modules but we aren't
> > yet at the point where the standard and JDK modules are fully
> > encapsulated at run-time.
> >
> > As part of JEP 260 we put sun.reflect.ReflectionFactory into the
> > "Critical internal API" bucket (with sun.misc.Unsafe and a few others)
> > as it provides functionality that custom serialization libraries have
> > been using. I think the CORBA bridge was the main user of
> > newConstructorForSerialization. We neglected to remove the method in
> JDK
> > 11 when removing java.corba module. It was removed in JDK 12 and that
> > change should probably should have had a CSR (we wouldn't remove
> > anything from sun.misc.Signal or sun.misc.Unsafe without a CSR). I'm not
> > involved in JDK updates but I don't think it's a good idea to attempt to
> > remove this in an update release.
> 
> I agree. It'd need a big upside to justify the risk.
> 
> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671