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 <a...@redhat.com> > Sent: Dienstag, 25. Juni 2019 10:18 > To: Alan Bateman <alan.bate...@oracle.com>; Langer, Christoph > <christoph.lan...@sap.com> > Cc: AWT-DEV Mailing List <awt-dev@openjdk.java.net>; Java Core Libs > <core-libs-...@openjdk.java.net>; jdk-updates-...@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
