When we try to pass one, we currently get
>the class java.lang.StackTraceElement is neither
>PassByConstruction nor PassByProxy
This is because java.lang.StackTraceElement is new in
1.4 and is serialized as part of a Throwable. We've
been developing mostly on 1.3.1, so we didn't notice
this till just now.
A consequence is that broken references aren't
successfully passed, and remote unresolved references
(remote promises) that should be resolved to a broken
reference will instead remain unresolved.
There is also a strange security issue here: should
stack traces be revealed across vats? If we say "no",
we severely impede debugging. If we say "yes", we lose
some of the privacy promised by the capability
computation model -- it's an encapsulation loss.
My current opinion is for this to be switchable on a
per-vat basis. The debugging difference is so great,
and the privacy loss sufficiently moderate under most
conditions, that I believe this switch should default
to "yes".
Followups 2001-Sep-23 04:44 markm
java.lang.StackTraceElement made PassByConstruction and
Persistent, which solves the immediate issue, but we
still haven't provided a per-vat switch for not passing
these between vats (as explained in the original
submission). Therefore, I'm downgrading the priority
and changing the Summary and classification, but
leaving this open.
