Updated ARM Spec

David Holmes David.Holmes at oracle.com
Tue Oct 26 23:08:22 PDT 2010


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



More information about the coin-dev mailing list