JEP 193: Enhanced Volatiles
brian.goetz at oracle.com
Wed Mar 5 00:11:04 UTC 2014
>> Embedded in this proposal is the desire to not provide a
>> full-blown "lvalue" form for variables; supporting any form of
>> pass-by-reference at the language level is a super-non-goal here.
> Why is this? It solves these problems in an extremely clean way and
> also provides lots of other value (for example, for JEP 191: Foreign
> Function Interface).
> I understand pass-by-reference is an expensive feature, but IMNSHO
> poluting Java with this proposal will prove to be more expensive in
> the long run. It's like erased generics all over again.
It has nothing to do with it being expensive (though it is); it has to
do with being an outright *bad idea* from a stewardship perspective.
Right now, the semantics of method calls in Java are simple --
everything (primitives, object references) is passed by value. Adding
pass-by-reference would add significant complexity. And method calls
are not a niche feature; that added complexity will be borne by every
developer, every day.
On the other hand, these weird foo.volatile.xxx operations would be used
by .0001% of Java developers (congratulations, you're special!) Doesn't
it make sense to move the damage to where it only affects those who need
it? Or, looking at it the other way, does it make any sense at all to
make a key facet of the language dramatically more complex just so that
a niche cadre of sewer-dwelling expert users can more easily write the
code they want?
Spending most of your time in the performance-critical coding sewers
often has the unfortunate effect of anti-qualifying you for reasoning
about what platform features would be good for the community as a whole.
My goal here is to make sure that expert users can get their job done
somehow, *without* making the job of mainstream developers harder. The
"add lvalues to Java so experts can write CAS-libraries" fails that test
Note that we're not adding any new functionality here; what we're doing
is pulling some functionality from Unsafe into the public programming
model. Making drastic changes to a key language feature to support that
would be killing a fly with a bazooka. And, as I said at the top, its a
bad idea anyway.
More information about the core-libs-dev