Jeroen, I agree with you (1) not everyone holds the belief and (2) this is not a technical limitation. This is simply a matter of perspective and intent. However, those in charge in the JDK seem pretty strong on #1 -- at least from what I've seen in my interactions. That's why I don't think this will gain traction, but I am always willing to be surprised.
On Wed, Mar 5, 2014 at 9:38 AM, Jeroen Frijters <jer...@sumatra.nl> wrote: > 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.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] > > On Behalf Of Paul Benedict > > Sent: Wednesday, March 5, 2014 16:19 > > To: Christoph Engelbert > > Cc: Jeroen Frijters; core-libs-dev@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 <m...@noctarius.com > > <mailto:m...@noctarius.com> > wrote: > > > > > > Am 05.03.2014 um 08:40 schrieb Jeroen Frijters <jer...@sumatra.nl > > <mailto:jer...@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 > -- Cheers, Paul
