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: <AANLkTi=UeNRX21AzZkM7vx6eAZmdeS=7yhptRTZY2GzZ@mail.gmail.com>
	<AANLkTikaJGzMHZkBw7u29bWd51sn=RDAWQHc=4WDEgAH@mail.gmail.com>
	<AANLkTik3txj-Q1bHhE46vgqzA5scdZWMNv_cL4SgV32e@mail.gmail.com>
	<4CA4CDDD.5050701@gmail.com> <4CA56420.7090203@oracle.com>
Message-ID: <AANLkTi=SU0Gnxm1b8d1W5c53fYvZw9Di4t8TxdOrdHLz@mail.gmail.com>

Thanks Joe and Osvaldo for your feedback. I like getSuppressed() too.

On Thu, Sep 30, 2010 at 11:31 PM, Joe Darcy <joe.darcy at oracle.com> 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: <AANLkTi=SU0Gnxm1b8d1W5c53fYvZw9Di4t8TxdOrdHLz@mail.gmail.com>
References: <AANLkTi=UeNRX21AzZkM7vx6eAZmdeS=7yhptRTZY2GzZ@mail.gmail.com>
	<AANLkTikaJGzMHZkBw7u29bWd51sn=RDAWQHc=4WDEgAH@mail.gmail.com>
	<AANLkTik3txj-Q1bHhE46vgqzA5scdZWMNv_cL4SgV32e@mail.gmail.com>
	<4CA4CDDD.5050701@gmail.com> <4CA56420.7090203@oracle.com>
	<AANLkTi=SU0Gnxm1b8d1W5c53fYvZw9Di4t8TxdOrdHLz@mail.gmail.com>
Message-ID: <AANLkTin4R1+hoM=mS3+zJOgm9HbiNGZu1DmGS12z8xCL@mail.gmail.com>

On Fri, Oct 1, 2010 at 7:44 AM, Paul Benedict <pbenedict at apache.org> 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: <AANLkTikTr9PRB8Q_gY+V1nVUkeLpLLcjH2oVr6CU+84T@mail.gmail.com>
	<4CA23A2C.6020105@oracle.com>
	<AANLkTi=1kLfSpo+EzCJkcokyRNfh8NiFYEaDoVY1-5-h@mail.gmail.com>
	<4CA36104.4010308@oracle.com>
Message-ID: <AANLkTin+M-BjFMknPWqWem=zbG6Ju_tn2rCmO7pfeuzP@mail.gmail.com>

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 <brian.goetz at oracle.com> 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: <AANLkTimLmmc+LMG7nu0JjgNjT2fh4wmiKHnnBqP_t+GF@mail.gmail.com>

Java Lambdas <http://blog.approvaltests.com/2010/10/java-lambdas.html>

