RE: Query on stacktrace management logic

[David Holmes]

Steven Augart wrote:
> In Jikes RVM, we override a few of Classpath's implementations; we
> have our own Object.java and (relevant to your case) Throwable.java,
> for instance.  Hope this helps.
>
> The biggest ugliness here is that the version the rest of Classpath
> sees is not the same one as will actually be loaded at run time.  One
> day this will probably bite us when Classpath adds some new (Java 1.5
> or 1.6?) method or field to a class we override before we do it
> ourselves, and some other Classpath class uses the new method or field.

Right. We try to abide by the XXX vs. VMXXX split and not customise any
class that isn't specifically listed as being VM-specific. So far we've only
had to override System to change the initialization sequence, but the
further we get the more classes we want to be able to customise outside the
normal set. :( This isn't great from a maintenance perspective as I'd like
to be able to just 'cvs up' the latest classpath and having everything just
work. That said, our support of RTSJ will mandate a number of library
changes to make more of the core classes "async exception" safe in the face
of the potential memory access errors that the RTSJ scoped-memory and
no-heap threads introduce.

We do ensure that we compile all the classpath classes against our
customised versions though, to ensure compatability. And I should point out
that at present we only use a subset of Classpath.

Cheers,
David Holmes