Updated ARM Spec

[David Holmes]

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