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
