Updated ARM Spec

[Paul Benedict]

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