From scolebourne at joda.org Tue Feb 1 01:50:14 2011 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 1 Feb 2011 09:50:14 +0000 Subject: How to terminate resources in try-with-resources In-Reply-To: <4D477AD8.3040303@oracle.com> References: <4D477AD8.3040303@oracle.com> Message-ID: On 1 February 2011 03:15, Joe Darcy wrote: > In addition to mulling over nulling in the try-with-resources statement, > the JSR 334 expert group has decided to slightly amend the syntax of > try-with-resources statement: an optional trailing semicolon will now be > allowed to terminate the list of resources. +1 Stephen From mbien at fh-landshut.de Mon Feb 7 05:10:22 2011 From: mbien at fh-landshut.de (Michael Bien) Date: Mon, 07 Feb 2011 14:10:22 +0100 Subject: JDK6 backwards compatible AutoCloseable from a libraries perspective Message-ID: <4D4FEF3E.4080600@fh-landshut.de> Hello everyone, I would like to support the new try-with-resource feature in jocl while staying backwards compatible with JDK5/6. The problem is that AutoCloseable resides in java.lang which means i have no chance to load the class if i would ship it for jdk5 backwards compatibility. Providing two builds for JOCL is not what i would like to do just to be able to be upwards compatible. any ideas what i could do in this situation? best regards, michael -- http://jocl.jogamp.org http://michael-bien.com/ From forax at univ-mlv.fr Mon Feb 7 05:40:46 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 07 Feb 2011 14:40:46 +0100 Subject: JDK6 backwards compatible AutoCloseable from a libraries perspective In-Reply-To: <4D4FEF3E.4080600@fh-landshut.de> References: <4D4FEF3E.4080600@fh-landshut.de> Message-ID: <4D4FF65E.10605@univ-mlv.fr> Le 07/02/2011 14:10, Michael Bien a ?crit : > Hello everyone, > > I would like to support the new try-with-resource feature in jocl while > staying backwards compatible with JDK5/6. The problem is that > AutoCloseable resides in java.lang which means i have no chance to load > the class if i would ship it for jdk5 backwards compatibility. > > Providing two builds for JOCL is not what i would like to do just to be > able to be upwards compatible. > > any ideas what i could do in this situation? > > best regards, > michael You need to: Create a jocl internal equivalent to java.lang.AutoClosable, let say jocl.lang.AutoClosable, this class should extends java.lang.AutoClosable. modify you managed classes to implements jocl.lang.AutoClosable. compile with javac -source 7 -target 7 Now you have a 1.7 compatible version. The trick is to downgrade the classfiles to have a 1.5 compatible version. For this use a bytecode rewriter tools like ASM [1] to change a just some bits in the classfiles. modify the classfile of jocl.lang.AutoClosable to don't inherits from java.lang.AutoClosable anymore. downgrade the classfiles major version number from 51 (V1_7) to 49 (V1_5) In fact, there is a way to avoid to create jocl.lang.AutoClosable, you can analyze the bytecode to detect call to AutoClosable.close() and replace it by the type of the variable infered using the same algorithm as the verifier does. ASM package org.objectweb.asm.analysis already provides this analysis. R?mi [1] http://asm.ow2.org/ From mbien at fh-landshut.de Mon Feb 7 06:08:41 2011 From: mbien at fh-landshut.de (Michael Bien) Date: Mon, 07 Feb 2011 15:08:41 +0100 Subject: JDK6 backwards compatible AutoCloseable from a librariesperspective In-Reply-To: <4D4FF65E.10605@univ-mlv.fr> References: <4D4FEF3E.4080600@fh-landshut.de> <4D4FF65E.10605@univ-mlv.fr> Message-ID: <4D4FFCE9.7090709@fh-landshut.de> On 02/07/2011 02:40 PM, R?mi Forax wrote: > Le 07/02/2011 14:10, Michael Bien a ?crit : >> Hello everyone, >> >> I would like to support the new try-with-resource feature in jocl while >> staying backwards compatible with JDK5/6. The problem is that >> AutoCloseable resides in java.lang which means i have no chance to load >> the class if i would ship it for jdk5 backwards compatibility. >> >> Providing two builds for JOCL is not what i would like to do just to be >> able to be upwards compatible. >> >> any ideas what i could do in this situation? >> >> best regards, >> michael > You need to: > Create a jocl internal equivalent to java.lang.AutoClosable, let say > jocl.lang.AutoClosable, > this class should extends java.lang.AutoClosable. > modify you managed classes to implements jocl.lang.AutoClosable. > compile with javac -source 7 -target 7 > Now you have a 1.7 compatible version. > > The trick is to downgrade the classfiles to have a 1.5 compatible version. > For this use a bytecode rewriter tools like ASM [1] to change a just > some bits > in the classfiles. > modify the classfile of jocl.lang.AutoClosable to don't inherits from > java.lang.AutoClosable anymore. > downgrade the classfiles major version number from 51 (V1_7) to 49 (V1_5) > > In fact, there is a way to avoid to create jocl.lang.AutoClosable, you can > analyze the bytecode to detect call to AutoClosable.close() and replace it > by the type of the variable infered using the same algorithm as the > verifier does. > ASM package org.objectweb.asm.analysis already provides this analysis. > > R?mi > > [1] http://asm.ow2.org/ > > Thank you Remi, do i really have to compile with 1.7 language level even if i don't use ARM internally? -michael -- http://michael-bien.com/ From forax at univ-mlv.fr Mon Feb 7 06:32:17 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 07 Feb 2011 15:32:17 +0100 Subject: JDK6 backwards compatible AutoCloseable from a librariesperspective In-Reply-To: <4D4FFCE9.7090709@fh-landshut.de> References: <4D4FEF3E.4080600@fh-landshut.de> <4D4FF65E.10605@univ-mlv.fr> <4D4FFCE9.7090709@fh-landshut.de> Message-ID: <4D500271.8020005@univ-mlv.fr> Le 07/02/2011 15:08, Michael Bien a ?crit : > On 02/07/2011 02:40 PM, R?mi Forax wrote: >> Le 07/02/2011 14:10, Michael Bien a ?crit : >>> Hello everyone, >>> >>> I would like to support the new try-with-resource feature in jocl while >>> staying backwards compatible with JDK5/6. The problem is that >>> AutoCloseable resides in java.lang which means i have no chance to load >>> the class if i would ship it for jdk5 backwards compatibility. >>> >>> Providing two builds for JOCL is not what i would like to do just to be >>> able to be upwards compatible. >>> >>> any ideas what i could do in this situation? >>> >>> best regards, >>> michael >> You need to: >> Create a jocl internal equivalent to java.lang.AutoClosable, let say >> jocl.lang.AutoClosable, >> this class should extends java.lang.AutoClosable. >> modify you managed classes to implements jocl.lang.AutoClosable. >> compile with javac -source 7 -target 7 >> Now you have a 1.7 compatible version. >> >> The trick is to downgrade the classfiles to have a 1.5 compatible version. >> For this use a bytecode rewriter tools like ASM [1] to change a just >> some bits >> in the classfiles. >> modify the classfile of jocl.lang.AutoClosable to don't inherits from >> java.lang.AutoClosable anymore. >> downgrade the classfiles major version number from 51 (V1_7) to 49 (V1_5) >> >> In fact, there is a way to avoid to create jocl.lang.AutoClosable, you can >> analyze the bytecode to detect call to AutoClosable.close() and replace it >> by the type of the variable infered using the same algorithm as the >> verifier does. >> ASM package org.objectweb.asm.analysis already provides this analysis. >> >> R?mi >> >> [1] http://asm.ow2.org/ >> >> > Thank you Remi, > > do i really have to compile with 1.7 language level even if i don't use > ARM internally? yes, you have to. source of the compiler near line 165: http://hg.openjdk.java.net/jdk7/jdk7/langtools/file/1383d1ee8b5d/src/share/classes/com/sun/tools/javac/code/Source.java public boolean allowTryWithResources() { return compareTo(JDK1_7)>= 0; } > -michael R?mi From mbien at fh-landshut.de Mon Feb 7 07:06:24 2011 From: mbien at fh-landshut.de (Michael Bien) Date: Mon, 07 Feb 2011 16:06:24 +0100 Subject: JDK6 backwards compatible AutoCloseable from a libraries perspective In-Reply-To: <4D500271.8020005@univ-mlv.fr> References: <4D4FEF3E.4080600@fh-landshut.de> <4D4FF65E.10605@univ-mlv.fr><4D4FFCE9.7090709@fh-landshut.de> <4D500271.8020005@univ-mlv.fr> Message-ID: <4D500A70.2060802@fh-landshut.de> On 02/07/2011 03:32 PM, R?mi Forax wrote: > Le 07/02/2011 15:08, Michael Bien a ?crit : >> On 02/07/2011 02:40 PM, R?mi Forax wrote: >>> Le 07/02/2011 14:10, Michael Bien a ?crit : >>>> Hello everyone, >>>> >>>> I would like to support the new try-with-resource feature in jocl while >>>> staying backwards compatible with JDK5/6. The problem is that >>>> AutoCloseable resides in java.lang which means i have no chance to load >>>> the class if i would ship it for jdk5 backwards compatibility. >>>> >>>> Providing two builds for JOCL is not what i would like to do just to be >>>> able to be upwards compatible. >>>> >>>> any ideas what i could do in this situation? >>>> >>>> best regards, >>>> michael >>> You need to: >>> Create a jocl internal equivalent to java.lang.AutoClosable, let say >>> jocl.lang.AutoClosable, >>> this class should extends java.lang.AutoClosable. >>> modify you managed classes to implements jocl.lang.AutoClosable. >>> compile with javac -source 7 -target 7 >>> Now you have a 1.7 compatible version. >>> >>> The trick is to downgrade the classfiles to have a 1.5 compatible version. >>> For this use a bytecode rewriter tools like ASM [1] to change a just >>> some bits >>> in the classfiles. >>> modify the classfile of jocl.lang.AutoClosable to don't inherits from >>> java.lang.AutoClosable anymore. >>> downgrade the classfiles major version number from 51 (V1_7) to 49 (V1_5) >>> >>> In fact, there is a way to avoid to create jocl.lang.AutoClosable, you can >>> analyze the bytecode to detect call to AutoClosable.close() and replace it >>> by the type of the variable infered using the same algorithm as the >>> verifier does. >>> ASM package org.objectweb.asm.analysis already provides this analysis. >>> >>> R?mi >>> >>> [1] http://asm.ow2.org/ >>> >>> >> Thank you Remi, >> >> do i really have to compile with 1.7 language level even if i don't use >> ARM internally? > yes, you have to. > source of the compiler near line 165: > http://hg.openjdk.java.net/jdk7/jdk7/langtools/file/1383d1ee8b5d/src/share/classes/com/sun/tools/javac/code/Source.java > > public boolean allowTryWithResources() { > return compareTo(JDK1_7)>= 0; > } > >> -michael > R?mi > hmm. In this case it would be much easier (and less risky regarding QA) do just use simple string replacement and build the library twice. (since we can't create one jar which is compatible in both scenarios) Once with com.jogamp.common.AutoCloseable extends java.lang.AutoCloseable (with JDK7 lang level7) and once with com.jogamp.common.AutoCloseable /*extends java.lang.AutoCloseable*/ (with JDK6 lang level5) should have the same effect, right? michael From forax at univ-mlv.fr Mon Feb 7 07:14:21 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 07 Feb 2011 16:14:21 +0100 Subject: JDK6 backwards compatible AutoCloseable from a libraries perspective In-Reply-To: <4D500A70.2060802@fh-landshut.de> References: <4D4FEF3E.4080600@fh-landshut.de> <4D4FF65E.10605@univ-mlv.fr><4D4FFCE9.7090709@fh-landshut.de> <4D500271.8020005@univ-mlv.fr> <4D500A70.2060802@fh-landshut.de> Message-ID: <4D500C4D.1020503@univ-mlv.fr> Le 07/02/2011 16:06, Michael Bien a ?crit : > On 02/07/2011 03:32 PM, R?mi Forax wrote: >> Le 07/02/2011 15:08, Michael Bien a ?crit : >>> On 02/07/2011 02:40 PM, R?mi Forax wrote: >>>> Le 07/02/2011 14:10, Michael Bien a ?crit : >>>>> Hello everyone, >>>>> >>>>> I would like to support the new try-with-resource feature in jocl while >>>>> staying backwards compatible with JDK5/6. The problem is that >>>>> AutoCloseable resides in java.lang which means i have no chance to load >>>>> the class if i would ship it for jdk5 backwards compatibility. >>>>> >>>>> Providing two builds for JOCL is not what i would like to do just to be >>>>> able to be upwards compatible. >>>>> >>>>> any ideas what i could do in this situation? >>>>> >>>>> best regards, >>>>> michael >>>> You need to: >>>> Create a jocl internal equivalent to java.lang.AutoClosable, let say >>>> jocl.lang.AutoClosable, >>>> this class should extends java.lang.AutoClosable. >>>> modify you managed classes to implements jocl.lang.AutoClosable. >>>> compile with javac -source 7 -target 7 >>>> Now you have a 1.7 compatible version. >>>> >>>> The trick is to downgrade the classfiles to have a 1.5 compatible version. >>>> For this use a bytecode rewriter tools like ASM [1] to change a just >>>> some bits >>>> in the classfiles. >>>> modify the classfile of jocl.lang.AutoClosable to don't inherits from >>>> java.lang.AutoClosable anymore. >>>> downgrade the classfiles major version number from 51 (V1_7) to 49 (V1_5) >>>> >>>> In fact, there is a way to avoid to create jocl.lang.AutoClosable, you can >>>> analyze the bytecode to detect call to AutoClosable.close() and replace it >>>> by the type of the variable infered using the same algorithm as the >>>> verifier does. >>>> ASM package org.objectweb.asm.analysis already provides this analysis. >>>> >>>> R?mi >>>> >>>> [1] http://asm.ow2.org/ >>>> >>>> >>> Thank you Remi, >>> >>> do i really have to compile with 1.7 language level even if i don't use >>> ARM internally? >> yes, you have to. >> source of the compiler near line 165: >> http://hg.openjdk.java.net/jdk7/jdk7/langtools/file/1383d1ee8b5d/src/share/classes/com/sun/tools/javac/code/Source.java >> >> public boolean allowTryWithResources() { >> return compareTo(JDK1_7)>= 0; >> } >> >>> -michael >> R?mi >> > hmm. In this case it would be much easier (and less risky regarding QA) > do just use simple string replacement and build the library twice. > (since we can't create one jar which is compatible in both scenarios) > > Once with > com.jogamp.common.AutoCloseable extends java.lang.AutoCloseable (with > JDK7 lang level7) > and once with > com.jogamp.common.AutoCloseable /*extends java.lang.AutoCloseable*/ > (with JDK6 lang level5) > > should have the same effect, right? > > michael > Almost, you also have to downgrade the classfile version. R?mi From tball at google.com Mon Feb 7 10:21:17 2011 From: tball at google.com (Tom Ball) Date: Mon, 7 Feb 2011 10:21:17 -0800 Subject: JDK6 backwards compatible AutoCloseable from a librariesperspective In-Reply-To: <4D500271.8020005@univ-mlv.fr> References: <4D4FEF3E.4080600@fh-landshut.de> <4D4FF65E.10605@univ-mlv.fr> <4D4FFCE9.7090709@fh-landshut.de> <4D500271.8020005@univ-mlv.fr> Message-ID: Hacking javac seems easier -- just change the allowTryWithResources test and the constant for the AutoCloseable classname so its package is outside of java.lang. The compiler changes I submitted to support ARM don't have any other Java 7 dependencies, nor do they create Java 7-only output (aside from the java.lang reference). Although Oracle has changed what I submitted (made it better, no doubt :-), it's unlikely they added anything that would break this. To hack javac, just clone langtools/ and follow its README for the build instructions. Tom On Mon, Feb 7, 2011 at 6:32 AM, R?mi Forax wrote: > Le 07/02/2011 15:08, Michael Bien a ?crit : > > On 02/07/2011 02:40 PM, R?mi Forax wrote: > >> Le 07/02/2011 14:10, Michael Bien a ?crit : > >>> Hello everyone, > >>> > >>> I would like to support the new try-with-resource feature in jocl while > >>> staying backwards compatible with JDK5/6. The problem is that > >>> AutoCloseable resides in java.lang which means i have no chance to load > >>> the class if i would ship it for jdk5 backwards compatibility. > >>> > >>> Providing two builds for JOCL is not what i would like to do just to be > >>> able to be upwards compatible. > >>> > >>> any ideas what i could do in this situation? > >>> > >>> best regards, > >>> michael > >> You need to: > >> Create a jocl internal equivalent to java.lang.AutoClosable, let say > >> jocl.lang.AutoClosable, > >> this class should extends java.lang.AutoClosable. > >> modify you managed classes to implements jocl.lang.AutoClosable. > >> compile with javac -source 7 -target 7 > >> Now you have a 1.7 compatible version. > >> > >> The trick is to downgrade the classfiles to have a 1.5 compatible > version. > >> For this use a bytecode rewriter tools like ASM [1] to change a just > >> some bits > >> in the classfiles. > >> modify the classfile of jocl.lang.AutoClosable to don't inherits > from > >> java.lang.AutoClosable anymore. > >> downgrade the classfiles major version number from 51 (V1_7) to 49 > (V1_5) > >> > >> In fact, there is a way to avoid to create jocl.lang.AutoClosable, you > can > >> analyze the bytecode to detect call to AutoClosable.close() and replace > it > >> by the type of the variable infered using the same algorithm as the > >> verifier does. > >> ASM package org.objectweb.asm.analysis already provides this analysis. > >> > >> R?mi > >> > >> [1] http://asm.ow2.org/ > >> > >> > > Thank you Remi, > > > > do i really have to compile with 1.7 language level even if i don't use > > ARM internally? > > yes, you have to. > source of the compiler near line 165: > > http://hg.openjdk.java.net/jdk7/jdk7/langtools/file/1383d1ee8b5d/src/share/classes/com/sun/tools/javac/code/Source.java > > public boolean allowTryWithResources() { > return compareTo(JDK1_7)>= 0; > } > > > > -michael > > R?mi > > > > From sonali.goel at oracle.com Mon Feb 7 12:00:40 2011 From: sonali.goel at oracle.com (sonali.goel at oracle.com) Date: Mon, 7 Feb 2011 12:00:40 -0800 (PST) Subject: Auto Reply: coin-dev Digest, Vol 25, Issue 2 Message-ID: <7583ab54-7649-4d95-b5ef-a1c1ff2e89ec@default> This is an auto-reply. I am out of office and travelling with limited access to email. Please contact the following: Steve Sides - Rhino and JavaDoc for JDK7 Randy - Sponsor Revamp and JdkTests For urgent matters, please contact Vita.Santrucek at oracle.com From daniel.smith at oracle.com Mon Feb 7 16:21:13 2011 From: daniel.smith at oracle.com (Dan Smith) Date: Mon, 7 Feb 2011 16:21:13 -0800 Subject: JDK6 backwards compatible AutoCloseable from a libraries perspective In-Reply-To: <4D4FEF3E.4080600@fh-landshut.de> References: <4D4FEF3E.4080600@fh-landshut.de> Message-ID: <6402823E-3DA6-4F22-92AE-3DE12B54BCBF@oracle.com> You should definitely take a look at Retroweaver, if you're not aware of it: It provides substitute APIs for Java 5 features and performs appropriate transformations to class files as a post-compilation step. Of course, it won't solve your problem automatically (it doesn't know about Java 7 features; I don't know if it will be updated eventually to handle them). But it would probably be straightforward to modify its sources appropriately. ?Dan On Feb 7, 2011, at 5:10 AM, Michael Bien wrote: > Hello everyone, > > I would like to support the new try-with-resource feature in jocl while > staying backwards compatible with JDK5/6. The problem is that > AutoCloseable resides in java.lang which means i have no chance to load > the class if i would ship it for jdk5 backwards compatibility. > > Providing two builds for JOCL is not what i would like to do just to be > able to be upwards compatible. > > any ideas what i could do in this situation? > > best regards, > michael > > -- > http://jocl.jogamp.org > http://michael-bien.com/ > > From daniel.smith at oracle.com Wed Feb 9 12:43:13 2011 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 9 Feb 2011 12:43:13 -0800 Subject: Update on JSR 334 Expert Group activities In-Reply-To: References: <4D3A1522.40901@oracle.com> <4D3E933B.2040506@paradise.net.nz> <4D408010.4060304@oracle.com> Message-ID: If Charles Babbage could make a computer without electronics, surely we'll be able to assemble a Java Mechanical Machine (JMM) to implement the JVM. ?Dan On Jan 26, 2011, at 4:14 PM, Joshua Bloch wrote: > Joe, > > > Well, after the impending EMP destroys all digital devices, perhaps there > will be a resurgence of Morse Code. But on the other hand, there won't be > any CPUs to take advantage of our fine specifications. > > Josh > > On Wed, Jan 26, 2011 at 12:12 PM, Joe Darcy wrote: > >> On 1/25/2011 8:52 PM, Cay Horstmann wrote: >>>> On 25/01/2011 9:22 p.m., Reinier Zwitserloot wrote: >>>> One good reason to disallow multiple underscores is to keep multiple >>>> underscores available for future language expansion. Presumably JDK7 >> isn't >>>> the last java release to have new language features. I admit I can't >> think >>>> of anything that would be best served by multiple underscores, but who >> knows >>>> what java needs 5 years from now? >>> Morse code literals, ._.. .. _._ . _ .... .. ... >>> >>> Cheers, >>> >>> _._. ._ _.__ >> >> ..-. .-- .. .--, given that the FCC has dropped the Morse code >> requirement to obtain an amateur radio license in the US [1], I don't >> see a growing need for Morse code literals five years hence! >> >> -Joe >> >> [1] >> >> http://en.wikipedia.org/wiki/Amateur_radio_licensing_in_the_United_States#Technician:_the_first_license_without_Morse_code >> >> >> > From forax at univ-mlv.fr Wed Feb 16 02:04:19 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 16 Feb 2011 11:04:19 +0100 Subject: Huston, we have a problem ! Message-ID: <4D5BA123.8050801@univ-mlv.fr> public class DiamondRaw { public static void main(String[] args) { String s = new String<>("foo"); } } R?mi From David.Holmes at oracle.com Wed Feb 16 03:02:43 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 16 Feb 2011 21:02:43 +1000 Subject: Huston, we have a problem ! In-Reply-To: <4D5BA123.8050801@univ-mlv.fr> References: <4D5BA123.8050801@univ-mlv.fr> Message-ID: <4D5BAED3.7020909@oracle.com> R?mi Forax said the following on 02/16/11 20:04: > public class DiamondRaw { > public static void main(String[] args) { > String s = new String<>("foo"); > } > } Ok I'll bite. What's the problem? :) I haven't seen a complete spec for this operator, but it doesn't seem unreasonable that diamond on a non-generic type is just a waste of two characters. David From maurizio.cimadamore at oracle.com Wed Feb 16 03:11:40 2011 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 16 Feb 2011 11:11:40 +0000 Subject: Huston, we have a problem ! In-Reply-To: <4D5BA123.8050801@univ-mlv.fr> References: <4D5BA123.8050801@univ-mlv.fr> Message-ID: <4D5BB0EC.4020602@oracle.com> On 16/02/11 10:04, R?mi Forax wrote: > public class DiamondRaw { > public static void main(String[] args) { > String s = new String<>("foo"); > } > } > > R?mi > > Ouch - good catch; JLS 4.5 requires that a compile-time error should be issued if the numbers of type-arguments of a parameterized type is different from the number of the type-parameters in the corresponding generic class declaration. Now, with diamond this a bit of a gray area - i.e. can <> stand for a nilary type-argument list? If so, the above program should compile, otherwise it shouldn't. The compiler implements the former, but I agree with Remi that the latter should be preferred. Maurizio From forax at univ-mlv.fr Wed Feb 16 03:30:26 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 16 Feb 2011 12:30:26 +0100 Subject: Huston, we have a problem ! In-Reply-To: <4D5BAED3.7020909@oracle.com> References: <4D5BA123.8050801@univ-mlv.fr> <4D5BAED3.7020909@oracle.com> Message-ID: <4D5BB552.1050902@univ-mlv.fr> On 02/16/2011 12:02 PM, David Holmes wrote: > R?mi Forax said the following on 02/16/11 20:04: >> public class DiamondRaw { >> public static void main(String[] args) { >> String s = new String<>("foo"); >> } >> } > > Ok I'll bite. What's the problem? :) > > I haven't seen a complete spec for this operator, but it doesn't seem > unreasonable that diamond on a non-generic type is just a waste of two > characters. > > David David, In fact, you have already use this feature when you write ForkJoinUtils. I've found that bug when trying to understand your code. R?mi From David.Holmes at oracle.com Wed Feb 16 04:39:33 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 16 Feb 2011 22:39:33 +1000 Subject: Huston, we have a problem ! In-Reply-To: <4D5BB552.1050902@univ-mlv.fr> References: <4D5BA123.8050801@univ-mlv.fr> <4D5BAED3.7020909@oracle.com> <4D5BB552.1050902@univ-mlv.fr> Message-ID: <4D5BC585.3020306@oracle.com> R?mi Forax said the following on 02/16/11 21:30: > On 02/16/2011 12:02 PM, David Holmes wrote: >> R?mi Forax said the following on 02/16/11 20:04: >>> public class DiamondRaw { >>> public static void main(String[] args) { >>> String s = new String<>("foo"); >>> } >>> } >> Ok I'll bite. What's the problem? :) >> >> I haven't seen a complete spec for this operator, but it doesn't seem >> unreasonable that diamond on a non-generic type is just a waste of two >> characters. >> > > In fact, you have already use this feature when you write ForkJoinUtils. > I've found that bug when trying to understand your code. :) Pure accident. David From jjb at google.com Wed Feb 16 08:26:52 2011 From: jjb at google.com (Joshua Bloch) Date: Wed, 16 Feb 2011 08:26:52 -0800 Subject: Huston, we have a problem ! In-Reply-To: <4D5BC585.3020306@oracle.com> References: <4D5BA123.8050801@univ-mlv.fr> <4D5BAED3.7020909@oracle.com> <4D5BB552.1050902@univ-mlv.fr> <4D5BC585.3020306@oracle.com> Message-ID: I agree that it should be illegal. Josh From joe.darcy at oracle.com Wed Feb 16 10:07:08 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 16 Feb 2011 10:07:08 -0800 Subject: Huston, we have a problem ! In-Reply-To: References: <4D5BA123.8050801@univ-mlv.fr> <4D5BAED3.7020909@oracle.com> <4D5BB552.1050902@univ-mlv.fr> <4D5BC585.3020306@oracle.com> Message-ID: <4D5C124C.90906@oracle.com> On 2/16/2011 8:26 AM, Joshua Bloch wrote: > I agree that it should be illegal. > > Josh > Hello. Yes, applying <> to a non-generic class is explicitly forbidden in a revised specification under discussion by the expert group. Thanks for finding the issue Remi. I've filed 7020043 "Project Coin: diamond allowed on non-generic type" to track this and we'll get it fixed in a upcoming build. -Joe From benjamin.john.evans at gmail.com Wed Feb 16 11:35:49 2011 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Wed, 16 Feb 2011 19:35:49 +0000 Subject: Fwd: Huston, we have a problem ! References: Message-ID: <4761FC7F-AEF0-410B-9708-4FCCFC38090B@gmail.com> Try again, actually replying to list this time. Sent from my iPhone Begin forwarded message: > From: Ben Evans > Date: 16 February 2011 17:05:12 GMT > To: Joshua Bloch > Subject: Re: Huston, we have a problem ! > > OK, at the risk of looking stupid - why? > > I read <> as a "do some type inference about the generics" - if it's not a generic type, then I could see it resolving to nothing at all. > > In a related example, what about the case of a raw type on the LHS? > > HashMap hm = new HashMap<>(); > > If the non-generic example is deemed to be a syntax error, what about this case? > > Thanks, > > Ben > > On 16 Feb 2011, at 16:26, Joshua Bloch wrote: > >> I agree that it should be illegal. >> >> Josh >> From tronicek at fit.cvut.cz Wed Feb 16 12:01:14 2011 From: tronicek at fit.cvut.cz (=?utf-8?B?IlpkZW7Em2sgVHJvbsOtxI1layI=?=) Date: Wed, 16 Feb 2011 21:01:14 +0100 Subject: Fwd: Huston, we have a problem ! In-Reply-To: <4761FC7F-AEF0-410B-9708-4FCCFC38090B@gmail.com> References: <4761FC7F-AEF0-410B-9708-4FCCFC38090B@gmail.com> Message-ID: Isn't <> rather "do the type inference from the type on the left side of assignment"? Then HashMap p = new HashMap<>(); is wrong because the type of the variable on the left side is not parameterized. And if you proposed to treat raw types as generic with no type parameter, you would have allowed the following syntax: String<> p; Z. -- Zdenek Tronicek FIT CTU in Prague Ben Evans napsal(a): > Try again, actually replying to list this time. > > Sent from my iPhone > > Begin forwarded message: > >> From: Ben Evans >> Date: 16 February 2011 17:05:12 GMT >> To: Joshua Bloch >> Subject: Re: Huston, we have a problem ! >> > >> OK, at the risk of looking stupid - why? >> >> I read <> as a "do some type inference about the generics" - if it's not >> a generic type, then I could see it resolving to nothing at all. >> >> In a related example, what about the case of a raw type on the LHS? >> >> HashMap hm = new HashMap<>(); >> >> If the non-generic example is deemed to be a syntax error, what about >> this case? >> >> Thanks, >> >> Ben >> >> On 16 Feb 2011, at 16:26, Joshua Bloch wrote: >> >>> I agree that it should be illegal. >>> >>> Josh >>> > > From joe.darcy at oracle.com Wed Feb 16 15:06:04 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 16 Feb 2011 15:06:04 -0800 Subject: Upcoming change in semantics to try-with-resources on a null resource Message-ID: <4D5C585C.8020100@oracle.com> Hello. After due consideration the JSR 334 expert group has decided the semantics of the try-with-resources statement on a null resource should be changed as follows: the compiler-generated calls to close a resource will only occur if the resource is non-null. Concretely, the semantics of the desugaring of the finally block are changed from finally { if (#primaryException != null) { try { #resource.close(); } catch(Throwable #suppressedException) { #primaryException.addSuppressed(#suppressedException); } } else { #resource.close(); } } to finally { if (#primaryException != null) { try { if(#resource != null) #resource.close(); } catch(Throwable #suppressedException) { #primaryException.addSuppressed(#suppressedException); } } else { if(#resource != null) #resource.close(); } } This decision was informed by discussions on coin-dev as well as experiments retrofitting try-with-resources onto the JDK libraries. The change allows idioms like try(Resource r = methodThatMightReturnNull()) { if (r == null) return; // nothing to do } to complete normally without generating a null pointer exception. Note that the programmer still has responsibility to check for a null resource if the resource is used inside the try block; the generated null check does *not* occur before the try block is entered. Implementing the change is being tracked under Oracle bug 7020047 "Project Coin: generate null-check around try-with-resources close call." Thanks for the feedback; cheers, -Joe From forax at univ-mlv.fr Wed Feb 16 23:56:22 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 17 Feb 2011 08:56:22 +0100 Subject: Upcoming change in semantics to try-with-resources on a null resource In-Reply-To: <4D5C585C.8020100@oracle.com> References: <4D5C585C.8020100@oracle.com> Message-ID: <4D5CD4A6.4000508@univ-mlv.fr> On 02/17/2011 12:06 AM, Joe Darcy wrote: > Hello. > > After due consideration the JSR 334 expert group has decided the > semantics of the try-with-resources statement on a null resource should > be changed as follows: the compiler-generated calls to close a resource > will only occur if the resource is non-null. > > Concretely, the semantics of the desugaring of the finally block are > changed from > > finally { > if (#primaryException != null) { > try { > #resource.close(); > } catch(Throwable #suppressedException) { > #primaryException.addSuppressed(#suppressedException); > } > } else { > #resource.close(); > } > } > > to > > finally { > if (#primaryException != null) { > try { > if(#resource != null) > #resource.close(); > } catch(Throwable #suppressedException) { > #primaryException.addSuppressed(#suppressedException); > } > } else { > if(#resource != null) > #resource.close(); > } > } > > This decision was informed by discussions on coin-dev as well as > experiments retrofitting try-with-resources onto the JDK libraries. > > The change allows idioms like > > try(Resource r = methodThatMightReturnNull()) { > if (r == null) > return; // nothing to do > } > > to complete normally without generating a null pointer exception. Note > that the programmer still has responsibility to check for a null > resource if the resource is used inside the try block; the generated > null check does *not* occur before the try block is entered. > > Implementing the change is being tracked under Oracle bug 7020047 > "Project Coin: generate null-check around try-with-resources close call." > > Thanks for the feedback; cheers, > > -Joe > Thanks, Joe :) R?mi From joe.darcy at oracle.com Thu Feb 17 13:52:55 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 17 Feb 2011 13:52:55 -0800 Subject: Upcoming change in semantics to try-with-resources on a null resource In-Reply-To: <4D5C585C.8020100@oracle.com> References: <4D5C585C.8020100@oracle.com> Message-ID: <4D5D98B7.5060208@oracle.com> On 2/16/2011 3:06 PM, Joe Darcy wrote: > Hello. > > After due consideration the JSR 334 expert group has decided the > semantics of the try-with-resources statement on a null resource > should be changed as follows: the compiler-generated calls to close a > resource will only occur if the resource is non-null. > > Concretely, the semantics of the desugaring of the finally block are > changed from > > finally { > if (#primaryException != null) { > try { > #resource.close(); > } catch(Throwable #suppressedException) { > #primaryException.addSuppressed(#suppressedException); > } > } else { > #resource.close(); > } > } > > to > > finally { > if (#primaryException != null) { > try { > if(#resource != null) > #resource.close(); > } catch(Throwable #suppressedException) { > #primaryException.addSuppressed(#suppressedException); > } > } else { > if(#resource != null) > #resource.close(); > } > } > FYI, inspired by a comment left on my blog [1], javac will hoist the null check of the resource, resulting in the semantically equivalent but shorter code finally { if (#resource != null) if (#primaryException != null) { try { // if(#resource != null) #resource.close(); } catch(Throwable #suppressedException) { #primaryException.addSuppressed(#suppressedException); } } else { // if(#resource != null) #resource.close(); } } } -Joe [1] http://blogs.sun.com/darcy/entry/project_coin_null_try_with#comment-1297968215000 From forax at univ-mlv.fr Thu Feb 17 14:10:36 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 17 Feb 2011 23:10:36 +0100 Subject: Upcoming change in semantics to try-with-resources on a null resource In-Reply-To: <4D5D98B7.5060208@oracle.com> References: <4D5C585C.8020100@oracle.com> <4D5D98B7.5060208@oracle.com> Message-ID: <4D5D9CDC.3020602@univ-mlv.fr> On 02/17/2011 10:52 PM, Joe Darcy wrote: > On 2/16/2011 3:06 PM, Joe Darcy wrote: >> Hello. >> >> After due consideration the JSR 334 expert group has decided the >> semantics of the try-with-resources statement on a null resource >> should be changed as follows: the compiler-generated calls to close a >> resource will only occur if the resource is non-null. >> >> Concretely, the semantics of the desugaring of the finally block are >> changed from >> >> finally { >> if (#primaryException != null) { >> try { >> #resource.close(); >> } catch(Throwable #suppressedException) { >> #primaryException.addSuppressed(#suppressedException); >> } >> } else { >> #resource.close(); >> } >> } >> >> to >> >> finally { >> if (#primaryException != null) { >> try { >> if(#resource != null) >> #resource.close(); >> } catch(Throwable #suppressedException) { >> #primaryException.addSuppressed(#suppressedException); >> } >> } else { >> if(#resource != null) >> #resource.close(); >> } >> } >> > FYI, inspired by a comment left on my blog [1], javac will hoist the > null check of the resource, resulting in the semantically equivalent but > shorter code > > finally { > if (#resource != null) > if (#primaryException != null) { > try { > // if(#resource != null) > #resource.close(); > } catch(Throwable #suppressedException) { > #primaryException.addSuppressed(#suppressedException); > } > } else { > // if(#resource != null) > #resource.close(); > } > } > } > > -Joe > > [1] > http://blogs.sun.com/darcy/entry/project_coin_null_try_with#comment-1297968215000 There is another cheap optimization. Only generate the nullcheck if the resource is not initialized with a new XXX. try(XXX resource = new XXX()) { ... } Allocating the resource in the try expression is really a common code. R?mi From joe.darcy at oracle.com Thu Feb 17 16:50:21 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 17 Feb 2011 16:50:21 -0800 Subject: Upcoming change in semantics to try-with-resources on a null resource In-Reply-To: <4D5D9CDC.3020602@univ-mlv.fr> References: <4D5C585C.8020100@oracle.com> <4D5D98B7.5060208@oracle.com> <4D5D9CDC.3020602@univ-mlv.fr> Message-ID: <4D5DC24D.8020808@oracle.com> R?mi Forax wrote: > On 02/17/2011 10:52 PM, Joe Darcy wrote: > >> On 2/16/2011 3:06 PM, Joe Darcy wrote: >> >>> Hello. >>> >>> After due consideration the JSR 334 expert group has decided the >>> semantics of the try-with-resources statement on a null resource >>> should be changed as follows: the compiler-generated calls to close a >>> resource will only occur if the resource is non-null. >>> >>> Concretely, the semantics of the desugaring of the finally block are >>> changed from >>> >>> finally { >>> if (#primaryException != null) { >>> try { >>> #resource.close(); >>> } catch(Throwable #suppressedException) { >>> #primaryException.addSuppressed(#suppressedException); >>> } >>> } else { >>> #resource.close(); >>> } >>> } >>> >>> to >>> >>> finally { >>> if (#primaryException != null) { >>> try { >>> if(#resource != null) >>> #resource.close(); >>> } catch(Throwable #suppressedException) { >>> #primaryException.addSuppressed(#suppressedException); >>> } >>> } else { >>> if(#resource != null) >>> #resource.close(); >>> } >>> } >>> >>> >> FYI, inspired by a comment left on my blog [1], javac will hoist the >> null check of the resource, resulting in the semantically equivalent but >> shorter code >> >> finally { >> if (#resource != null) >> if (#primaryException != null) { >> try { >> // if(#resource != null) >> #resource.close(); >> } catch(Throwable #suppressedException) { >> #primaryException.addSuppressed(#suppressedException); >> } >> } else { >> // if(#resource != null) >> #resource.close(); >> } >> } >> } >> >> -Joe >> >> [1] >> http://blogs.sun.com/darcy/entry/project_coin_null_try_with#comment-1297968215000 >> > > There is another cheap optimization. > Only generate the nullcheck if the resource is not initialized with a > new XXX. > try(XXX resource = new XXX()) { > ... > } > > Allocating the resource in the try expression is really a common code. > > R?mi > > Hi R?mi. Thanks for the suggestion; I've recored it in 7020499 "Project Coin: improvements to try-with-resources desugaring." I don't plan to use that optimization in the initial push of the new semantics, but we'll certainly consider it for future refinements. Thanks, -Joe From fweimer at bfk.de Fri Feb 18 06:45:38 2011 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 18 Feb 2011 14:45:38 +0000 Subject: Huston, we have a problem ! In-Reply-To: <4D5BA123.8050801@univ-mlv.fr> (=?iso-8859-1?Q?=22R=E9mi?= Forax"'s message of "Wed\, 16 Feb 2011 11\:04\:19 +0100") References: <4D5BA123.8050801@univ-mlv.fr> Message-ID: <827hcxpfjh.fsf@mid.bfk.de> * R?mi Forax: > public class DiamondRaw { > public static void main(String[] args) { > String s = new String<>("foo"); > } > } After seeing this example, I've been wondering why the diamond is needed at all. Wouldn't it be sufficient to suppress the raw type warning in all places where you could add a diamond, without introducing a compilation error? What crucial piece of information does the presence of a diamond provide? -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From maurizio.cimadamore at oracle.com Fri Feb 18 07:07:49 2011 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 18 Feb 2011 15:07:49 +0000 Subject: Huston, we have a problem ! In-Reply-To: <827hcxpfjh.fsf@mid.bfk.de> References: <4D5BA123.8050801@univ-mlv.fr> <827hcxpfjh.fsf@mid.bfk.de> Message-ID: <4D5E8B45.4030709@oracle.com> On 18/02/11 14:45, Florian Weimer wrote: > * R?mi Forax: > >> public class DiamondRaw { >> public static void main(String[] args) { >> String s = new String<>("foo"); >> } >> } > After seeing this example, I've been wondering why the diamond is > needed at all. Wouldn't it be sufficient to suppress the raw type > warning in all places where you could add a diamond, without > introducing a compilation error? What crucial piece of information > does the presence of a diamond provide? > Here's an example where the two constructs (raw type and diamond) behave differently: interface I {} class Foo { Foo(X x) {}; Foo get(X x) { return this; }; } class Test { void test(I i) { Foo f1 = new Foo(1).get(""); //ok - can pass String where Object is expected Foo f2 = new Foo<>(1).get(""); //fail - cannot pass String where Integer is expected } } In short, a raw type doesn't have any info about type-parameter instantiation - anything that will work with the erasure of the generic class Foo, will also work with the raw type Foo. On the contrary, Foo<> is a full parameterized type - as such, javac is able to apply strict type-checking as it if were an ordinary parameterized type. In terms of language evolution, it is also important not to replace and existing concept (raw type) with a new one (generic type with unspecified type-parameters, as in diamond). The problem becomes more evident as soon as you start exploring new language features that imply exact runtime information about generic types (i.e. reification). If we were to add reified generics to Java, it is very likely that we will have to support runtime raw types (!!) for backwards compatibility - so the syntactic distinction between diamond and raw turns out to be quite sweet. Maurizio From tronicek at fit.cvut.cz Fri Feb 18 07:46:22 2011 From: tronicek at fit.cvut.cz (=?utf-8?B?IlpkZW7Em2sgVHJvbsOtxI1layI=?=) Date: Fri, 18 Feb 2011 16:46:22 +0100 Subject: Huston, we have a problem ! In-Reply-To: <4D5E8B45.4030709@oracle.com> References: <4D5BA123.8050801@univ-mlv.fr> <827hcxpfjh.fsf@mid.bfk.de> <4D5E8B45.4030709@oracle.com> Message-ID: <2d8acf5cefe887564e6dd7232e73c954.squirrel@imap.fit.cvut.cz> Maurizio, this is not good example because the first call is not correct here. So, if it does not compile it should not be wrong even if it compiled under previous version. And hopefully you do not want to drive the language design by a requirement to be source compatible with sources which are apparently wrong. Z. -- Zdenek Tronicek FIT CTU in Prague Maurizio Cimadamore napsal(a): > Here's an example where the two constructs (raw type and diamond) behave > differently: > > interface I {} > class Foo { > Foo(X x) {}; > Foo get(X x) { return this; }; > } > > class Test { > void test(I i) { > Foo f1 = new Foo(1).get(""); //ok - can pass String where > Object is expected > Foo f2 = new Foo<>(1).get(""); //fail - cannot pass String > where Integer is expected > } > } > > In short, a raw type doesn't have any info about type-parameter > instantiation - anything that will work with the erasure of the generic > class Foo, will also work with the raw type Foo. On the contrary, Foo<> > is a full parameterized type - as such, javac is able to apply strict > type-checking as it if were an ordinary parameterized type. > > In terms of language evolution, it is also important not to replace and > existing concept (raw type) with a new one (generic type with > unspecified type-parameters, as in diamond). The problem becomes more > evident as soon as you start exploring new language features that imply > exact runtime information about generic types (i.e. reification). If we > were to add reified generics to Java, it is very likely that we will > have to support runtime raw types (!!) for backwards compatibility - so > the syntactic distinction between diamond and raw turns out to be quite > sweet. > > Maurizio > > From fweimer at bfk.de Fri Feb 18 08:34:45 2011 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 18 Feb 2011 16:34:45 +0000 Subject: Huston, we have a problem ! In-Reply-To: <4D5E8B45.4030709@oracle.com> (Maurizio Cimadamore's message of "Fri\, 18 Feb 2011 15\:07\:49 +0000") References: <4D5BA123.8050801@univ-mlv.fr> <827hcxpfjh.fsf@mid.bfk.de> <4D5E8B45.4030709@oracle.com> Message-ID: <82oc69nvx6.fsf@mid.bfk.de> * Maurizio Cimadamore: >> After seeing this example, I've been wondering why the diamond is >> needed at all. Wouldn't it be sufficient to suppress the raw type >> warning in all places where you could add a diamond, without >> introducing a compilation error? What crucial piece of information >> does the presence of a diamond provide? >> > > Here's an example where the two constructs (raw type and diamond) > behave differently: > > interface I {} > class Foo { > Foo(X x) {}; > Foo get(X x) { return this; }; > } > > class Test { > void test(I i) { > Foo f1 = new Foo(1).get(""); //ok - can pass String where > Object is expected > Foo f2 = new Foo<>(1).get(""); //fail - cannot pass String > where Integer is expected > } > } Interesting example. This is a case where automatically adding <> fails and the raw type warning has to be supplied. (There are much simpler ones, of course.) > In terms of language evolution, it is also important not to replace > and existing concept (raw type) with a new one (generic type with > unspecified type-parameters, as in diamond). But are these concepts actually different? If they are, there has to be case where adding <> to a raw type results in different results at run-time. > The problem becomes more evident as soon as you start exploring new > language features that imply exact runtime information about generic > types (i.e. reification). It is impossible to implement reification in a backwards-compatible fashion. And I think it is fair to say that the planned backwards compatibility of the generics feature in Java 5 did not materialize in practice. 8-( -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From maurizio.cimadamore at oracle.com Fri Feb 18 08:55:43 2011 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 18 Feb 2011 16:55:43 +0000 Subject: Huston, we have a problem ! In-Reply-To: <2d8acf5cefe887564e6dd7232e73c954.squirrel@imap.fit.cvut.cz> References: <4D5BA123.8050801@univ-mlv.fr> <827hcxpfjh.fsf@mid.bfk.de> <4D5E8B45.4030709@oracle.com> <2d8acf5cefe887564e6dd7232e73c954.squirrel@imap.fit.cvut.cz> Message-ID: <4D5EA48F.8020806@oracle.com> On 18/02/11 15:46, "Zden?k Tron??ek" wrote: > Maurizio, this is not good example because the first call is not correct > here. So, if it does not compile it should not be wrong even if it > compiled under previous version. What is wrong about the following code? Foo f1 = new Foo(1).get(""); Maurizio > And hopefully you do not want to drive the language design by a > requirement to be source compatible with sources which are apparently > wrong. > > Z. From maurizio.cimadamore at oracle.com Fri Feb 18 09:03:06 2011 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 18 Feb 2011 17:03:06 +0000 Subject: Huston, we have a problem ! In-Reply-To: <82oc69nvx6.fsf@mid.bfk.de> References: <4D5BA123.8050801@univ-mlv.fr> <827hcxpfjh.fsf@mid.bfk.de> <4D5E8B45.4030709@oracle.com> <82oc69nvx6.fsf@mid.bfk.de> Message-ID: <4D5EA64A.2010407@oracle.com> > But are these concepts actually different? If they are, there has to > be case where adding<> to a raw type results in different results at > run-time. Well, because of type-erasure you won't be able to tell the difference between List and List either - so are they the same thing? >> The problem becomes more evident as soon as you start exploring new >> language features that imply exact runtime information about generic >> types (i.e. reification). > It is impossible to implement reification in a backwards-compatible > fashion. I guess it depends on what we mean by reification - there are several proposals, each one with different implications on backwards compatibility. Maurizio From fweimer at bfk.de Fri Feb 18 09:10:20 2011 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 18 Feb 2011 17:10:20 +0000 Subject: Huston, we have a problem ! In-Reply-To: <4D5EA64A.2010407@oracle.com> (Maurizio Cimadamore's message of "Fri\, 18 Feb 2011 17\:03\:06 +0000") References: <4D5BA123.8050801@univ-mlv.fr> <827hcxpfjh.fsf@mid.bfk.de> <4D5E8B45.4030709@oracle.com> <82oc69nvx6.fsf@mid.bfk.de> <4D5EA64A.2010407@oracle.com> Message-ID: <82wrkxl14z.fsf@mid.bfk.de> * Maurizio Cimadamore: >> But are these concepts actually different? If they are, there has to >> be case where adding<> to a raw type results in different results at >> run-time. > Well, because of type-erasure you won't be able to tell the difference > between List and List either - so are they the same > thing? Clearly, those a different at compile time. What I'm looking for is a case where both Foo and Foo<> result in legal expressions at compile time and produce different byte code. If there is not an example, then <> does not provide any information to the compiler. Does it tell something to the reader? I really doubt that. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From maurizio.cimadamore at oracle.com Fri Feb 18 09:14:28 2011 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 18 Feb 2011 17:14:28 +0000 Subject: Huston, we have a problem ! In-Reply-To: <82wrkxl14z.fsf@mid.bfk.de> References: <4D5BA123.8050801@univ-mlv.fr> <827hcxpfjh.fsf@mid.bfk.de> <4D5E8B45.4030709@oracle.com> <82oc69nvx6.fsf@mid.bfk.de> <4D5EA64A.2010407@oracle.com> <82wrkxl14z.fsf@mid.bfk.de> Message-ID: <4D5EA8F4.8020209@oracle.com> On 18/02/11 17:10, Florian Weimer wrote: > * Maurizio Cimadamore: > >>> But are these concepts actually different? If they are, there has to >>> be case where adding<> to a raw type results in different results at >>> run-time. >> Well, because of type-erasure you won't be able to tell the difference >> between List and List either - so are they the same >> thing? > Clearly, those a different at compile time. What I'm looking for is a > case where both Foo and Foo<> result in legal expressions at compile > time and produce different byte code. > As I've shown with my example, Foo and Foo<> are different at compile-time. Just as List and List are (well, in a more subtle way). They have different members, different supertypes etc. They are just different types. Maurizio From neal at gafter.com Fri Feb 18 10:03:24 2011 From: neal at gafter.com (Neal Gafter) Date: Fri, 18 Feb 2011 10:03:24 -0800 Subject: Huston, we have a problem ! In-Reply-To: <82wrkxl14z.fsf@mid.bfk.de> References: <4D5BA123.8050801@univ-mlv.fr> <827hcxpfjh.fsf@mid.bfk.de> <4D5E8B45.4030709@oracle.com> <82oc69nvx6.fsf@mid.bfk.de> <4D5EA64A.2010407@oracle.com> <82wrkxl14z.fsf@mid.bfk.de> Message-ID: On Fri, Feb 18, 2011 at 9:10 AM, Florian Weimer wrote: > Clearly, those a different at compile time. What I'm looking for is a > case where both Foo and Foo<> result in legal expressions at compile > time and produce different byte code. > *public class X { public X(T t) {} public T get() { return null; } public static int f(String s) { return 1; } public static int f(Object o) { return 2; } public static void main(String[] args) { System.out.println(f(new X<>("").get())); System.out.println(f(new X("").get())); } }* From forax at univ-mlv.fr Fri Feb 18 10:03:54 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 18 Feb 2011 19:03:54 +0100 Subject: Huston, we have a problem ! In-Reply-To: <82oc69nvx6.fsf@mid.bfk.de> References: <4D5BA123.8050801@univ-mlv.fr> <827hcxpfjh.fsf@mid.bfk.de> <4D5E8B45.4030709@oracle.com> <82oc69nvx6.fsf@mid.bfk.de> Message-ID: <4D5EB48A.5040007@univ-mlv.fr> On 02/18/2011 05:34 PM, Florian Weimer wrote: > It is impossible to implement reification in a backwards-compatible > fashion. never say never :) > And I think it is fair to say that the planned backwards > compatibility of the generics feature in Java 5 did not materialize in > practice. 8-( > R?mi From tronicek at fit.cvut.cz Fri Feb 18 10:08:38 2011 From: tronicek at fit.cvut.cz (=?utf-8?B?IlpkZW7Em2sgVHJvbsOtxI1layI=?=) Date: Fri, 18 Feb 2011 19:08:38 +0100 Subject: Huston, we have a problem ! In-Reply-To: <4D5EA8F4.8020209@oracle.com> References: <4D5BA123.8050801@univ-mlv.fr> <827hcxpfjh.fsf@mid.bfk.de> <4D5E8B45.4030709@oracle.com> <82oc69nvx6.fsf@mid.bfk.de> <4D5EA64A.2010407@oracle.com> <82wrkxl14z.fsf@mid.bfk.de> <4D5EA8F4.8020209@oracle.com> Message-ID: <79bfe0469106261c9301196e634a3826.squirrel@imap.fit.cvut.cz> As far as I understood the original question, it was as follows: Why we need to write List p = new ArrayList<>(); and not only List p = new ArrayList(); ? Is there any special reason for <>? Z. -- Zdenek Tronicek FIT CTU in Prague Maurizio Cimadamore napsal(a): > On 18/02/11 17:10, Florian Weimer wrote: >> * Maurizio Cimadamore: >> >>>> But are these concepts actually different? If they are, there has to >>>> be case where adding<> to a raw type results in different results at >>>> run-time. >>> Well, because of type-erasure you won't be able to tell the difference >>> between List and List either - so are they the same >>> thing? >> Clearly, those a different at compile time. What I'm looking for is a >> case where both Foo and Foo<> result in legal expressions at compile >> time and produce different byte code. >> > As I've shown with my example, Foo and Foo<> are different at > compile-time. Just as List and List are (well, in a > more subtle way). They have different members, different supertypes etc. > They are just different types. > > Maurizio > > From forax at univ-mlv.fr Fri Feb 18 10:19:35 2011 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Fri, 18 Feb 2011 19:19:35 +0100 Subject: Huston, we have a problem ! In-Reply-To: <79bfe0469106261c9301196e634a3826.squirrel@imap.fit.cvut.cz> References: <4D5BA123.8050801@univ-mlv.fr> <827hcxpfjh.fsf@mid.bfk.de> <4D5E8B45.4030709@oracle.com> <82oc69nvx6.fsf@mid.bfk.de> <4D5EA64A.2010407@oracle.com> <82wrkxl14z.fsf@mid.bfk.de> <4D5EA8F4.8020209@oracle.com> <79bfe0469106261c9301196e634a3826.squirrel@imap.fit.cvut.cz> Message-ID: <4D5EB837.3070601@univ-mlv.fr> On 02/18/2011 07:08 PM, "Zden?k Tron??ek" wrote: > As far as I understood the original question, it was as follows: Why we > need to write > > List p = new ArrayList<>(); > > and not only > > List p = new ArrayList(); ? > > Is there any special reason for<>? > > Z. List p = new ArrayList(new ArrayList()); // ok List p = new ArrayList<>(new ArrayList()); // not ok R. From neal at gafter.com Fri Feb 18 10:30:03 2011 From: neal at gafter.com (Neal Gafter) Date: Fri, 18 Feb 2011 10:30:03 -0800 Subject: Huston, we have a problem ! In-Reply-To: <82oc69nvx6.fsf@mid.bfk.de> References: <4D5BA123.8050801@univ-mlv.fr> <827hcxpfjh.fsf@mid.bfk.de> <4D5E8B45.4030709@oracle.com> <82oc69nvx6.fsf@mid.bfk.de> Message-ID: On Fri, Feb 18, 2011 at 8:34 AM, Florian Weimer wrote: > It is impossible to implement reification in a backwards-compatible > fashion. See for one approach that is clearly backwards-compatible. > And I think it is fair to say that the planned backwards > compatibility of the generics feature in Java 5 did not materialize in > practice. 8-( > Compatibility is most successful when you don't even notice it. Few existing programs failed to compile in Java 5, yet the widely-used collections APIs are now generic. From tronicek at fit.cvut.cz Fri Feb 18 10:41:22 2011 From: tronicek at fit.cvut.cz (=?utf-8?B?IlpkZW7Em2sgVHJvbsOtxI1layI=?=) Date: Fri, 18 Feb 2011 19:41:22 +0100 Subject: Huston, we have a problem ! In-Reply-To: <4D5EB837.3070601@univ-mlv.fr> References: <4D5BA123.8050801@univ-mlv.fr> <827hcxpfjh.fsf@mid.bfk.de> <4D5E8B45.4030709@oracle.com> <82oc69nvx6.fsf@mid.bfk.de> <4D5EA64A.2010407@oracle.com> <82wrkxl14z.fsf@mid.bfk.de> <4D5EA8F4.8020209@oracle.com> <79bfe0469106261c9301196e634a3826.squirrel@imap.fit.cvut.cz> <4D5EB837.3070601@univ-mlv.fr> Message-ID: <92383052a43230cb92a05343ec24d453.squirrel@imap.fit.cvut.cz> R?mi Forax napsal(a): > On 02/18/2011 07:08 PM, "Zden?k Tron??ek" wrote: >> As far as I understood the original question, it was as follows: Why we >> need to write >> >> List p = new ArrayList<>(); >> >> and not only >> >> List p = new ArrayList(); ? >> >> Is there any special reason for<>? >> >> Z. > > List p = new ArrayList(new ArrayList()); // ok > > List p = new ArrayList<>(new ArrayList()); // not ok > The problem is that the first line is apparently wrong. Do you feel as an obligation to be backward compatible with code that is wrong? Z. -- Zdenek Tronicek FIT CTU in Prague From joe.darcy at oracle.com Fri Feb 18 10:57:05 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 18 Feb 2011 10:57:05 -0800 Subject: Huston, we have a problem ! In-Reply-To: <92383052a43230cb92a05343ec24d453.squirrel@imap.fit.cvut.cz> References: <4D5BA123.8050801@univ-mlv.fr> <827hcxpfjh.fsf@mid.bfk.de> <4D5E8B45.4030709@oracle.com> <82oc69nvx6.fsf@mid.bfk.de> <4D5EA64A.2010407@oracle.com> <82wrkxl14z.fsf@mid.bfk.de> <4D5EA8F4.8020209@oracle.com> <79bfe0469106261c9301196e634a3826.squirrel@imap.fit.cvut.cz> <4D5EB837.3070601@univ-mlv.fr> <92383052a43230cb92a05343ec24d453.squirrel@imap.fit.cvut.cz> Message-ID: <4D5EC101.2080106@oracle.com> Zden?k Tron??ek wrote: > R?mi Forax napsal(a): > >> On 02/18/2011 07:08 PM, "Zden?k Tron??ek" wrote: >> >>> As far as I understood the original question, it was as follows: Why we >>> need to write >>> >>> List p = new ArrayList<>(); >>> >>> and not only >>> >>> List p = new ArrayList(); ? >>> >>> Is there any special reason for<>? >>> >>> Z. >>> >> List p = new ArrayList(new ArrayList()); // ok >> >> List p = new ArrayList<>(new ArrayList()); // not ok >> >> > > The problem is that the first line is apparently wrong. Do you feel as an > obligation to be backward compatible with code that is wrong? > > > This discussion is off-topic. The differences between diamond and raw types and the advantages of diamond were well-covered on coin-dev when the proposal was first discussed. Please check the archives. -Joe From fweimer at bfk.de Mon Feb 21 01:44:36 2011 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 21 Feb 2011 09:44:36 +0000 Subject: Huston, we have a problem ! In-Reply-To: (Neal Gafter's message of "Fri\, 18 Feb 2011 10\:03\:24 -0800") References: <4D5BA123.8050801@univ-mlv.fr> <827hcxpfjh.fsf@mid.bfk.de> <4D5E8B45.4030709@oracle.com> <82oc69nvx6.fsf@mid.bfk.de> <4D5EA64A.2010407@oracle.com> <82wrkxl14z.fsf@mid.bfk.de> Message-ID: <82d3mlg1rv.fsf@mid.bfk.de> * Neal Gafter: > On Fri, Feb 18, 2011 at 9:10 AM, Florian Weimer wrote: > >> Clearly, those a different at compile time. What I'm looking for is a >> case where both Foo and Foo<> result in legal expressions at compile >> time and produce different byte code. >> > > *public class X { > public X(T t) {} > public T get() { return null; } > public static int f(String s) { return 1; } > public static int f(Object o) { return 2; } > public static void main(String[] args) > { > System.out.println(f(new X<>("").get())); > System.out.println(f(new X("").get())); > } > }* Ah, thanks. Of course, this settles it. 8-) -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From Ulf.Zibis at gmx.de Tue Feb 22 09:22:07 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 22 Feb 2011 18:22:07 +0100 Subject: Huston, we have a problem ! In-Reply-To: References: <4D5BA123.8050801@univ-mlv.fr> <827hcxpfjh.fsf@mid.bfk.de> <4D5E8B45.4030709@oracle.com> <82oc69nvx6.fsf@mid.bfk.de> <4D5EA64A.2010407@oracle.com> <82wrkxl14z.fsf@mid.bfk.de> Message-ID: <4D63F0BF.608@gmx.de> Am 18.02.2011 19:03, schrieb Neal Gafter: > On Fri, Feb 18, 2011 at 9:10 AM, Florian Weimer wrote: >> Clearly, those a different at compile time. What I'm looking for is a >> case where both Foo and Foo<> result in legal expressions at compile >> time and produce different byte code. > *public class X { > public X(T t) {} > public T get() { return null; } > public static int f(String s) { return 1; } > public static int f(Object o) { return 2; } > public static void main(String[] args) > { > System.out.println(f(new X<>("").get())); > System.out.println(f(new X("").get())); > } > }* 1.) Yes, the diamond operator is helpful to explicitly target overlaid methods. But the term 'new X<>("")' exactly creates the same object than 'new X("")' and <> is more used as a way to describe a cast outside that term than the way of instantiating an object. We could deliberately code f((String)(new X("").get())) to result in 1, which would be much more descriptive, even for long experienced programmers, and avoid misinterpretation, confusion and too-much-too-learn-before-first-success at least for beginners. 2.) It doesn't even help if there are 3 overloadings: public static int f(Object o) { return 1; } public static int f(Number n) { return 2; } public static int f(Integer i) { return 3; } I personally would prefer, that 'f(new X(1).get())' would invoke f(Integer i) by default. If someone wants to rollback to Number or Object, he should use an explicit cast. But this may be impossible for compatibility reasons. 3.a) Does it help here? : X a = new X<>(""); X b = new X(""); System.out.println(f(a.get())); System.out.println(f(b.get())); 3.b) Or here? : X a = new X<>(""); X b = new X(""); System.out.println(f(a.get())); System.out.println(f(b.get())); So I think, the question of Florian is again kinda open. -Ulf From vimilsaju at yahoo.com Tue Feb 22 09:47:31 2011 From: vimilsaju at yahoo.com (Vimil Saju) Date: Tue, 22 Feb 2011 09:47:31 -0800 (PST) Subject: For Coin 8: this keyword for static methods Message-ID: <427142.93272.qm@web161204.mail.bf1.yahoo.com> Hi, It would be nice to have a 'this' keyword for static methods. For static methods 'this' refers to the class in which the static method is defined. In our code-base we have a lot of places where we initialize a logger for a class as follows public class MyApp { ???static Logger logger = Logger.getLogger(MyApp.class); ... ... If we could refer to MyApp using the keyword 'this' then when copying this code to other classes there wouldn't be a need to remember to change the class passed to the getLogger method. Thanks Vimil From mbien at fh-landshut.de Tue Feb 22 10:58:47 2011 From: mbien at fh-landshut.de (Michael Bien) Date: Tue, 22 Feb 2011 19:58:47 +0100 Subject: JDK6 backwards compatible AutoCloseable from a libraries perspective In-Reply-To: <4D500C4D.1020503@univ-mlv.fr> References: <4D4FEF3E.4080600@fh-landshut.de> <4D4FF65E.10605@univ-mlv.fr><4D4FFCE9.7090709@fh-landshut.de> <4D500271.8020005@univ-mlv.fr><4D500A70.2060802@fh-landshut.de> <4D500C4D.1020503@univ-mlv.fr> Message-ID: <4D640767.4070208@fh-landshut.de> On 02/07/2011 04:14 PM, R?mi Forax wrote: > Le 07/02/2011 16:06, Michael Bien a ?crit : >> On 02/07/2011 03:32 PM, R?mi Forax wrote: >>> Le 07/02/2011 15:08, Michael Bien a ?crit : >>>> On 02/07/2011 02:40 PM, R?mi Forax wrote: >>>>> Le 07/02/2011 14:10, Michael Bien a ?crit : >>>>>> Hello everyone, >>>>>> >>>>>> I would like to support the new try-with-resource feature in jocl while >>>>>> staying backwards compatible with JDK5/6. The problem is that >>>>>> AutoCloseable resides in java.lang which means i have no chance to load >>>>>> the class if i would ship it for jdk5 backwards compatibility. >>>>>> >>>>>> Providing two builds for JOCL is not what i would like to do just to be >>>>>> able to be upwards compatible. >>>>>> >>>>>> any ideas what i could do in this situation? >>>>>> >>>>>> best regards, >>>>>> michael >>>>> You need to: >>>>> Create a jocl internal equivalent to java.lang.AutoClosable, let say >>>>> jocl.lang.AutoClosable, >>>>> this class should extends java.lang.AutoClosable. >>>>> modify you managed classes to implements jocl.lang.AutoClosable. >>>>> compile with javac -source 7 -target 7 >>>>> Now you have a 1.7 compatible version. >>>>> >>>>> The trick is to downgrade the classfiles to have a 1.5 compatible version. >>>>> For this use a bytecode rewriter tools like ASM [1] to change a just >>>>> some bits >>>>> in the classfiles. >>>>> modify the classfile of jocl.lang.AutoClosable to don't inherits from >>>>> java.lang.AutoClosable anymore. >>>>> downgrade the classfiles major version number from 51 (V1_7) to 49 (V1_5) >>>>> >>>>> In fact, there is a way to avoid to create jocl.lang.AutoClosable, you can >>>>> analyze the bytecode to detect call to AutoClosable.close() and replace it >>>>> by the type of the variable infered using the same algorithm as the >>>>> verifier does. >>>>> ASM package org.objectweb.asm.analysis already provides this analysis. >>>>> >>>>> R?mi >>>>> >>>>> [1] http://asm.ow2.org/ >>>>> >>>>> >>>> Thank you Remi, >>>> >>>> do i really have to compile with 1.7 language level even if i don't use >>>> ARM internally? >>> yes, you have to. >>> source of the compiler near line 165: >>> http://hg.openjdk.java.net/jdk7/jdk7/langtools/file/1383d1ee8b5d/src/share/classes/com/sun/tools/javac/code/Source.java >>> >>> public boolean allowTryWithResources() { >>> return compareTo(JDK1_7)>= 0; >>> } >>> >>>> -michael >>> R?mi >>> >> hmm. In this case it would be much easier (and less risky regarding QA) >> do just use simple string replacement and build the library twice. >> (since we can't create one jar which is compatible in both scenarios) >> >> Once with >> com.jogamp.common.AutoCloseable extends java.lang.AutoCloseable (with >> JDK7 lang level7) >> and once with >> com.jogamp.common.AutoCloseable /*extends java.lang.AutoCloseable*/ >> (with JDK6 lang level5) >> >> should have the same effect, right? >> >> michael >> > Almost, you also have to downgrade the classfile version. > > R?mi > Hello, In case someone is interested thats how i ended up implementing it: A little bit sourcecode preprocessing and we can build now eather against our AutoCloseable dummy or against a AutoCloseable extending JDK7's AutoCloseable. This lets us produce one set of binaries which are compatible with 1.5 and an other set of jars which support the try-with-resource feature but require 1.7. Thats not perfect but its at least simple to maintain. bytecode processing and/or using custom compilers where both no-gos for us at least not for this kind of nice-to-have features. thank you all for the help, michael -- http://michael-bien.com/ From joe.darcy at oracle.com Tue Feb 22 11:12:38 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 22 Feb 2011 11:12:38 -0800 Subject: JDK6 backwards compatible AutoCloseable from a libraries perspective In-Reply-To: <4D640767.4070208@fh-landshut.de> References: <4D4FEF3E.4080600@fh-landshut.de> <4D4FF65E.10605@univ-mlv.fr><4D4FFCE9.7090709@fh-landshut.de> <4D500271.8020005@univ-mlv.fr><4D500A70.2060802@fh-landshut.de> <4D500C4D.1020503@univ-mlv.fr> <4D640767.4070208@fh-landshut.de> Message-ID: <4D640AA6.7010407@oracle.com> Michael Bien wrote: > On 02/07/2011 04:14 PM, R?mi Forax wrote: > >> Le 07/02/2011 16:06, Michael Bien a ?crit : >> >>> On 02/07/2011 03:32 PM, R?mi Forax wrote: >>> >>>> Le 07/02/2011 15:08, Michael Bien a ?crit : >>>> >>>>> On 02/07/2011 02:40 PM, R?mi Forax wrote: >>>>> >>>>>> Le 07/02/2011 14:10, Michael Bien a ?crit : >>>>>> >>>>>>> Hello everyone, >>>>>>> >>>>>>> I would like to support the new try-with-resource feature in jocl while >>>>>>> staying backwards compatible with JDK5/6. The problem is that >>>>>>> AutoCloseable resides in java.lang which means i have no chance to load >>>>>>> the class if i would ship it for jdk5 backwards compatibility. >>>>>>> >>>>>>> Providing two builds for JOCL is not what i would like to do just to be >>>>>>> able to be upwards compatible. >>>>>>> >>>>>>> any ideas what i could do in this situation? >>>>>>> >>>>>>> best regards, >>>>>>> michael >>>>>>> >>>>>> You need to: >>>>>> Create a jocl internal equivalent to java.lang.AutoClosable, let say >>>>>> jocl.lang.AutoClosable, >>>>>> this class should extends java.lang.AutoClosable. >>>>>> modify you managed classes to implements jocl.lang.AutoClosable. >>>>>> compile with javac -source 7 -target 7 >>>>>> Now you have a 1.7 compatible version. >>>>>> >>>>>> The trick is to downgrade the classfiles to have a 1.5 compatible version. >>>>>> For this use a bytecode rewriter tools like ASM [1] to change a just >>>>>> some bits >>>>>> in the classfiles. >>>>>> modify the classfile of jocl.lang.AutoClosable to don't inherits from >>>>>> java.lang.AutoClosable anymore. >>>>>> downgrade the classfiles major version number from 51 (V1_7) to 49 (V1_5) >>>>>> >>>>>> In fact, there is a way to avoid to create jocl.lang.AutoClosable, you can >>>>>> analyze the bytecode to detect call to AutoClosable.close() and replace it >>>>>> by the type of the variable infered using the same algorithm as the >>>>>> verifier does. >>>>>> ASM package org.objectweb.asm.analysis already provides this analysis. >>>>>> >>>>>> R?mi >>>>>> >>>>>> [1] http://asm.ow2.org/ >>>>>> >>>>>> >>>>>> >>>>> Thank you Remi, >>>>> >>>>> do i really have to compile with 1.7 language level even if i don't use >>>>> ARM internally? >>>>> >>>> yes, you have to. >>>> source of the compiler near line 165: >>>> http://hg.openjdk.java.net/jdk7/jdk7/langtools/file/1383d1ee8b5d/src/share/classes/com/sun/tools/javac/code/Source.java >>>> >>>> public boolean allowTryWithResources() { >>>> return compareTo(JDK1_7)>= 0; >>>> } >>>> >>>> >>>>> -michael >>>>> >>>> R?mi >>>> >>>> >>> hmm. In this case it would be much easier (and less risky regarding QA) >>> do just use simple string replacement and build the library twice. >>> (since we can't create one jar which is compatible in both scenarios) >>> >>> Once with >>> com.jogamp.common.AutoCloseable extends java.lang.AutoCloseable (with >>> JDK7 lang level7) >>> and once with >>> com.jogamp.common.AutoCloseable /*extends java.lang.AutoCloseable*/ >>> (with JDK6 lang level5) >>> >>> should have the same effect, right? >>> >>> michael >>> >>> >> Almost, you also have to downgrade the classfile version. >> >> R?mi >> >> > Hello, > > In case someone is interested thats how i ended up implementing it: > A little bit sourcecode preprocessing and we can build now eather > against our AutoCloseable dummy or against a AutoCloseable extending > JDK7's AutoCloseable. > This lets us produce one set of binaries which are compatible with 1.5 > and an other set of jars which support the try-with-resource feature but > require 1.7. > Thats not perfect but its at least simple to maintain. > > bytecode processing and/or using custom compilers where both no-gos for > us at least not for this kind of nice-to-have features. > > thank you all for the help, > michael > Hello. If you're willing to use annotation processing during your build, you could also declare your class to implement a *missing* superclass. That missing superclass could then be generated via annotation processing, by apt if you're stuck on JDK 5 or by javac if you can use JDK 6 or later. The annotation processor can generate a target-appropriate superclass, having it implement java.lang.AutoCloseable on JDK 7 and some other interface otherwise. -Joe From mcnepp02 at googlemail.com Wed Feb 23 09:31:53 2011 From: mcnepp02 at googlemail.com (Gernot Neppert) Date: Wed, 23 Feb 2011 18:31:53 +0100 Subject: Please: try-with-resouces Lock support! In-Reply-To: <4D640AA6.7010407@oracle.com> References: <4D4FEF3E.4080600@fh-landshut.de> <4D4FF65E.10605@univ-mlv.fr><4D4FFCE9.7090709@fh-landshut.de> <4D500271.8020005@univ-mlv.fr><4D500A70.2060802@fh-landshut.de> <4D500C4D.1020503@univ-mlv.fr> <4D640767.4070208@fh-landshut.de> <4D640AA6.7010407@oracle.com> Message-ID: <4D654489.3030300@googlemail.com> Hi all, this has been discussed here before, but somehow got lost: Wouldn't it be very handy having a class "java.util.concurrent.AutoLockable" that could be used as follows: try(AutoLockable locked = AutoLockable.locked(lock)) { // Do something in locked scope } It would look something like this: package java.util.concurrent.locks; public abstract class AutoLockable implements AutoCloseable { public static AutoLockable locked(final Lock lock) { lock.lock(); return new AutoLockable() { @Override public void close() { lock.unlock(); } }; } public abstract void close(); } From neal at gafter.com Wed Feb 23 12:45:09 2011 From: neal at gafter.com (Neal Gafter) Date: Wed, 23 Feb 2011 12:45:09 -0800 Subject: Please: try-with-resouces Lock support! In-Reply-To: <4D654489.3030300@googlemail.com> References: <4D4FEF3E.4080600@fh-landshut.de> <4D4FF65E.10605@univ-mlv.fr> <4D4FFCE9.7090709@fh-landshut.de> <4D500271.8020005@univ-mlv.fr> <4D500A70.2060802@fh-landshut.de> <4D500C4D.1020503@univ-mlv.fr> <4D640767.4070208@fh-landshut.de> <4D640AA6.7010407@oracle.com> <4D654489.3030300@googlemail.com> Message-ID: If I recall, Doug Lea's comment was that the overhead of creating a new object every time you lock negates much of the performance benefits of the underlying primitives, and the authors of the original proposal rejected this as a valid use case for the new language feature. On Wednesday, February 23, 2011, Gernot Neppert wrote: > ?Hi all, > > this has been discussed here before, but somehow got lost: > Wouldn't it be very handy having a class > "java.util.concurrent.AutoLockable" that could be used as follows: > > try(AutoLockable locked = AutoLockable.locked(lock)) > { > // Do something in locked scope > } > > It would look something like this: > > package java.util.concurrent.locks; > > public abstract class AutoLockable implements AutoCloseable { > > ? ? public static AutoLockable locked(final Lock lock) > ? ? { > ? ? ? ? lock.lock(); > ? ? ? ? return new AutoLockable() { > > ? ? ? ? ? ? @Override > ? ? ? ? ? ? public void close() { > ? ? ? ? ? ? ? ? lock.unlock(); > ? ? ? ? ? ? } > ? ? ? ? }; > ? ? } > > ? ? public abstract void close(); > } > > > From David.Holmes at oracle.com Wed Feb 23 16:42:17 2011 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 24 Feb 2011 10:42:17 +1000 Subject: Please: try-with-resouces Lock support! In-Reply-To: <4D654489.3030300@googlemail.com> References: <4D4FEF3E.4080600@fh-landshut.de> <4D4FF65E.10605@univ-mlv.fr><4D4FFCE9.7090709@fh-landshut.de> <4D500271.8020005@univ-mlv.fr><4D500A70.2060802@fh-landshut.de> <4D500C4D.1020503@univ-mlv.fr> <4D640767.4070208@fh-landshut.de> <4D640AA6.7010407@oracle.com> <4D654489.3030300@googlemail.com> Message-ID: <4D65A969.5000307@oracle.com> I suspect Joe will shut this down as being out of scope for coin-dev in its present state, but my 2c Gernot Neppert said the following on 02/24/11 03:31: > this has been discussed here before, but somehow got lost: > Wouldn't it be very handy having a class > "java.util.concurrent.AutoLockable" that could be used as follows: No not really. The way try-with-resources has evolved really doesn't mesh with lock usage. As Neal already mentioned the overhead of creating the AutoLockable per lock operation is simply prohibitive. Even if you retrofitted Lock with AutoCloseable you would still need (given t-w-r synatx) to have a helper method to acquire the lock and return it so you can assign it to the local: try ( Lock l = Lock.lockAndReturn(lock) ) { ... } This is just a round-hole vs square-peg situation, and trying to make it fit really doesn't add anything to clarity or useability in my view. I can imagine a more general (more specific?) t-w-r that might allow: try (lock) { ... } but that would be for future debate. Cheers, David Holmes > try(AutoLockable locked = AutoLockable.locked(lock)) > { > // Do something in locked scope > } > > It would look something like this: > > package java.util.concurrent.locks; > > public abstract class AutoLockable implements AutoCloseable { > > public static AutoLockable locked(final Lock lock) > { > lock.lock(); > return new AutoLockable() { > > @Override > public void close() { > lock.unlock(); > } > }; > } > > public abstract void close(); > } > > From lnarasimhan at in.ibm.com Thu Feb 24 14:33:41 2011 From: lnarasimhan at in.ibm.com (Lakshmi Narasimhan) Date: Fri, 25 Feb 2011 04:03:41 +0530 Subject: AUTO: I'm off on 25th Feb 2011 (returning 28/02/2011) Message-ID: I am out of the office until 28/02/2011. Please contact Anshu Verma (ansverma at in.ibm.com) for any CL issues. Note: This is an automated response to your message "coin-dev Digest, Vol 25, Issue 12" sent on 25/2/11 1:30:01. This is the only notification you will receive while this person is away. From howard.lovatt at gmail.com Fri Feb 25 16:40:42 2011 From: howard.lovatt at gmail.com (Howard Lovatt) Date: Sat, 26 Feb 2011 11:40:42 +1100 Subject: Please: try-with-resouces Lock support! In-Reply-To: <4D65A969.5000307@oracle.com> References: <4D4FEF3E.4080600@fh-landshut.de> <4D4FF65E.10605@univ-mlv.fr> <4D4FFCE9.7090709@fh-landshut.de> <4D500271.8020005@univ-mlv.fr> <4D500A70.2060802@fh-landshut.de> <4D500C4D.1020503@univ-mlv.fr> <4D640767.4070208@fh-landshut.de> <4D640AA6.7010407@oracle.com> <4D654489.3030300@googlemail.com> <4D65A969.5000307@oracle.com> Message-ID: The use case: try ( new ReentrantLock() ) { ... } makes no sense, you *need* to share the lock. However if Lock were modified to use defender methods: interface Lock extends AutoCloseable { ... // As before Lock autoLock() default Trait.autoLock; // Similarly autoLockInterruptibly void close() default Trait.close; static final class Trait { public Lock autoLock(final Lock self) { self.lock(); return self; } // Similarly autoLockInterruptibly public void close(final Lock self) { self.unlock(); } } } Then try (l.autoLock()) { ... } would work. -- Howard. On 24 February 2011 11:42, David Holmes wrote: > I suspect Joe will shut this down as being out of scope for coin-dev in > its present state, but my 2c > > Gernot Neppert said the following on 02/24/11 03:31: >> this has been discussed here before, but somehow got lost: >> Wouldn't it be very handy having a class >> "java.util.concurrent.AutoLockable" that could be used as follows: > > No not really. The way try-with-resources has evolved really doesn't > mesh with lock usage. As Neal already mentioned the overhead of creating > the AutoLockable per lock operation is simply prohibitive. Even if you > retrofitted Lock with AutoCloseable you would still need (given t-w-r > synatx) to have a helper method to acquire the lock and return it so you > can assign it to the local: > > ?try ( Lock l = Lock.lockAndReturn(lock) ) { > ? ... > ?} > > This is just a round-hole vs square-peg situation, and trying to make it > fit really doesn't add anything to clarity or useability in my view. > > I can imagine a more general (more specific?) t-w-r that might allow: > > try (lock) { > ? ?... > } > > but that would be for future debate. > > Cheers, > David Holmes > >> try(AutoLockable locked = AutoLockable.locked(lock)) >> { >> // Do something in locked scope >> } >> >> It would look something like this: >> >> package java.util.concurrent.locks; >> >> public abstract class AutoLockable implements AutoCloseable { >> >> ? ? ?public static AutoLockable locked(final Lock lock) >> ? ? ?{ >> ? ? ? ? ?lock.lock(); >> ? ? ? ? ?return new AutoLockable() { >> >> ? ? ? ? ? ? ?@Override >> ? ? ? ? ? ? ?public void close() { >> ? ? ? ? ? ? ? ? ?lock.unlock(); >> ? ? ? ? ? ? ?} >> ? ? ? ? ?}; >> ? ? ?} >> >> ? ? ?public abstract void close(); >> } >> >> > > -- ? -- Howard. From David.Holmes at oracle.com Fri Feb 25 18:18:29 2011 From: David.Holmes at oracle.com (David Holmes) Date: Sat, 26 Feb 2011 12:18:29 +1000 Subject: Please: try-with-resouces Lock support! In-Reply-To: References: <4D4FEF3E.4080600@fh-landshut.de> <4D4FF65E.10605@univ-mlv.fr> <4D4FFCE9.7090709@fh-landshut.de> <4D500271.8020005@univ-mlv.fr> <4D500A70.2060802@fh-landshut.de> <4D500C4D.1020503@univ-mlv.fr> <4D640767.4070208@fh-landshut.de> <4D640AA6.7010407@oracle.com> <4D654489.3030300@googlemail.com> <4D65A969.5000307@oracle.com> Message-ID: <4D6862F5.6090606@oracle.com> Howard, The t-w-r needs a resource declaration, so as per my example you'd still need to do: try ( Lock l2 = l.autolock()) { ... } Using defenders to retrofit AutoCloseable to Lock does make it simpler to implement. However there's still additional overhead here and I wouldn't vote for this. David Howard Lovatt said the following on 02/26/11 10:40: > The use case: > > try ( new ReentrantLock() ) { ... } > > makes no sense, you *need* to share the lock. However if Lock were > modified to use defender methods: > > interface Lock extends AutoCloseable { > > ... // As before > > Lock autoLock() default Trait.autoLock; > > // Similarly autoLockInterruptibly > > void close() default Trait.close; > > static final class Trait { > public Lock autoLock(final Lock self) { > self.lock(); > return self; > } > > // Similarly autoLockInterruptibly > > public void close(final Lock self) { > self.unlock(); > } > } > } > > Then > > try (l.autoLock()) { ... } > > would work. > > -- Howard. > > On 24 February 2011 11:42, David Holmes wrote: >> I suspect Joe will shut this down as being out of scope for coin-dev in >> its present state, but my 2c >> >> Gernot Neppert said the following on 02/24/11 03:31: >>> this has been discussed here before, but somehow got lost: >>> Wouldn't it be very handy having a class >>> "java.util.concurrent.AutoLockable" that could be used as follows: >> No not really. The way try-with-resources has evolved really doesn't >> mesh with lock usage. As Neal already mentioned the overhead of creating >> the AutoLockable per lock operation is simply prohibitive. Even if you >> retrofitted Lock with AutoCloseable you would still need (given t-w-r >> synatx) to have a helper method to acquire the lock and return it so you >> can assign it to the local: >> >> try ( Lock l = Lock.lockAndReturn(lock) ) { >> ... >> } >> >> This is just a round-hole vs square-peg situation, and trying to make it >> fit really doesn't add anything to clarity or useability in my view. >> >> I can imagine a more general (more specific?) t-w-r that might allow: >> >> try (lock) { >> ... >> } >> >> but that would be for future debate. >> >> Cheers, >> David Holmes >> >>> try(AutoLockable locked = AutoLockable.locked(lock)) >>> { >>> // Do something in locked scope >>> } >>> >>> It would look something like this: >>> >>> package java.util.concurrent.locks; >>> >>> public abstract class AutoLockable implements AutoCloseable { >>> >>> public static AutoLockable locked(final Lock lock) >>> { >>> lock.lock(); >>> return new AutoLockable() { >>> >>> @Override >>> public void close() { >>> lock.unlock(); >>> } >>> }; >>> } >>> >>> public abstract void close(); >>> } >>> >>> >> > > > From howard.lovatt at gmail.com Fri Feb 25 19:19:29 2011 From: howard.lovatt at gmail.com (Howard Lovatt) Date: Sat, 26 Feb 2011 14:19:29 +1100 Subject: Please: try-with-resouces Lock support! In-Reply-To: <4D6862F5.6090606@oracle.com> References: <4D4FEF3E.4080600@fh-landshut.de> <4D4FF65E.10605@univ-mlv.fr> <4D4FFCE9.7090709@fh-landshut.de> <4D500271.8020005@univ-mlv.fr> <4D500A70.2060802@fh-landshut.de> <4D500C4D.1020503@univ-mlv.fr> <4D640767.4070208@fh-landshut.de> <4D640AA6.7010407@oracle.com> <4D654489.3030300@googlemail.com> <4D65A969.5000307@oracle.com> <4D6862F5.6090606@oracle.com> Message-ID: I haven't checked the specification, but on the latest JDK from the Mercurial repository: try ( l.autoLock() ) { ... } Is fine, -- Howard. On 26 February 2011 13:18, David Holmes wrote: > Howard, > > The t-w-r needs a resource declaration, so as per my example you'd still > need to do: > > try ( Lock l2 = l.autolock()) { ... } > > Using defenders to retrofit AutoCloseable to Lock does make it simpler to > implement. > > However there's still additional overhead here and I wouldn't vote for this. > > David > > Howard Lovatt said the following on 02/26/11 10:40: >> >> The use case: >> >> try ( new ReentrantLock() ) { ... } >> >> makes no sense, you *need* to share the lock. However if Lock were >> modified to use defender methods: >> >> interface Lock extends AutoCloseable { >> >> ?... // As before >> >> ?Lock autoLock() ?default Trait.autoLock; >> >> ?// Similarly autoLockInterruptibly >> >> ?void close() default Trait.close; >> >> ?static final class Trait { >> ? ?public Lock autoLock(final Lock self) { >> ? ? ?self.lock(); >> ? ? ?return self; >> ? ?} >> >> ? ?// Similarly autoLockInterruptibly >> >> ? ?public void close(final Lock self) { >> ? ? ?self.unlock(); >> ? ?} >> ?} >> } >> >> Then >> >> try (l.autoLock()) { ... } >> >> would work. >> >> ?-- Howard. >> >> On 24 February 2011 11:42, David Holmes wrote: >>> >>> I suspect Joe will shut this down as being out of scope for coin-dev in >>> its present state, but my 2c >>> >>> Gernot Neppert said the following on 02/24/11 03:31: >>>> >>>> this has been discussed here before, but somehow got lost: >>>> Wouldn't it be very handy having a class >>>> "java.util.concurrent.AutoLockable" that could be used as follows: >>> >>> No not really. The way try-with-resources has evolved really doesn't >>> mesh with lock usage. As Neal already mentioned the overhead of creating >>> the AutoLockable per lock operation is simply prohibitive. Even if you >>> retrofitted Lock with AutoCloseable you would still need (given t-w-r >>> synatx) to have a helper method to acquire the lock and return it so you >>> can assign it to the local: >>> >>> ?try ( Lock l = Lock.lockAndReturn(lock) ) { >>> ?... >>> ?} >>> >>> This is just a round-hole vs square-peg situation, and trying to make it >>> fit really doesn't add anything to clarity or useability in my view. >>> >>> I can imagine a more general (more specific?) t-w-r that might allow: >>> >>> try (lock) { >>> ? ... >>> } >>> >>> but that would be for future debate. >>> >>> Cheers, >>> David Holmes >>> >>>> try(AutoLockable locked = AutoLockable.locked(lock)) >>>> { >>>> // Do something in locked scope >>>> } >>>> >>>> It would look something like this: >>>> >>>> package java.util.concurrent.locks; >>>> >>>> public abstract class AutoLockable implements AutoCloseable { >>>> >>>> ? ? public static AutoLockable locked(final Lock lock) >>>> ? ? { >>>> ? ? ? ? lock.lock(); >>>> ? ? ? ? return new AutoLockable() { >>>> >>>> ? ? ? ? ? ? @Override >>>> ? ? ? ? ? ? public void close() { >>>> ? ? ? ? ? ? ? ? lock.unlock(); >>>> ? ? ? ? ? ? } >>>> ? ? ? ? }; >>>> ? ? } >>>> >>>> ? ? public abstract void close(); >>>> } >>>> >>>> >>> >> >> >> > -- ? -- Howard. From brucechapman at paradise.net.nz Sat Feb 26 00:30:07 2011 From: brucechapman at paradise.net.nz (Bruce Chapman) Date: Sat, 26 Feb 2011 21:30:07 +1300 Subject: Please: try-with-resouces Lock support! In-Reply-To: References: <4D4FEF3E.4080600@fh-landshut.de> <4D4FF65E.10605@univ-mlv.fr> <4D4FFCE9.7090709@fh-landshut.de> <4D500271.8020005@univ-mlv.fr> <4D500A70.2060802@fh-landshut.de> <4D500C4D.1020503@univ-mlv.fr> <4D640767.4070208@fh-landshut.de> <4D640AA6.7010407@oracle.com> <4D654489.3030300@googlemail.com> <4D65A969.5000307@oracle.com> <4D6862F5.6090606@oracle.com> Message-ID: <4D68BA0F.6080905@paradise.net.nz> On 26/02/2011 4:19 p.m., Howard Lovatt wrote: > I haven't checked the specification, but on the latest JDK from the > Mercurial repository: > > try ( l.autoLock() ) { ... } > > Is fine, > > -- Howard. You re both right. Previous specs allowed an expression or a variable declaration but that is too hard (read impossible) to get to work right with 1 lookahead. Joe's blog has some examples. Therefore the expression form has been removed from the spec by the expert group, the code base is probably lagging a little behind which is why it works (for now). Bruce > On 26 February 2011 13:18, David Holmes wrote: >> Howard, >> >> The t-w-r needs a resource declaration, so as per my example you'd still >> need to do: >> >> try ( Lock l2 = l.autolock()) { ... } >> >> Using defenders to retrofit AutoCloseable to Lock does make it simpler to >> implement. >> >> However there's still additional overhead here and I wouldn't vote for this. >> >> David >> >> Howard Lovatt said the following on 02/26/11 10:40: >>> The use case: >>> >>> try ( new ReentrantLock() ) { ... } >>> >>> makes no sense, you *need* to share the lock. However if Lock were >>> modified to use defender methods: >>> >>> interface Lock extends AutoCloseable { >>> >>> ... // As before >>> >>> Lock autoLock() default Trait.autoLock; >>> >>> // Similarly autoLockInterruptibly >>> >>> void close() default Trait.close; >>> >>> static final class Trait { >>> public Lock autoLock(final Lock self) { >>> self.lock(); >>> return self; >>> } >>> >>> // Similarly autoLockInterruptibly >>> >>> public void close(final Lock self) { >>> self.unlock(); >>> } >>> } >>> } >>> >>> Then >>> >>> try (l.autoLock()) { ... } >>> >>> would work. >>> >>> -- Howard. >>> >>> On 24 February 2011 11:42, David Holmes wrote: >>>> I suspect Joe will shut this down as being out of scope for coin-dev in >>>> its present state, but my 2c >>>> >>>> Gernot Neppert said the following on 02/24/11 03:31: >>>>> this has been discussed here before, but somehow got lost: >>>>> Wouldn't it be very handy having a class >>>>> "java.util.concurrent.AutoLockable" that could be used as follows: >>>> No not really. The way try-with-resources has evolved really doesn't >>>> mesh with lock usage. As Neal already mentioned the overhead of creating >>>> the AutoLockable per lock operation is simply prohibitive. Even if you >>>> retrofitted Lock with AutoCloseable you would still need (given t-w-r >>>> synatx) to have a helper method to acquire the lock and return it so you >>>> can assign it to the local: >>>> >>>> try ( Lock l = Lock.lockAndReturn(lock) ) { >>>> ... >>>> } >>>> >>>> This is just a round-hole vs square-peg situation, and trying to make it >>>> fit really doesn't add anything to clarity or useability in my view. >>>> >>>> I can imagine a more general (more specific?) t-w-r that might allow: >>>> >>>> try (lock) { >>>> ... >>>> } >>>> >>>> but that would be for future debate. >>>> >>>> Cheers, >>>> David Holmes >>>> >>>>> try(AutoLockable locked = AutoLockable.locked(lock)) >>>>> { >>>>> // Do something in locked scope >>>>> } >>>>> >>>>> It would look something like this: >>>>> >>>>> package java.util.concurrent.locks; >>>>> >>>>> public abstract class AutoLockable implements AutoCloseable { >>>>> >>>>> public static AutoLockable locked(final Lock lock) >>>>> { >>>>> lock.lock(); >>>>> return new AutoLockable() { >>>>> >>>>> @Override >>>>> public void close() { >>>>> lock.unlock(); >>>>> } >>>>> }; >>>>> } >>>>> >>>>> public abstract void close(); >>>>> } >>>>> >>>>> >>> >>> > > From forax at univ-mlv.fr Sat Feb 26 13:35:20 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 26 Feb 2011 22:35:20 +0100 Subject: For Coin 8: this keyword for static methods In-Reply-To: <427142.93272.qm@web161204.mail.bf1.yahoo.com> References: <427142.93272.qm@web161204.mail.bf1.yahoo.com> Message-ID: <4D697218.9030306@univ-mlv.fr> On 02/22/2011 06:47 PM, Vimil Saju wrote: > Hi, > > It would be nice to have a 'this' > keyword for static methods. For static methods 'this' refers > to the class in which the static method is defined. > > In our code-base we have a lot of places where we > initialize a logger for a class as follows > > public class MyApp { > static Logger logger = Logger.getLogger(MyApp.class); > ... > ... > > If we could refer to MyApp using the keyword 'this' then when copying this code to other classes there wouldn't be a need to remember to change the class passed to the getLogger method. > > Thanks > Vimil see my blog :) http://weblogs.java.net/blog/forax/archive/2010/10/26/how-get-current-class-java R?mi From vimilsaju at yahoo.com Sat Feb 26 16:47:52 2011 From: vimilsaju at yahoo.com (Vimil Saju) Date: Sat, 26 Feb 2011 16:47:52 -0800 (PST) Subject: For Coin 8: this keyword for static methods In-Reply-To: <4D697218.9030306@univ-mlv.fr> Message-ID: <285945.29751.qm@web161219.mail.bf1.yahoo.com> Hi, From your blog I see that in JDK7 the code MethodHandles.lookup().lookupClass() returns the current class. I read it is also possible to get the current class from the stack trace. However from a performance point of view wouldn't having a keyword of some sort to get the current class be more efficient than having to go-through the stack trace to determine the current class, or does the JVM also have to do the same thing to determine the current class? Thanks Vimil --- On Sat, 2/26/11, R?mi Forax wrote: > From: R?mi Forax > Subject: Re: For Coin 8: this keyword for static methods > To: coin-dev at openjdk.java.net > Date: Saturday, February 26, 2011, 1:35 PM > On 02/22/2011 06:47 PM, Vimil Saju > wrote: > > Hi, > > > >???It would be nice to have a 'this' > >???keyword for static methods. For > static methods 'this' refers > >???to the class in which the static > method is defined. > > > >???In our code-base we have a lot of > places where we > >???initialize a logger for a class as > follows > > > >???public class MyApp { > >? ? ? static Logger logger = > Logger.getLogger(MyApp.class); > >? ? ? ... > >? ? ? ... > > > > If we could refer to MyApp using the keyword 'this' > then when copying this code to other classes there wouldn't > be a need to remember to change the class passed to the > getLogger method. > > > > Thanks > > Vimil > > see my blog :) > http://weblogs.java.net/blog/forax/archive/2010/10/26/how-get-current-class-java > > R?mi > > > > From pbenedict at apache.org Sat Feb 26 16:54:54 2011 From: pbenedict at apache.org (Paul Benedict) Date: Sat, 26 Feb 2011 18:54:54 -0600 Subject: For Coin 8: this keyword for static methods In-Reply-To: <285945.29751.qm@web161219.mail.bf1.yahoo.com> References: <4D697218.9030306@univ-mlv.fr> <285945.29751.qm@web161219.mail.bf1.yahoo.com> Message-ID: I thought the original question was to find a way to remove the static class name. That's not anything that needs computation at runtime. The compiler can emit it. On Sat, Feb 26, 2011 at 6:47 PM, Vimil Saju wrote: > Hi, > > >From your blog I see that in JDK7 the code > MethodHandles.lookup().lookupClass() > returns the current class. I read it is also possible to get the current > class from the stack trace. > > However from a performance point of view wouldn't having a keyword of some > sort to get the current class be more efficient than having to go-through > the stack trace to determine the current class, or does the JVM also have to > do the same thing to determine the current class? > > Thanks > Vimil > > --- On Sat, 2/26/11, R?mi Forax wrote: > > > From: R?mi Forax > > Subject: Re: For Coin 8: this keyword for static methods > > To: coin-dev at openjdk.java.net > > Date: Saturday, February 26, 2011, 1:35 PM > > On 02/22/2011 06:47 PM, Vimil Saju > > wrote: > > > Hi, > > > > > > It would be nice to have a 'this' > > > keyword for static methods. For > > static methods 'this' refers > > > to the class in which the static > > method is defined. > > > > > > In our code-base we have a lot of > > places where we > > > initialize a logger for a class as > > follows > > > > > > public class MyApp { > > > static Logger logger = > > Logger.getLogger(MyApp.class); > > > ... > > > ... > > > > > > If we could refer to MyApp using the keyword 'this' > > then when copying this code to other classes there wouldn't > > be a need to remember to change the class passed to the > > getLogger method. > > > > > > Thanks > > > Vimil > > > > see my blog :) > > > http://weblogs.java.net/blog/forax/archive/2010/10/26/how-get-current-class-java > > > > R?mi > > > > > > > > > > > > > From vimilsaju at yahoo.com Sat Feb 26 16:59:08 2011 From: vimilsaju at yahoo.com (Vimil Saju) Date: Sat, 26 Feb 2011 16:59:08 -0800 (PST) Subject: For Coin 8: this keyword for static methods In-Reply-To: Message-ID: <661356.52914.qm@web161210.mail.bf1.yahoo.com> Yes that was my question, but for a static method isn't the current class and the class to which the static method belongs to the same? --- On Sat, 2/26/11, Paul Benedict wrote: From: Paul Benedict Subject: Re: For Coin 8: this keyword for static methods To: "Vimil Saju" Cc: coin-dev at openjdk.java.net, "R?mi Forax" Date: Saturday, February 26, 2011, 4:54 PM I thought the original question was to find a way to remove the static class name. That's not anything that needs computation at runtime. The compiler can emit it. On Sat, Feb 26, 2011 at 6:47 PM, Vimil Saju wrote: Hi, >From your blog I see that in JDK7 the code ?MethodHandles.lookup().lookupClass() returns the current class. I read it is also possible to get the current class from the stack trace. However from a performance point of view wouldn't having a keyword of some sort to get the current class be more efficient than having to go-through the stack trace to determine the current class, or does the JVM also have to do the same thing to determine the current class? Thanks Vimil --- On Sat, 2/26/11, R?mi Forax wrote: > From: R?mi Forax > Subject: Re: For Coin 8: this keyword for static methods > To: coin-dev at openjdk.java.net > Date: Saturday, February 26, 2011, 1:35 PM > On 02/22/2011 06:47 PM, Vimil Saju > wrote: > > Hi, > > > >???It would be nice to have a 'this' > >???keyword for static methods. For > static methods 'this' refers > >???to the class in which the static > method is defined. > > > >???In our code-base we have a lot of > places where we > >???initialize a logger for a class as > follows > > > >???public class MyApp { > >? ? ? static Logger logger = > Logger.getLogger(MyApp.class); > >? ? ? ... > >? ? ? ... > > > > If we could refer to MyApp using the keyword 'this' > then when copying this code to other classes there wouldn't > be a need to remember to change the class passed to the > getLogger method. > > > > Thanks > > Vimil > > see my blog :) > http://weblogs.java.net/blog/forax/archive/2010/10/26/how-get-current-class-java > > R?mi > > > > From heinz at javaspecialists.eu Sun Feb 27 11:30:01 2011 From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz) Date: Sun, 27 Feb 2011 21:30:01 +0200 Subject: AutoLock Message-ID: <4D6AA639.7070709@javaspecialists.eu> Hi, Brian told me about the discussion going on here on coin-dev. I published a newsletter today on the new Java 7 try-with-resource construct and how we could use it for automatically unlocking. By combining it with static imports, we can write the following code: try (lock(lock)) { printLockStatus(); } Instead of the current more verbose lock.lock(); try { printLockStatus(); } finally { lock.unlock(); } In my newsletter, I expressed the same concern as Neal, that constructing objects, and in fact encouraging people to do this in performance critical code, could be a killer for this idea. However, initial tests indicate that escape analysis actually does a nice job of eliminating the cost of the object construction. These are just completely basic initial tests and are quite possibly flawed. However, with the default escape analysis turned on, my try (lock(lock)) code did not cause any objects to be created, even though I called it 1_000_000_000 times. When I turned off escape analysis, it constructed about 30GB of objects. As I said, I have not tested this properly, just an initial investigation. Here is the link to my article: http://www.javaspecialists.eu/archive/Issue190.html Regards Heinz -- Dr Heinz M. Kabutz (PhD CompSci) Author of "The Java(tm) Specialists' Newsletter" Sun Java Champion IEEE Certified Software Development Professional http://www.javaspecialists.eu Tel: +30 69 72 850 460 Skype: kabutz From David.Holmes at oracle.com Sun Feb 27 14:42:23 2011 From: David.Holmes at oracle.com (David Holmes) Date: Mon, 28 Feb 2011 08:42:23 +1000 Subject: AutoLock In-Reply-To: <4D6AA639.7070709@javaspecialists.eu> References: <4D6AA639.7070709@javaspecialists.eu> Message-ID: <4D6AD34F.3040700@oracle.com> Hi Heinz, One slight glitch here is that, as I recall (and I'd like Joe to confirm as I can't find anything in writing) they updated the spec to disallow simple expressions, so you need to use something slightly more verbose that introduces a local variable to refer to the Lock. Also as I understand it escape-analysis is only used by the server compiler, so we can not rely on having it to get rid of the object creation overhead. As indicated in the other threads on coin-dev there are ways to do this without having to introduce a new object as a wrapper - but they introduce their own overheads. By the way, the "whopping 553 classes" that implement AuoCloseable comes about due to Closeable being retrofitted to also be AutoCloseable. No big surprise that these are primarily (all?) I/O related classes. Cheers, David Holmes Dr Heinz M. Kabutz said the following on 02/28/11 05:30: > Hi, > > Brian told me about the discussion going on here on coin-dev. I > published a newsletter today on the new Java 7 try-with-resource > construct and how we could use it for automatically unlocking. By > combining it with static imports, we can write the following code: > > try (lock(lock)) { > printLockStatus(); > } > > Instead of the current more verbose > > lock.lock(); > try { > printLockStatus(); > } finally { > lock.unlock(); > } > > In my newsletter, I expressed the same concern as Neal, that > constructing objects, and in fact encouraging people to do this in > performance critical code, could be a killer for this idea. > > However, initial tests indicate that escape analysis actually does a > nice job of eliminating the cost of the object construction. These are > just completely basic initial tests and are quite possibly flawed. > However, with the default escape analysis turned on, my try (lock(lock)) > code did not cause any objects to be created, even though I called it > 1_000_000_000 times. > > When I turned off escape analysis, it constructed about 30GB of objects. > > As I said, I have not tested this properly, just an initial investigation. > > Here is the link to my article: > http://www.javaspecialists.eu/archive/Issue190.html > > Regards > > Heinz From jjb at google.com Sun Feb 27 17:13:40 2011 From: jjb at google.com (Joshua Bloch) Date: Sun, 27 Feb 2011 17:13:40 -0800 Subject: AutoLock In-Reply-To: <4D6AD34F.3040700@oracle.com> References: <4D6AA639.7070709@javaspecialists.eu> <4D6AD34F.3040700@oracle.com> Message-ID: Folks, This (locking) was an explicit non-goal of the JSR. If we were in favor of supporting it, I'd recommend: protected (lock) { ... code ... } But Doug and other concurrency experts say that we shouldn't be encouraging people to use locks directly. Josh On Sun, Feb 27, 2011 at 2:42 PM, David Holmes wrote: > Hi Heinz, > > One slight glitch here is that, as I recall (and I'd like Joe to confirm > as I can't find anything in writing) they updated the spec to disallow > simple expressions, so you need to use something slightly more verbose > that introduces a local variable to refer to the Lock. > > Also as I understand it escape-analysis is only used by the server > compiler, so we can not rely on having it to get rid of the object > creation overhead. As indicated in the other threads on coin-dev there > are ways to do this without having to introduce a new object as a > wrapper - but they introduce their own overheads. > > By the way, the "whopping 553 classes" that implement AuoCloseable comes > about due to Closeable being retrofitted to also be AutoCloseable. No > big surprise that these are primarily (all?) I/O related classes. > > Cheers, > David Holmes > > > Dr Heinz M. Kabutz said the following on 02/28/11 05:30: > > Hi, > > > > Brian told me about the discussion going on here on coin-dev. I > > published a newsletter today on the new Java 7 try-with-resource > > construct and how we could use it for automatically unlocking. By > > combining it with static imports, we can write the following code: > > > > try (lock(lock)) { > > printLockStatus(); > > } > > > > Instead of the current more verbose > > > > lock.lock(); > > try { > > printLockStatus(); > > } finally { > > lock.unlock(); > > } > > > > In my newsletter, I expressed the same concern as Neal, that > > constructing objects, and in fact encouraging people to do this in > > performance critical code, could be a killer for this idea. > > > > However, initial tests indicate that escape analysis actually does a > > nice job of eliminating the cost of the object construction. These are > > just completely basic initial tests and are quite possibly flawed. > > However, with the default escape analysis turned on, my try (lock(lock)) > > code did not cause any objects to be created, even though I called it > > 1_000_000_000 times. > > > > When I turned off escape analysis, it constructed about 30GB of objects. > > > > As I said, I have not tested this properly, just an initial > investigation. > > > > Here is the link to my article: > > http://www.javaspecialists.eu/archive/Issue190.html > > > > Regards > > > > Heinz > > From mcnepp02 at googlemail.com Mon Feb 28 02:21:06 2011 From: mcnepp02 at googlemail.com (Gernot Neppert) Date: Mon, 28 Feb 2011 10:21:06 +0000 Subject: AutoLock In-Reply-To: <4D6AA639.7070709@javaspecialists.eu> References: <4D6AA639.7070709@javaspecialists.eu> Message-ID: 2011/2/27 Dr Heinz M. Kabutz : > Hi, > > Brian told me about the discussion going on here on coin-dev. ?I > published a newsletter today on the new Java 7 try-with-resource > construct and how we could use it for automatically unlocking. ?By > combining it with static imports, we can write the following code: > > ? ?try (lock(lock)) { > ? ? ?printLockStatus(); > ? ?} > To be frank: publishing the exact proposal that I made on this list a couple of days back as your idea seems not to be the best of manners... But then, you may become minster of defense in Germany with this technique ;-) (For those not familiar with German current affairs: google "Guttenberg plagiat") From heinz at javaspecialists.eu Mon Feb 28 04:14:38 2011 From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz) Date: Mon, 28 Feb 2011 14:14:38 +0200 Subject: AutoLock In-Reply-To: <4D6AD34F.3040700@oracle.com> References: <4D6AA639.7070709@javaspecialists.eu> <4D6AD34F.3040700@oracle.com> Message-ID: <4D6B91AE.50701@javaspecialists.eu> On 2/28/11 12:42 AM, David Holmes wrote: > One slight glitch here is that, as I recall (and I'd like Joe to > confirm as I can't find anything in writing) they updated the spec to > disallow simple expressions, so you need to use something slightly > more verbose that introduces a local variable to refer to the Lock. Brian pointed this out to me after I wrote my idea. Once we go more verbose, I think the slight syntactic sugar advantage goes away. Pity. > Also as I understand it escape-analysis is only used by the server > compiler, so we can not rely on having it to get rid of the object > creation overhead. As indicated in the other threads on coin-dev there > are ways to do this without having to introduce a new object as a > wrapper - but they introduce their own overheads. This sounds like a case of premature optimization to me. > By the way, the "whopping 553 classes" that implement AuoCloseable > comes about due to Closeable being retrofitted to also be > AutoCloseable. No big surprise that these are primarily (all?) I/O > related classes. Yes, of course. Plus the database and media classes are now AutoCloseable. All very nice. I love this construct as it fixes a serious flaw in most IO exception code. > > Cheers, > David Holmes > > > Dr Heinz M. Kabutz said the following on 02/28/11 05:30: >> Hi, >> >> Brian told me about the discussion going on here on coin-dev. I >> published a newsletter today on the new Java 7 try-with-resource >> construct and how we could use it for automatically unlocking. By >> combining it with static imports, we can write the following code: >> >> try (lock(lock)) { >> printLockStatus(); >> } >> >> Instead of the current more verbose >> >> lock.lock(); >> try { >> printLockStatus(); >> } finally { >> lock.unlock(); >> } >> >> In my newsletter, I expressed the same concern as Neal, that >> constructing objects, and in fact encouraging people to do this in >> performance critical code, could be a killer for this idea. >> >> However, initial tests indicate that escape analysis actually does a >> nice job of eliminating the cost of the object construction. These >> are just completely basic initial tests and are quite possibly >> flawed. However, with the default escape analysis turned on, my try >> (lock(lock)) code did not cause any objects to be created, even >> though I called it 1_000_000_000 times. >> >> When I turned off escape analysis, it constructed about 30GB of objects. >> >> As I said, I have not tested this properly, just an initial >> investigation. >> >> Here is the link to my article: >> http://www.javaspecialists.eu/archive/Issue190.html >> >> Regards >> >> Heinz > From joe.darcy at oracle.com Mon Feb 28 10:21:54 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 28 Feb 2011 10:21:54 -0800 Subject: AutoLock In-Reply-To: <4D6AD34F.3040700@oracle.com> References: <4D6AA639.7070709@javaspecialists.eu> <4D6AD34F.3040700@oracle.com> Message-ID: <4D6BE7C2.5080803@oracle.com> Hello. David Holmes wrote: > Hi Heinz, > > One slight glitch here is that, as I recall (and I'd like Joe to confirm > as I can't find anything in writing) they updated the spec to disallow > simple expressions, so you need to use something slightly more verbose > that introduces a local variable to refer to the Lock. > That is correct; the rationale for this change was given in: http://mail.openjdk.java.net/pipermail/coin-dev/2011-January/002972.html > Also as I understand it escape-analysis is only used by the server > compiler, so we can not rely on having it to get rid of the object > creation overhead. As indicated in the other threads on coin-dev there > are ways to do this without having to introduce a new object as a > wrapper - but they introduce their own overheads. > > By the way, the "whopping 553 classes" that implement AuoCloseable comes > about due to Closeable being retrofitted to also be AutoCloseable. No > big surprise that these are primarily (all?) I/O related classes. > Most types that implement AutoCloseable do so by implementing java.io.Closeable. There are a few that just implement AutoCloseable: java.nio.channels.FileLock java.beans.XMLDecoder java.beans.XMLEncoder java.io.ObjectInput java.io.ObjectOutput java.sql.Connection java.sql.ResultSet java.sql.Statement javax.sound.midi.MidiDevice javax.sound.midi.Receiver javax.sound.sampled.Line Retrofitting JDBC with AutoCloseable occurred after the initial library changes [1]. For those wishing to retrofit types in a codebase to implement Closeable or AutoCloseable, an annotation processor is available to assist [2]. -Joe [1] http://blogs.sun.com/darcy/entry/project_coin_jdbc_4_1 [2] http://blogs.sun.com/darcy/entry/project_coin_bring_close > Cheers, > David Holmes > > > Dr Heinz M. Kabutz said the following on 02/28/11 05:30: > >> Hi, >> >> Brian told me about the discussion going on here on coin-dev. I >> published a newsletter today on the new Java 7 try-with-resource >> construct and how we could use it for automatically unlocking. By >> combining it with static imports, we can write the following code: >> >> try (lock(lock)) { >> printLockStatus(); >> } >> >> Instead of the current more verbose >> >> lock.lock(); >> try { >> printLockStatus(); >> } finally { >> lock.unlock(); >> } >> >> In my newsletter, I expressed the same concern as Neal, that >> constructing objects, and in fact encouraging people to do this in >> performance critical code, could be a killer for this idea. >> >> However, initial tests indicate that escape analysis actually does a >> nice job of eliminating the cost of the object construction. These are >> just completely basic initial tests and are quite possibly flawed. >> However, with the default escape analysis turned on, my try (lock(lock)) >> code did not cause any objects to be created, even though I called it >> 1_000_000_000 times. >> >> When I turned off escape analysis, it constructed about 30GB of objects. >> >> As I said, I have not tested this properly, just an initial investigation. >> >> Here is the link to my article: >> http://www.javaspecialists.eu/archive/Issue190.html >> >> Regards >> >> Heinz >> > > From heinz at javaspecialists.eu Mon Feb 28 11:07:03 2011 From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz) Date: Mon, 28 Feb 2011 21:07:03 +0200 Subject: AutoLock In-Reply-To: <4D6BE7C2.5080803@oracle.com> References: <4D6AA639.7070709@javaspecialists.eu> <4D6AD34F.3040700@oracle.com> <4D6BE7C2.5080803@oracle.com> Message-ID: <4D6BF257.6000805@javaspecialists.eu> Hi Joe, David, thank you for humoring me regarding this issue. I understand all of your rationales for not allowing simple expressions. I also agree with Doug that we should not encourage people to write locking code, because they will probably get it wrong. This will probably be my last comment on this and then I'll go back to my hole on the island of Crete and shut up ;-) Here is a piece of code that returns the correct exception when used with my AutoLock try-with-resource approach, but returns an unexpected exception when used with the traditional await approach, also used in the BlockingQueues: import java.util.concurrent.locks.*; public class StopTest { private static Lock lock = new ReentrantLock(); private static Condition condition = lock.newCondition(); private static void incorrectExceptionReturned() throws InterruptedException { lock.lock(); try { condition.await(); } catch (InterruptedException e) { condition.signal(); throw e; } finally { lock.unlock(); } } private static void correctExceptionReturned() throws InterruptedException { try (AutoLock.lock(lock)) { condition.await(); } catch(InterruptedException e) { condition.signal(); throw e; } } public static void main(String[] args) throws InterruptedException { Thread t1 = new Thread() { public void run() { try { incorrectExceptionReturned(); } catch (Throwable t) { System.out.println("incorrect exception: " + t); t.printStackTrace(System.out); } } }; Thread t2 = new Thread() { public void run() { try { correctExceptionReturned(); } catch (Throwable t) { System.out.println("correct exception: " + t); t.printStackTrace(System.out); } } }; t1.start(); t2.start(); Thread.sleep(100); t1.stop(); Thread.sleep(100); t2.stop(); } } I am calling the method stop(). Yes, I know it is deprecated. I know it should never be called. I also know why :-) However, until it is removed from the JDK (never?), it will remain there and programmers will be able to call it. When I call stop() on a thread, I expect a ThreadDeath. However, if it is in the await() state, it will come back from the await() without getting the lock again. This means that we will see the IllegalMonitorStateException, like so: incorrect exception: java.lang.IllegalMonitorStateException java.lang.IllegalMonitorStateException at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:155) at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1258) at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:459) at eu.javaspecialists.concurrent.StopTest.incorrectExceptionReturned(StopTest.java:17) at eu.javaspecialists.concurrent.StopTest.access$000(StopTest.java:5) at eu.javaspecialists.concurrent.StopTest$1.run(StopTest.java:36) correct exception: java.lang.ThreadDeath java.lang.ThreadDeath at java.lang.Thread.stop(Thread.java:828) at eu.javaspecialists.concurrent.StopTest.main(StopTest.java:58) Suppressed: java.lang.IllegalMonitorStateException at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:155) at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1258) at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:459) at eu.javaspecialists.concurrent.AutoLock.close(AutoLock.java:18) at eu.javaspecialists.concurrent.StopTest.correctExceptionReturned(StopTest.java:24) at eu.javaspecialists.concurrent.StopTest.access$100(StopTest.java:5) at eu.javaspecialists.concurrent.StopTest$2.run(StopTest.java:46) I understand this is a contrived example, because we should never call stop(). But I still like the way that the try-with-resource returns the correct throwable :-) Regards Heinz -- Dr Heinz M. Kabutz (PhD CompSci) Author of "The Java(tm) Specialists' Newsletter" Sun Java Champion IEEE Certified Software Development Professional http://www.javaspecialists.eu Tel: +30 69 72 850 460 Skype: kabutz On 2/28/11 8:21 PM, Joe Darcy wrote: > Hello. > > David Holmes wrote: >> Hi Heinz, >> >> One slight glitch here is that, as I recall (and I'd like Joe to >> confirm as I can't find anything in writing) they updated the spec to >> disallow simple expressions, so you need to use something slightly >> more verbose that introduces a local variable to refer to the Lock. >> > > That is correct; the rationale for this change was given in: > http://mail.openjdk.java.net/pipermail/coin-dev/2011-January/002972.html > >> Also as I understand it escape-analysis is only used by the server >> compiler, so we can not rely on having it to get rid of the object >> creation overhead. As indicated in the other threads on coin-dev >> there are ways to do this without having to introduce a new object as >> a wrapper - but they introduce their own overheads. >> >> By the way, the "whopping 553 classes" that implement AuoCloseable >> comes about due to Closeable being retrofitted to also be >> AutoCloseable. No big surprise that these are primarily (all?) I/O >> related classes. >> > Most types that implement AutoCloseable do so by implementing > java.io.Closeable. There are a few that just implement AutoCloseable: > > java.nio.channels.FileLock > java.beans.XMLDecoder > java.beans.XMLEncoder > java.io.ObjectInput > java.io.ObjectOutput > java.sql.Connection > java.sql.ResultSet > java.sql.Statement > javax.sound.midi.MidiDevice > javax.sound.midi.Receiver > javax.sound.sampled.Line > > Retrofitting JDBC with AutoCloseable occurred after the initial > library changes [1]. For those wishing to retrofit types in a > codebase to implement Closeable or AutoCloseable, an annotation > processor is available to assist [2]. > > -Joe > > [1] http://blogs.sun.com/darcy/entry/project_coin_jdbc_4_1 > [2] http://blogs.sun.com/darcy/entry/project_coin_bring_close > > >> Cheers, >> David Holmes >> >> >> Dr Heinz M. Kabutz said the following on 02/28/11 05:30: >> >>> Hi, >>> >>> Brian told me about the discussion going on here on coin-dev. I >>> published a newsletter today on the new Java 7 try-with-resource >>> construct and how we could use it for automatically unlocking. By >>> combining it with static imports, we can write the following code: >>> >>> try (lock(lock)) { >>> printLockStatus(); >>> } >>> >>> Instead of the current more verbose >>> >>> lock.lock(); >>> try { >>> printLockStatus(); >>> } finally { >>> lock.unlock(); >>> } >>> >>> In my newsletter, I expressed the same concern as Neal, that >>> constructing objects, and in fact encouraging people to do this in >>> performance critical code, could be a killer for this idea. >>> >>> However, initial tests indicate that escape analysis actually does a >>> nice job of eliminating the cost of the object construction. These >>> are just completely basic initial tests and are quite possibly >>> flawed. However, with the default escape analysis turned on, my try >>> (lock(lock)) code did not cause any objects to be created, even >>> though I called it 1_000_000_000 times. >>> >>> When I turned off escape analysis, it constructed about 30GB of >>> objects. >>> >>> As I said, I have not tested this properly, just an initial >>> investigation. >>> >>> Here is the link to my article: >>> http://www.javaspecialists.eu/archive/Issue190.html >>> >>> Regards >>> >>> Heinz >>> >> >> > > From joe.darcy at oracle.com Mon Feb 28 11:27:58 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 28 Feb 2011 11:27:58 -0800 Subject: AutoLock In-Reply-To: <4D6BF257.6000805@javaspecialists.eu> References: <4D6AA639.7070709@javaspecialists.eu> <4D6AD34F.3040700@oracle.com> <4D6BE7C2.5080803@oracle.com> <4D6BF257.6000805@javaspecialists.eu> Message-ID: <4D6BF73E.6000508@oracle.com> Hello Heinz. Dr Heinz M. Kabutz wrote: > Hi Joe, David, > > thank you for humoring me regarding this issue. I understand all of > your rationales for not allowing simple expressions. I also agree > with Doug that we should not encourage people to write locking code, > because they will probably get it wrong. This will probably be my > last comment on this and then I'll go back to my hole on the island of > Crete and shut up ;-) > I found the escape analysis results you reported about using a lock wrapper with try-with-resources very interesting, even if using try-with-resources with a lock is outside the recommended usage. More empirical results from using the Coin features, their performance, ease of retrofitting, etc., would be welcome from Crete or elsewhere :-) -Joe From David.Holmes at oracle.com Mon Feb 28 18:05:35 2011 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 01 Mar 2011 12:05:35 +1000 Subject: AutoLock In-Reply-To: <4D6BF257.6000805@javaspecialists.eu> References: <4D6AA639.7070709@javaspecialists.eu> <4D6AD34F.3040700@oracle.com> <4D6BE7C2.5080803@oracle.com> <4D6BF257.6000805@javaspecialists.eu> Message-ID: <4D6C546F.6070506@oracle.com> (Re-send without cc's due to ongoing mailer issues) Heinz, > I understand this is a contrived example, because we should never call > stop(). But I still like the way that the try-with-resource returns > the correct throwable :-) In my opinion it doesn't throw the "correct" throwable at all! The IllegalMonitorStateException would normally (not here because of stop()) indicate a significant programming error and so is much more significant in my view. Even worse for this example, ThreadDeath doesn't trigger printStackTrace in the default uncaught-exception handler, so you'd never even see you had this IllegalMonitorStateException lurking. Just my 2c. David Dr Heinz M. Kabutz said the following on 03/01/11 05:07: > Hi Joe, David, > > thank you for humoring me regarding this issue. I understand all of > your rationales for not allowing simple expressions. I also agree with > Doug that we should not encourage people to write locking code, because > they will probably get it wrong. This will probably be my last comment > on this and then I'll go back to my hole on the island of Crete and shut > up ;-) > > Here is a piece of code that returns the correct exception when used > with my AutoLock try-with-resource approach, but returns an unexpected > exception when used with the traditional await approach, also used in > the BlockingQueues: > > > import java.util.concurrent.locks.*; > > public class StopTest { > private static Lock lock = new ReentrantLock(); > private static Condition condition = lock.newCondition(); > > private static void incorrectExceptionReturned() throws > InterruptedException { > lock.lock(); > try { > condition.await(); > } catch (InterruptedException e) { > condition.signal(); > throw e; > } finally { > lock.unlock(); > } > } > > private static void correctExceptionReturned() throws > InterruptedException { > try (AutoLock.lock(lock)) { > condition.await(); > } catch(InterruptedException e) { > condition.signal(); > throw e; > } > } > > public static void main(String[] args) > throws InterruptedException { > > Thread t1 = new Thread() { > public void run() { > try { > incorrectExceptionReturned(); > } catch (Throwable t) { > System.out.println("incorrect exception: " + t); > t.printStackTrace(System.out); > } > } > }; > Thread t2 = new Thread() { > public void run() { > try { > correctExceptionReturned(); > } catch (Throwable t) { > System.out.println("correct exception: " + t); > t.printStackTrace(System.out); > } > } > }; > t1.start(); > t2.start(); > Thread.sleep(100); > t1.stop(); > Thread.sleep(100); > t2.stop(); > } > } > > > I am calling the method stop(). Yes, I know it is deprecated. I know > it should never be called. I also know why :-) However, until it is > removed from the JDK (never?), it will remain there and programmers will > be able to call it. When I call stop() on a thread, I expect a > ThreadDeath. However, if it is in the await() state, it will come back > from the await() without getting the lock again. This means that we > will see the IllegalMonitorStateException, like so: > > incorrect exception: java.lang.IllegalMonitorStateException > java.lang.IllegalMonitorStateException > at > java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:155) > > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1258) > > at > java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:459) > at > eu.javaspecialists.concurrent.StopTest.incorrectExceptionReturned(StopTest.java:17) > > at eu.javaspecialists.concurrent.StopTest.access$000(StopTest.java:5) > at eu.javaspecialists.concurrent.StopTest$1.run(StopTest.java:36) > correct exception: java.lang.ThreadDeath > java.lang.ThreadDeath > at java.lang.Thread.stop(Thread.java:828) > at eu.javaspecialists.concurrent.StopTest.main(StopTest.java:58) > Suppressed: java.lang.IllegalMonitorStateException > at > java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:155) > > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1258) > > at > java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:459) > at eu.javaspecialists.concurrent.AutoLock.close(AutoLock.java:18) > at > eu.javaspecialists.concurrent.StopTest.correctExceptionReturned(StopTest.java:24) > > at > eu.javaspecialists.concurrent.StopTest.access$100(StopTest.java:5) > at eu.javaspecialists.concurrent.StopTest$2.run(StopTest.java:46) > > I understand this is a contrived example, because we should never call > stop(). But I still like the way that the try-with-resource returns the > correct throwable :-) > > Regards > > Heinz From brucechapman at paradise.net.nz Mon Feb 28 23:50:40 2011 From: brucechapman at paradise.net.nz (Bruce Chapman) Date: Tue, 01 Mar 2011 20:50:40 +1300 Subject: AutoLock In-Reply-To: References: <4D6AA639.7070709@javaspecialists.eu> Message-ID: <4D6CA550.3020807@paradise.net.nz> On 28/02/2011 11:21 p.m., Gernot Neppert wrote: > 2011/2/27 Dr Heinz M. Kabutz: >> Hi, >> >> Brian told me about the discussion going on here on coin-dev. I >> published a newsletter today on the new Java 7 try-with-resource >> construct and how we could use it for automatically unlocking. By >> combining it with static imports, we can write the following code: >> >> try (lock(lock)) { >> printLockStatus(); >> } >> > To be frank: publishing the exact proposal that I made on this list a > couple of days back as your idea seems not to be the best of > manners... If two people read the same old version of the spec and try to apply it outside the square, it is highly likely they will choose Locks and solve it in this same wrong way. That's not plagiarism, it's what happens when there is a lack of novelty in both the problem and solution. All the same it's nice to see Peckish's third law of memetics still providing some entertainment, exquisitely served on a bed of memepool predation. Bruce > But then, you may become minster of defense in Germany with this technique ;-) > (For those not familiar with German current affairs: google > "Guttenberg plagiat") > >