>From a user perspective, Jikes RVM uses classpath "out of the box". (It builds with unmodified GNU classpath releases and classpath cvs head; we don't distribute GNU classpath with Jikes RVM).
We do provide our own versions of a few classes in java.* that the build process selects instead of using the classpath ones, but if that's the definition of not using classpath out of the box, then I'm not sure anyone actually uses classpath out of the box. --dave > You're a bit confused here. Of course the Classpath VM interface > requires the VM to provide certain classes. How else would it work? > > That does not mean to say that classpath itself needs modification > > > - jamvm > > Uses Classpath out of the box. > > > - jikesRVM > > Does not. It did not use Classpath originally, and hasn't migrated fully > to the Classpath VM interface. > > > - sableVM (1.11.3) > > Uses Classpath out of the box. SableVM bundles it's own Classpath for > practicality, and because they want some things slightly different. It > can still use Classpath out of the box if you want that. > > Out of your three examples, two can use Classpath straight out of the > box. Only JikesRVM can't, and it was, after all, developed for an > entirely different class library. > > > This is inconvenient for VM writers, as they must bundle or track the > > development of those classes in both libraries. > > Yes. Changes to the class library<->VM interface are inconvenient. > > > I think that this is why there was a suggestion to isolate all > > references in a separate "deliverable" (be it package, jar, bundle, > > whatever), > > That's what the VM interface is for. > > /Sven > >
