VarHandle prototype pushed

[Paul Benedict]

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.

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?


Cheers,
Paul


On Fri, Aug 8, 2014 at 11:08 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> The two exist at different layers; they don’t compete.
>
> Doug’s proposal was for surface syntax.  But, that still leaves the
> question, if the compiler accepts this syntax, what bytecode should it
> generate to tell the VM what should be done?  Which means something like
> VarHandle (or more method handle forms, or some other “safe unsafe” API) is
> needed under the hood anyway.
>
> That said, my current gut feeling is that, the VarHandle API is clean
> enough that we could get away without additional syntax, which would be
> nice.
>
> On Aug 8, 2014, at 11:18 AM, Paul Benedict <pbenedict at apache.org> wrote:
>
> > Is the VarHandle prototype the favored solution at this point? Is Doug's
> > volatile proposal no longer favored?
> >
> >
> > Cheers,
> > Paul
> >
> >
> > On Thu, Aug 7, 2014 at 3:31 AM, Paul Sandoz <Paul.Sandoz at oracle.com>
> wrote:
> >
> >> Hi,
> >>
> >> I have just pushed the VarHandle prototype. More details can be found
> here:
> >>
> >>  http://cr.openjdk.java.net/~psandoz/varhandles/VarHandle-0.1.md
> >>  http://cr.openjdk.java.net/~psandoz/varhandles/jvmls14-varHandles.pdf
> >>
> >> Hopefully it won't cause too much disturbance in the "force", but if
> >> anyone pulled in-between my pushes to jdk, langtools and hotspot then
> one
> >> will need pull again so everything is in sync. Also, it is unlikely to
> step
> >> on the value type/specialization area as the changes to
> langtools/hotspot
> >> are focused on areas particular to polymorphic signature methods.
> >>
> >> This prototype is sufficient to play around with the API, validate
> >> performance and find issues, but it's still very much work in progress.
> >>
> >> I have yet to push a patch to update certain j.u.c classes to replace
> >> Unsafe with VarHandle [1]. I am pondering whether to have separate
> renamed
> >> classes, which is nice for a side-to-side comparison in the same code
> base,
> >> but would force test code (e.g. 166 loops tests) to be updated.
> >>
> >> Paul.
> >>
> >> [1]
> >>
> http://cr.openjdk.java.net/~psandoz/varhandles/jdk-varhandle-juc.patch/webrev/
>
>