JEP 193: Enhanced Volatiles (original) (raw)

Paul Benedict pbenedict at apache.org
Wed Mar 5 15🔞30 UTC 2014

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

More information about the core-libs-dev mailing list