Jigsaw Hackday in London - Anything in particular you want us to look at?

[Vitaly Davidovich]

>
> sun.misc.Unsafe and its ilk will go away one day.  In preparation for
> that, making it a bit harder to use will motivate its current users to
> consider whether they really do need to use it -- some do, but some
> don't.


I think there's already sufficient noise about use of Unsafe that there's
no need for yet another inconvenience -- I don't think this class is flying
under the radar in this regard?

If you absolutely do need it then now is the time to start looking at
> the alternatives in development, and contribute to those efforts in
> order to make sure that your needs are met.  Paul's work on variable
> handles (JEP 193 [1]), e.g., is far enough along that feedback would
> be useful.


Sure, but that's orthogonal to putting up more red tape in java 9 when
replacements aren't in place yet.  If you guys want more involvement in the
development/validation of replacements, that needs to happen now anyway and
not wait until java 9.

Making sun.misc.Unsafe harder to use will also help the many users who
> unknowingly depend upon this unsupported API, via libraries which do
> depend upon it, to become aware of that dependence.  They can then
> either seek alternatives or ask the maintainers of those libraries to
> do so.


I get what you're after here, but I'm not sure it's going to have the
desired effect; if a user of a lib that uses Unsafe has to now change their
launch commands to add a flag, they're not going to be irritated by the lib
author.  Also, the library author may rightly point out that s/he can't
move away from Unsafe yet because some of the replacement feature(s) aren't
in place yet.  This type of thing would carry more weight if Unsafe is
fully replaceable in terms of perf and functionality when these roadblocks
are put up.


On Tue, Jun 23, 2015 at 12:12 PM, <mark.reinhold at oracle.com> wrote:

> 2015/6/23 8:45 -0700, vitalyd at gmail.com:
> > Yes, but until all the "safe" replacements are in place and vetted (e.g.
> > performance is on par with Unsafe, same functionality is available,
> etc), I
> > don't see the point of making it even more annoying to grab hold of.  The
> > people who are using it will continue using it until the replacements are
> > available, and this is just going to annoy them.
>
> That's precisely the point.
>
> sun.misc.Unsafe and its ilk will go away one day.  In preparation for
> that, making it a bit harder to use will motivate its current users to
> consider whether they really do need to use it -- some do, but some
> don't.
>
> If you absolutely do need it then now is the time to start looking at
> the alternatives in development, and contribute to those efforts in
> order to make sure that your needs are met.  Paul's work on variable
> handles (JEP 193 [1]), e.g., is far enough along that feedback would
> be useful.
>
> Making sun.misc.Unsafe harder to use will also help the many users who
> unknowingly depend upon this unsupported API, via libraries which do
> depend upon it, to become aware of that dependence.  They can then
> either seek alternatives or ask the maintainers of those libraries to
> do so.
>
> - Mark
>
>
> [1] http://openjdk.java.net/jeps/193
>