Hi Mark,
On 06/23/2015 06:12 PM, [email protected] wrote:
2015/6/23 8:45 -0700, [email protected]:
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