Lambdas allow for code like:
Query.*orderBy*(people, *new* S1<Person>(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<Person>(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<Person, String>(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<Person, Address>(a){{ret(a
.getAddress());}});

you can even do transforms

 List<Student> students =
     Query.*select*(people,
        *new* F1<Person, Student>(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<Person,Boolean>(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<Person,Boolean>(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<Person, Number>(a){{ret(a
.getName().length());}});

of course for averages, the return type F1<InputType, ReturnType>  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<Person>(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<Input> here instead
of F1<Input,ReturnType> 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: <AANLkTimLmmc+LMG7nu0JjgNjT2fh4wmiKHnnBqP_t+GF@mail.gmail.com>
References: <AANLkTimLmmc+LMG7nu0JjgNjT2fh4wmiKHnnBqP_t+GF@mail.gmail.com>
Message-ID: <4CB49145.2030505@oracle.com>

Llewellyn Falco wrote:
> Java Lambdas <http://blog.approvaltests.com/2010/10/java-lambdas.html>
>   

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: <AANLkTimLmmc+LMG7nu0JjgNjT2fh4wmiKHnnBqP_t+GF@mail.gmail.com>
	<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<http://blog.approvaltests.com/2010/10/java-lambdas.html>
>>
>>      
> 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: <AANLkTimLmmc+LMG7nu0JjgNjT2fh4wmiKHnnBqP_t+GF@mail.gmail.com>	<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: <AANLkTimLmmc+LMG7nu0JjgNjT2fh4wmiKHnnBqP_t+GF@mail.gmail.com>
	<4CB49145.2030505@oracle.com>
Message-ID: <AANLkTikts6_j_Eoyw=X05k47YMpeoSZpMd2E0tLhb4pp@mail.gmail.com>

On Tue, Oct 12, 2010 at 9:48 AM, Joe Darcy <joe.darcy at oracle.com> wrote:

> Llewellyn Falco wrote:
>
>> Java Lambdas <http://blog.approvaltests.com/2010/10/java-lambdas.html>
>>
>>
>
> 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<Person>(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: <AANLkTikts6_j_Eoyw=X05k47YMpeoSZpMd2E0tLhb4pp@mail.gmail.com>
References: <AANLkTimLmmc+LMG7nu0JjgNjT2fh4wmiKHnnBqP_t+GF@mail.gmail.com>	<4CB49145.2030505@oracle.com>
	<AANLkTikts6_j_Eoyw=X05k47YMpeoSZpMd2E0tLhb4pp@mail.gmail.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 <http://www.oracle.com>
Dalibor Topic | Java F/OSS Ambassador
Phone: +494023646738 <tel:+494023646738> | | | Mobile: +491772664192 <tel:+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 <http://www.oracle.com/commitment> 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: <AANLkTimLmmc+LMG7nu0JjgNjT2fh4wmiKHnnBqP_t+GF@mail.gmail.com>	<4CB49145.2030505@oracle.com>	<AANLkTikts6_j_Eoyw=X05k47YMpeoSZpMd2E0tLhb4pp@mail.gmail.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>	<AANLkTikm2Z9SL=OQ5yR043=ub9mQMVZjWmFHLQEBx=Vy@mail.gmail.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>
	<AANLkTikm2Z9SL=OQ5yR043=ub9mQMVZjWmFHLQEBx=Vy@mail.gmail.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: <AANLkTi=he85pG6URPnhB10FNwVqrHRDL362PiB8DJoRC@mail.gmail.com>

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 <joe.darcy at oracle.com> 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: <AANLkTi=he85pG6URPnhB10FNwVqrHRDL362PiB8DJoRC@mail.gmail.com>
References: <4C3F8142.2030203@oracle.com>
	<4C5AE91C.1070908@oracle.com>	<AANLkTikm2Z9SL=OQ5yR043=ub9mQMVZjWmFHLQEBx=Vy@mail.gmail.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>
	<AANLkTi=he85pG6URPnhB10FNwVqrHRDL362PiB8DJoRC@mail.gmail.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<joe.darcy at oracle.com>  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>
	<AANLkTikm2Z9SL=OQ5yR043=ub9mQMVZjWmFHLQEBx=Vy@mail.gmail.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>
	<AANLkTi=he85pG6URPnhB10FNwVqrHRDL362PiB8DJoRC@mail.gmail.com>
	<4CC76555.7030301@univ-mlv.fr>
Message-ID: <AANLkTinVX0DGsJYxDNpo4OuO21QK-Gkn_SqQ9QJzLs64@mail.gmail.com>

On Tue, Oct 26, 2010 at 6:33 PM, R?mi Forax <forax at univ-mlv.fr> 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: <AANLkTinVX0DGsJYxDNpo4OuO21QK-Gkn_SqQ9QJzLs64@mail.gmail.com>
References: <4C3F8142.2030203@oracle.com>
	<4C5AE91C.1070908@oracle.com>	<AANLkTikm2Z9SL=OQ5yR043=ub9mQMVZjWmFHLQEBx=Vy@mail.gmail.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>	<AANLkTi=he85pG6URPnhB10FNwVqrHRDL362PiB8DJoRC@mail.gmail.com>	<4CC76555.7030301@univ-mlv.fr>
	<AANLkTinVX0DGsJYxDNpo4OuO21QK-Gkn_SqQ9QJzLs64@mail.gmail.com>
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: <AANLkTikv7aPvXk0aqEwERyoNnBo+FcBx3x=hF35rzSF6@mail.gmail.com>

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: <AANLkTikv7aPvXk0aqEwERyoNnBo+FcBx3x=hF35rzSF6@mail.gmail.com>
References: <AANLkTikv7aPvXk0aqEwERyoNnBo+FcBx3x=hF35rzSF6@mail.gmail.com>
Message-ID: <AANLkTikVYUNu35UJLK8gBgQVRgnMP2WZwfrM9c5s4r7d@mail.gmail.com>

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 <howard.lovatt at gmail.com> 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: <AANLkTikv7aPvXk0aqEwERyoNnBo+FcBx3x=hF35rzSF6@mail.gmail.com>
References: <AANLkTikv7aPvXk0aqEwERyoNnBo+FcBx3x=hF35rzSF6@mail.gmail.com>
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: <AANLkTikVYUNu35UJLK8gBgQVRgnMP2WZwfrM9c5s4r7d@mail.gmail.com>
References: <AANLkTikv7aPvXk0aqEwERyoNnBo+FcBx3x=hF35rzSF6@mail.gmail.com>
	<AANLkTikVYUNu35UJLK8gBgQVRgnMP2WZwfrM9c5s4r7d@mail.gmail.com>
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 <howard.lovatt at gmail.com> 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: <AANLkTikv7aPvXk0aqEwERyoNnBo+FcBx3x=hF35rzSF6@mail.gmail.com>	<AANLkTikVYUNu35UJLK8gBgQVRgnMP2WZwfrM9c5s4r7d@mail.gmail.com>
	<4CC7BB63.7030800@oracle.com>
Message-ID: <4CC7C1D6.2010601@oracle.com>

<red face on>

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 <howard.lovatt at gmail.com> 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: <AANLkTi=he85pG6URPnhB10FNwVqrHRDL362PiB8DJoRC@mail.gmail.com>
References: <4C3F8142.2030203@oracle.com> <4C5AE91C.1070908@oracle.com>
	<AANLkTikm2Z9SL=OQ5yR043=ub9mQMVZjWmFHLQEBx=Vy@mail.gmail.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>
	<AANLkTi=he85pG6URPnhB10FNwVqrHRDL362PiB8DJoRC@mail.gmail.com>
Message-ID: <AANLkTimiFKDGPw+ZJ-75a5ZHhSF2Oh=mH1C4gGSOoDLE@mail.gmail.com>

>
>
> 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