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

[Remi Forax]

Hi Mark,

On 06/23/2015 06: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.

I've never seen a project that use Unsafe without a good reason
(off-heap, more fine grained concurrency primitives, faster 
serialization, etc).

People will move from unsafe iff there is a good public replacement API.
'Educating' smart people, the ones that build businesses on top of this API,
by trying to use their users against them is in my opinion a stupid move.

There will be no replacement for Unsafe in 9, it's a shame but we are 
not ready,
we should wait 10 have a good migation plan and push the red button.
But you already know that.

regards,
Rémi

> 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