JEP 193: Enhanced Volatiles

[Brian Goetz]

>> 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 
miserably.

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.