From joe.darcy at oracle.com Fri Apr 1 18:21:32 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 01 Apr 2011 18:21:32 -0700 Subject: New protocol for disabling exception suppression Message-ID: <4D967A1C.3060001@oracle.com> As part of the library support for the try-with-resources statement, several API changes were made to Throwable including an addSuppressed method to allow suppressed exceptions to be recorded. As previously discussed on coin-dev [1], to support VM needs for reusable exception objects, a protocol was devised to disable the suppression mechanism so that a zero-length array would be returned from getSuppressed even if addSuppressed was called with a valid argument. The mechanism was a bit of a kludge, relying on an initial call to addSuppressed with a null argument, and the design was called out as such. [2] I'm happy to report the JSR 334 expert group has devised a more elegant protocol to disable exception suppression: a new constructor is added to Throwable which supports disabling suppression. The existing constructors of Throwable always enable suppression and addSuppressed(null) now always throws a NullPointerException. A few exception and error types in the platform are allowed by behave as if their objects were created with suppression disabled. The fix was recently pushed [3] and will appear in a future JDK 7 build. -Joe [1] http://mail.openjdk.java.net/pipermail/coin-dev/2010-August/002830.html [2] http://mail.openjdk.java.net/pipermail/coin-dev/2010-October/thread.html#2920 [3] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/856cc9e97aea From barney at frontofficedeveloper.com Sat Apr 2 08:41:37 2011 From: barney at frontofficedeveloper.com (Barney Pitt) Date: Sat, 2 Apr 2011 15:41:37 +0000 Subject: coin-dev Digest, Vol 27, Issue 1 In-Reply-To: References: Message-ID: Hi Paul Sorry for the long delay on the response - I had flu for a few days and then had a monster of a bad week at work, then also had to check the dates of my sister's wedding (which fortunately is the weekend after that one). You are extremely welcome, I look forward to seeing you. B From forax at univ-mlv.fr Sat Apr 2 18:52:06 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 03 Apr 2011 03:52:06 +0200 Subject: New protocol for disabling exception suppression In-Reply-To: <4D967A1C.3060001@oracle.com> References: <4D967A1C.3060001@oracle.com> Message-ID: <4D97D2C6.2080702@univ-mlv.fr> On 04/02/2011 03:21 AM, joe.darcy at oracle.com wrote: > As part of the library support for the try-with-resources statement, > several API changes were made to Throwable including an addSuppressed > method to allow suppressed exceptions to be recorded. As previously > discussed on coin-dev [1], to support VM needs for reusable exception > objects, a protocol was devised to disable the suppression mechanism so > that a zero-length array would be returned from getSuppressed even if > addSuppressed was called with a valid argument. The mechanism was a bit > of a kludge, relying on an initial call to addSuppressed with a null > argument, and the design was called out as such. [2] I'm happy to report > the JSR 334 expert group has devised a more elegant protocol to disable > exception suppression: a new constructor is added to Throwable which > supports disabling suppression. The existing constructors of Throwable > always enable suppression and addSuppressed(null) now always throws a > NullPointerException. A few exception and error types in the platform > are allowed by behave as if their objects were created with suppression > disabled. > > The fix was recently pushed [3] and will appear in a future JDK 7 build. > > -Joe > > [1] http://mail.openjdk.java.net/pipermail/coin-dev/2010-August/002830.html > [2] > http://mail.openjdk.java.net/pipermail/coin-dev/2010-October/thread.html#2920 > [3] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/856cc9e97aea > So the code of the VM was changed to call the constructor if it exists ? R?mi From David.Holmes at oracle.com Sat Apr 2 19:28:52 2011 From: David.Holmes at oracle.com (David Holmes) Date: Sun, 03 Apr 2011 12:28:52 +1000 Subject: New protocol for disabling exception suppression In-Reply-To: <4D97D2C6.2080702@univ-mlv.fr> References: <4D967A1C.3060001@oracle.com> <4D97D2C6.2080702@univ-mlv.fr> Message-ID: <4D97DB64.5010107@oracle.com> R?mi Forax said the following on 04/03/11 11:52: > On 04/02/2011 03:21 AM, joe.darcy at oracle.com wrote: >> As part of the library support for the try-with-resources statement, >> several API changes were made to Throwable including an addSuppressed >> method to allow suppressed exceptions to be recorded. As previously >> discussed on coin-dev [1], to support VM needs for reusable exception >> objects, a protocol was devised to disable the suppression mechanism so >> that a zero-length array would be returned from getSuppressed even if >> addSuppressed was called with a valid argument. The mechanism was a bit >> of a kludge, relying on an initial call to addSuppressed with a null >> argument, and the design was called out as such. [2] I'm happy to report >> the JSR 334 expert group has devised a more elegant protocol to disable >> exception suppression: a new constructor is added to Throwable which >> supports disabling suppression. The existing constructors of Throwable >> always enable suppression and addSuppressed(null) now always throws a >> NullPointerException. A few exception and error types in the platform >> are allowed by behave as if their objects were created with suppression >> disabled. >> >> The fix was recently pushed [3] and will appear in a future JDK 7 build. >> >> -Joe >> >> [1] http://mail.openjdk.java.net/pipermail/coin-dev/2010-August/002830.html >> [2] >> http://mail.openjdk.java.net/pipermail/coin-dev/2010-October/thread.html#2920 >> [3] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/856cc9e97aea >> > > So the code of the VM was changed to call the constructor if it exists ? No. The VM never calls a constructor it just allocates zeroed memory - which has the same affect as calling the new constructor. David > R?mi > > > From forax at univ-mlv.fr Sun Apr 3 02:09:42 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 03 Apr 2011 11:09:42 +0200 Subject: New protocol for disabling exception suppression In-Reply-To: <4D97DB64.5010107@oracle.com> References: <4D967A1C.3060001@oracle.com> <4D97D2C6.2080702@univ-mlv.fr> <4D97DB64.5010107@oracle.com> Message-ID: <4D983956.7040903@univ-mlv.fr> On 04/03/2011 04:28 AM, David Holmes wrote: > R?mi Forax said the following on 04/03/11 11:52: >> On 04/02/2011 03:21 AM, joe.darcy at oracle.com wrote: >>> As part of the library support for the try-with-resources statement, >>> several API changes were made to Throwable including an addSuppressed >>> method to allow suppressed exceptions to be recorded. As previously >>> discussed on coin-dev [1], to support VM needs for reusable exception >>> objects, a protocol was devised to disable the suppression mechanism so >>> that a zero-length array would be returned from getSuppressed even if >>> addSuppressed was called with a valid argument. The mechanism was a bit >>> of a kludge, relying on an initial call to addSuppressed with a null >>> argument, and the design was called out as such. [2] I'm happy to >>> report >>> the JSR 334 expert group has devised a more elegant protocol to disable >>> exception suppression: a new constructor is added to Throwable which >>> supports disabling suppression. The existing constructors of Throwable >>> always enable suppression and addSuppressed(null) now always throws a >>> NullPointerException. A few exception and error types in the platform >>> are allowed by behave as if their objects were created with suppression >>> disabled. >>> >>> The fix was recently pushed [3] and will appear in a future JDK 7 >>> build. >>> >>> -Joe >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/coin-dev/2010-August/002830.html >>> [2] >>> http://mail.openjdk.java.net/pipermail/coin-dev/2010-October/thread.html#2920 >>> >>> [3] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/856cc9e97aea >>> >> >> So the code of the VM was changed to call the constructor if it exists ? > > No. The VM never calls a constructor it just allocates zeroed memory - > which has the same affect as calling the new constructor. > > David So I don't see the improvement ? R?mi From David.Holmes at oracle.com Sun Apr 3 02:31:44 2011 From: David.Holmes at oracle.com (David Holmes) Date: Sun, 03 Apr 2011 19:31:44 +1000 Subject: New protocol for disabling exception suppression In-Reply-To: <4D983956.7040903@univ-mlv.fr> References: <4D967A1C.3060001@oracle.com> <4D97D2C6.2080702@univ-mlv.fr> <4D97DB64.5010107@oracle.com> <4D983956.7040903@univ-mlv.fr> Message-ID: <4D983E80.6030601@oracle.com> R?mi Forax said the following on 04/03/11 19:09: > On 04/03/2011 04:28 AM, David Holmes wrote: >> R?mi Forax said the following on 04/03/11 11:52: >>> On 04/02/2011 03:21 AM, joe.darcy at oracle.com wrote: >>>> As part of the library support for the try-with-resources statement, >>>> several API changes were made to Throwable including an addSuppressed >>>> method to allow suppressed exceptions to be recorded. As previously >>>> discussed on coin-dev [1], to support VM needs for reusable exception >>>> objects, a protocol was devised to disable the suppression mechanism so >>>> that a zero-length array would be returned from getSuppressed even if >>>> addSuppressed was called with a valid argument. The mechanism was a bit >>>> of a kludge, relying on an initial call to addSuppressed with a null >>>> argument, and the design was called out as such. [2] I'm happy to >>>> report >>>> the JSR 334 expert group has devised a more elegant protocol to disable >>>> exception suppression: a new constructor is added to Throwable which >>>> supports disabling suppression. The existing constructors of Throwable >>>> always enable suppression and addSuppressed(null) now always throws a >>>> NullPointerException. A few exception and error types in the platform >>>> are allowed by behave as if their objects were created with suppression >>>> disabled. >>>> >>>> The fix was recently pushed [3] and will appear in a future JDK 7 >>>> build. >>>> >>>> -Joe >>>> >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/coin-dev/2010-August/002830.html >>>> [2] >>>> http://mail.openjdk.java.net/pipermail/coin-dev/2010-October/thread.html#2920 >>>> >>>> [3] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/856cc9e97aea >>>> >>> >>> So the code of the VM was changed to call the constructor if it exists ? >> >> No. The VM never calls a constructor it just allocates zeroed memory - >> which has the same affect as calling the new constructor. >> > > So I don't see the improvement ? The improvement is that you no longer have the "hack" whereby calling addSuppressed(null) is interpreted as meaning "disable addSuppressed". Now suppression is enabled by default, unless this new constructor is used, or it is a VM created exception instance which acts as-if the new constructor had been used. Just makes the semantics for addSuppressed cleaner and simpler. David From forax at univ-mlv.fr Sun Apr 3 02:32:15 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 03 Apr 2011 11:32:15 +0200 Subject: New protocol for disabling exception suppression In-Reply-To: <4D983E80.6030601@oracle.com> References: <4D967A1C.3060001@oracle.com> <4D97D2C6.2080702@univ-mlv.fr> <4D97DB64.5010107@oracle.com> <4D983956.7040903@univ-mlv.fr> <4D983E80.6030601@oracle.com> Message-ID: <4D983E9F.8020609@univ-mlv.fr> On 04/03/2011 11:31 AM, David Holmes wrote: > R?mi Forax said the following on 04/03/11 19:09: >> On 04/03/2011 04:28 AM, David Holmes wrote: >>> R?mi Forax said the following on 04/03/11 11:52: >>>> On 04/02/2011 03:21 AM, joe.darcy at oracle.com wrote: >>>>> As part of the library support for the try-with-resources statement, >>>>> several API changes were made to Throwable including an addSuppressed >>>>> method to allow suppressed exceptions to be recorded. As previously >>>>> discussed on coin-dev [1], to support VM needs for reusable exception >>>>> objects, a protocol was devised to disable the suppression >>>>> mechanism so >>>>> that a zero-length array would be returned from getSuppressed even if >>>>> addSuppressed was called with a valid argument. The mechanism was >>>>> a bit >>>>> of a kludge, relying on an initial call to addSuppressed with a null >>>>> argument, and the design was called out as such. [2] I'm happy to >>>>> report >>>>> the JSR 334 expert group has devised a more elegant protocol to >>>>> disable >>>>> exception suppression: a new constructor is added to Throwable which >>>>> supports disabling suppression. The existing constructors of >>>>> Throwable >>>>> always enable suppression and addSuppressed(null) now always throws a >>>>> NullPointerException. A few exception and error types in the platform >>>>> are allowed by behave as if their objects were created with >>>>> suppression >>>>> disabled. >>>>> >>>>> The fix was recently pushed [3] and will appear in a future JDK 7 >>>>> build. >>>>> >>>>> -Joe >>>>> >>>>> [1] >>>>> http://mail.openjdk.java.net/pipermail/coin-dev/2010-August/002830.html >>>>> >>>>> [2] >>>>> http://mail.openjdk.java.net/pipermail/coin-dev/2010-October/thread.html#2920 >>>>> >>>>> [3] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/856cc9e97aea >>>>> >>>> >>>> So the code of the VM was changed to call the constructor if it >>>> exists ? >>> >>> No. The VM never calls a constructor it just allocates zeroed memory >>> - which has the same affect as calling the new constructor. >>> >> >> So I don't see the improvement ? > > The improvement is that you no longer have the "hack" whereby calling > addSuppressed(null) is interpreted as meaning "disable addSuppressed". > Now suppression is enabled by default, unless this new constructor is > used, or it is a VM created exception instance which acts as-if the > new constructor had been used. Just makes the semantics for > addSuppressed cleaner and simpler. Ok, got it. Thanks. > > David R?mi From neal at gafter.com Sun Apr 3 08:43:35 2011 From: neal at gafter.com (Neal Gafter) Date: Sun, 3 Apr 2011 08:43:35 -0700 Subject: New protocol for disabling exception suppression In-Reply-To: <4D967A1C.3060001@oracle.com> References: <4D967A1C.3060001@oracle.com> Message-ID: The mechanism for adding suppressed exceptions does not appear to be thread-safe. Since this introduces a way in which exceptions used to be thread-safe but no longer are thread-safe, this might require significant nonlocal refactoring of existing code in order to use the new try-with-resources statement. On Friday, April 1, 2011, wrote: > As part of the library support for the try-with-resources statement, > several API changes were made to Throwable including an addSuppressed > method to allow suppressed exceptions to be recorded. As previously > discussed on coin-dev [1], to support VM needs for reusable exception > objects, a protocol was devised to disable the suppression mechanism so > that a zero-length array would be returned from getSuppressed even if > addSuppressed was called with a valid argument. The mechanism was a bit > of a kludge, relying on an initial call to addSuppressed with a null > argument, and the design was called out as such. [2] I'm happy to report > the JSR 334 expert group has devised a more elegant protocol to disable > exception suppression: a new constructor is added to Throwable which > supports disabling suppression. The existing constructors of Throwable > always enable suppression and addSuppressed(null) now always throws a > NullPointerException. A few exception and error types in the platform > are allowed by behave as if their objects were created with suppression > disabled. > > The fix was recently pushed [3] and will appear in a future JDK 7 build. > > -Joe > > [1] http://mail.openjdk.java.net/pipermail/coin-dev/2010-August/002830.html > [2] > http://mail.openjdk.java.net/pipermail/coin-dev/2010-October/thread.html#2920 > [3] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/856cc9e97aea > > > From forax at univ-mlv.fr Sun Apr 3 09:11:29 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 03 Apr 2011 18:11:29 +0200 Subject: New protocol for disabling exception suppression In-Reply-To: References: <4D967A1C.3060001@oracle.com> Message-ID: <4D989C31.4020507@univ-mlv.fr> On 04/03/2011 05:43 PM, Neal Gafter wrote: > The mechanism for adding suppressed exceptions does not appear to be > thread-safe. Why do you claim that ? It's thread-safe like initCause is thread-safe. > Since this introduces a way in which exceptions used to > be thread-safe but no longer are thread-safe, this might require > significant nonlocal refactoring of existing code in order to use the > new try-with-resources statement. Exceptions are still thread-safe. R?mi From forax at univ-mlv.fr Sun Apr 3 11:18:56 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 03 Apr 2011 20:18:56 +0200 Subject: New protocol for disabling exception suppression In-Reply-To: <4D967A1C.3060001@oracle.com> References: <4D967A1C.3060001@oracle.com> Message-ID: <4D98BA10.40303@univ-mlv.fr> On 04/02/2011 03:21 AM, joe.darcy at oracle.com wrote: > As part of the library support for the try-with-resources statement, > several API changes were made to Throwable including an addSuppressed > method to allow suppressed exceptions to be recorded. As previously > discussed on coin-dev [1], to support VM needs for reusable exception > objects, a protocol was devised to disable the suppression mechanism so > that a zero-length array would be returned from getSuppressed even if > addSuppressed was called with a valid argument. The mechanism was a bit > of a kludge, relying on an initial call to addSuppressed with a null > argument, and the design was called out as such. [2] I'm happy to report > the JSR 334 expert group has devised a more elegant protocol to disable > exception suppression: a new constructor is added to Throwable which > supports disabling suppression. The existing constructors of Throwable > always enable suppression and addSuppressed(null) now always throws a > NullPointerException. A few exception and error types in the platform > are allowed by behave as if their objects were created with suppression > disabled. > > The fix was recently pushed [3] and will appear in a future JDK 7 build. > > -Joe Reading the corresponding javadoc, I've found that the constructor is protected. In my opinon, it should be public. All the other constructors are public, you can instantiate a Throwable but if you want a Throwable that don't store suppressed exceptions, you have to subclass it. I don't understand the rational of this decision. > [1] http://mail.openjdk.java.net/pipermail/coin-dev/2010-August/002830.html > [2] > http://mail.openjdk.java.net/pipermail/coin-dev/2010-October/thread.html#2920 > [3] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/856cc9e97aea R?mi From neal at gafter.com Sun Apr 3 13:11:13 2011 From: neal at gafter.com (Neal Gafter) Date: Sun, 3 Apr 2011 13:11:13 -0700 Subject: New protocol for disabling exception suppression In-Reply-To: <4D989C31.4020507@univ-mlv.fr> References: <4D967A1C.3060001@oracle.com> <4D989C31.4020507@univ-mlv.fr> Message-ID: ArrayList.add is used to add suppressed exceptions but that is not thread-safe. On Sunday, April 3, 2011, R?mi Forax wrote: > On 04/03/2011 05:43 PM, Neal Gafter wrote: >> The mechanism for adding suppressed exceptions does not appear to be >> thread-safe. > > Why do you claim that ? > It's thread-safe like initCause is thread-safe. > >> Since this introduces a way in which exceptions used to >> be thread-safe but no longer are thread-safe, this might require >> significant nonlocal refactoring of existing code in order to use the >> new try-with-resources statement. > > Exceptions are still thread-safe. > > R?mi > > > From forax at univ-mlv.fr Sun Apr 3 13:21:03 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 03 Apr 2011 22:21:03 +0200 Subject: New protocol for disabling exception suppression In-Reply-To: References: <4D967A1C.3060001@oracle.com> <4D989C31.4020507@univ-mlv.fr> Message-ID: <4D98D6AF.2060205@univ-mlv.fr> On 04/03/2011 10:11 PM, Neal Gafter wrote: > ArrayList.add is used to add suppressed exceptions but that is not thread-safe. but ArrayList.add() is done under a monitor on this or in readResolve ?? R?mi > On Sunday, April 3, 2011, R?mi Forax wrote: >> On 04/03/2011 05:43 PM, Neal Gafter wrote: >>> The mechanism for adding suppressed exceptions does not appear to be >>> thread-safe. >> Why do you claim that ? >> It's thread-safe like initCause is thread-safe. >> >>> Since this introduces a way in which exceptions used to >>> be thread-safe but no longer are thread-safe, this might require >>> significant nonlocal refactoring of existing code in order to use the >>> new try-with-resources statement. >> Exceptions are still thread-safe. >> >> R?mi >> >> >> From brucechapman at paradise.net.nz Sun Apr 3 14:29:12 2011 From: brucechapman at paradise.net.nz (brucechapman at paradise.net.nz) Date: Mon, 04 Apr 2011 09:29:12 +1200 (NZST) Subject: New protocol for disabling exception suppression In-Reply-To: <4D98BA10.40303@univ-mlv.fr> References: <4D967A1C.3060001@oracle.com> <4D98BA10.40303@univ-mlv.fr> Message-ID: <1301866152.4d98e6a8203af@www.paradise.net.nz> Quoting R?mi Forax : > On 04/02/2011 03:21 AM, joe.darcy at oracle.com wrote: > > As part of the library support for the try-with-resources statement, > > several API changes were made to Throwable including an addSuppressed > > method to allow suppressed exceptions to be recorded. As previously > > discussed on coin-dev [1], to support VM needs for reusable exception > > objects, a protocol was devised to disable the suppression mechanism > so > > that a zero-length array would be returned from getSuppressed even if > > addSuppressed was called with a valid argument. The mechanism was a > bit > > of a kludge, relying on an initial call to addSuppressed with a null > > argument, and the design was called out as such. [2] I'm happy to > report > > the JSR 334 expert group has devised a more elegant protocol to > disable > > exception suppression: a new constructor is added to Throwable which > > supports disabling suppression. The existing constructors of > Throwable > > always enable suppression and addSuppressed(null) now always throws a > > NullPointerException. A few exception and error types in the platform > > are allowed by behave as if their objects were created with > suppression > > disabled. > > > > The fix was recently pushed [3] and will appear in a future JDK 7 > build. > > > > -Joe > > Reading the corresponding javadoc, > I've found that the constructor is protected. In my opinon, it should > be public. All the other constructors are public, you can instantiate > a Throwable but if you want a Throwable that don't store > suppressed exceptions, you have to subclass it. > I don't understand the rational of this decision. This makes it non trivial to ignore suppressed exceptions - which is (IMHO) a good thing. If you have extraordinary circumstances where it is necessary to ignore suppressed exceptions (such as VM Out of memory) then this restriction will not be onerous. If it is onerous, then probably you should not be trying to ignore supressed exceptions. Do you have a use case that justifies ignoring supressed exceptions for an existing subclass of Throwable that cannot be simply subclassed in order to achieve ignoring suppressed exceptions? Bruce > > > [1] > http://mail.openjdk.java.net/pipermail/coin-dev/2010-August/002830.html > > [2] > > > http://mail.openjdk.java.net/pipermail/coin-dev/2010-October/thread.html#2920 > > [3] http://hg.openjdk.java.net/jdk7/tl/jdk/rev/856cc9e97aea > > R?mi > > > From forax at univ-mlv.fr Sun Apr 3 14:42:00 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 03 Apr 2011 23:42:00 +0200 Subject: New protocol for disabling exception suppression In-Reply-To: <1301866152.4d98e6a8203af@www.paradise.net.nz> References: <4D967A1C.3060001@oracle.com> <4D98BA10.40303@univ-mlv.fr> <1301866152.4d98e6a8203af@www.paradise.net.nz> Message-ID: <4D98E9A8.5010500@univ-mlv.fr> On 04/03/2011 11:29 PM, brucechapman at paradise.net.nz wrote: > Quoting R?mi Forax: > >> On 04/02/2011 03:21 AM, joe.darcy at oracle.com wrote: >>> As part of the library support for the try-with-resources statement, >>> several API changes were made to Throwable including an addSuppressed >>> method to allow suppressed exceptions to be recorded. As previously >>> discussed on coin-dev [1], to support VM needs for reusable exception >>> objects, a protocol was devised to disable the suppression mechanism >> so >>> that a zero-length array would be returned from getSuppressed even if >>> addSuppressed was called with a valid argument. The mechanism was a >> bit >>> of a kludge, relying on an initial call to addSuppressed with a null >>> argument, and the design was called out as such. [2] I'm happy to >> report >>> the JSR 334 expert group has devised a more elegant protocol to >> disable >>> exception suppression: a new constructor is added to Throwable which >>> supports disabling suppression. The existing constructors of >> Throwable >>> always enable suppression and addSuppressed(null) now always throws a >>> NullPointerException. A few exception and error types in the platform >>> are allowed by behave as if their objects were created with >> suppression >>> disabled. >>> >>> The fix was recently pushed [3] and will appear in a future JDK 7 >> build. >>> -Joe >> Reading the corresponding javadoc, >> I've found that the constructor is protected. In my opinon, it should >> be public. All the other constructors are public, you can instantiate >> a Throwable but if you want a Throwable that don't store >> suppressed exceptions, you have to subclass it. >> I don't understand the rational of this decision. > This makes it non trivial to ignore suppressed exceptions - which is (IMHO) a > good thing. If you have extraordinary circumstances where it is necessary to > ignore suppressed exceptions (such as VM Out of memory) then this restriction > will not be onerous. If it is onerous, then probably you should not be trying to > ignore supressed exceptions. It's not that extraordinary if you write language runtimes :) I use to use exceptions to jump back in the control flow when by example you jump from a compiled code (in bytecode) back to the interpreter (of the language). In that case, I don't want to create a subclass if I can create a Throwable once and reuse it. But if I want to be able to reuse it, it should not be able to collect suppressed exceptions. > Do you have a use case that justifies ignoring supressed exceptions for an > existing subclass of Throwable that cannot be simply subclassed in order to > achieve ignoring suppressed exceptions? see above. But anyway, the real question is why I can't create a Thowable that doesn't collect suppressed exceptions. Is Throwable a second order citizen ? > Bruce R?mi From brucechapman at paradise.net.nz Sun Apr 3 14:54:16 2011 From: brucechapman at paradise.net.nz (brucechapman at paradise.net.nz) Date: Mon, 04 Apr 2011 09:54:16 +1200 (NZST) Subject: New protocol for disabling exception suppression In-Reply-To: References: <4D967A1C.3060001@oracle.com> <4D989C31.4020507@univ-mlv.fr> Message-ID: <1301867656.4d98ec887df06@www.paradise.net.nz> Quoting Neal Gafter : > ArrayList.add is used to add suppressed exceptions but that is not > thread-safe. True, but is that anything more than theoretical, given that for the thread-unsafeness to be a problem, two threads would need access to the Throwable? While I am sure that situation could easily be contrived in a test, I can't see it happening in practice, except where multiple threads are throwing the same instance of an exception, and that is one of the cases where ignoring suppressed exceptions would be expected. On the other hand, I do have code that re-uses an exception (for flow control to achieve backtrack in a large lookahead parsing situation), and maybe the ignore suppressed functionality should be a little more obviously highlighted as very appropriate (necessary) to this situation. Otherwise if that re-used exception instance happens to pass through a t-w-r construct, it could keep having more and more suppressed exceptions added to it, so in a long running app, none of these suppressed exceptions can be garbage collected. This is not necessarily a thread safety issue but is a potential 'memory leak'. Bruce > > On Sunday, April 3, 2011, R?mi Forax wrote: > > On 04/03/2011 05:43 PM, Neal Gafter wrote: > >> The mechanism for adding suppressed exceptions does not appear to be > >> thread-safe. > > > > Why do you claim that ? > > It's thread-safe like initCause is thread-safe. > > > >> Since this introduces a way in which exceptions used to > >> be thread-safe but no longer are thread-safe, this might require > >> significant nonlocal refactoring of existing code in order to use > the > >> new try-with-resources statement. > > > > Exceptions are still thread-safe. > > > > R?mi > > > > > > > > From brucechapman at paradise.net.nz Sun Apr 3 15:11:03 2011 From: brucechapman at paradise.net.nz (brucechapman at paradise.net.nz) Date: Mon, 04 Apr 2011 10:11:03 +1200 (NZST) Subject: New protocol for disabling exception suppression In-Reply-To: <4D98E9A8.5010500@univ-mlv.fr> References: <4D967A1C.3060001@oracle.com> <4D98BA10.40303@univ-mlv.fr> <1301866152.4d98e6a8203af@www.paradise.net.nz> <4D98E9A8.5010500@univ-mlv.fr> Message-ID: <1301868663.4d98f07780b91@www.paradise.net.nz> Quoting R?mi Forax : > On 04/03/2011 11:29 PM, brucechapman at paradise.net.nz wrote: > > Quoting R?mi Forax: > > > >> On 04/02/2011 03:21 AM, joe.darcy at oracle.com wrote: > >>> As part of the library support for the try-with-resources > statement, > >>> several API changes were made to Throwable including an > addSuppressed > >>> method to allow suppressed exceptions to be recorded. As previously > >>> discussed on coin-dev [1], to support VM needs for reusable > exception > >>> objects, a protocol was devised to disable the suppression > mechanism > >> so > >>> that a zero-length array would be returned from getSuppressed even > if > >>> addSuppressed was called with a valid argument. The mechanism was a > >> bit > >>> of a kludge, relying on an initial call to addSuppressed with a > null > >>> argument, and the design was called out as such. [2] I'm happy to > >> report > >>> the JSR 334 expert group has devised a more elegant protocol to > >> disable > >>> exception suppression: a new constructor is added to Throwable > which > >>> supports disabling suppression. The existing constructors of > >> Throwable > >>> always enable suppression and addSuppressed(null) now always throws > a > >>> NullPointerException. A few exception and error types in the > platform > >>> are allowed by behave as if their objects were created with > >> suppression > >>> disabled. > >>> > >>> The fix was recently pushed [3] and will appear in a future JDK 7 > >> build. > >>> -Joe > >> Reading the corresponding javadoc, > >> I've found that the constructor is protected. In my opinon, it > should > >> be public. All the other constructors are public, you can > instantiate > >> a Throwable but if you want a Throwable that don't store > >> suppressed exceptions, you have to subclass it. > >> I don't understand the rational of this decision. > > This makes it non trivial to ignore suppressed exceptions - which is > (IMHO) a > > good thing. If you have extraordinary circumstances where it is > necessary to > > ignore suppressed exceptions (such as VM Out of memory) then this > restriction > > will not be onerous. If it is onerous, then probably you should not be > trying to > > ignore supressed exceptions. > > It's not that extraordinary if you write language runtimes :) > I use to use exceptions to jump back in the control flow when by > example you jump from a compiled code (in bytecode) back to > the interpreter (of the language). > In that case, I don't want to create a subclass if I can create a > Throwable > once and reuse it. > But if I want to be able to reuse it, it should not be able to collect > suppressed exceptions. > > > Do you have a use case that justifies ignoring supressed exceptions > for an > > existing subclass of Throwable that cannot be simply subclassed in > order to > > achieve ignoring suppressed exceptions? > > see above. > But anyway, the real question is why I can't create a Thowable that > doesn't collect > suppressed exceptions. Is Throwable a second order citizen ? Yes in a way it is second order. If it is a Throwable (rather than a subclass) then you are saying it is not an Error, and it is not an Exception, and it is not a RuntimeException! So what is it? Maybe there should be some new top level form of Throwable for these reusable flow control situations which we both have. maybe a checked form, and an unchecked form of it? Those two could then be made to do the right thing, possibly even not having a stacktrace! If it was checked tho' I'd want to subclass it so that my throws clauses used my own name, not 'ReusableFlowControlException' or whatever it might be called. Bruce > > > Bruce > > R?mi > > From forax at univ-mlv.fr Sun Apr 3 15:26:20 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 04 Apr 2011 00:26:20 +0200 Subject: New protocol for disabling exception suppression In-Reply-To: <1301868663.4d98f07780b91@www.paradise.net.nz> References: <4D967A1C.3060001@oracle.com> <4D98BA10.40303@univ-mlv.fr> <1301866152.4d98e6a8203af@www.paradise.net.nz> <4D98E9A8.5010500@univ-mlv.fr> <1301868663.4d98f07780b91@www.paradise.net.nz> Message-ID: <4D98F40C.5030200@univ-mlv.fr> On 04/04/2011 12:11 AM, brucechapman at paradise.net.nz wrote: > Yes in a way it is second order. If it is a Throwable (rather than a subclass) > then you are saying it is not an Error, and it is not an Exception, and it is > not a RuntimeException! So what is it? First, from the JLS point of view, exception are defined in term of Throwable. The class j.l.Exception is not the root of all checked exceptions, it's j.l.Throwable. j.l.Throwable is not an abstract class. So Throwable was not a second order citizen until recently. R?mi From David.Holmes at oracle.com Sun Apr 3 15:34:18 2011 From: David.Holmes at oracle.com (David Holmes) Date: Mon, 04 Apr 2011 08:34:18 +1000 Subject: New protocol for disabling exception suppression In-Reply-To: <4D98F40C.5030200@univ-mlv.fr> References: <4D967A1C.3060001@oracle.com> <4D98BA10.40303@univ-mlv.fr> <1301866152.4d98e6a8203af@www.paradise.net.nz> <4D98E9A8.5010500@univ-mlv.fr> <1301868663.4d98f07780b91@www.paradise.net.nz> <4D98F40C.5030200@univ-mlv.fr> Message-ID: <4D98F5EA.2080409@oracle.com> R?mi Forax said the following on 04/04/11 08:26: > On 04/04/2011 12:11 AM, brucechapman at paradise.net.nz wrote: >> Yes in a way it is second order. If it is a Throwable (rather than a subclass) >> then you are saying it is not an Error, and it is not an Exception, and it is >> not a RuntimeException! So what is it? > > First, from the JLS point of view, exception are defined in term of > Throwable. > The class j.l.Exception is not the root of all checked exceptions, > it's j.l.Throwable. > > j.l.Throwable is not an abstract class. So Throwable was not > a second order citizen until recently. Personally I don't have an issue with the new constructor being public. But I don't expect anyone to create a direct instance of Throwable in any realistic/practical situation. David From forax at univ-mlv.fr Sun Apr 3 15:44:19 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 04 Apr 2011 00:44:19 +0200 Subject: New protocol for disabling exception suppression In-Reply-To: <4D98F5EA.2080409@oracle.com> References: <4D967A1C.3060001@oracle.com> <4D98BA10.40303@univ-mlv.fr> <1301866152.4d98e6a8203af@www.paradise.net.nz> <4D98E9A8.5010500@univ-mlv.fr> <1301868663.4d98f07780b91@www.paradise.net.nz> <4D98F40C.5030200@univ-mlv.fr> <4D98F5EA.2080409@oracle.com> Message-ID: <4D98F843.5030903@univ-mlv.fr> On 04/04/2011 12:34 AM, David Holmes wrote: > R?mi Forax said the following on 04/04/11 08:26: >> On 04/04/2011 12:11 AM, brucechapman at paradise.net.nz wrote: >>> Yes in a way it is second order. If it is a Throwable (rather than a >>> subclass) >>> then you are saying it is not an Error, and it is not an Exception, >>> and it is >>> not a RuntimeException! So what is it? >> >> First, from the JLS point of view, exception are defined in term of >> Throwable. >> The class j.l.Exception is not the root of all checked exceptions, >> it's j.l.Throwable. >> >> j.l.Throwable is not an abstract class. So Throwable was not >> a second order citizen until recently. > > Personally I don't have an issue with the new constructor being > public. But I don't expect anyone to create a direct instance of > Throwable in any realistic/practical situation. Anyone never think like anyone else. > > David R?mi From neal at gafter.com Sun Apr 3 16:51:08 2011 From: neal at gafter.com (Neal Gafter) Date: Sun, 3 Apr 2011 16:51:08 -0700 Subject: New protocol for disabling exception suppression In-Reply-To: <4D98D6AF.2060205@univ-mlv.fr> References: <4D967A1C.3060001@oracle.com> <4D989C31.4020507@univ-mlv.fr> <4D98D6AF.2060205@univ-mlv.fr> Message-ID: Good point. I missed that. -Neal On Sun, Apr 3, 2011 at 1:21 PM, R?mi Forax wrote: > On 04/03/2011 10:11 PM, Neal Gafter wrote: > >> ArrayList.add is used to add suppressed exceptions but that is not >> thread-safe. >> > > but ArrayList.add() is done under a monitor on this or in readResolve ?? > > R?mi > > > On Sunday, April 3, 2011, R?mi Forax wrote: >> >>> On 04/03/2011 05:43 PM, Neal Gafter wrote: >>> >>>> The mechanism for adding suppressed exceptions does not appear to be >>>> thread-safe. >>>> >>> Why do you claim that ? >>> It's thread-safe like initCause is thread-safe. >>> >>> Since this introduces a way in which exceptions used to >>>> be thread-safe but no longer are thread-safe, this might require >>>> significant nonlocal refactoring of existing code in order to use the >>>> new try-with-resources statement. >>>> >>> Exceptions are still thread-safe. >>> >>> R?mi >>> >>> >>> >>> > From joe.darcy at oracle.com Sun Apr 3 22:22:14 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 03 Apr 2011 22:22:14 -0700 Subject: New protocol for disabling exception suppression In-Reply-To: References: <4D967A1C.3060001@oracle.com> <4D989C31.4020507@univ-mlv.fr> <4D98D6AF.2060205@univ-mlv.fr> Message-ID: <4D995586.1090100@oracle.com> The suppressedExceptions field is initialized to a nonnull value. The new constructor can set the field to null. The readObject method accesses the field on the reconstituted object; readObject does not need to be synchronized. Both the addSuppressed and getSuppressed methods are synchronized (as well as final). There are no other access to this private field in Throwable. Therefore, I see no thread-safety issues around the suppressedExceptions field in the current implementation. -Joe Neal Gafter wrote: > Good point. I missed that. > > -Neal > > On Sun, Apr 3, 2011 at 1:21 PM, R?mi Forax wrote: > > >> On 04/03/2011 10:11 PM, Neal Gafter wrote: >> >> >>> ArrayList.add is used to add suppressed exceptions but that is not >>> thread-safe. >>> >>> >> but ArrayList.add() is done under a monitor on this or in readResolve ?? >> >> R?mi >> >> >> On Sunday, April 3, 2011, R?mi Forax wrote: >> >>>> On 04/03/2011 05:43 PM, Neal Gafter wrote: >>>> >>>> >>>>> The mechanism for adding suppressed exceptions does not appear to be >>>>> thread-safe. >>>>> >>>>> >>>> Why do you claim that ? >>>> It's thread-safe like initCause is thread-safe. >>>> >>>> Since this introduces a way in which exceptions used to >>>> >>>>> be thread-safe but no longer are thread-safe, this might require >>>>> significant nonlocal refactoring of existing code in order to use the >>>>> new try-with-resources statement. >>>>> >>>>> >>>> Exceptions are still thread-safe. >>>> >>>> R?mi >>>> >>>> >>>> >>>> >>>> > > From joe.darcy at oracle.com Sun Apr 3 22:31:44 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 03 Apr 2011 22:31:44 -0700 Subject: New protocol for disabling exception suppression In-Reply-To: <4D98BA10.40303@univ-mlv.fr> References: <4D967A1C.3060001@oracle.com> <4D98BA10.40303@univ-mlv.fr> Message-ID: <4D9957C0.6030501@oracle.com> R?mi Forax wrote: > On 04/02/2011 03:21 AM, joe.darcy at oracle.com wrote: > >> As part of the library support for the try-with-resources statement, >> several API changes were made to Throwable including an addSuppressed >> method to allow suppressed exceptions to be recorded. As previously >> discussed on coin-dev [1], to support VM needs for reusable exception >> objects, a protocol was devised to disable the suppression mechanism so >> that a zero-length array would be returned from getSuppressed even if >> addSuppressed was called with a valid argument. The mechanism was a bit >> of a kludge, relying on an initial call to addSuppressed with a null >> argument, and the design was called out as such. [2] I'm happy to report >> the JSR 334 expert group has devised a more elegant protocol to disable >> exception suppression: a new constructor is added to Throwable which >> supports disabling suppression. The existing constructors of Throwable >> always enable suppression and addSuppressed(null) now always throws a >> NullPointerException. A few exception and error types in the platform >> are allowed by behave as if their objects were created with suppression >> disabled. >> >> The fix was recently pushed [3] and will appear in a future JDK 7 build. >> >> -Joe >> > > Reading the corresponding javadoc, > I've found that the constructor is protected. That was intentional. > In my opinon, it should > be public. All the other constructors are public, you can instantiate > a Throwable but if you want a Throwable that don't store > suppressed exceptions, you have to subclass it. > I don't understand the rational of this decision. > > Disabling suppression is a niche capability. It does not need to be made as easy to use as other capabilities of Throwable. If a need arises to make the new constructor public, that can be done compatibly in a future release. -Joe From forax at univ-mlv.fr Mon Apr 4 01:54:01 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 04 Apr 2011 10:54:01 +0200 Subject: New protocol for disabling exception suppression In-Reply-To: <4D9957C0.6030501@oracle.com> References: <4D967A1C.3060001@oracle.com> <4D98BA10.40303@univ-mlv.fr> <4D9957C0.6030501@oracle.com> Message-ID: <4D998729.5040903@univ-mlv.fr> [...] >> >> Reading the corresponding javadoc, >> I've found that the constructor is protected. > > That was intentional. I know. You aren't a student anymore. But I think this intention is not well grounded. > >> In my opinon, it should >> be public. All the other constructors are public, you can instantiate >> a Throwable but if you want a Throwable that don't store >> suppressed exceptions, you have to subclass it. >> I don't understand the rational of this decision. >> > > Disabling suppression is a niche capability. It does not need to be > made as easy to use as other capabilities of Throwable. If a need > arises to make the new constructor public, that can be done compatibly > in a future release. Why not now ? Again, why Throwable has to be different from one of it's subclass. > > -Joe R?mi From joe.darcy at oracle.com Mon Apr 4 10:52:38 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 04 Apr 2011 10:52:38 -0700 Subject: New protocol for disabling exception suppression In-Reply-To: <4D998729.5040903@univ-mlv.fr> References: <4D967A1C.3060001@oracle.com> <4D98BA10.40303@univ-mlv.fr> <4D9957C0.6030501@oracle.com> <4D998729.5040903@univ-mlv.fr> Message-ID: <4D9A0566.90902@oracle.com> Hi Remi. R?mi Forax wrote: > [...] > >>> >>> Reading the corresponding javadoc, >>> I've found that the constructor is protected. >> >> That was intentional. > > I know. You aren't a student anymore. That doesn't mean I don't make mistakes from time to time ;-) > But I think this intention is not well grounded. > >> >>> In my opinon, it should >>> be public. All the other constructors are public, you can instantiate >>> a Throwable but if you want a Throwable that don't store >>> suppressed exceptions, you have to subclass it. >>> I don't understand the rational of this decision. >>> >> >> Disabling suppression is a niche capability. It does not need to be >> made as easy to use as other capabilities of Throwable. If a need >> arises to make the new constructor public, that can be done >> compatibly in a future release. > > Why not now ? > Again, why Throwable has to be different from one of it's subclass. > This capability does not need to be used widely; in particular, I don't think it needs to be used on instantiations of Throwable objects. Any subclass of Throwable can disable exceptions so the only behavioral difference between having this constructor public and protected is that that objects where getClass == Throwable cannot have exception suppression disabled. -Joe From forax at univ-mlv.fr Mon Apr 4 11:33:31 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 04 Apr 2011 20:33:31 +0200 Subject: New protocol for disabling exception suppression In-Reply-To: <4D9A0566.90902@oracle.com> References: <4D967A1C.3060001@oracle.com> <4D98BA10.40303@univ-mlv.fr> <4D9957C0.6030501@oracle.com> <4D998729.5040903@univ-mlv.fr> <4D9A0566.90902@oracle.com> Message-ID: <4D9A0EFB.6070207@univ-mlv.fr> On 04/04/2011 07:52 PM, Joe Darcy wrote: > Hi Remi. > > R?mi Forax wrote: >> [...] >> >>>> >>>> Reading the corresponding javadoc, >>>> I've found that the constructor is protected. >>> >>> That was intentional. >> >> I know. You aren't a student anymore. > > That doesn't mean I don't make mistakes from time to time ;-) > >> But I think this intention is not well grounded. >> >>> >>>> In my opinon, it should >>>> be public. All the other constructors are public, you can instantiate >>>> a Throwable but if you want a Throwable that don't store >>>> suppressed exceptions, you have to subclass it. >>>> I don't understand the rational of this decision. >>>> >>> >>> Disabling suppression is a niche capability. It does not need to be >>> made as easy to use as other capabilities of Throwable. If a need >>> arises to make the new constructor public, that can be done >>> compatibly in a future release. >> >> Why not now ? >> Again, why Throwable has to be different from one of it's subclass. >> > > This capability does not need to be used widely; in particular, I > don't think it needs to be used on instantiations of Throwable > objects. Any subclass of Throwable can disable exceptions so the only > behavioral difference between having this constructor public and > protected is that that objects where getClass == Throwable cannot have > exception suppression disabled. Yes, this is a small corner case and yes perhaps never someone will create a Throwable with exception suppression disabled. But those who design Throwable had thunk that create a Throwable with new make sense, so for completeness one should be able to create a Throwable with exception suppression disabled. By declaring the constructor as protected you add a special rule, you increase the entropy of the Throwable API without, in my opinion, any benefit. > > -Joe R?mi From joe.darcy at oracle.com Mon Apr 4 19:41:34 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 04 Apr 2011 19:41:34 -0700 Subject: New protocol for disabling exception suppression In-Reply-To: <4D9A0EFB.6070207@univ-mlv.fr> References: <4D967A1C.3060001@oracle.com> <4D98BA10.40303@univ-mlv.fr> <4D9957C0.6030501@oracle.com> <4D998729.5040903@univ-mlv.fr> <4D9A0566.90902@oracle.com> <4D9A0EFB.6070207@univ-mlv.fr> Message-ID: <4D9A815E.7090809@oracle.com> On 4/4/2011 11:33 AM, R?mi Forax wrote: > On 04/04/2011 07:52 PM, Joe Darcy wrote: >> Hi Remi. >> >> R?mi Forax wrote: >>> [...] >>> >>>>> >>>>> Reading the corresponding javadoc, >>>>> I've found that the constructor is protected. >>>> >>>> That was intentional. >>> >>> I know. You aren't a student anymore. >> >> That doesn't mean I don't make mistakes from time to time ;-) >> >>> But I think this intention is not well grounded. >>> >>>> >>>>> In my opinon, it should >>>>> be public. All the other constructors are public, you can instantiate >>>>> a Throwable but if you want a Throwable that don't store >>>>> suppressed exceptions, you have to subclass it. >>>>> I don't understand the rational of this decision. >>>>> >>>> >>>> Disabling suppression is a niche capability. It does not need to >>>> be made as easy to use as other capabilities of Throwable. If a >>>> need arises to make the new constructor public, that can be done >>>> compatibly in a future release. >>> >>> Why not now ? >>> Again, why Throwable has to be different from one of it's subclass. >>> >> >> This capability does not need to be used widely; in particular, I >> don't think it needs to be used on instantiations of Throwable >> objects. Any subclass of Throwable can disable exceptions so the >> only behavioral difference between having this constructor public and >> protected is that that objects where getClass == Throwable cannot >> have exception suppression disabled. > > Yes, this is a small corner case and yes perhaps never someone will > create a Throwable with exception suppression disabled. > But those who design Throwable had thunk that create a Throwable with > new make sense, so for completeness > one should be able to create a Throwable with exception suppression > disabled. > > By declaring the constructor as protected you add a special rule, you > increase the entropy of the Throwable API > without, in my opinion, any benefit. > I could see an argument for adding analogous protected constructors to java.lang.{Exception, RuntimeException, Error} to allow non-platform exceptions to control this behavior. However, just as not all exception types have a full complement of the existing four Throwable constructors, very, very few exceptions types need a constructor that allows suppression to be disabled. In particular, there are no plans to go through and retrofit a bunch of these constructors into the majority of the exception types defined in the platform. -Joe From neal at gafter.com Mon Apr 4 21:27:06 2011 From: neal at gafter.com (Neal Gafter) Date: Mon, 4 Apr 2011 21:27:06 -0700 Subject: New protocol for disabling exception suppression In-Reply-To: <4D9A815E.7090809@oracle.com> References: <4D967A1C.3060001@oracle.com> <4D98BA10.40303@univ-mlv.fr> <4D9957C0.6030501@oracle.com> <4D998729.5040903@univ-mlv.fr> <4D9A0566.90902@oracle.com> <4D9A0EFB.6070207@univ-mlv.fr> <4D9A815E.7090809@oracle.com> Message-ID: On Mon, Apr 4, 2011 at 7:41 PM, wrote: > > > On 4/4/2011 11:33 AM, R?mi Forax wrote: > > On 04/04/2011 07:52 PM, Joe Darcy wrote: > >> Hi Remi. > >> > >> R?mi Forax wrote: > >>> [...] > >>> > >>>>> > >>>>> Reading the corresponding javadoc, > >>>>> I've found that the constructor is protected. > >>>> > >>>> That was intentional. > >>> > >>> I know. You aren't a student anymore. > >> > >> That doesn't mean I don't make mistakes from time to time ;-) > >> > >>> But I think this intention is not well grounded. > >>> > >>>> > >>>>> In my opinon, it should > >>>>> be public. All the other constructors are public, you can instantiate > >>>>> a Throwable but if you want a Throwable that don't store > >>>>> suppressed exceptions, you have to subclass it. > >>>>> I don't understand the rational of this decision. > >>>>> > >>>> > >>>> Disabling suppression is a niche capability. It does not need to > >>>> be made as easy to use as other capabilities of Throwable. If a > >>>> need arises to make the new constructor public, that can be done > >>>> compatibly in a future release. > >>> > >>> Why not now ? > >>> Again, why Throwable has to be different from one of it's subclass. > >>> > >> > >> This capability does not need to be used widely; in particular, I > >> don't think it needs to be used on instantiations of Throwable > >> objects. Any subclass of Throwable can disable exceptions so the > >> only behavioral difference between having this constructor public and > >> protected is that that objects where getClass == Throwable cannot > >> have exception suppression disabled. > > > > Yes, this is a small corner case and yes perhaps never someone will > > create a Throwable with exception suppression disabled. > > But those who design Throwable had thunk that create a Throwable with > > new make sense, so for completeness > > one should be able to create a Throwable with exception suppression > > disabled. > > > > By declaring the constructor as protected you add a special rule, you > > increase the entropy of the Throwable API > > without, in my opinion, any benefit. > > I could see an argument for adding analogous protected constructors to > java.lang.{Exception, RuntimeException, Error} to allow non-platform > exceptions to control this behavior. However, just as not all exception > types have a full complement of the existing four Throwable > constructors, very, very few exceptions types need a constructor that > allows suppression to be disabled. In particular, there are no plans to > go through and retrofit a bunch of these constructors into the majority > of the exception types defined in the platform. > Your response is a paraphrase of the illogical argument "don't do that, because what if everybody else did". It feels very strange for the API to declare that this feature is reserved for subclasses but forbidden on the base class. You might think it a shame that Throwable has a public constructor to begin with, but a public API is not a nice place to air such grievances. Just saying. From heinz at javaspecialists.eu Mon Apr 4 21:55:34 2011 From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz) Date: Tue, 05 Apr 2011 07:55:34 +0300 Subject: New protocol for disabling exception suppression In-Reply-To: <4D9A0EFB.6070207@univ-mlv.fr> References: <4D967A1C.3060001@oracle.com> <4D98BA10.40303@univ-mlv.fr> <4D9957C0.6030501@oracle.com> <4D998729.5040903@univ-mlv.fr> <4D9A0566.90902@oracle.com> <4D9A0EFB.6070207@univ-mlv.fr> Message-ID: <4D9AA0C6.1050706@javaspecialists.eu> >> This capability does not need to be used widely; in particular, I >> don't think it needs to be used on instantiations of Throwable >> objects. Any subclass of Throwable can disable exceptions so the only >> behavioral difference between having this constructor public and >> protected is that that objects where getClass == Throwable cannot have >> exception suppression disabled. >> > > Yes, this is a small corner case and yes perhaps never someone will > create a Throwable with exception suppression disabled. > But those who design Throwable had thunk that create a Throwable with > new make sense, so for completeness > one should be able to create a Throwable with exception suppression > disabled. > > By declaring the constructor as protected you add a special rule, you > increase the entropy of the Throwable API > without, in my opinion, any benefit. > Hi R?mi, by moving the functionality to the constructor, where it probably belongs, it means that in order for subclasses to be able to turn off the ability to add suppressed exceptions, every single exception in the history of Java needs to have a new constructor (or set of constructors) that take the boolean. In a constructor, I cannot call my super-super-class' constructor directly. This means Exception needs this constructor, and IOException and FileNotFoundException, plus of course all the exceptions that people might have added to their own projects. Kind regards from Crete, where spring has sprung :-) Heinz From neal at gafter.com Mon Apr 4 21:57:50 2011 From: neal at gafter.com (Neal Gafter) Date: Mon, 4 Apr 2011 21:57:50 -0700 Subject: JDK7 language specification issue with MethodHandle Message-ID: Project coin took on the task of specifying language changes related to method handles, invokeDynamic, and other jsr292-related things. In the end project coin's leaders decided not to specify any Java language changes in jdk7 for jsr292. The documentation for MethodHandle (see "Method Handle Compilation" in < http://download.java.net/jdk7/docs/api/java/lang/invoke/MethodHandle.html>) appears to contradict the requirements of the Java Language Specification by describing compiler behavior that does not conform to the requirements of the JLS. I have not checked, but I would not be surprised if jdk7's javac also fails to satisfy the specification in this area. This is the kind of backdoor language change that Java's corporate owner has consistently considered a clear violation of Java trademark licensing requirements. Are there any plans to resolve this? Are the required language changes going into the JLS through some other mechanism? Cheers, Neal From forax at univ-mlv.fr Tue Apr 5 01:24:20 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 05 Apr 2011 10:24:20 +0200 Subject: JDK7 language specification issue with MethodHandle In-Reply-To: References: Message-ID: <4D9AD1B4.7020402@univ-mlv.fr> On 04/05/2011 06:57 AM, Neal Gafter wrote: > Project coin took on the task of specifying language changes related to > method handles, invokeDynamic, and other jsr292-related things. In the end > project coin's leaders decided not to specify any Java language changes in > jdk7 for jsr292. Several JLS changes was proposed. One for invoking method handles, one for specifying constant method handle and an other for invokedynamic. The changes for invokedynamic and constant method handle was delayed due to its interaction with lambda. You're right that these changes was first submitted to coin, but it was latter decided that the only the syntax change implemented in Java 7, invoking a method handle, will be done under JSR 292. > The documentation for MethodHandle (see "Method Handle Compilation" in< > http://download.java.net/jdk7/docs/api/java/lang/invoke/MethodHandle.html>) > appears to contradict the requirements of the Java Language Specification by > describing compiler behavior that does not conform to the requirements of > the JLS. I have not checked, but I would not be surprised if jdk7's javac > also fails to satisfy the specification in this area. This is the kind of > backdoor language change that Java's corporate owner has consistently > considered a clear violation of Java trademark licensing requirements. I don't understand exactly what you mean. Coud you be a little more specific ? > Are there any plans to resolve this? Are the required language changes > going into the JLS through some other mechanism? > > Cheers, > Neal > cheers, R?mi From brucechapman at paradise.net.nz Tue Apr 5 03:00:28 2011 From: brucechapman at paradise.net.nz (Bruce Chapman) Date: Tue, 05 Apr 2011 22:00:28 +1200 Subject: New protocol for disabling exception suppression In-Reply-To: <4D9A815E.7090809@oracle.com> References: <4D967A1C.3060001@oracle.com> <4D98BA10.40303@univ-mlv.fr> <4D9957C0.6030501@oracle.com> <4D998729.5040903@univ-mlv.fr> <4D9A0566.90902@oracle.com> <4D9A0EFB.6070207@univ-mlv.fr> <4D9A815E.7090809@oracle.com> Message-ID: <4D9AE83C.5030402@paradise.net.nz> On 5/04/2011 2:41 p.m., joe.darcy at oracle.com wrote: > I could see an argument for adding analogous protected constructors to > java.lang.{Exception, RuntimeException, Error} to allow non-platform Without analogous constructors I don't think it will be possible to make a checked exception with suppressed disabled. So long as users can make their own checked and unchecked exceptions with suppression disabled that should be enough. Bruce > exceptions to control this behavior. However, just as not all exception > types have a full complement of the existing four Throwable > constructors, very, very few exceptions types need a constructor that > allows suppression to be disabled. In particular, there are no plans to > go through and retrofit a bunch of these constructors into the majority > of the exception types defined in the platform. > > -Joe > > From David.Holmes at oracle.com Tue Apr 5 03:27:22 2011 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 05 Apr 2011 20:27:22 +1000 Subject: New protocol for disabling exception suppression In-Reply-To: <4D9AE83C.5030402@paradise.net.nz> References: <4D967A1C.3060001@oracle.com> <4D98BA10.40303@univ-mlv.fr> <4D9957C0.6030501@oracle.com> <4D998729.5040903@univ-mlv.fr> <4D9A0566.90902@oracle.com> <4D9A0EFB.6070207@univ-mlv.fr> <4D9A815E.7090809@oracle.com> <4D9AE83C.5030402@paradise.net.nz> Message-ID: <4D9AEE8A.20408@oracle.com> Bruce Chapman said the following on 04/05/11 20:00: > On 5/04/2011 2:41 p.m., joe.darcy at oracle.com wrote: >> I could see an argument for adding analogous protected constructors to >> java.lang.{Exception, RuntimeException, Error} to allow non-platform > Without analogous constructors I don't think it will be possible to make > a checked exception with suppressed disabled. Well Throwable is a checked exception. Without analogous constructors users won't be able to make instances of any existing exception types (checked or unchecked) with suppression disabled, but ... > So long as users can make their own checked and unchecked exceptions > with suppression disabled that should be enough. ... the intent was never to provide users with such a facility, but simply to ensure that the actions of the VM were allowed under the specification. David > Bruce >> exceptions to control this behavior. However, just as not all exception >> types have a full complement of the existing four Throwable >> constructors, very, very few exceptions types need a constructor that >> allows suppression to be disabled. In particular, there are no plans to >> go through and retrofit a bunch of these constructors into the majority >> of the exception types defined in the platform. >> >> -Joe >> >> > > From forax at univ-mlv.fr Tue Apr 5 05:24:13 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 05 Apr 2011 14:24:13 +0200 Subject: New protocol for disabling exception suppression In-Reply-To: <4D9AEE8A.20408@oracle.com> References: <4D967A1C.3060001@oracle.com> <4D98BA10.40303@univ-mlv.fr> <4D9957C0.6030501@oracle.com> <4D998729.5040903@univ-mlv.fr> <4D9A0566.90902@oracle.com> <4D9A0EFB.6070207@univ-mlv.fr> <4D9A815E.7090809@oracle.com> <4D9AE83C.5030402@paradise.net.nz> <4D9AEE8A.20408@oracle.com> Message-ID: <4D9B09ED.2040508@univ-mlv.fr> On 04/05/2011 12:27 PM, David Holmes wrote: > Bruce Chapman said the following on 04/05/11 20:00: >> On 5/04/2011 2:41 p.m., joe.darcy at oracle.com wrote: >>> I could see an argument for adding analogous protected constructors to >>> java.lang.{Exception, RuntimeException, Error} to allow non-platform >> Without analogous constructors I don't think it will be possible to make >> a checked exception with suppressed disabled. > Well Throwable is a checked exception. Without analogous constructors > users won't be able to make instances of any existing exception types > (checked or unchecked) with suppression disabled, but ... > >> So long as users can make their own checked and unchecked exceptions >> with suppression disabled that should be enough. > ... the intent was never to provide users with such a facility, but > simply to ensure that the actions of the VM were allowed under the > specification. > > David But one thing that I really like in Java is the fact that the user has a power really similar to the VM. That why JRuby, Jython or Groovy runtime exists, you should not have to be the VM to create a an expression with suppress exceptions disable. So like we have initCause, we should have a method disableSuppressionException. R?mi From neal at gafter.com Tue Apr 5 06:41:04 2011 From: neal at gafter.com (Neal Gafter) Date: Tue, 5 Apr 2011 06:41:04 -0700 Subject: JDK7 language specification issue with MethodHandle In-Reply-To: <4D9AD1B4.7020402@univ-mlv.fr> References: <4D9AD1B4.7020402@univ-mlv.fr> Message-ID: On Tue, Apr 5, 2011 at 1:24 AM, R?mi Forax wrote: > > On 04/05/2011 06:57 AM, Neal Gafter wrote: > > The documentation for MethodHandle (see "Method Handle Compilation" in< > > > http://download.java.net/jdk7/docs/api/java/lang/invoke/MethodHandle.html > >) > > appears to contradict the requirements of the Java Language Specification > by > > describing compiler behavior that does not conform to the requirements of > > the JLS. I have not checked, but I would not be surprised if jdk7's > javac > > also fails to satisfy the specification in this area. This is the kind > of > > backdoor language change that Java's corporate owner has consistently > > considered a clear violation of Java trademark licensing requirements. > > I don't understand exactly what you mean. > Coud you be a little more specific ? > I'm referring to requirements such as not boxing primitives, not building a varargs array, and producing the "wrong" method signature in the invoke instruction. The binary compatibility section of the JLS specifies what method signature to be generated in the invocation, and this documentation specifies another. From forax at univ-mlv.fr Tue Apr 5 07:00:39 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 05 Apr 2011 16:00:39 +0200 Subject: JDK7 language specification issue with MethodHandle In-Reply-To: References: <4D9AD1B4.7020402@univ-mlv.fr> Message-ID: <4D9B2087.3080101@univ-mlv.fr> On 04/05/2011 03:41 PM, Neal Gafter wrote: > On Tue, Apr 5, 2011 at 1:24 AM, R?mi Forax > wrote: > > > On 04/05/2011 06:57 AM, Neal Gafter wrote: > > The documentation for MethodHandle (see "Method Handle > Compilation" in< > > > http://download.java.net/jdk7/docs/api/java/lang/invoke/MethodHandle.html>) > > appears to contradict the requirements of the Java Language > Specification by > > describing compiler behavior that does not conform to the > requirements of > > the JLS. I have not checked, but I would not be surprised if > jdk7's javac > > also fails to satisfy the specification in this area. This is > the kind of > > backdoor language change that Java's corporate owner has > consistently > > considered a clear violation of Java trademark licensing > requirements. > > I don't understand exactly what you mean. > Coud you be a little more specific ? > > > I'm referring to requirements such as not boxing primitives, not > building a varargs array, and producing the "wrong" method signature > in the invoke instruction. The binary compatibility section of the > JLS specifies what method signature to be generated in the invocation, > and this documentation specifies another. Ok, let step back a moment. When you do a MethodHandle.invokeExact() the compiler has no idea of the target method so it can't do any conversions like boxing or varargs. Because invokeExact() has a polymorphic signature, it can't be represented by a classical method in the bytecode. But, it has been chosen to have a corresponding invokeExact() in the class MethodHandle. This method is not the real invokeExact() but more a placeholder for documentation. The method invokeExact() in the bytecode is annotated with an annotation saying that the compiler should not care about the signature of this method but should build the method descriptor based on the type of the argument and the type of the cast (or void for statement) for the return type. R?mi From neal at gafter.com Tue Apr 5 07:47:55 2011 From: neal at gafter.com (Neal Gafter) Date: Tue, 5 Apr 2011 07:47:55 -0700 Subject: JDK7 language specification issue with MethodHandle In-Reply-To: <4D9B2087.3080101@univ-mlv.fr> References: <4D9AD1B4.7020402@univ-mlv.fr> <4D9B2087.3080101@univ-mlv.fr> Message-ID: On Tue, Apr 5, 2011 at 7:00 AM, R?mi Forax wrote: > On 04/05/2011 03:41 PM, Neal Gafter wrote: > > I'm referring to requirements such as not boxing primitives, not building a > varargs array, and producing the "wrong" method signature in the invoke > instruction. The binary compatibility section of the JLS specifies what > method signature to be generated in the invocation, and this documentation > specifies another. > > > Ok, let step back a moment. > When you do a MethodHandle.invokeExact() the compiler has no idea of the > target method > so it can't do any conversions like boxing or varargs. > That's not what the JLS says. The JLS precisely specifies which method is to be called: MethodHandle.invokeExact(java.lang.Object[]):java.lang.Object, typically (but not always) as a variable-arity invocation. Because invokeExact() has a polymorphic signature, it can't be represented > by a classical > method in the bytecode. > The JLS doesn't have a concept of polymorphic signature in this sense. But, it has been chosen to have a corresponding invokeExact() in the class > MethodHandle. > This method is not the real invokeExact() but more a placeholder for > documentation. > The method invokeExact() in the bytecode is annotated with an annotation > saying > that the compiler should not care about the signature of this method but > should build the method descriptor based on the type of the argument and > the type of the cast (or void for statement) for the return type. > The JLS doesn't say that this annotation may change compile-time behavior otherwise specified by the JLS. Cheers, Neal From brucechapman at paradise.net.nz Wed Apr 6 03:14:45 2011 From: brucechapman at paradise.net.nz (Bruce Chapman) Date: Wed, 06 Apr 2011 22:14:45 +1200 Subject: New protocol for disabling exception suppression In-Reply-To: <4D9AEE8A.20408@oracle.com> References: <4D967A1C.3060001@oracle.com> <4D98BA10.40303@univ-mlv.fr> <4D9957C0.6030501@oracle.com> <4D998729.5040903@univ-mlv.fr> <4D9A0566.90902@oracle.com> <4D9A0EFB.6070207@univ-mlv.fr> <4D9A815E.7090809@oracle.com> <4D9AE83C.5030402@paradise.net.nz> <4D9AEE8A.20408@oracle.com> Message-ID: <4D9C3D15.6000303@paradise.net.nz> On 5/04/2011 10:27 p.m., David Holmes wrote: > Bruce Chapman said the following on 04/05/11 20:00: >> On 5/04/2011 2:41 p.m., joe.darcy at oracle.com wrote: >>> I could see an argument for adding analogous protected constructors to >>> java.lang.{Exception, RuntimeException, Error} to allow non-platform >> Without analogous constructors I don't think it will be possible to >> make a checked exception with suppressed disabled. > > Well Throwable is a checked exception. Without analogous constructors > users won't be able to make instances of any existing exception types > (checked or unchecked) with suppression disabled, but ... > >> So long as users can make their own checked and unchecked exceptions >> with suppression disabled that should be enough. > > ... the intent was never to provide users with such a facility, but > simply to ensure that the actions of the VM were allowed under the > specification. Yes, I understand the history, but for cases where a single exception instance is being used multiple times (both Remi and I have given example use cases), if those were unwound through a t-w-r, then we could keep getting more and more suppressed exceptions added, each time it was used and the close() failed. Unusual? yes, but possible. The right way to make a reusable (flow control) exception is to disable suppressed exceptions - that ability needs to be provided. Bruce > > David > >> Bruce >>> exceptions to control this behavior. However, just as not all >>> exception >>> types have a full complement of the existing four Throwable >>> constructors, very, very few exceptions types need a constructor that >>> allows suppression to be disabled. In particular, there are no >>> plans to >>> go through and retrofit a bunch of these constructors into the majority >>> of the exception types defined in the platform. >>> >>> -Joe >>> >>> >> >> > From joe.darcy at oracle.com Wed Apr 6 23:30:59 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 06 Apr 2011 23:30:59 -0700 Subject: FYI, on core-libs-dev Code review request for 6998871 "Support making the Throwable.stackTrace field immutable" Message-ID: <4D9D5A23.1050902@oracle.com> FYI, over on code-libs-dev, I have a code review request out for 6998871 "Support making the Throwable.stackTrace field immutable" http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-April/006427.html -Joe From carsten.zerbst at groy-groy.de Sat Apr 9 12:59:34 2011 From: carsten.zerbst at groy-groy.de (carsten.zerbst at groy-groy.de) Date: Sat, 09 Apr 2011 21:59:34 +0200 Subject: Difference parsing from String and byte literal Message-ID: <20110409215934.p5meox0l9ncco8k0@www.netbeat.de> Hello, I played a little with the new JDK7 and run into a inconsistency with existing code. So far I use the following code to represent a mask long SOURCE_ENTITY_TYPE_MASK = Long.parseLong("10000000" + // "00000000" + // "00000000" + // "10000000", 2); Ok, the shiny new version would be long coin = 0b10000000_00000000_00000000_10000000; But if one print the decimal and binary representation one gets a difference from String 2147483776 from String 10000000000000000000000010000000 binary -2147483520 binary 1111111111111111111111111111111110000000000000000000000010000000 This is no problem for my mask but should perhaps be mentioned in the tutorial ? Bye, Carsten From vimilsaju at yahoo.com Sat Apr 9 13:47:41 2011 From: vimilsaju at yahoo.com (Vimil Saju) Date: Sat, 9 Apr 2011 13:47:41 -0700 (PDT) Subject: Difference parsing from String and byte literal In-Reply-To: <20110409215934.p5meox0l9ncco8k0@www.netbeat.de> Message-ID: <109838.75742.qm@web161204.mail.bf1.yahoo.com> Shouldn't you use long coin = 0b10000000_00000000_00000000_10000000l; ? --- On Sat, 4/9/11, carsten.zerbst at groy-groy.de wrote: > From: carsten.zerbst at groy-groy.de > Subject: Difference parsing from String and byte literal > To: coin-dev at openjdk.java.net > Date: Saturday, April 9, 2011, 12:59 PM > Hello, > > I played a little with the new JDK7 and run into a > inconsistency with > existing code. > > So far I use the following code to represent a mask > > ? long SOURCE_ENTITY_TYPE_MASK = > Long.parseLong("10000000" + // > ? ? ? ? ? ? ? > ???"00000000" + // > ? ? ? ? ? ? ? > ???"00000000" + // > ? ? ? ? ? ? ? > ???"10000000", 2); > > Ok, the shiny new version would be > > long coin = 0b10000000_00000000_00000000_10000000; > > But if one print the decimal and binary representation one > gets a difference > > from String 2147483776 > from String? ? ? ? ? ? ? > ? ? ? ? ? ? ? > 10000000000000000000000010000000 > binary -2147483520 > binary > 1111111111111111111111111111111110000000000000000000000010000000 > > > This is no problem for my mask but should perhaps be > mentioned in the? > tutorial ? > > Bye, Carsten > > From heinz at javaspecialists.eu Sat Apr 9 22:44:03 2011 From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz) Date: Sun, 10 Apr 2011 08:44:03 +0300 Subject: Difference parsing from String and byte literal In-Reply-To: <109838.75742.qm@web161204.mail.bf1.yahoo.com> References: <109838.75742.qm@web161204.mail.bf1.yahoo.com> Message-ID: <4DA143A3.20304@javaspecialists.eu> Please use capital L, especially for a binary number! long coin = 0b10000000_00000000_00000000_10000000L; 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 4/9/11 11:47 PM, Vimil Saju wrote: > Shouldn't you use > long coin = 0b10000000_00000000_00000000_10000000l; > ? > > > --- On Sat, 4/9/11, carsten.zerbst at groy-groy.de wrote: > > >> From: carsten.zerbst at groy-groy.de >> Subject: Difference parsing from String and byte literal >> To: coin-dev at openjdk.java.net >> Date: Saturday, April 9, 2011, 12:59 PM >> Hello, >> >> I played a little with the new JDK7 and run into a >> inconsistency with >> existing code. >> >> So far I use the following code to represent a mask >> >> long SOURCE_ENTITY_TYPE_MASK = >> Long.parseLong("10000000" + // >> >> "00000000" + // >> >> "00000000" + // >> >> "10000000", 2); >> >> Ok, the shiny new version would be >> >> long coin = 0b10000000_00000000_00000000_10000000; >> >> But if one print the decimal and binary representation one >> gets a difference >> >> from String 2147483776 >> from String >> >> 10000000000000000000000010000000 >> binary -2147483520 >> binary >> 1111111111111111111111111111111110000000000000000000000010000000 >> >> >> This is no problem for my mask but should perhaps be >> mentioned in the >> tutorial ? >> >> Bye, Carsten >> >> >> > > > From vimilsaju at yahoo.com Sat Apr 9 22:59:51 2011 From: vimilsaju at yahoo.com (Vimil Saju) Date: Sat, 9 Apr 2011 22:59:51 -0700 (PDT) Subject: Difference parsing from String and byte literal In-Reply-To: <4DA143A3.20304@javaspecialists.eu> Message-ID: <46677.63279.qm@web161210.mail.bf1.yahoo.com> Yeah.. that 'l' does look like a '1' --- On Sat, 4/9/11, Dr Heinz M. Kabutz wrote: > From: Dr Heinz M. Kabutz > Subject: Re: Difference parsing from String and byte literal > To: "Vimil Saju" > Cc: coin-dev at openjdk.java.net, carsten.zerbst at groy-groy.de > Date: Saturday, April 9, 2011, 10:44 PM > Please use capital L, especially for > a binary number! > > long coin = 0b10000000_00000000_00000000_10000000L; > > 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 4/9/11 11:47 PM, Vimil Saju wrote: > > Shouldn't you use long coin = > 0b10000000_00000000_00000000_10000000l; ? > > > > > > --- On Sat, 4/9/11, carsten.zerbst at groy-groy.de > > wrote: > > > >??? > >> From: carsten.zerbst at groy-groy.de > > >> Subject: Difference parsing from String and byte > literal > >> To: coin-dev at openjdk.java.net > >> Date: Saturday, April 9, 2011, 12:59 PM > >> Hello, > >> > >> I played a little with the new JDK7 and run into > a > >> inconsistency with > >> existing code. > >> > >> So far I use the following code to represent a > mask > >> > >>???long SOURCE_ENTITY_TYPE_MASK = > >> Long.parseLong("10000000" + // > >>? ? ? ? ? ? ? > ???"00000000" + // > >>? ? ? ? ? ? ? > ???"00000000" + // > >>? ? ? ? ? ? ? > ???"10000000", 2); > >> > >> Ok, the shiny new version would be > >> > >> long coin = > 0b10000000_00000000_00000000_10000000; > >> > >> But if one print the decimal and binary > representation one > >> gets a difference > >> > >> from String 2147483776 > >> from String? ? ? ? ? > ? ? ? ? ? ? ? ? > 10000000000000000000000010000000 > >> binary -2147483520 > >> binary > >> > 1111111111111111111111111111111110000000000000000000000010000000 > >> > >> > >> This is no problem for my mask but should perhaps > be > >> mentioned in the? tutorial ? > >> > >> Bye, Carsten > >> > >> > >>? ??? > > > > > >??? From neal at gafter.com Sun Apr 10 07:52:39 2011 From: neal at gafter.com (Neal Gafter) Date: Sun, 10 Apr 2011 07:52:39 -0700 Subject: Difference parsing from String and byte literal In-Reply-To: <4DA143A3.20304@javaspecialists.eu> References: <109838.75742.qm@web161204.mail.bf1.yahoo.com> <4DA143A3.20304@javaspecialists.eu> Message-ID: Actually, since the binary literal is new, this is an opportunity to make the small letter l at the end illegal. On Sat, Apr 9, 2011 at 10:44 PM, Dr Heinz M. Kabutz < heinz at javaspecialists.eu> wrote: > Please use capital L, especially for a binary number! > > long coin = 0b10000000_00000000_00000000_10000000L; > > > 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 4/9/11 11:47 PM, Vimil Saju wrote: > > Shouldn't you use > > long coin = 0b10000000_00000000_00000000_10000000l; > > ? > > > > > > --- On Sat, 4/9/11, carsten.zerbst at groy-groy.de < > carsten.zerbst at groy-groy.de> wrote: > > > > > >> From: carsten.zerbst at groy-groy.de > >> Subject: Difference parsing from String and byte literal > >> To: coin-dev at openjdk.java.net > >> Date: Saturday, April 9, 2011, 12:59 PM > >> Hello, > >> > >> I played a little with the new JDK7 and run into a > >> inconsistency with > >> existing code. > >> > >> So far I use the following code to represent a mask > >> > >> long SOURCE_ENTITY_TYPE_MASK = > >> Long.parseLong("10000000" + // > >> > >> "00000000" + // > >> > >> "00000000" + // > >> > >> "10000000", 2); > >> > >> Ok, the shiny new version would be > >> > >> long coin = 0b10000000_00000000_00000000_10000000; > >> > >> But if one print the decimal and binary representation one > >> gets a difference > >> > >> from String 2147483776 > >> from String > >> > >> 10000000000000000000000010000000 > >> binary -2147483520 > >> binary > >> 1111111111111111111111111111111110000000000000000000000010000000 > >> > >> > >> This is no problem for my mask but should perhaps be > >> mentioned in the > >> tutorial ? > >> > >> Bye, Carsten > >> > >> > >> > > > > > > > > From heinz at javaspecialists.eu Sun Apr 10 14:02:18 2011 From: heinz at javaspecialists.eu (Dr Heinz M. Kabutz) Date: Mon, 11 Apr 2011 00:02:18 +0300 Subject: Difference parsing from String and byte literal In-Reply-To: References: <109838.75742.qm@web161204.mail.bf1.yahoo.com> <4DA143A3.20304@javaspecialists.eu> Message-ID: <4DA21ADA.5040806@javaspecialists.eu> +l 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 4/10/11 5:52 PM, Neal Gafter wrote: > Actually, since the binary literal is new, this is an opportunity to > make the small letter l at the end illegal. > > On Sat, Apr 9, 2011 at 10:44 PM, Dr Heinz M. Kabutz > > wrote: > > Please use capital L, especially for a binary number! > > long coin = 0b10000000_00000000_00000000_10000000L; > > > 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 4/9/11 11:47 PM, Vimil Saju wrote: > > Shouldn't you use > > long coin = 0b10000000_00000000_00000000_10000000l; > > ? > > > > > > --- On Sat, 4/9/11, carsten.zerbst at groy-groy.de > > wrote: > > > > > >> From: carsten.zerbst at groy-groy.de > > > >> Subject: Difference parsing from String and byte literal > >> To: coin-dev at openjdk.java.net > >> Date: Saturday, April 9, 2011, 12:59 PM > >> Hello, > >> > >> I played a little with the new JDK7 and run into a > >> inconsistency with > >> existing code. > >> > >> So far I use the following code to represent a mask > >> > >> long SOURCE_ENTITY_TYPE_MASK = > >> Long.parseLong("10000000" + // > >> > >> "00000000" + // > >> > >> "00000000" + // > >> > >> "10000000", 2); > >> > >> Ok, the shiny new version would be > >> > >> long coin = 0b10000000_00000000_00000000_10000000; > >> > >> But if one print the decimal and binary representation one > >> gets a difference > >> > >> from String 2147483776 > >> from String > >> > >> 10000000000000000000000010000000 > >> binary -2147483520 > >> binary > >> 1111111111111111111111111111111110000000000000000000000010000000 > >> > >> > >> This is no problem for my mask but should perhaps be > >> mentioned in the > >> tutorial ? > >> > >> Bye, Carsten > >> > >> > >> > > > > > > > > From rich.midwinter at gmail.com Sun Apr 10 14:37:43 2011 From: rich.midwinter at gmail.com (Rich Midwinter) Date: Sun, 10 Apr 2011 22:37:43 +0100 Subject: Difference parsing from String and byte literal In-Reply-To: <4DA21ADA.5040806@javaspecialists.eu> References: <109838.75742.qm@web161204.mail.bf1.yahoo.com> <4DA143A3.20304@javaspecialists.eu> <4DA21ADA.5040806@javaspecialists.eu> Message-ID: Wouldn't it being illegal just for binary literals be confusingly inconsistent? Ideal as it is. KR Rich On 10 April 2011 22:02, Dr Heinz M. Kabutz wrote: > +l > > 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 4/10/11 5:52 PM, Neal Gafter wrote: > > Actually, since the binary literal is new, this is an opportunity to > > make the small letter l at the end illegal. > > > > On Sat, Apr 9, 2011 at 10:44 PM, Dr Heinz M. Kabutz > > > wrote: > > > > Please use capital L, especially for a binary number! > > > > long coin = 0b10000000_00000000_00000000_10000000L; > > > > > > 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 4/9/11 11:47 PM, Vimil Saju wrote: > > > Shouldn't you use > > > long coin = 0b10000000_00000000_00000000_10000000l; > > > ? > > > > > > > > > --- On Sat, 4/9/11, carsten.zerbst at groy-groy.de > > > > wrote: > > > > > > > > >> From: carsten.zerbst at groy-groy.de > > > > > > >> Subject: Difference parsing from String and byte literal > > >> To: coin-dev at openjdk.java.net > > >> Date: Saturday, April 9, 2011, 12:59 PM > > >> Hello, > > >> > > >> I played a little with the new JDK7 and run into a > > >> inconsistency with > > >> existing code. > > >> > > >> So far I use the following code to represent a mask > > >> > > >> long SOURCE_ENTITY_TYPE_MASK = > > >> Long.parseLong("10000000" + // > > >> > > >> "00000000" + // > > >> > > >> "00000000" + // > > >> > > >> "10000000", 2); > > >> > > >> Ok, the shiny new version would be > > >> > > >> long coin = 0b10000000_00000000_00000000_10000000; > > >> > > >> But if one print the decimal and binary representation one > > >> gets a difference > > >> > > >> from String 2147483776 > > >> from String > > >> > > >> 10000000000000000000000010000000 > > >> binary -2147483520 > > >> binary > > >> 1111111111111111111111111111111110000000000000000000000010000000 > > >> > > >> > > >> This is no problem for my mask but should perhaps be > > >> mentioned in the > > >> tutorial ? > > >> > > >> Bye, Carsten > > >> > > >> > > >> > > > > > > > > > > > > > > > From joe.darcy at oracle.com Sun Apr 10 17:33:56 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Sun, 10 Apr 2011 17:33:56 -0700 Subject: Difference parsing from String and byte literal In-Reply-To: <4DA21ADA.5040806@javaspecialists.eu> References: <109838.75742.qm@web161204.mail.bf1.yahoo.com> <4DA143A3.20304@javaspecialists.eu> <4DA21ADA.5040806@javaspecialists.eu> Message-ID: <4DA24C74.40008@oracle.com> Dr Heinz M. Kabutz wrote: > +l > > Regards > > Heinz > +1L -Joe From cbeams at vmware.com Tue Apr 12 20:58:31 2011 From: cbeams at vmware.com (Chris Beams) Date: Tue, 12 Apr 2011 20:58:31 -0700 Subject: Field and Method Literals Message-ID: <81F1761C-0C0B-466C-9315-7D31E889835F@vmware.com> Jesse Wilson submitted a proposal for field and method literals on March 10th 2009 [1], which was followed by quite a thread of discussion. As far as I can tell, however, the last mention of this work was just two days later on March 12th 2009 [2]. Since that time, the Method Handles work has become a reality, but quoting John Rose in his 'nutshell' article [3], "[T]he point is not calling or using these things from Java; the point is using them, down near the metal, to assemble the next 700 witty and winsome programming languages" In the spirit of Mark's recent call for JDK8 proposals [4], I'd like to inquire about the status (if any) of Jesse's original proposal. Simply put, are field and method literals in any way on the roadmap for JDK8? If not, are there any reasons that submitting such a proposal (or simply re-submitting Jesse's work) would be a non-starter? When I asked Jesse directly about the status of the proposal in December of 2009, he suggested it was dependent upon decisions in the closure space [5]. Perhaps that's still the case, but as closures will be decided in JDK8, perhaps we can make sure that method/field literals are as well. For context, we would find method literals in particular to be beneficial for various features of the Spring Framework. To cite one: in Spring's code-based (i.e., non-XML) application configuration style, it is often necessary for the user to specify a method that the framework should call on their behalf at a certain point in the application lifecycle. For example, calling the 'close()' method on a Spring-managed Hibernate SessionFactory object. Currently, users are forced to use strings to represent these method names (and annotations such as @PostConstruct are not applicable in the case of configuring third-party code). Method literals would Spring users to go from writing: @Configuration public class AppConfig { @Bean(destroyMethod="close") public SessionFactory sessionFactory() { // create, configure and return the Hibernate SessionFactory } } to something like the following: @Configuration public class AppConfig { @Bean(destroyMethod=SessionFactory#close) public SessionFactory sessionFactory() { // create, configure and return the Hibernate SessionFactory } } Again this is just one example, but you can see from the above how proper method literals would aid Spring users (as opposed to implementers) in writing safer, more navigable and IDE-friendly code. Thanks, - Chris Beams [1]: http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000388.html [2]: http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000414.html [3]: http://blogs.sun.com/jrose/entry/method_handles_in_a_nutshell [4]: http://mail.openjdk.java.net/pipermail/discuss/2011-March/001704.html [5]: http://twitter.com/#!/jessewilson/status/6557984814 From neal at gafter.com Wed Apr 13 08:13:24 2011 From: neal at gafter.com (Neal Gafter) Date: Wed, 13 Apr 2011 08:13:24 -0700 Subject: JDK7 language specification issue with MethodHandle In-Reply-To: <4D9AD1B4.7020402@univ-mlv.fr> References: <4D9AD1B4.7020402@univ-mlv.fr> Message-ID: On Tue, Apr 5, 2011 at 1:24 AM, R?mi Forax wrote: > You're right that these changes was first submitted to coin, > but it was latter decided that the only the syntax change implemented > in Java 7, invoking a method handle, will be done under JSR 292. > Can you please send me a pointer to the minutes for that JCP EC vote? The public page for jsr292 doesn't give any evidence that the EC accepted the expansion of jsr292's scope beyond VM specification changes. From carsten.zerbst at groy-groy.de Wed Apr 13 13:08:08 2011 From: carsten.zerbst at groy-groy.de (carsten.zerbst at groy-groy.de) Date: Wed, 13 Apr 2011 22:08:08 +0200 Subject: Difference parsing from String and byte literal In-Reply-To: <46677.63279.qm@web161210.mail.bf1.yahoo.com> References: <46677.63279.qm@web161210.mail.bf1.yahoo.com> Message-ID: <20110413220808.1ste8m4hnxj8kskw@www.netbeat.de> Hello all, thanks for the answer. I was not aware that one need to add the L even for binary notation. Bye, the way, I'm currently using java.runtime.version=1.7.0-ea-b137 and not all things mentioned on the Project Coin page do compile. E.g. catch-with-resource and multiple catch do not work yet. Is there #1 a list when these features will be available or #2 a VM option to switch them on ? Bye, Carsten From stuart.marks at oracle.com Wed Apr 13 14:47:02 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 13 Apr 2011 14:47:02 -0700 Subject: Difference parsing from String and byte literal In-Reply-To: <20110413220808.1ste8m4hnxj8kskw@www.netbeat.de> References: <46677.63279.qm@web161210.mail.bf1.yahoo.com> <20110413220808.1ste8m4hnxj8kskw@www.netbeat.de> Message-ID: <4DA619D6.40206@oracle.com> On 4/13/11 1:08 PM, carsten.zerbst at groy-groy.de wrote: > Hello all, > > thanks for the answer. I was not aware that one > need to add the L even for binary notation. > > Bye, the way, I'm currently using java.runtime.version=1.7.0-ea-b137 > and not all things mentioned on the Project Coin page do compile. > > E.g. catch-with-resource and multiple catch do not work yet. > Is there #1 a list when these features will be available or #2 a > VM option to switch them on ? All the Coin features should work well in builds as recent as b137. We're using them in the JDK itself. If you're building from the command line you don't need any compiler or VM switches to enable them. If you're using NetBeans, you may need to change the source-level to 7 to enable the new features. The default source-level in NB is 6 (at least that's what it was in the NB 7 betas). Also, the Coin features have evolved, so it could be that you're looking at examples that used to work but which are no longer allowed. Could you send a pointer to the examples that aren't working for you so that we can make sure they get updated? Thanks. s'marks From joe.darcy at oracle.com Wed Apr 13 19:30:41 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 13 Apr 2011 19:30:41 -0700 Subject: Field and Method Literals In-Reply-To: <81F1761C-0C0B-466C-9315-7D31E889835F@vmware.com> References: <81F1761C-0C0B-466C-9315-7D31E889835F@vmware.com> Message-ID: <4DA65C51.2000608@oracle.com> Hi Chris. In Project Lambda/JSR 335 targeted for Java SE 8, method references are currently supported in all the same SAM conversion contexts as lambdas, with the same rules. The "State of the Lambda" document from a few months back, including a description of method references is: http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html and the public archive of the mailing list for Project Lambda is at: http://mail.openjdk.java.net/pipermail/lambda-dev/ Cheers, -Joe On 4/12/2011 8:58 PM, Chris Beams wrote: > Jesse Wilson submitted a proposal for field and method literals on March 10th 2009 [1], which was followed by quite a thread of discussion. As far as I can tell, however, the last mention of this work was just two days later on March 12th 2009 [2]. Since that time, the Method Handles work has become a reality, but quoting John Rose in his 'nutshell' article [3], > > "[T]he point is not calling or using these things from Java; the point is using them, down near the metal, to assemble the next 700 witty and winsome programming languages" > > In the spirit of Mark's recent call for JDK8 proposals [4], I'd like to inquire about the status (if any) of Jesse's original proposal. Simply put, are field and method literals in any way on the roadmap for JDK8? If not, are there any reasons that submitting such a proposal (or simply re-submitting Jesse's work) would be a non-starter? When I asked Jesse directly about the status of the proposal in December of 2009, he suggested it was dependent upon decisions in the closure space [5]. Perhaps that's still the case, but as closures will be decided in JDK8, perhaps we can make sure that method/field literals are as well. > > For context, we would find method literals in particular to be beneficial for various features of the Spring Framework. To cite one: in Spring's code-based (i.e., non-XML) application configuration style, it is often necessary for the user to specify a method that the framework should call on their behalf at a certain point in the application lifecycle. For example, calling the 'close()' method on a Spring-managed Hibernate SessionFactory object. Currently, users are forced to use strings to represent these method names (and annotations such as @PostConstruct are not applicable in the case of configuring third-party code). Method literals would Spring users to go from writing: > > @Configuration > public class AppConfig { > @Bean(destroyMethod="close") > public SessionFactory sessionFactory() { > // create, configure and return the Hibernate SessionFactory > } > } > > to something like the following: > > @Configuration > public class AppConfig { > @Bean(destroyMethod=SessionFactory#close) > public SessionFactory sessionFactory() { > // create, configure and return the Hibernate SessionFactory > } > } > > Again this is just one example, but you can see from the above how proper method literals would aid Spring users (as opposed to implementers) in writing safer, more navigable and IDE-friendly code. > > Thanks, > > - Chris Beams > > > [1]: http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000388.html > [2]: http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000414.html > [3]: http://blogs.sun.com/jrose/entry/method_handles_in_a_nutshell > [4]: http://mail.openjdk.java.net/pipermail/discuss/2011-March/001704.html > [5]: http://twitter.com/#!/jessewilson/status/6557984814 > > From scolebourne at joda.org Wed Apr 13 23:31:37 2011 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 14 Apr 2011 07:31:37 +0100 Subject: Field and Method Literals In-Reply-To: <4DA65C51.2000608@oracle.com> References: <81F1761C-0C0B-466C-9315-7D31E889835F@vmware.com> <4DA65C51.2000608@oracle.com> Message-ID: I would note that the use case below (use of a method reference in an annotation) is not yet in P.Lambda AFAIK. I consider that a highly desirable use case. Stephen On 14 April 2011 03:30, wrote: > Hi Chris. > > In Project Lambda/JSR 335 targeted for Java SE 8, method references are > currently supported in all the same SAM conversion contexts as lambdas, > with the same rules. > > The "State of the Lambda" document from a few months back, including a > description of method references is: > ? ?http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html > and the public archive of the mailing list for Project Lambda is at: > ? ?http://mail.openjdk.java.net/pipermail/lambda-dev/ > > Cheers, > > -Joe > > On 4/12/2011 8:58 PM, Chris Beams wrote: >> Jesse Wilson submitted a proposal for field and method literals on March 10th 2009 [1], which was followed by quite a thread of discussion. ?As far as I can tell, however, the last mention of this work was just two days later on March 12th 2009 [2]. ?Since that time, the Method Handles work has become a reality, but quoting John Rose in his 'nutshell' article [3], >> >> "[T]he point is not calling or using these things from Java; the point is using them, down near the metal, to assemble the next 700 witty and winsome programming languages" >> >> In the spirit of Mark's recent call for JDK8 proposals [4], I'd like to inquire about the status (if any) of Jesse's original proposal. ?Simply put, are field and method literals in any way on the roadmap for JDK8? ?If not, are there any reasons that submitting such a proposal (or simply re-submitting Jesse's work) would be a non-starter? ?When I asked Jesse directly about the status of the proposal in December of 2009, he suggested it was dependent upon decisions in the closure space [5]. ?Perhaps that's still the case, but as closures will be decided in JDK8, perhaps we can make sure that method/field literals are as well. >> >> For context, we would find method literals in particular to be beneficial for various features of the Spring Framework. ?To cite one: in Spring's code-based (i.e., non-XML) application configuration style, it is often necessary for the user to specify a method that the framework should call on their behalf at a certain point in the application lifecycle. ?For example, calling the 'close()' method on a Spring-managed Hibernate SessionFactory object. ?Currently, users are forced to use strings to represent these method names (and annotations such as @PostConstruct are not applicable in the case of configuring third-party code). ?Method literals would Spring users to go from writing: >> >> @Configuration >> public class AppConfig { >> @Bean(destroyMethod="close") >> public SessionFactory sessionFactory() { >> // create, configure and return the Hibernate SessionFactory >> } >> } >> >> to something like the following: >> >> @Configuration >> public class AppConfig { >> @Bean(destroyMethod=SessionFactory#close) >> public SessionFactory sessionFactory() { >> // create, configure and return the Hibernate SessionFactory >> } >> } >> >> Again this is just one example, but you can see from the above how proper method literals would aid Spring users (as opposed to implementers) in writing safer, more navigable and IDE-friendly code. >> >> Thanks, >> >> - Chris Beams >> >> >> [1]: http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000388.html >> [2]: http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000414.html >> [3]: http://blogs.sun.com/jrose/entry/method_handles_in_a_nutshell >> [4]: http://mail.openjdk.java.net/pipermail/discuss/2011-March/001704.html >> [5]: http://twitter.com/#!/jessewilson/status/6557984814 >> >> > > From davimesquita at gmail.com Thu Apr 14 08:53:58 2011 From: davimesquita at gmail.com (=?ISO-8859-1?Q?Davi_S=E1r=E1nszky_Mesquita?=) Date: Thu, 14 Apr 2011 12:53:58 -0300 Subject: To instantiate interfaces. Message-ID: Maybe i am late, but i will love to receive critic's about this. thansks, SMALL LANGUAGE CHANGE PROPOSAL FORM *AUTHOR(S):* Davi Saranszky Mesquita, SCJP 6.0 *OVERVIEW* Ability to instantiate interfaces using pre-implemented behavior. When we have lots of factories and native implemented Java. Cloud and multi-platform implementations needs to creates factories and interface oriented programing. For example: For the Google App Engine, we create an interface with pre-implemented behavior. When we ship this product to another platform, the only thing we need to do its using the same interface. The excess of using this will result in bigger Jar libraries. *EXAMPLES* A TARGET 6 EXAMPLE: // FILE: StoreFile.java import java.io.File; interface StoreFile { void doIt(File file); } // FILE: StoreFileImpl.java import java.io.File; class StoreFileImpl implements StoreFile { public void doIt(File file) { // DO MAJOR USER IMPLEMENTATION } } A TARGET 7 EXAMPLE: // FILE: StoreFile.java import java.io.File; interface StoreFile { void doIt(File file) { public void doIt(File file) { // DO MAJOR USER IMPLEMENTATION } } } At this point on target 7 example, we can instantiate the interface OR implements that for changing behaviors. // FILE StoreFileGAE.java import java.io.File; class StoreFileGAE implements StoreFile { void doIt(File file) { public void doIt(File file) { // DO Google App Engine NATIVE IMPLEMENTATION } } } At this point. We can just does nothing for just instantiations interfaces. The: new StoreFile(); just works. For localhost or the major products but for this example we can ship to Google App Engine for changing the implementations. This can be used for cloud storeges, cloud threads and task workers, for private grid and clustering like Cassandra or Haboop. Davi +55 (11) 8180-9411 TIM From Kai.Kunstmann at combase.de Thu Apr 14 10:34:09 2011 From: Kai.Kunstmann at combase.de (Kai Kunstmann) Date: Thu, 14 Apr 2011 19:34:09 +0200 Subject: To instantiate interfaces. In-Reply-To: References: Message-ID: <1302802449.5937.15.camel@kak-box> Hi, There is a "Design Pattern" called "Strategy" for this kind of behaviour. Have a look at Google's Guice library or the Spring Framework for pluggable components. Cheers, Kai Am Donnerstag, den 14.04.2011, 12:53 -0300 schrieb Davi S?r?nszky Mesquita: > Maybe i am late, but i will love to receive critic's about this. > > thansks, > SMALL LANGUAGE CHANGE PROPOSAL FORM *AUTHOR(S):* Davi Saranszky Mesquita, > SCJP 6.0 > > *OVERVIEW* > Ability to instantiate interfaces using pre-implemented behavior. > > When we have lots of factories and native implemented Java. Cloud and > multi-platform implementations needs to creates factories and interface > oriented programing. > > For example: For the Google App Engine, we create an interface with > pre-implemented behavior. When we ship this product to another platform, the > only thing we need to do its using the same interface. > > The excess of using this will result in bigger Jar libraries. > > > *EXAMPLES* > > > A TARGET 6 EXAMPLE: > > // FILE: StoreFile.java > > import java.io.File; > > interface StoreFile { > > void doIt(File file); > > } > > // FILE: StoreFileImpl.java > import java.io.File; > class StoreFileImpl implements StoreFile { > public void doIt(File file) { > // DO MAJOR USER IMPLEMENTATION > } > } > > A TARGET 7 EXAMPLE: > > // FILE: StoreFile.java > > import java.io.File; > > interface StoreFile { > > void doIt(File file) { > public void doIt(File file) { > // DO MAJOR USER IMPLEMENTATION > } > } > > } > > At this point on target 7 example, we can instantiate the interface OR > implements that for changing behaviors. > > // FILE StoreFileGAE.java > import java.io.File; > class StoreFileGAE implements StoreFile { > > void doIt(File file) { > public void doIt(File file) { > // DO Google App Engine NATIVE IMPLEMENTATION > } > } > } > > At this point. We can just does nothing for just instantiations interfaces. > > The: new StoreFile(); > > just works. > > For localhost or the major products but for this example we can ship to > Google App Engine for changing the implementations. > > This can be used for cloud storeges, cloud threads and task workers, for > private grid and clustering like Cassandra or Haboop. > > > > Davi > +55 (11) 8180-9411 TIM > From davimesquita at gmail.com Thu Apr 14 12:08:52 2011 From: davimesquita at gmail.com (=?ISO-8859-1?Q?Davi_S=E1r=E1nszky_Mesquita?=) Date: Thu, 14 Apr 2011 16:08:52 -0300 Subject: To instantiate interfaces. In-Reply-To: <1302802449.5937.15.camel@kak-box> References: <1302802449.5937.15.camel@kak-box> Message-ID: Thanks for advice. But my proposal it's for reduce the quantity of classes and get more productive. Davi +55 (11) 8180-9411 TIM 2011/4/14 Kai Kunstmann > Hi, > > There is a "Design Pattern" called "Strategy" for this kind of > behaviour. Have a look at Google's Guice library or the Spring Framework > for pluggable components. > > Cheers, > Kai > > > Am Donnerstag, den 14.04.2011, 12:53 -0300 schrieb Davi S?r?nszky > Mesquita: > > Maybe i am late, but i will love to receive critic's about this. > > > > thansks, > > SMALL LANGUAGE CHANGE PROPOSAL FORM *AUTHOR(S):* Davi Saranszky Mesquita, > > SCJP 6.0 > > > > *OVERVIEW* > > Ability to instantiate interfaces using pre-implemented behavior. > > > > When we have lots of factories and native implemented Java. Cloud and > > multi-platform implementations needs to creates factories and interface > > oriented programing. > > > > For example: For the Google App Engine, we create an interface with > > pre-implemented behavior. When we ship this product to another platform, > the > > only thing we need to do its using the same interface. > > > > The excess of using this will result in bigger Jar libraries. > > > > > > *EXAMPLES* > > > > > > A TARGET 6 EXAMPLE: > > > > // FILE: StoreFile.java > > > > import java.io.File; > > > > interface StoreFile { > > > > void doIt(File file); > > > > } > > > > // FILE: StoreFileImpl.java > > import java.io.File; > > class StoreFileImpl implements StoreFile { > > public void doIt(File file) { > > // DO MAJOR USER IMPLEMENTATION > > } > > } > > > > A TARGET 7 EXAMPLE: > > > > // FILE: StoreFile.java > > > > import java.io.File; > > > > interface StoreFile { > > > > void doIt(File file) { > > public void doIt(File file) { > > // DO MAJOR USER IMPLEMENTATION > > } > > } > > > > } > > > > At this point on target 7 example, we can instantiate the interface OR > > implements that for changing behaviors. > > > > // FILE StoreFileGAE.java > > import java.io.File; > > class StoreFileGAE implements StoreFile { > > > > void doIt(File file) { > > public void doIt(File file) { > > // DO Google App Engine NATIVE IMPLEMENTATION > > } > > } > > } > > > > At this point. We can just does nothing for just instantiations > interfaces. > > > > The: new StoreFile(); > > > > just works. > > > > For localhost or the major products but for this example we can ship to > > Google App Engine for changing the implementations. > > > > This can be used for cloud storeges, cloud threads and task workers, for > > private grid and clustering like Cassandra or Haboop. > > > > > > > > Davi > > +55 (11) 8180-9411 TIM > > > From neal at gafter.com Thu Apr 14 13:18:38 2011 From: neal at gafter.com (Neal Gafter) Date: Thu, 14 Apr 2011 13:18:38 -0700 Subject: To instantiate interfaces. In-Reply-To: References: Message-ID: Davi- Please see the "defender methods" part of project lambda, proposed for inclusion in Java 8. Cheers, Neal 2011/4/14 Davi S?r?nszky Mesquita > Maybe i am late, but i will love to receive critic's about this. > > thansks, > SMALL LANGUAGE CHANGE PROPOSAL FORM *AUTHOR(S):* Davi Saranszky Mesquita, > SCJP 6.0 > > *OVERVIEW* > Ability to instantiate interfaces using pre-implemented behavior. > > When we have lots of factories and native implemented Java. Cloud and > multi-platform implementations needs to creates factories and interface > oriented programing. > > For example: For the Google App Engine, we create an interface with > pre-implemented behavior. When we ship this product to another platform, > the > only thing we need to do its using the same interface. > > The excess of using this will result in bigger Jar libraries. > > > *EXAMPLES* > > > A TARGET 6 EXAMPLE: > > // FILE: StoreFile.java > > import java.io.File; > > interface StoreFile { > > void doIt(File file); > > } > > // FILE: StoreFileImpl.java > import java.io.File; > class StoreFileImpl implements StoreFile { > public void doIt(File file) { > // DO MAJOR USER IMPLEMENTATION > } > } > > A TARGET 7 EXAMPLE: > > // FILE: StoreFile.java > > import java.io.File; > > interface StoreFile { > > void doIt(File file) { > public void doIt(File file) { > // DO MAJOR USER IMPLEMENTATION > } > } > > } > > At this point on target 7 example, we can instantiate the interface OR > implements that for changing behaviors. > > // FILE StoreFileGAE.java > import java.io.File; > class StoreFileGAE implements StoreFile { > > void doIt(File file) { > public void doIt(File file) { > // DO Google App Engine NATIVE IMPLEMENTATION > } > } > } > > At this point. We can just does nothing for just instantiations interfaces. > > The: new StoreFile(); > > just works. > > For localhost or the major products but for this example we can ship to > Google App Engine for changing the implementations. > > This can be used for cloud storeges, cloud threads and task workers, for > private grid and clustering like Cassandra or Haboop. > > > > Davi > +55 (11) 8180-9411 TIM > > From cbeams at vmware.com Sun Apr 17 01:35:23 2011 From: cbeams at vmware.com (Chris Beams) Date: Sun, 17 Apr 2011 01:35:23 -0700 Subject: Field and Method Literals In-Reply-To: References: <81F1761C-0C0B-466C-9315-7D31E889835F@vmware.com> <4DA65C51.2000608@oracle.com> Message-ID: <429C137B-9C51-461D-B018-C45EA97DBBF5@vmware.com> Stephen's comment reflects our concern - that method literal support limited to or designed for lambda contexts does not go far enough. The "State of the Lambda" document linked below uses the following example for static method literals: Arrays.sort(people, #Person.compareByAge); Then goes on to differentiate syntax for instance method literals: Arrays.sort(people, #comparatorHolder.comparePersonByAge); The proposal for static method syntax would be fine for our purposes, but the the proposal for instance method syntax assumes that a receiver variable (comparatorHolder in this case) is available in the first place. For Spring's purposes, this would invalidate a number of use cases, and rules out use within annotations entirely. We're looking for a general purpose constant-expression method literal syntax usable in any programmatic context and that may refer to any type of method. We particularly care about usability within annotations, thus the necessity for evaluation as constant expressions. Toolability is also key - for example, Eclipse users should be able to hit 'F3' on the use of a method literal and arrive at its associated method declaration, just as doing the same on a class literal opens the class declaration. Such support would be straightforward for tool vendors to implement. Method (and field) literals seem to me an obvious addition to the language; I've often wondered why they weren't there from the beginning, just as class literals have been. Is there a theoretical reason why they should not or cannot be introduced? I would think they are more fundamental than any closure proposal, and that closure proposals would build atop field/method literal support as opposed to the other way around. - Chris On Apr 14, 2011, at 2:31 PM, Stephen Colebourne wrote: I would note that the use case below (use of a method reference in an annotation) is not yet in P.Lambda AFAIK. I consider that a highly desirable use case. Stephen On 14 April 2011 03:30, > wrote: Hi Chris. In Project Lambda/JSR 335 targeted for Java SE 8, method references are currently supported in all the same SAM conversion contexts as lambdas, with the same rules. The "State of the Lambda" document from a few months back, including a description of method references is: http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-3.html and the public archive of the mailing list for Project Lambda is at: http://mail.openjdk.java.net/pipermail/lambda-dev/ Cheers, -Joe On 4/12/2011 8:58 PM, Chris Beams wrote: Jesse Wilson submitted a proposal for field and method literals on March 10th 2009 [1], which was followed by quite a thread of discussion. As far as I can tell, however, the last mention of this work was just two days later on March 12th 2009 [2]. Since that time, the Method Handles work has become a reality, but quoting John Rose in his 'nutshell' article [3], "[T]he point is not calling or using these things from Java; the point is using them, down near the metal, to assemble the next 700 witty and winsome programming languages" In the spirit of Mark's recent call for JDK8 proposals [4], I'd like to inquire about the status (if any) of Jesse's original proposal. Simply put, are field and method literals in any way on the roadmap for JDK8? If not, are there any reasons that submitting such a proposal (or simply re-submitting Jesse's work) would be a non-starter? When I asked Jesse directly about the status of the proposal in December of 2009, he suggested it was dependent upon decisions in the closure space [5]. Perhaps that's still the case, but as closures will be decided in JDK8, perhaps we can make sure that method/field literals are as well. For context, we would find method literals in particular to be beneficial for various features of the Spring Framework. To cite one: in Spring's code-based (i.e., non-XML) application configuration style, it is often necessary for the user to specify a method that the framework should call on their behalf at a certain point in the application lifecycle. For example, calling the 'close()' method on a Spring-managed Hibernate SessionFactory object. Currently, users are forced to use strings to represent these method names (and annotations such as @PostConstruct are not applicable in the case of configuring third-party code). Method literals would Spring users to go from writing: @Configuration public class AppConfig { @Bean(destroyMethod="close") public SessionFactory sessionFactory() { // create, configure and return the Hibernate SessionFactory } } to something like the following: @Configuration public class AppConfig { @Bean(destroyMethod=SessionFactory#close) public SessionFactory sessionFactory() { // create, configure and return the Hibernate SessionFactory } } Again this is just one example, but you can see from the above how proper method literals would aid Spring users (as opposed to implementers) in writing safer, more navigable and IDE-friendly code. Thanks, - Chris Beams [1]: http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000388.html [2]: http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000414.html [3]: http://blogs.sun.com/jrose/entry/method_handles_in_a_nutshell [4]: http://mail.openjdk.java.net/pipermail/discuss/2011-March/001704.html [5]: http://twitter.com/#!/jessewilson/status/6557984814 From forax at univ-mlv.fr Sun Apr 17 08:52:51 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 17 Apr 2011 17:52:51 +0200 Subject: Field and Method Literals In-Reply-To: <429C137B-9C51-461D-B018-C45EA97DBBF5@vmware.com> References: <81F1761C-0C0B-466C-9315-7D31E889835F@vmware.com> <4DA65C51.2000608@oracle.com> <429C137B-9C51-461D-B018-C45EA97DBBF5@vmware.com> Message-ID: <4DAB0CD3.8050009@univ-mlv.fr> It's more a discussion for lambda list. On 04/17/2011 10:35 AM, Chris Beams wrote: > Stephen's comment reflects our concern - that method literal support limited to or designed for lambda contexts does not go far enough. The "State of the Lambda" document linked below uses the following example for static method literals: > > > Arrays.sort(people, #Person.compareByAge); > > > Then goes on to differentiate syntax for instance method literals: > > > Arrays.sort(people, #comparatorHolder.comparePersonByAge); > > > The proposal for static method syntax would be fine for our purposes, but the the proposal for instance method syntax assumes that a receiver variable (comparatorHolder in this case) is available in the first place. For Spring's purposes, this would invalidate a number of use cases, and rules out use within annotations entirely. Using static method references in annotation is not a good idea because you will tie your specification (the annotation) to one implementation (the code of the method reference). Adding or removing formal parameters of that method will break the compatibility. An annotation must be loosely couple to its implementation, it's the only way to garantee implementation evolution. > We're looking for a general purpose constant-expression method literal syntax usable in any programmatic context and that may refer to any type of method. > We particularly care about usability within annotations, thus the necessity for evaluation as constant expressions. Annotation expression is defined as a subset of all expressions. So it can be limited to constant method reference but again it's bad(tm) to use it in an annotation. > Toolability is also key - for example, Eclipse users should be able to hit 'F3' on the use of a method literal and arrive at its associated method declaration, just as doing the same on a class literal opens the class declaration. Such support would be straightforward for tool vendors to implement. Agree. It should not be hard knowing that one IntelliJ guy and one Eclipse guy are in the expert group and that the reference implementation is javac which is used by NetBeans. > Method (and field) literals seem to me an obvious addition to the language; I've often wondered why they weren't there from the beginning, just as class literals have been. Class literal was introduced in 1.1 and really supported by the VM in 1.5 :) > Is there a theoretical reason why they should not or cannot be introduced? I would think they are more fundamental than any closure proposal, and that closure proposals would build atop field/method literal support as opposed to the other way around. Currently they are not built atop but both lambda and method reference share the same underlying mechanism. A lambda is almost an anonymous method reference (if you forget serialization). > - Chris R?mi From neal at gafter.com Sun Apr 17 09:38:27 2011 From: neal at gafter.com (Neal Gafter) Date: Sun, 17 Apr 2011 09:38:27 -0700 Subject: Field and Method Literals In-Reply-To: <429C137B-9C51-461D-B018-C45EA97DBBF5@vmware.com> References: <81F1761C-0C0B-466C-9315-7D31E889835F@vmware.com> <4DA65C51.2000608@oracle.com> <429C137B-9C51-461D-B018-C45EA97DBBF5@vmware.com> Message-ID: On Sunday, April 17, 2011, Chris Beams wrote: > Method (and field) literals seem to me an obvious addition to the language; I've often wondered why they weren't there from the beginning, just as class literals have been. ?Is there a theoretical reason why they should not or cannot be introduced? ?I would think they are more fundamental than any closure proposal, and that closure proposals would build atop field/method literal support as opposed to the other way around. Chris- The sort of method literals you're looking for - of type java.lang.reflect.Method - have very little to do with anything proposed for closures. The only thing they have in common is that the same syntax has been proposed for both. Cheers, Neal From forax at univ-mlv.fr Sun Apr 17 17:47:56 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 18 Apr 2011 02:47:56 +0200 Subject: Field and Method Literals In-Reply-To: References: <81F1761C-0C0B-466C-9315-7D31E889835F@vmware.com> <4DA65C51.2000608@oracle.com> <429C137B-9C51-461D-B018-C45EA97DBBF5@vmware.com> <4DAB0CD3.8050009@univ-mlv.fr> Message-ID: <4DAB8A3C.5040703@univ-mlv.fr> On 04/17/2011 10:04 PM, Alessio Stalla wrote: > On Sun, Apr 17, 2011 at 8:14 PM, Collin Fagan wrote: >> *Adding or removing formal parameters of that method will break the >> compatibility.* >> >> Isn't this almost always the case? I'm having a hard time understanding why >> it's any worse to break an annotation then any other line of code. > A agree. Also, he's talking about Spring, where annotations are used > for the configuration of a graph of objects and are necessarily tied > to the implementation (intended as method signatures in this case). I found a nice post from Gavin King that explains why depending on interceptor implementation is not a good idea: http://relation.to/Bloggers/OnCDIInterceptorBindings I think you can easily apply this principle to constant method handle in annotations. >> But more to the point what is Chris actually asking for? Is it just to be >> able to use static method references with annotations? > I believe he's asking for non-static method references without a > receiver object, usable in annotations. > > Alessio R?mi From joe.darcy at oracle.com Mon Apr 18 16:13:33 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 18 Apr 2011 16:13:33 -0700 Subject: JDK7 language specification issue with MethodHandle In-Reply-To: References: Message-ID: <4DACC59D.80908@oracle.com> Hi Neal. Neither Project Coin nor JSR 334 have covered any JSR 292-related features for some time, although discussions of JSR 292-related features did take place on coin-dev in the past. Changes to the JSR 292 specification to clarify the Java language changes that support MethodHandle are in process. Such changes include the definition of polymorphic signatures and extended rules for compile-time method resolution. Please direct all further inquiries related to JSR 292 to its spec lead, John Rose. Regards, -Joe On 4/4/2011 9:57 PM, Neal Gafter wrote: > Project coin took on the task of specifying language changes related > to method handles, invokeDynamic, and other jsr292-related things. > In the end project coin's leaders decided not to specify any Java > language changes in jdk7 for jsr292. > > The documentation for MethodHandle (see "Method Handle Compilation" in > ) > appears to contradict the requirements of the Java Language > Specification by describing compiler behavior that does not conform to > the requirements of the JLS. I have not checked, but I would not be > surprised if jdk7's javac also fails to satisfy the specification in > this area. This is the kind of backdoor language change that Java's > corporate owner has consistently considered a clear violation of Java > trademark licensing requirements. > > Are there any plans to resolve this? Are the required language > changes going into the JLS through some other mechanism? > > Cheers, > Neal From neal at gafter.com Mon Apr 18 23:27:54 2011 From: neal at gafter.com (Neal Gafter) Date: Mon, 18 Apr 2011 23:27:54 -0700 Subject: JDK7 language specification issue with MethodHandle In-Reply-To: <4DACC59D.80908@oracle.com> References: <4DACC59D.80908@oracle.com> Message-ID: I'm really confused here. Are you saying that jsr292 is "clarifying" the language? The sort of changes we're talking about don't qualify as "clarifications" according to any dictionary definition I'm familiar with. Even if they did, the language specification is out of scope for jsr292. That is clear from its charter. I'm not asking about the VM changes (i.e. jsr-292's charter), but about language changes (Coin's charter). Has there been a change in jsr292's charter that hasn't yet made it to jsr-292's JCP website? Cheers, Neal On Mon, Apr 18, 2011 at 4:13 PM, wrote: > Hi Neal. > > Neither Project Coin nor JSR 334 have covered any JSR 292-related features > for some time, although discussions of JSR 292-related features did take > place on coin-dev in the past. > > Changes to the JSR 292 specification to clarify the Java language changes > that support MethodHandle are in process. Such changes include the > definition of polymorphic signatures and extended rules for compile-time > method resolution. > > Please direct all further inquiries related to JSR 292 to its spec lead, > John Rose. > > Regards, > > -Joe > > > On 4/4/2011 9:57 PM, Neal Gafter wrote: > >> Project coin took on the task of specifying language changes related to >> method handles, invokeDynamic, and other jsr292-related things. In the end >> project coin's leaders decided not to specify any Java language changes in >> jdk7 for jsr292. >> >> The documentation for MethodHandle (see "Method Handle Compilation" in < >> http://download.java.net/jdk7/docs/api/java/lang/invoke/MethodHandle.html>) >> appears to contradict the requirements of the Java Language Specification by >> describing compiler behavior that does not conform to the requirements of >> the JLS. I have not checked, but I would not be surprised if jdk7's javac >> also fails to satisfy the specification in this area. This is the kind of >> backdoor language change that Java's corporate owner has consistently >> considered a clear violation of Java trademark licensing requirements. >> >> Are there any plans to resolve this? Are the required language changes >> going into the JLS through some other mechanism? >> >> Cheers, >> Neal >> > From joe.darcy at oracle.com Wed Apr 20 15:21:19 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 20 Apr 2011 15:21:19 -0700 Subject: Field and Method Literals In-Reply-To: <429C137B-9C51-461D-B018-C45EA97DBBF5@vmware.com> References: <81F1761C-0C0B-466C-9315-7D31E889835F@vmware.com> <4DA65C51.2000608@oracle.com> <429C137B-9C51-461D-B018-C45EA97DBBF5@vmware.com> Message-ID: <4DAF5C5F.2060403@oracle.com> Hello Chris. Chris Beams wrote: [snip] > Method (and field) literals seem to me an obvious addition to the language; I've often wondered why they weren't there from the beginning, just as class literals have been. Is there a theoretical reason why they should not or cannot be introduced? I would think they are more fundamental than any closure proposal, and that closure proposals would build atop field/method literal support as opposed to the other way around. > > - Chris > > Just addressing the last points on feature selection, I've written about this general topic a few years back: "Project Coin: Elephants, Knapsacks, and Language Features" http://blogs.sun.com/darcy/entry/project_coin_elephants_knapsacks_language Quoting a few paragraphs: > Therefore for Project Coin, in addition to determining whether a > proposal to change the language is in and of itself appropriate, a > determination also has to be made as to whether the change is more > compelling than all but four or so other proposals. In economic terms, > there an an opportunity cost in the proposal selection; that is, > because of finite resources, choosing to have a particular proposal in > the platform removes the opportunity to do other proposals. There will > be good, compelling proposals that would improve the language /not/ > selected for Project Coin because there are a full set of better, more > compelling proposals that are more useful to include instead. Having > available prototypes for proposals, running the existing tests, and > writing new tests can only better inform the continuing proposal > evaluation and selection. > > Part of evaluating proposals is judging their utility to the Java > platform as a whole. In this way, I've long thought the Java platform > is like the elephant in the parable about the blind men and the > elephant : > > While each Duke and each of us may know and understand our own usage > of Java quite well and have valid ideas about how Java could be > changed to improve programming in our own areas of interest > (properties! operator overloading! design by contract! your favorite > feature!), putting together all that accurate /local/ information > might just result in a patchwork elephant: > Rather than just a collection of local views, a broad perspective is > needed to have an accurate, unified picture of the platform so Java > can keep evolving and improving as a general-purpose programming > language. This approach favors features with broader applicability. > For example, a usability improvement to generics, like the diamond > operator which allows type parameters to be elided during constructor > calls, is usable more often than, say, one of the various proposals to > allow extensible or abstract |enum| types, a change that would only > helpful in a small minority of |enum| declarations. Cheers, -Joe PS Class literals weren't there right at the beginning of the platform, but they were added in 1.1: http://java.sun.com/docs/books/jls/first_edition/html/1.1Update.html From joe.darcy at oracle.com Thu Apr 21 18:45:06 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 21 Apr 2011 18:45:06 -0700 Subject: IDE support for Project Coin Message-ID: <4DB0DDA2.2090107@oracle.com> FYI, all of NetBeans, IntelliJ, and Eclipse have some level of support in progress for Project Coin's language features. The recently released NetBeans 7.0 [1] has support for all the Coin features. As explained in its release notes [2], beyond just recognizing the features in the editor NetBeans 7.0 provides auto-completion to diamond and gives hints to apply the new features to existing code. As previously announced for IntelliJ IDEA [3], the builds of IDEA 10.5 EAP (early access program) [4] provide similar quickfix support. Finally, an Eclipse branch [5] is hosting their efforts to support Project Coin. As JSR 334 is not quite done yet [6], I'd expect the IDEs to be updated after JSR 334 is completed to account for any specification changes made in the interim. Happy hacking, -Joe [1] http://netbeans.org/community/releases/70/ [2] http://wiki.netbeans.org/NewAndNoteworthyNB70#JDK7_support [3] http://blogs.jetbrains.com/idea/2011/02/announcing-intellij-idea-105-with-full-java-7-support/ [4] http://confluence.jetbrains.net/display/IDEADEV/IDEA+10.5+EAP [5] http://wiki.eclipse.org/JDT_Core/Java7 [6] http://blogs.sun.com/darcy/entry/project_coin_jsr_334_pr From scolebourne at joda.org Fri Apr 22 07:17:01 2011 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 22 Apr 2011 09:17:01 -0500 Subject: Field and Method Literals In-Reply-To: <4DAF5C5F.2060403@oracle.com> References: <81F1761C-0C0B-466C-9315-7D31E889835F@vmware.com> <4DA65C51.2000608@oracle.com> <429C137B-9C51-461D-B018-C45EA97DBBF5@vmware.com> <4DAF5C5F.2060403@oracle.com> Message-ID: Could I suggest someone (not me, as I'm on holiday) looks at various Java frameworks and find all the places where annotations curently define method names as strings in annotations. I suspect that there are quite a few, perhaps including Spring and Play. Both method references and method literals are very useful elements for anotations, as I believe the current string usages will show. Stephen On 20/04/2011, Joe Darcy wrote: > Hello Chris. > > Chris Beams wrote: > [snip] >> Method (and field) literals seem to me an obvious addition to the >> language; I've often wondered why they weren't there from the beginning, >> just as class literals have been. Is there a theoretical reason why they >> should not or cannot be introduced? I would think they are more >> fundamental than any closure proposal, and that closure proposals would >> build atop field/method literal support as opposed to the other way >> around. >> >> - Chris >> >> > > Just addressing the last points on feature selection, I've written about > this general topic a few years back: > > "Project Coin: Elephants, Knapsacks, and Language Features" > > http://blogs.sun.com/darcy/entry/project_coin_elephants_knapsacks_language > > Quoting a few paragraphs: > >> Therefore for Project Coin, in addition to determining whether a >> proposal to change the language is in and of itself appropriate, a >> determination also has to be made as to whether the change is more >> compelling than all but four or so other proposals. In economic terms, >> there an an opportunity cost in the proposal selection; that is, >> because of finite resources, choosing to have a particular proposal in >> the platform removes the opportunity to do other proposals. There will >> be good, compelling proposals that would improve the language /not/ >> selected for Project Coin because there are a full set of better, more >> compelling proposals that are more useful to include instead. Having >> available prototypes for proposals, running the existing tests, and >> writing new tests can only better inform the continuing proposal >> evaluation and selection. >> >> Part of evaluating proposals is judging their utility to the Java >> platform as a whole. In this way, I've long thought the Java platform >> is like the elephant in the parable about the blind men and the >> elephant : >> >> While each Duke and each of us may know and understand our own usage >> of Java quite well and have valid ideas about how Java could be >> changed to improve programming in our own areas of interest >> (properties! operator overloading! design by contract! your favorite >> feature!), putting together all that accurate /local/ information >> might just result in a patchwork elephant: >> Rather than just a collection of local views, a broad perspective is >> needed to have an accurate, unified picture of the platform so Java >> can keep evolving and improving as a general-purpose programming >> language. This approach favors features with broader applicability. >> For example, a usability improvement to generics, like the diamond >> operator which allows type parameters to be elided during constructor >> calls, is usable more often than, say, one of the various proposals to >> allow extensible or abstract |enum| types, a change that would only >> helpful in a small minority of |enum| declarations. > > Cheers, > > -Joe > > PS Class literals weren't there right at the beginning of the platform, > but they were added in 1.1: > http://java.sun.com/docs/books/jls/first_edition/html/1.1Update.html > > > > > From David.Holmes at oracle.com Mon Apr 25 23:23:43 2011 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 26 Apr 2011 16:23:43 +1000 Subject: javac warnings for multi-catch Message-ID: <4DB664EF.8080701@oracle.com> I have a query regarding the warnings that javac now issues that are related to the work on multi-catch that does more precise analysis of the exceptions that can be thrown. Here's an example: ../../../src/share/classes/java/util/concurrent/ThreadPoolExecutor.java:1115: warning: unreachable catch clause } catch (Throwable x) { ^ thrown types RuntimeException,Error have already been caught and here's the code: try { task.run(); } catch (RuntimeException x) { thrown = x; throw x; } catch (Error x) { thrown = x; throw x; } catch (Throwable x) { thrown = x; throw new Error(x); } finally { afterExecute(task, thrown); } This pattern is not uncommon. The final catch of Throwable is there to close the gap that exists because of the API's (Class.newInstance) that allow you to throw checked-exceptions from methods that don't declare them. So the catch clause is not in fact unreachable. It seems to me that these warnings will encourage people to remove the "offending" catch clause and actually end up with code that is not robust because of these historical flaws in the API's (not to mention native calls). Perhaps it would be better to restrict the warnings to the cases where a previous clause will catch the exception expected by the later clause, rather than incorrectly assuming which exceptions can be thrown from the methods in the try-block. David From neal at gafter.com Tue Apr 26 09:36:46 2011 From: neal at gafter.com (Neal Gafter) Date: Tue, 26 Apr 2011 09:36:46 -0700 Subject: FYI, JSR 334 is now in public review In-Reply-To: <4D95577D.7050102@oracle.com> References: <4D8BB1E1.6000309@oracle.com> <4D95577D.7050102@oracle.com> Message-ID: On Thu, Mar 31, 2011 at 9:41 PM, Bernard Traversat wrote: > ?On 3/24/11 3:37 PM, Neal Gafter wrote: >> Please provide access to the archives of the expert group mailing list. > > We are working on it and committed to a transparent process. Actions speak louder than words. A month has passed. Oracle has concluded shepherding this JSR through the public review ballot, and yet there remains no public access to the archives of the expert group mailing list. That calls into question the seriousness of Oracle's commitment. As I have repeatedly said, I will be happy to respond to the public review by providing detailed comments once the archives have been made available. But if the public review period is closed before those comments can be acted upon, there will be no point in my effort. It appears that Oracle's intransigence is undermining the value of an "open" process. Cheers, Neal From mcnepp02 at googlemail.com Tue Apr 26 23:56:15 2011 From: mcnepp02 at googlemail.com (Gernot Neppert) Date: Wed, 27 Apr 2011 08:56:15 +0200 Subject: javac warnings for multi-catch In-Reply-To: <4DB664EF.8080701@oracle.com> References: <4DB664EF.8080701@oracle.com> Message-ID: Interesting observation! One might argue that the compiler warning points to a flaw in the original code: even though it 'works' as intended, it's not really 'clean code'. The author obviously did not trust the official API of task.run(). If he had, catching RuntimeException and Error would have sufficed. Rather, he wanted to catch 'sneaky' checked Exceptions, too. So he used 'catch Throwable' to cover for that, even though there are no Throwable-derivatives other than 'Error' and 'Exception'. To sum it up, I'd suggest the following code as a better, more concise way of expressing the intent: try { task.run(); } catch (Exception x) { thrown = x; throw x; } catch (Error x) { thrown = x; throw x; } finally { afterExecute(task, thrown); } Does the Java-7 compiler issue a warning for this, too? 2011/4/26 David Holmes : > I have a query regarding the warnings that javac now issues that are > related to the work on multi-catch that does more precise analysis of > the exceptions that can be thrown. Here's an example: > > ../../../src/share/classes/java/util/concurrent/ThreadPoolExecutor.java:1115: > warning: unreachable catch clause > ? ? ? ? ? ? ? ? ? ? } catch (Throwable x) { > ? ? ? ? ? ? ? ? ? ? ? ^ > ? thrown types RuntimeException,Error have already been caught > > and here's the code: > > ? ? ? ? ? ? ? ? ? ? try { > ? ? ? ? ? ? ? ? ? ? ? ? task.run(); > ? ? ? ? ? ? ? ? ? ? } catch (RuntimeException x) { > ? ? ? ? ? ? ? ? ? ? ? ? thrown = x; throw x; > ? ? ? ? ? ? ? ? ? ? } catch (Error x) { > ? ? ? ? ? ? ? ? ? ? ? ? thrown = x; throw x; > ? ? ? ? ? ? ? ? ? ? } catch (Throwable x) { > ? ? ? ? ? ? ? ? ? ? ? ? thrown = x; throw new Error(x); > ? ? ? ? ? ? ? ? ? ? } finally { > ? ? ? ? ? ? ? ? ? ? ? ? afterExecute(task, thrown); > ? ? ? ? ? ? ? ? ? ? } > > This pattern is not uncommon. The final catch of Throwable is there to > close the gap that exists because of the API's (Class.newInstance) that > allow you to throw checked-exceptions from methods that don't declare > them. So the catch clause is not in fact unreachable. > > It seems to me that these warnings will encourage people to remove the > "offending" catch clause and actually end up with code that is not > robust because of these historical flaws in the API's (not to mention > native calls). > > Perhaps it would be better to restrict the warnings to the cases where a > previous clause will catch the exception expected by the later clause, > rather than incorrectly assuming which exceptions can be thrown from the > methods in the try-block. > > David > > From David.Holmes at oracle.com Wed Apr 27 00:34:59 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 27 Apr 2011 17:34:59 +1000 Subject: javac warnings for multi-catch In-Reply-To: References: <4DB664EF.8080701@oracle.com> Message-ID: <4DB7C723.2020104@oracle.com> Gernot Neppert said the following on 04/27/11 16:56: > Interesting observation! > One might argue that the compiler warning points to a flaw in the > original code: even though it 'works' as intended, > it's not really 'clean code'. The author obviously did not trust the > official API of task.run(). We do not trust the programmers that implement run(). The code we right is robust in the face of user-defined code that does unexpected things. The code might "innocently" invoke Class.newInstance for a class where the constructor can throw a checked-exception. > If he had, catching RuntimeException and Error would have sufficed. > Rather, he wanted to catch 'sneaky' checked Exceptions, too. > So he used 'catch Throwable' to cover for that, even though there are > no Throwable-derivatives other than 'Error' and 'Exception'. Users can define their own subclass of Throwable - which would be a checked exception of course. > To sum it up, I'd suggest the following code as a better, more concise > way of expressing the intent: > > try { > task.run(); > } catch (Exception x) { > thrown = x; throw x; > } catch (Error x) { > thrown = x; throw x; > } finally { > afterExecute(task, thrown); > } > > Does the Java-7 compiler issue a warning for this, too? Don't know but it can't be used because the Exception is checked and so we can't rethrow it unless we declare it. David > > 2011/4/26 David Holmes : >> I have a query regarding the warnings that javac now issues that are >> related to the work on multi-catch that does more precise analysis of >> the exceptions that can be thrown. Here's an example: >> >> ../../../src/share/classes/java/util/concurrent/ThreadPoolExecutor.java:1115: >> warning: unreachable catch clause >> } catch (Throwable x) { >> ^ >> thrown types RuntimeException,Error have already been caught >> >> and here's the code: >> >> try { >> task.run(); >> } catch (RuntimeException x) { >> thrown = x; throw x; >> } catch (Error x) { >> thrown = x; throw x; >> } catch (Throwable x) { >> thrown = x; throw new Error(x); >> } finally { >> afterExecute(task, thrown); >> } >> >> This pattern is not uncommon. The final catch of Throwable is there to >> close the gap that exists because of the API's (Class.newInstance) that >> allow you to throw checked-exceptions from methods that don't declare >> them. So the catch clause is not in fact unreachable. >> >> It seems to me that these warnings will encourage people to remove the >> "offending" catch clause and actually end up with code that is not >> robust because of these historical flaws in the API's (not to mention >> native calls). >> >> Perhaps it would be better to restrict the warnings to the cases where a >> previous clause will catch the exception expected by the later clause, >> rather than incorrectly assuming which exceptions can be thrown from the >> methods in the try-block. >> >> David >> >> From tim at peierls.net Wed Apr 27 06:20:50 2011 From: tim at peierls.net (Tim Peierls) Date: Wed, 27 Apr 2011 09:20:50 -0400 Subject: javac warnings for multi-catch In-Reply-To: <4DB664EF.8080701@oracle.com> References: <4DB664EF.8080701@oracle.com> Message-ID: On Tue, Apr 26, 2011 at 2:23 AM, David Holmes wrote: > Perhaps it would be better to restrict the warnings to the cases where a > previous clause will catch the exception expected by the later clause, > rather than incorrectly assuming which exceptions can be thrown from the > methods in the try-block. > Agreed. Don't say unreachable if it really is reachable. --tim