On 8 Feb 2016, at 06:27, Alan Bateman <alan.bate...@oracle.com> wrote:
> > On 07/02/2016 22:20, Peter Levart wrote: >> : >> >> If the decision to remove sun.misc.Cleaner was partly influenced by the >> desire to maintain just 2 instead of 3 Cleaner(s), then my proposal to >> migrate JDK code to the public API might enable Oracle to reconsider keeping >> sun.misc.Cleaner. > > The main issue driving this is the design principles that we have listed in > JEP 200. We don't want a standard module (java.base in this case) exporting a > non-standard API. This means surgery to jettison the sun.misc package from > java.base and move it to its own module (jdk.unsupported is the proposal in > JEP 260). This is painful of course but we are at least in good shape for the > most critical internal API, sun.misc.Unsafe. > > For sun.misc.Cleaner then the original proposal was for it to be a critical > internal API too but it become clear that changing the type of > internal/private fields in the NIO buffer and channel classes would break > libraries that have been hacking into those fields. If they are changing away > then there seems little motive to keep sun.misc.Cleaner so Chris moved into > into jdk.internal.ref for now. As to whether we even need to keep > jdk.internal.ref.Cleaner then I think the only remaining question was whether > the special handling of Cleaner in the Reference implementation was worth it > or not. It may not be, in which case your current proposal to just remove > seems right. Alan’s summary of the situation is spot on. Before moving sun.misc.Cleaner to jdk.internal.ref, I did enquire if it would be possible to just remove it and use the new public Cleaner, but I got feedback that there were some issues with failing NIO tests ( it appeared that Cleaners were not running as quickly as possible ). I didn’t look further into that at the time, since the VM still had special knowledge of these cleaners, but as you say this is now removed. It is probably a good time to revisit this. -Chris.
