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