Updated ARM Spec

[Howard Lovatt]

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