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 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
