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

[Andrew Haley]

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