From pbenedict at apache.org Fri Oct 1 06:44:36 2010 From: pbenedict at apache.org (Paul Benedict) Date: Fri, 1 Oct 2010 08:44:36 -0500 Subject: Hmm... Suppressed Exceptions are Throwables[] In-Reply-To: <4CA56420.7090203@oracle.com> References: <4CA4CDDD.5050701@gmail.com> <4CA56420.7090203@oracle.com> Message-ID: Thanks Joe and Osvaldo for your feedback. I like getSuppressed() too. On Thu, Sep 30, 2010 at 11:31 PM, Joe Darcy wrote: > Osvaldo Pinali Doederlein wrote: >> ? My $0.02: ?getSupressed(). >> > > Hopefully the method name would not be misinterpreted as a command! > >> - It's sufficiently clear (from both the context of the containing class >> and the return static type), so this is terse without being obscure; >> - There is a BIG precedent: we already have getCause(), not >> getCauseException() or getCauseThrowable(). >> > > Good point; I'll consider this renaming. > > Thanks, > > -Joe > >> A+ >> Osvaldo >> >> On 30/09/2010 14:12, Mike Clark wrote: >> >>> Re: "cause" instead of "suppressed" >>> To me it is fairly obvious that suppressed exceptions are not causes, >>> secondary or otherwise. ?Thus I would vote against any use of the term >>> "cause" in relationship to suppressed exceptions. >>> >>> Re: "Exception" vs "Throwable": >>> The Java exception class hierarchy and naming has always been ever so >>> slightly awkward. ?In conversation, when I talk about exceptions in a >>> _general_ sense, I mean anything that can be thrown. ?Thus when I >>> speak of Java exceptions in the general sense, I am usually talking >>> about Throwable and its subclasses. >>> >>> This follows with the Java Language Specification where you will find >>> the specification of java.lang.Throwable under the prominent chapter >>> title "Exceptions." ?So, you might say that while java.lang.Exception >>> is subordinate to java.lang.Throwable, java.lang.Throwable is itself >>> subordinate to the Java language feature "exceptions." ?And so it >>> could be argued that the "Exceptions" term in >>> "getSuppressedExceptions" actually refers to the exceptions language >>> feature, not java.lang.Exception. >>> >>> I am also familiar with (and myself use, where appropriate) the >>> convention of keeping a method's name in sync with the type name of >>> its return value. ?Under this convention, the method would be better >>> named "getSuppressedThrowables." >>> >>> However, I think the current naming ("getSuppressedExceptions") is >>> understandable and justifiable under the perspective of "exceptions >>> are a language feature" (e.g. JLS.) >>> >>> So for me, I'm happy either way. >>> >>> my 2 cents, >>> >>> Mike >>> >>> >> >> >> > > > From mclark at apache.org Fri Oct 1 09:18:51 2010 From: mclark at apache.org (Mike Clark) Date: Fri, 1 Oct 2010 10:18:51 -0600 Subject: Hmm... Suppressed Exceptions are Throwables[] In-Reply-To: References: <4CA4CDDD.5050701@gmail.com> <4CA56420.7090203@oracle.com> Message-ID: On Fri, Oct 1, 2010 at 7:44 AM, Paul Benedict wrote: > Thanks Joe and Osvaldo for your feedback. I like getSuppressed() too. Agreed. It follows from getCause() and sidesteps some confusion between exceptions, Exceptions, and Throwables. From neal at gafter.com Fri Oct 8 14:12:36 2010 From: neal at gafter.com (Neal Gafter) Date: Fri, 8 Oct 2010 14:12:36 -0700 Subject: Lambda's/Closures & Extension Methods in JDK 1.6 In-Reply-To: <4CA36104.4010308@oracle.com> References: <4CA23A2C.6020105@oracle.com> <4CA36104.4010308@oracle.com> Message-ID: As I've repeated before, changing the default of defender methods is the one kind of change that the defender method proposal does not discuss in its binary compatibility section. It doesn't make sense to criticize another proposal for exactly the same problem that the defender method proposal suffers from. On Wed, Sep 29, 2010 at 8:53 AM, Brian Goetz wrote: > > As I mentioned, I'm currently using them without even changing the > compiler. > > They work well, but I find the syntax a bit cumbersome. I haven't found > any > > brittle class issues. I should mention that the syntax was cumbersome > enough > > that I didn't use them for about a year, until I started using lambdas. > Now > > they have become more essential. > > > > Did you try out the solution? > > A compiler-only solution fails on the following case: > > interface Foo { > public extension void foo() default X.a(); > } > > interface Bar extends Foo { > } > > class C implements Bar { } > > // Compile the above classes, then recompile Bar with: > > interface Bar extends Foo { > public extension void foo() default X.b(); > } > > // Re-run your program. Now behavior of C is wrong; you call the wrong > default when C.foo() is called. > > > From isidore at setgame.com Tue Oct 12 09:38:26 2010 From: isidore at setgame.com (Llewellyn Falco) Date: Tue, 12 Oct 2010 09:38:26 -0700 Subject: Lambda's/Closures in JDK 1.6 Message-ID: Java Lambdas Lambdas allow for code like: Query.*orderBy*(people, *new* S1(a){{ret(a.getAge());}}); Check out the video and download the jar to get started at http://bit.ly/lambdas I mentioned last month that I had found a way to add lambdas to the current JDK. I struck me that perhaps many of you had not used lambdas before, so I thought I make a small tutorial on one of the common uses: *Sql like queries against your objects.* Let?s start with the most basic, *Order By* If you where writing an Sql query to get people based on age, you would say *Select* * *From* People *Order By *age or perhaps *Select* * *From* People a *Order By* a.age If you had an array of people in *C#* this would be written as Linq.OrderBy(people, a => a.GetAge()) Now, to do this in Java is a little more compacted, but very similar Query.*orderBy*(people, *new* S1(a){{ret(a.getAge());}}); let?s look at some more examples. *Select* Let?s say you wanted to get the names of all the people, you?d write a query like *Select* a.names *From* people a Now, let?s translate that into java Query.*select*(people, *new* F1(a){{ret(a.getName());}}); of course, with java you can select more than just primitives, if you wanted the Addresses, you could do that too. Query.*select*(people, *new* F1(a){{ret(a .getAddress());}}); you can even do transforms List students = Query.*select*(people, *new* F1(a){{ret(*new* Student(a.getName(), a .getAge()));}}); let?s move on. *Where* Of course most queries wouldn?t be much use without the where statement. Let?s find the all the A+ students Query.*where*(people, *new* F1(a){{ret(a.getGradePoint() > 3.8);}}) btw: it might be worth expanding the code a bit. I?m cheating a little to help with understanding. For lambdas to work in Java, there is an unfortunate side effect. It gets call 1 extra time. Specifically the first time. So you need to pass in an object. That object in the examples above is pre-defined as ?a? but in practice I usually use a blank object *new* F1(new Person()){{ret(a.getGradePoint() > 3.8);}} unfortunately, you can?t use ?null? because it would throw a null pointer exception. I also use the null object pattern a lot: Person.Null of course there are some standard calculations that are nice too. *Average* what if you wanted the average length of a person?s name? simple Query.*average*(people, *new* F1(a){{ret(a .getName().length());}}); of course for averages, the return type F1 must be a Number. *Min* by now you probably see how easy it would be to get a minimum or maximum, so let?s up the lambda by using a local variable. Let?s find the person who got the closest grade to sally. *final* Person sally = getPersonByName("Sally"); Query.*min*(people, *new* S1(a, sally){{ ret(Math.*abs*(a.getGradePoint() - sally.getGradePoint()));}}); You might have noticed the *final *key word, java requires that for locals to be used inside of the lambdas. you might also have noticed that this time I had to pass in 2 parameters (a, sally) to use sally inside you need to add her as a parameter as well. Lastly, I used the class S1 here instead of F1 this is just a convenience class which extends F1, since any where, min, or max queries require the output to be a Comparable object, like Integer, String etc. Well, I hope this got you interested in what lambdas can do for you. Check out the video and download the jar to get started at http://bit.ly/lambdas Happy coding, Llewellyn Falco From joe.darcy at oracle.com Tue Oct 12 09:48:05 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 12 Oct 2010 09:48:05 -0700 Subject: Lambda's/Closures in JDK 1.6 In-Reply-To: References: Message-ID: <4CB49145.2030505@oracle.com> Llewellyn Falco wrote: > Java Lambdas > This post is off-topic for the Project Coin mailing list. The Project Coin mailing list is for developing and discussion the Project Coin features; lambdas/closures are *not* Project Coin features. Your previous message to the list about your work was sufficient to alert any interested parties to it. -Joe From forax at univ-mlv.fr Tue Oct 12 11:16:48 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 12 Oct 2010 20:16:48 +0200 Subject: Lambda's/Closures in JDK 1.6 In-Reply-To: <4CB49145.2030505@oracle.com> References: <4CB49145.2030505@oracle.com> Message-ID: <4CB4A610.2020809@univ-mlv.fr> Le 12/10/2010 18:48, Joe Darcy a ?crit : > Llewellyn Falco wrote: > >> Java Lambdas >> >> > This post is off-topic for the Project Coin mailing list. The Project > Coin mailing list is for developing and discussion the Project Coin > features; lambdas/closures are *not* Project Coin features. > > Your previous message to the list about your work was sufficient to > alert any interested parties to it. > > -Joe > By the way, Joe. When Coin2 will start ? R?mi From joe.darcy at oracle.com Tue Oct 12 14:11:01 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 12 Oct 2010 14:11:01 -0700 Subject: Coin 2? In-Reply-To: <4CB4A610.2020809@univ-mlv.fr> References: <4CB49145.2030505@oracle.com> <4CB4A610.2020809@univ-mlv.fr> Message-ID: <4CB4CEE5.9040606@oracle.com> R?mi Forax wrote: [snip] >> >> -Joe >> >> > > By the way, Joe. > When Coin2 will start ? > > R?mi > > Any plans and thoughts for "Coin - the flip side" will be shared when they are available; for now I'm focusing on getting the remainder of Coin for JDK 7 finished! -Joe From isidore at setgame.com Wed Oct 13 09:00:30 2010 From: isidore at setgame.com (Llewellyn Falco) Date: Wed, 13 Oct 2010 09:00:30 -0700 Subject: Lambda's/Closures in JDK 1.6 In-Reply-To: <4CB49145.2030505@oracle.com> References: <4CB49145.2030505@oracle.com> Message-ID: On Tue, Oct 12, 2010 at 9:48 AM, Joe Darcy wrote: > Llewellyn Falco wrote: > >> Java Lambdas >> >> > > This post is off-topic for the Project Coin mailing list. The Project Coin > mailing list is for developing and discussion the Project Coin features; > lambdas/closures are *not* Project Coin features. > > Your previous message to the list about your work was sufficient to alert > any interested parties to it. > > -Joe > Sorry, I must have miss understood. I when I created this at JavaOne, and showed it to the people at the Java Language booth, they asked if I had checked out the coin project (I had only heard of it that very day). My understanding was it was small syntactically changes that would make java easier to use. Since the lambdas don't require ANY changes to java, I thought there might be many changes that would make them better without having to add any additional syntax. for example: Query.*orderBy*(people, *new* S1(a){{ret(a.getAge());}}); could become Query.*orderBy*(people, *new* S1(a){a.getAge()}); I mistakenly believed this was within the scope of project coin. which project should I be posting too? Sorry for the trouble, Llewellyn From dalibor.topic at oracle.com Wed Oct 13 09:07:41 2010 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Wed, 13 Oct 2010 18:07:41 +0200 Subject: Lambda's/Closures in JDK 1.6 In-Reply-To: References: <4CB49145.2030505@oracle.com> Message-ID: <4CB5D94D.7010801@oracle.com> On 10/13/10 6:00 PM, Llewellyn Falco wrote: > I mistakenly believed this was within the scope of project coin. which > project should I be posting too? Hi Llewellyn, For discussion of ideas around lambda/closures, please use the lambda-dev mailing list. cheers, dalibor topic -- Oracle Dalibor Topic | Java F/OSS Ambassador Phone: +494023646738 | | | Mobile: +491772664192 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven Green Oracle Oracle is committed to developing practices and products that help protect the environment From David.Holmes at oracle.com Wed Oct 13 18:53:51 2010 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 14 Oct 2010 11:53:51 +1000 Subject: Lambda's/Closures in JDK 1.6 In-Reply-To: <4CB5D94D.7010801@oracle.com> References: <4CB49145.2030505@oracle.com> <4CB5D94D.7010801@oracle.com> Message-ID: <4CB662AF.2050404@oracle.com> Note that Llewellyn has already posted this info on coin-dev on September 26 and followed up with a post to lambda-dev on September 30. Cheers, David Holmes Dalibor Topic said the following on 10/14/10 02:07: > On 10/13/10 6:00 PM, Llewellyn Falco wrote: >> I mistakenly believed this was within the scope of project coin. which >> project should I be posting too? > > Hi Llewellyn, > > For discussion of ideas around lambda/closures, please use the lambda-dev > mailing list. > > cheers, > dalibor topic > From joe.darcy at oracle.com Tue Oct 26 10:40:09 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 26 Oct 2010 10:40:09 -0700 Subject: Updated ARM Spec In-Reply-To: <4C730FB0.6030100@oracle.com> References: <4C3F8142.2030203@oracle.com> <4C5AE91C.1070908@oracle.com> <4C653D7B.6020001@univ-mlv.fr> <4C7240FF.7020209@oracle.com> <4C724471.9010606@oracle.com> <4C72480B.3050104@univ-mlv.fr> <4C7248F3.4010200@oracle.com> <4C724C26.6040709@univ-mlv.fr> <4C724D9E.8030100@oracle.com> <4C727018.5090409@univ-mlv.fr> <4C72CFCF.5060904@oracle.com> <4C730FB0.6030100@oracle.com> Message-ID: <4CC71279.1060102@oracle.com> David Holmes wrote: > Joe Darcy said the following on 08/24/10 05:45: >> To recap, Throwable objects have several pieces of mutable state: >> >> * the cause; this is a write-at-most-once value that can be set set >> via a constructor, like Throwable(Throwable cause) or >> Throwable(String message, Throwable cause), or set after construction >> via the Throwable.initCause method. (Setting the cause to null >> prevents future assignment.) >> >> * the stack trace; set by fillInStackTrace() or >> setStackTrace(StackTraceElement[] stackTrace) -- there doesn't seem >> to be any API prohibition against setting the stack trace multiple times > > But note that the VM implements fillInStackTrace and can ignore the > request, while setStackTrace is pure Java. > >> * suppressed exceptions : new functionality added to support >> try-with-resources statements/ARM blocks. Modified via calling >> addSuppressedException >> >> Focusing just on suppressed exceptions, to support the JVM reusing >> exception objects, the Throwable API should have some idiom to >> indicate suppressed exception information should *not* be recorded. >> Logically this amount to having the list of exceptions be a >> zero-length list which just discards adds. >> >> I'm hesitant to overload a null cause with discarding suppressed >> exceptions too. Instead, I propose the following: >> >> * a null value of the suppressedException field indicates >> addSuppressedException is a no-op. >> >> * the suppressedException field is initialized to point to a sentinel >> list in Throwable, something non-null that can be used for == >> checks. With this protocol, the "raw" Throwable objects created by >> the JVM get the addSuppressedException is a no-op behavior for free. >> >> * if the first call to addSuppressedException has this as an >> argument, the suppressedException field is null-ed; otherwise, a list >> is appended to as usual. >> >> Comments? > > It seems to me, inline with what has been written, that Throwable > should adopt the overall approach that for each of the cause, > stacktrace and suppressedExceptions fields: > > - null indicates that these fields can not be modified (and is the > default we get from the instances pre-allocated in the VM) > - the default initialization, via the constructor, is always a > non-NULL sentinel value > > This requires several changes to the existing method specifications. > The needed library changes to Throwable are being worked on under bug 6991528 "Support immutable Throwable objects" and the changes will be sent out for review to core-libs-dev once they're ready. -Joe From pbenedict at apache.org Tue Oct 26 14:16:31 2010 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 26 Oct 2010 16:16:31 -0500 Subject: Updated ARM Spec In-Reply-To: <4CC71279.1060102@oracle.com> References: <4C3F8142.2030203@oracle.com> <4C5AE91C.1070908@oracle.com> <4C653D7B.6020001@univ-mlv.fr> <4C7240FF.7020209@oracle.com> <4C724471.9010606@oracle.com> <4C72480B.3050104@univ-mlv.fr> <4C7248F3.4010200@oracle.com> <4C724C26.6040709@univ-mlv.fr> <4C724D9E.8030100@oracle.com> <4C727018.5090409@univ-mlv.fr> <4C72CFCF.5060904@oracle.com> <4C730FB0.6030100@oracle.com> <4CC71279.1060102@oracle.com> Message-ID: Joe, I don't like the use of magical values to turn off functionality. If you a desiring to make Throwable immutable once constructed, just add a freeze() method -- it's a common idiom which prevents further changes from the outside. Freeze can either make other methods throw an IllegalStateException or no-op further requests. Paul On Tue, Oct 26, 2010 at 12:40 PM, Joe Darcy wrote: > David Holmes wrote: >> Joe Darcy said the following on 08/24/10 05:45: >>> To recap, Throwable objects have several pieces of mutable state: >>> >>> * the cause; this is a write-at-most-once value that can be set set >>> via a constructor, like Throwable(Throwable cause) or >>> Throwable(String message, Throwable cause), or set after construction >>> via the Throwable.initCause method. ?(Setting the cause to null >>> prevents future assignment.) >>> >>> * the stack trace; set by fillInStackTrace() or >>> setStackTrace(StackTraceElement[] stackTrace) -- there doesn't seem >>> to be any API prohibition against setting the stack trace multiple times >> >> But note that the VM implements fillInStackTrace and can ignore the >> request, while setStackTrace is pure Java. >> >>> * suppressed exceptions : new functionality added to support >>> try-with-resources statements/ARM blocks. ?Modified via calling >>> addSuppressedException >>> >>> Focusing just on suppressed exceptions, to support the JVM reusing >>> exception objects, the Throwable API should have some idiom to >>> indicate suppressed exception information should *not* be recorded. >>> Logically this amount to having the list of exceptions be a >>> zero-length list which just discards adds. >>> >>> I'm hesitant to overload a null cause with discarding suppressed >>> exceptions too. ?Instead, I propose the following: >>> >>> * a null value of the suppressedException field indicates >>> addSuppressedException is a no-op. >>> >>> * the suppressedException field is initialized to point to a sentinel >>> list in Throwable, something non-null that can be used for == >>> checks. ?With this protocol, the "raw" Throwable objects created by >>> the JVM get the addSuppressedException is a no-op behavior for free. >>> >>> * if the first call to addSuppressedException has this as an >>> argument, the suppressedException field is null-ed; otherwise, a list >>> is appended to as usual. >>> >>> Comments? >> >> It seems to me, inline with what has been written, that Throwable >> should adopt the overall approach that for each of the cause, >> stacktrace and suppressedExceptions fields: >> >> - null indicates that these fields can not be modified (and is the >> default we get from the instances pre-allocated in the VM) >> - the default initialization, via the constructor, is always a >> non-NULL sentinel value >> >> This requires several changes to the existing method specifications. >> > > The needed library changes to Throwable are being worked on under bug > 6991528 "Support immutable Throwable objects" and the changes will be > sent out for review to core-libs-dev once they're ready. > > -Joe > > > From forax at univ-mlv.fr Tue Oct 26 16:33:41 2010 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 27 Oct 2010 01:33:41 +0200 Subject: Updated ARM Spec In-Reply-To: References: <4C3F8142.2030203@oracle.com> <4C5AE91C.1070908@oracle.com> <4C653D7B.6020001@univ-mlv.fr> <4C7240FF.7020209@oracle.com> <4C724471.9010606@oracle.com> <4C72480B.3050104@univ-mlv.fr> <4C7248F3.4010200@oracle.com> <4C724C26.6040709@univ-mlv.fr> <4C724D9E.8030100@oracle.com> <4C727018.5090409@univ-mlv.fr> <4C72CFCF.5060904@oracle.com> <4C730FB0.6030100@oracle.com> <4CC71279.1060102@oracle.com> Message-ID: <4CC76555.7030301@univ-mlv.fr> Le 26/10/2010 23:16, Paul Benedict a ?crit : > Joe, > > I don't like the use of magical values to turn off functionality. If > you a desiring to make Throwable immutable once constructed, just add > a freeze() method -- it's a common idiom which prevents further > changes from the outside. Freeze can either make other methods throw > an IllegalStateException or no-op further requests. > > Paul > Throwable is not immutable. You can call initCause(), setStacktrace, etc. But we also want to be able to create some immutable throwables in order to preallocate them and share them between several threads. For these immutable throwable they should be initialized with nulls to avoid to tie the VM internals too much with the Throwable Java class. In fact we also want one shot throwable, i.e throwable that are preallocated but not shared. In that case, the stacktrace is created in the VM by the thread that will throw the throwable. Because we want to use these tricks, we can not create a method freeze as you suggest. As you say, this is a common idiom that work well but not in this peculiar case. R?mi > On Tue, Oct 26, 2010 at 12:40 PM, Joe Darcy wrote: > >> David Holmes wrote: >> >>> Joe Darcy said the following on 08/24/10 05:45: >>> >>>> To recap, Throwable objects have several pieces of mutable state: >>>> >>>> * the cause; this is a write-at-most-once value that can be set set >>>> via a constructor, like Throwable(Throwable cause) or >>>> Throwable(String message, Throwable cause), or set after construction >>>> via the Throwable.initCause method. (Setting the cause to null >>>> prevents future assignment.) >>>> >>>> * the stack trace; set by fillInStackTrace() or >>>> setStackTrace(StackTraceElement[] stackTrace) -- there doesn't seem >>>> to be any API prohibition against setting the stack trace multiple times >>>> >>> But note that the VM implements fillInStackTrace and can ignore the >>> request, while setStackTrace is pure Java. >>> >>> >>>> * suppressed exceptions : new functionality added to support >>>> try-with-resources statements/ARM blocks. Modified via calling >>>> addSuppressedException >>>> >>>> Focusing just on suppressed exceptions, to support the JVM reusing >>>> exception objects, the Throwable API should have some idiom to >>>> indicate suppressed exception information should *not* be recorded. >>>> Logically this amount to having the list of exceptions be a >>>> zero-length list which just discards adds. >>>> >>>> I'm hesitant to overload a null cause with discarding suppressed >>>> exceptions too. Instead, I propose the following: >>>> >>>> * a null value of the suppressedException field indicates >>>> addSuppressedException is a no-op. >>>> >>>> * the suppressedException field is initialized to point to a sentinel >>>> list in Throwable, something non-null that can be used for == >>>> checks. With this protocol, the "raw" Throwable objects created by >>>> the JVM get the addSuppressedException is a no-op behavior for free. >>>> >>>> * if the first call to addSuppressedException has this as an >>>> argument, the suppressedException field is null-ed; otherwise, a list >>>> is appended to as usual. >>>> >>>> Comments? >>>> >>> It seems to me, inline with what has been written, that Throwable >>> should adopt the overall approach that for each of the cause, >>> stacktrace and suppressedExceptions fields: >>> >>> - null indicates that these fields can not be modified (and is the >>> default we get from the instances pre-allocated in the VM) >>> - the default initialization, via the constructor, is always a >>> non-NULL sentinel value >>> >>> This requires several changes to the existing method specifications. >>> >>> >> The needed library changes to Throwable are being worked on under bug >> 6991528 "Support immutable Throwable objects" and the changes will be >> sent out for review to core-libs-dev once they're ready. >> >> -Joe >> >> >> >> > From pbenedict at apache.org Tue Oct 26 16:49:09 2010 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 26 Oct 2010 18:49:09 -0500 Subject: Updated ARM Spec In-Reply-To: <4CC76555.7030301@univ-mlv.fr> References: <4C3F8142.2030203@oracle.com> <4C5AE91C.1070908@oracle.com> <4C653D7B.6020001@univ-mlv.fr> <4C7240FF.7020209@oracle.com> <4C724471.9010606@oracle.com> <4C72480B.3050104@univ-mlv.fr> <4C7248F3.4010200@oracle.com> <4C724C26.6040709@univ-mlv.fr> <4C724D9E.8030100@oracle.com> <4C727018.5090409@univ-mlv.fr> <4C72CFCF.5060904@oracle.com> <4C730FB0.6030100@oracle.com> <4CC71279.1060102@oracle.com> <4CC76555.7030301@univ-mlv.fr> Message-ID: On Tue, Oct 26, 2010 at 6:33 PM, R?mi Forax wrote: > Throwable is not immutable. You can call initCause(), setStacktrace, > etc. Agreed. That's why Joe started the email. The problem is the mutability. > But we also want to be able to create some immutable throwables in > order to preallocate them and share them between several threads. > For these immutable throwable they should be initialized with nulls to > avoid to tie the VM internals too much with the Throwable Java class. I still don't see why you have to use null as a magic value. Share your immutable Throwable instances, just don't "overload" null to do your tricks. > Because we want to use these tricks, we can not create a method freeze > as you suggest. > As you say, this is a common idiom that work well but not in this > peculiar case. I may have read Joe's email wrong, but I thought he wanted the ability to tell certain Throwable instances not to tag on additional data. I thought he wanted to have immutability when he needed it. So why can't you preallocate your Throwable instances, call freeze(), and share them? What is "null" doing that freeze() cannot? Paul From David.Holmes at oracle.com Tue Oct 26 17:02:48 2010 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 27 Oct 2010 10:02:48 +1000 Subject: Updated ARM Spec In-Reply-To: References: <4C3F8142.2030203@oracle.com> <4C5AE91C.1070908@oracle.com> <4C653D7B.6020001@univ-mlv.fr> <4C7240FF.7020209@oracle.com> <4C724471.9010606@oracle.com> <4C72480B.3050104@univ-mlv.fr> <4C7248F3.4010200@oracle.com> <4C724C26.6040709@univ-mlv.fr> <4C724D9E.8030100@oracle.com> <4C727018.5090409@univ-mlv.fr> <4C72CFCF.5060904@oracle.com> <4C730FB0.6030100@oracle.com> <4CC71279.1060102@oracle.com> <4CC76555.7030301@univ-mlv.fr> Message-ID: <4CC76C28.9010300@oracle.com> Paul Benedict said the following on 10/27/10 09:49: > I may have read Joe's email wrong, but I thought he wanted the ability > to tell certain Throwable instances not to tag on additional data. I > thought he wanted to have immutability when he needed it. So why can't > you preallocate your Throwable instances, call freeze(), and share > them? What is "null" doing that freeze() cannot? I agree this is feasible. If internally we use "null" to represent immutability then freeze() could set everything to null, and the VM allocated instances would act as-if they were constructed and then had freeze() invoked upon them. The only downside to freeze() is that it freezes everything at once whereas the current scheme allows you to make the stacktrace immutable independently of the suppressedExceptions, and independently of the cause (which is a set once property anyway). The VM may make instances that are fully immutable, but the user may want more flexibility here. Cheers, David From howard.lovatt at gmail.com Tue Oct 26 21:55:36 2010 From: howard.lovatt at gmail.com (Howard Lovatt) Date: Wed, 27 Oct 2010 15:55:36 +1100 Subject: Updated ARM Spec Message-ID: The functionality could be exposed at a fine grained level if required, e.g. freeze() (does the lot), freezeStackTrace(), and freezeSuppressedExceptions(). This would make the UI much more friendly and would let you at some latter stage change your mind about the use of Null. Strikes me as good engineering practice not to use 'magic' values. ? -- Howard. David Holmes David.Holmes at oracle.com Tue Oct 26 17:02:48 PDT 2010 said: Paul Benedict said the following on 10/27/10 09:49: > I may have read Joe's email wrong, but I thought he wanted the ability > to tell certain Throwable instances not to tag on additional data. I > thought he wanted to have immutability when he needed it. So why can't > you preallocate your Throwable instances, call freeze(), and share > them? What is "null" doing that freeze() cannot? I agree this is feasible. If internally we use "null" to represent immutability then freeze() could set everything to null, and the VM allocated instances would act as-if they were constructed and then had freeze() invoked upon them. The only downside to freeze() is that it freezes everything at once whereas the current scheme allows you to make the stacktrace immutable independently of the suppressedExceptions, and independently of the cause (which is a set once property anyway). The VM may make instances that are fully immutable, but the user may want more flexibility here. Cheers, David From pbenedict at apache.org Tue Oct 26 22:01:09 2010 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 27 Oct 2010 00:01:09 -0500 Subject: Updated ARM Spec In-Reply-To: References: Message-ID: The other benefit I had in mind exposing accessors to check the state: isStackTraceFrozen(), etc. On Tue, Oct 26, 2010 at 11:55 PM, Howard Lovatt wrote: > The functionality could be exposed at a fine grained level if > required, e.g. freeze() (does the lot), freezeStackTrace(), and > freezeSuppressedExceptions(). This would make the UI much more > friendly and would let you at some latter stage change your mind about > the use of Null. Strikes me as good engineering practice not to use > 'magic' values. > > ? -- Howard. > > > David Holmes David.Holmes at oracle.com Tue Oct 26 17:02:48 PDT 2010 said: > Paul Benedict said the following on 10/27/10 09:49: >> I may have read Joe's email wrong, but I thought he wanted the ability >> to tell certain Throwable instances not to tag on additional data. I >> thought he wanted to have immutability when he needed it. So why can't >> you preallocate your Throwable instances, call freeze(), and share >> them? What is "null" doing that freeze() cannot? > > I agree this is feasible. If internally we use "null" to represent > immutability then freeze() could set everything to null, and the VM > allocated instances would act as-if they were constructed and then had > freeze() invoked upon them. > > The only downside to freeze() is that it freezes everything at once > whereas the current scheme allows you to make the stacktrace immutable > independently of the suppressedExceptions, and independently of the > cause (which is a set once property anyway). The VM may make instances > that are fully immutable, but the user may want more flexibility here. > > Cheers, > David > > From David.Holmes at oracle.com Tue Oct 26 22:08:48 2010 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 27 Oct 2010 15:08:48 +1000 Subject: Updated ARM Spec In-Reply-To: References: Message-ID: <4CC7B3E0.8070507@oracle.com> Howard Lovatt said the following on 10/27/10 14:55: > The functionality could be exposed at a fine grained level if > required, e.g. freeze() (does the lot), freezeStackTrace(), and > freezeSuppressedExceptions(). This would make the UI much more > friendly and would let you at some latter stage change your mind about > the use of Null. Strikes me as good engineering practice not to use > 'magic' values. You say "magic value", I say "sentinel value" - it is very much a matter of perspective and preference. I'm more averse to API bloat than I am to special-cases. YMMV of course. David > > -- Howard. > > > David Holmes David.Holmes at oracle.com Tue Oct 26 17:02:48 PDT 2010 said: > Paul Benedict said the following on 10/27/10 09:49: >> I may have read Joe's email wrong, but I thought he wanted the ability >> to tell certain Throwable instances not to tag on additional data. I >> thought he wanted to have immutability when he needed it. So why can't >> you preallocate your Throwable instances, call freeze(), and share >> them? What is "null" doing that freeze() cannot? > > I agree this is feasible. If internally we use "null" to represent > immutability then freeze() could set everything to null, and the VM > allocated instances would act as-if they were constructed and then had > freeze() invoked upon them. > > The only downside to freeze() is that it freezes everything at once > whereas the current scheme allows you to make the stacktrace immutable > independently of the suppressedExceptions, and independently of the > cause (which is a set once property anyway). The VM may make instances > that are fully immutable, but the user may want more flexibility here. > > Cheers, > David > From David.Holmes at oracle.com Tue Oct 26 22:40:51 2010 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 27 Oct 2010 15:40:51 +1000 Subject: Updated ARM Spec In-Reply-To: References: Message-ID: <4CC7BB63.7030800@oracle.com> Paul Benedict said the following on 10/27/10 15:01: > The other benefit I had in mind exposing accessors to check the state: > isStackTraceFrozen(), etc. I knew someone would raise that :) There was some discussion on this but it was felt that making Throwables immutable will be very rare, and someone caring about whether a Throwable _is_ immutable even rarer. I prefer not to see API's bloated with methods that we don't expect to be useful as they simply don't carry their weight. Again YMMV. David > On Tue, Oct 26, 2010 at 11:55 PM, Howard Lovatt wrote: >> The functionality could be exposed at a fine grained level if >> required, e.g. freeze() (does the lot), freezeStackTrace(), and >> freezeSuppressedExceptions(). This would make the UI much more >> friendly and would let you at some latter stage change your mind about >> the use of Null. Strikes me as good engineering practice not to use >> 'magic' values. >> >> -- Howard. >> >> >> David Holmes David.Holmes at oracle.com Tue Oct 26 17:02:48 PDT 2010 said: >> Paul Benedict said the following on 10/27/10 09:49: >>> I may have read Joe's email wrong, but I thought he wanted the ability >>> to tell certain Throwable instances not to tag on additional data. I >>> thought he wanted to have immutability when he needed it. So why can't >>> you preallocate your Throwable instances, call freeze(), and share >>> them? What is "null" doing that freeze() cannot? >> I agree this is feasible. If internally we use "null" to represent >> immutability then freeze() could set everything to null, and the VM >> allocated instances would act as-if they were constructed and then had >> freeze() invoked upon them. >> >> The only downside to freeze() is that it freezes everything at once >> whereas the current scheme allows you to make the stacktrace immutable >> independently of the suppressedExceptions, and independently of the >> cause (which is a set once property anyway). The VM may make instances >> that are fully immutable, but the user may want more flexibility here. >> >> Cheers, >> David >> >> > From David.Holmes at oracle.com Tue Oct 26 23:08:22 2010 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 27 Oct 2010 16:08:22 +1000 Subject: Updated ARM Spec In-Reply-To: <4CC7BB63.7030800@oracle.com> References: <4CC7BB63.7030800@oracle.com> Message-ID: <4CC7C1D6.2010601@oracle.com> David Holmes said the following on 10/27/10 15:40: > Paul Benedict said the following on 10/27/10 15:01: >> The other benefit I had in mind exposing accessors to check the state: >> isStackTraceFrozen(), etc. > > I knew someone would raise that :) > > There was some discussion on this but it was felt that making Throwables > immutable will be very rare, and someone caring about whether a > Throwable _is_ immutable even rarer. Umm actually I was misremembering a different discussion. The above is my own view on the need to query the immutability state, not any agreed upon view held by Joe or anyone else. Sorry. David I prefer not to see API's bloated > with methods that we don't expect to be useful as they simply don't > carry their weight. > > Again YMMV. > > David > >> On Tue, Oct 26, 2010 at 11:55 PM, Howard Lovatt wrote: >>> The functionality could be exposed at a fine grained level if >>> required, e.g. freeze() (does the lot), freezeStackTrace(), and >>> freezeSuppressedExceptions(). This would make the UI much more >>> friendly and would let you at some latter stage change your mind about >>> the use of Null. Strikes me as good engineering practice not to use >>> 'magic' values. >>> >>> -- Howard. >>> >>> >>> David Holmes David.Holmes at oracle.com Tue Oct 26 17:02:48 PDT 2010 said: >>> Paul Benedict said the following on 10/27/10 09:49: >>>> I may have read Joe's email wrong, but I thought he wanted the ability >>>> to tell certain Throwable instances not to tag on additional data. I >>>> thought he wanted to have immutability when he needed it. So why can't >>>> you preallocate your Throwable instances, call freeze(), and share >>>> them? What is "null" doing that freeze() cannot? >>> I agree this is feasible. If internally we use "null" to represent >>> immutability then freeze() could set everything to null, and the VM >>> allocated instances would act as-if they were constructed and then had >>> freeze() invoked upon them. >>> >>> The only downside to freeze() is that it freezes everything at once >>> whereas the current scheme allows you to make the stacktrace immutable >>> independently of the suppressedExceptions, and independently of the >>> cause (which is a set once property anyway). The VM may make instances >>> that are fully immutable, but the user may want more flexibility here. >>> >>> Cheers, >>> David >>> >>> > From isidore at setgame.com Wed Oct 27 02:09:37 2010 From: isidore at setgame.com (Llewellyn Falco) Date: Wed, 27 Oct 2010 02:09:37 -0700 Subject: Updated ARM Spec In-Reply-To: References: <4C3F8142.2030203@oracle.com> <4C5AE91C.1070908@oracle.com> <4C653D7B.6020001@univ-mlv.fr> <4C7240FF.7020209@oracle.com> <4C724471.9010606@oracle.com> <4C72480B.3050104@univ-mlv.fr> <4C7248F3.4010200@oracle.com> <4C724C26.6040709@univ-mlv.fr> <4C724D9E.8030100@oracle.com> <4C727018.5090409@univ-mlv.fr> <4C72CFCF.5060904@oracle.com> <4C730FB0.6030100@oracle.com> <4CC71279.1060102@oracle.com> Message-ID: > > > I don't like the use of magical values to turn off functionality. If > you a desiring to make Throwable immutable once constructed, just add > a freeze() method -- I agree with the disliking magical values, but why not Just make a VALUE_NOT_SET constant and by done with it? If you want to be extra nice, you could have the toString() of that constant actually return "Value has not yet been set" Llewellyn Falco From joe.darcy at oracle.com Thu Oct 28 11:02:05 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 28 Oct 2010 11:02:05 -0700 Subject: Planned improvements to multi-catch and more precise rethrow Message-ID: <4CC9BA9D.1030507@oracle.com> We've been working on some improvements to the multi-catch with more precise rethrow feature [1] and are planning to push the changes soon. First, as long as a catch parameter is *effectively final* (in other words not reassigned inside the catch block), the more precise analysis will be enabled if the exception is rethrown. An explicit "final" modifier will no longer be needed to enable the more precise analysis. As pointed out in the original proposal form for "Improved Exception Handling for Java," [2] the more precise exception analysis can cause programs that currently compile to stop compiling since more unreachable code is identified. While the general evolution policy of the JDK [3] does not promise source compatibility across releases, gratuitously breaking compatibility should be avoided. Fortunately, after examining millions of lines of code in a diverse set of code bases, include the JDK, no instances where the more precise analysis would cause an actual source incompatibility were found. (Details of the analysis will be written up later.) Second, the catch parameter of a multi-catch clause ("catch(Exception1 | Exception2 e) {...}") will be regarded as implicitly final; the compiler will reject code that writes to such a catch parameter. Consequently, an explicit "final" modifier will no longer be needed in this case, although it will remain legal. This provides a more concise syntax for multi-catch in JDK 7 while preserving flexibility to more fully support disjunctive types in later JDK releases. -Joe [1] http://blogs.sun.com/darcy/entry/project_coin_multi_catch_rethrow [2] http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000003.html [3] http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0.777.html#general_evolution_policy