JEP 193: Enhanced Volatiles

[Paul Benedict]

This idea really close very the commonly held belief that annotations
shouldn't be used to extend the language -- and thus will not be accepted.
If the compiler is picking up these annotations to emit different code,
that is obviously "shoehorning" annotations into a language feature.


On Wed, Mar 5, 2014 at 1:51 AM, Christoph Engelbert <me at noctarius.com>wrote:

> Am 05.03.2014 um 08:40 schrieb Jeroen Frijters <jeroen at sumatra.nl>:
>
> >>  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.
> >
> > Why not go for something far less intrusive then? Here's my straw man
> proposal:
> >
> > Add an annotation that can be placed on native methods to synthesize
> atomic accessor methods.
> >
> > Example usage:
> >
> > @AtomicField("next")
> > private native boolean compareAndSet(Node expected, Node newValue);
> >
> > @AtomicArray
> > private static native boolean compareAndSet(Node[] array, Node expected,
> Node newValue);
> >
> > (Note that the method name is not significant, the operation can be
> derived from the signature, or explicit in the annotation, if necessary.)
> >
> > This requires no changes to the language and adds only a slight burden
> on the developer (but it's very easy to add tooling support).
> >
> > Regards,
> > Jeroen
> >
>
> That looks like a good fit towards what was mentioned earlier using method
> handles. The JVM or compiler could just look out for those annotations and
> generate corresponding method / field handles to execute it.
>
> Thanks,
> Chris
>
>


-- 
Cheers,
Paul