David Holmes wrote:
But if the JVM acts upon annotations to change how it executes those
bytecodes then, as Peter said, the JVM is implementing the language
semantics.
The JVM synthesizes a native method, this has *nothing* to do with language
semantics. From the language point of view,
On 03/06/2014 01:24 AM, David Holmes wrote:
On 6/03/2014 3:22 AM, Remi Forax wrote:
On 03/05/2014 06:07 PM, Peter Levart wrote:
On 03/05/2014 05:55 PM, Jeroen Frijters wrote:
Brian Goetz wrote:
I suspect you were expecting this response: we don't add language
semantics through annotations.
On 03/05/2014 01:05 AM, Doug Lea wrote:
On 03/04/2014 05:12 PM, Florian Weimer wrote:
On 03/04/2014 01:05 PM, Doug Lea wrote:
On 03/04/2014 02:41 AM, Jeroen Frijters wrote:
I understand pass-by-reference is an expensive feature, but IMNSHO
poluting
Java with this proposal will prove to be
What is the interaction with synthetic accessor methods for private
fields? Is it not an issue because the field references will be textual
anyway, so that no JVM checks will interfere?
--
Florian Weimer / Red Hat Product Security Team
On 03/06/2014 09:25 AM, Florian Weimer wrote:
On 03/05/2014 01:05 AM, Doug Lea wrote:
On 03/04/2014 05:12 PM, Florian Weimer wrote:
On 03/04/2014 01:05 PM, Doug Lea wrote:
On 03/04/2014 02:41 AM, Jeroen Frijters wrote:
I understand pass-by-reference is an expensive feature, but IMNSHO
Am 03.03.2014 20:26, schrieb mark.reinh...@oracle.com:
Posted: http://openjdk.java.net/jeps/193
- Mark
Reading about ideas to integrate atomic operations into the language, I
was asking myself which of these operations I was using most frequently
in my own code (currently by means of
-
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
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
(This is already-traveled ground.)
The ++/--/+= trick is cute as a shorthand, but without a means of
expressing a full-blown CAS, falls short of the goal of integrate
atomic read-modify-write operations into the programming model. IF the
latter problem was addressed, we might consider
Why not go for something far less intrusive then?
I'm all for unintrusive. Though note that the intrusiveness metric on
language features I(f) is not uniform across observers :)
Here's my straw man
proposal:
Add an annotation that can be placed on native methods to synthesize
atomic
On 03/05/2014 05:55 PM, Jeroen Frijters wrote:
Brian Goetz wrote:
I suspect you were expecting this response: we don't add language
semantics through annotations.
Technically, we're not adding language semantics. The JVM is the one
interpreting the annotations.
And the JVM is the one
On 03/05/2014 06:07 PM, Peter Levart wrote:
On 03/05/2014 05:55 PM, Jeroen Frijters wrote:
Brian Goetz wrote:
I suspect you were expecting this response: we don't add language
semantics through annotations.
Technically, we're not adding language semantics. The JVM is the one
interpreting
I suspect you were expecting this response: we don't add language
semantics through annotations.
Technically, we're not adding language semantics. The JVM is the one
interpreting the annotations. BTW, as I mentioned in another post in this
thread, I specifically asked about this at the JVM
Brian Goetz wrote:
I'm all for unintrusive. Though note that the intrusiveness metric on
language features I(f) is not uniform across observers :)
Indeed :-)
Here's my straw man
proposal:
Add an annotation that can be placed on native methods to synthesize
atomic accessor methods.
On 03/05/2014 05:55 PM, Jeroen Frijters wrote:
Brian Goetz wrote:
I'm all for unintrusive. Though note that the intrusiveness metric on
language features I(f) is not uniform across observers :)
Indeed :-)
Here's my straw man
proposal:
Add an annotation that can be placed on native methods
On 03/03/2014 04:25 PM, Brian Goetz wrote:
Posted: http://openjdk.java.net/jeps/193
Some follow-up thoughts on teasing apart the issues covered by this JEP.
There are three main layers of questions to answer:
1. How do we surface the various pieces of this into the programming
model? This
On 03/04/2014 03:16 PM, David M. Lloyd wrote:
On 03/03/2014 04:53 PM, David M. Lloyd wrote:
On 03/03/2014 04:25 PM, Brian Goetz wrote:
Posted: http://openjdk.java.net/jeps/193
Some follow-up thoughts on teasing apart the issues covered by this JEP.
There are three main layers of questions
On 03/05/2014 02:37 PM, David M. Lloyd wrote:
On 03/03/2014 04:25 PM, Brian Goetz wrote:
Posted: http://openjdk.java.net/jeps/193
Some follow-up thoughts on teasing apart the issues covered by this JEP.
There are three main layers of questions to answer:
1. How do we surface the various
On 6/03/2014 3:22 AM, Remi Forax wrote:
On 03/05/2014 06:07 PM, Peter Levart wrote:
On 03/05/2014 05:55 PM, Jeroen Frijters wrote:
Brian Goetz wrote:
I suspect you were expecting this response: we don't add language
semantics through annotations.
Technically, we're not adding language
-Original Message-
From: Peter Levart [mailto:peter.lev...@gmail.com]
Sent: Wednesday, March 5, 2014 18:07
To: Jeroen Frijters; Brian Goetz; core-libs-dev@openjdk.java.net; Doug
Lea
Subject: Re: JEP 193: Enhanced Volatiles
On 03/05/2014 05:55 PM, Jeroen Frijters wrote:
Brian
On 03/04/2014 02:41 AM, Jeroen Frijters wrote:
Brian Goetz wrote:
Embedded in this proposal is the desire to not provide a full-blown
lvalue form for variables; supporting any form of pass-by-reference at
the language level is a super-non-goal here.
Why is this? It solves these problems in an
On 03/03/2014 04:53 PM, David M. Lloyd wrote:
On 03/03/2014 04:25 PM, Brian Goetz wrote:
Posted: http://openjdk.java.net/jeps/193
Some follow-up thoughts on teasing apart the issues covered by this JEP.
There are three main layers of questions to answer:
1. How do we surface the various
On 03/04/2014 01:05 PM, Doug Lea wrote:
On 03/04/2014 02:41 AM, Jeroen Frijters wrote:
Brian Goetz wrote:
Embedded in this proposal is the desire to not provide a full-blown
lvalue form for variables; supporting any form of pass-by-reference at
the language level is a super-non-goal here.
On 03/04/2014 05:12 PM, Florian Weimer wrote:
On 03/04/2014 01:05 PM, Doug Lea wrote:
On 03/04/2014 02:41 AM, Jeroen Frijters wrote:
I understand pass-by-reference is an expensive feature, but IMNSHO
poluting
Java with this proposal will prove to be more expensive in the long
run. It's
like
Embedded in this proposal is the desire to not provide a
full-blown lvalue form for variables; supporting any form of
pass-by-reference at the language level is a super-non-goal here.
Why is this? It solves these problems in an extremely clean way and
also provides lots of other value (for
Brian Goetz wrote:
Right now, the semantics of method calls in Java are simple --
everything (primitives, object references) is passed by value. Adding
pass-by-reference would add significant complexity. And method calls
are not a niche feature; that added complexity will be borne by every
Am 05.03.2014 um 08:40 schrieb Jeroen Frijters 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.
Posted: http://openjdk.java.net/jeps/193
- Mark
Posted: http://openjdk.java.net/jeps/193
Some follow-up thoughts on teasing apart the issues covered by this JEP.
There are three main layers of questions to answer:
1. How do we surface the various pieces of this into the programming
model? This includes language syntax (e.g.,
On 03/03/2014 04:25 PM, Brian Goetz wrote:
Posted: http://openjdk.java.net/jeps/193
Some follow-up thoughts on teasing apart the issues covered by this JEP.
There are three main layers of questions to answer:
1. How do we surface the various pieces of this into the programming
model? This
Brian Goetz wrote:
Embedded in this proposal is the desire to not provide a full-blown
lvalue form for variables; supporting any form of pass-by-reference at
the language level is a super-non-goal here.
Why is this? It solves these problems in an extremely clean way and also
provides lots of
31 matches
Mail list logo
