[11u]: Backport of RFR 8211122: Reduce the number of internal classes made accessible to jdk.unsupported (and JDK-8205537 and JDK-8211121)
aph at redhat.com
Tue Jun 25 08:17:50 UTC 2019
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>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the jdk-updates-dev