Hello,
thanks for clarifying about some APIs being considered "critical".
No, I'm not seeing lots of usage: actually just one instance so far so it
should be possible to patch already with minimal impact.
I'm understanding that this API will be hidden. Will there be an alternative?
In this case it's just being used to invoke:
sun.misc.VM.getSavedProperty("java.lang.Integer.IntegerCache.high")
I'm not entirely familiar with this code, but it seems the purpose is to
estimate memory usage at runtime for objects,
so it's attempting to read this value to disregard the Integer instances which
are being reused from the pool.
Wondering if you could suggest an alternative, or should we plan for not having
this level of detail anymore?
Thanks,
Sanne
----- Original Message -----
>
>
> On 20/01/2016 15:18, Sanne Grinovero wrote:
> > Hello all,
> > while testing latest Java 9 build 9-ea+101-2016-01-13-182959.javare.4276.nc
> > with some popular OSS libraries, I noticed that sun.misc.VM is gone and
> > this will cause some issues.
> >
> > This is causing compilation failures of type "cannot find symbol".
> > Similarly the same projects are using sun.misc.Unsafe, but in that case
> > we're getting a warning "sun.misc.Unsafe is internal proprietary API and
> > may be removed in a future release".
> >
> > Is it intentional that sun.misc.VM takes a more aggressive migration path
> > than the nice warnings we're getting for Unsafe?
> >
> sun.misc.VM is not one of the "critical internal APIs" that identified
> in JEP 260 [1]. There is ongoing work (mostly by Chris Hegarty) to move
> the non-critical APIs out of sun.misc and sun.reflect so that all that
> remains is the critical internal APIs.
>
> Are you seeing a lot of usage of sun.misc.VM? If so then best to bring
> usage data to jigsaw-dev to lobby for it to be considered as a critical
> internal API.
>
> -Alan.
>
> [1] http://openjdk.java.net/jeps/260
>
