JEP 193: Enhanced Volatiles

[Paul Benedict]

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 <jeroen at 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.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
>



-- 
Cheers,
Paul