JEP 193: Enhanced Volatiles

[Jeroen Frijters]

The JVM should be picking up the annotations (otherwise, you'd still need to design a public API to deal with atomics).

BTW, it was explained to me at the JVM Language Summit that the "commonly held belief" about annotations, is not in fact true.

Regards,
Jeroen

> -----Original Message-----
> From: paulus.benedictus at gmail.com [mailto:paulus.benedictus at gmail.com]
> On Behalf Of Paul Benedict
> Sent: Wednesday, March 5, 2014 16:19
> To: Christoph Engelbert
> Cc: Jeroen Frijters; core-libs-dev at openjdk.java.net
> Subject: Re: JEP 193: Enhanced Volatiles
> 
> 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
> <mailto:me at noctarius.com> > wrote:
> 
> 
> 	Am 05.03.2014 um 08:40 schrieb Jeroen Frijters <jeroen at sumatra.nl
> <mailto: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