VarHandle prototype pushed
john.r.rose at oracle.com
Fri Aug 8 19:32:07 UTC 2014
On Aug 8, 2014, at 10:56 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> Personally, I like the language enhancement because I am not fond of declaring wrapper objects -- it's more boilerplate. The tests seemed to confirm this for me. I like the inline convenience of the proposed keyword.
> I think when you finish pulling on the string entailed by the suggested language enhancements, you’ll find they’re not as clean as you might imagine. For example, where are the methods on “foo.volatile” declared? Magic is required.
These are easy questions to ask, and you have to pull the string pretty far to start to see the answers. Joe Darcy has written about the surprising number of factors that go into a simple-seeming language modification; see https://blogs.oracle.com/darcy/entry/so_you_want_to_change
The case of a syntax like foo.volatile is not as simple as the examples Joe talks about. But, it is possible that sugar can be designed by referring name and type checking to suitable VarHandle types, mixing in signature polymorphism (ad hoc or via MH) to avoid boxing, and managing the combinatorial complexity with invokedynamic. But it is complicated, and the quality of the outcome depends on many subtle factors. We're not ready to try it yet.
>> But I am more interested in the decision to make VarHandle an abstract class over an interface. Why wouldn't a pure contract be preferred?
> Note that MethodHandle is an abstract class too! (Most people don’t notice this.) There are implementation constraints that make this particular wart preferable (both security and performance constraints.)
In this case, we introduced a carefully limited language and VM feature called signature polymorphism. There is no direct way, in the Java language, to define or override a signature polymorphic method such as MH.invoke. (You could do stuff with boxing and varargs, but that defeats the purpose of a direct connection.) That is why invoke and invokeExact are carefully defined as native final methods. As a result, MH cannot be an interface.
More information about the valhalla-dev