Jigsaw Hackday in London - Anything in particular you want us to look at?
forax at univ-mlv.fr
Tue Jun 23 16:34:01 UTC 2015
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
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
we should wait 10 have a good migation plan and push the red button.
But you already know that.
> 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
> 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 ), 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
>  http://openjdk.java.net/jeps/193
More information about the jigsaw-dev