On 9/15/05, Dalibor Topic <[EMAIL PROTECTED]> wrote: > Missing bits and pieces: > String (yay, same as gcj. May be really hard. ;) > java.lang.reflection (hard in a way, easy in a way. Hard since GNU > Classpath has almost no code for it, so it'll be easy to merge in > Kaffe's implementation. Volunteers!) > java.util.zip (easy to do by switching completely over, but then the > performance is going to suffer extremely on the interpreter on slower > CPUs. Otoh...less work for me, and more pressure on people to write/fix > jits. Hmm... ;)
Makes me wonder, since the need to override certain files and/or packages in Classpath for a particular VM is such a common scenario, whether Classpath's build system shouldn't include native support for this. Obviously this doesn't jive with the eventual goal of a single glibj.zip shared between all runtimes, but until that point is reached, it might save Dalibor in particular lots of work ;) Wouldn't it be nice if there were a way to stick a kaffe.overrides file somewhere which contained something like: path ../whatever class java.lang.String package java.lang.reflect package java.util.zip Then you'd build classpath --with-overrides=path/to/kaffe.overrides and it produces a glibj-kaffe.zip taking most of the sources from the usual place but the String, reflect and zip sources from the ../whatever path instead. I think gcj already has something like this, because since the Big Merge they're actually using classpath in a subdirectory, but they still need to override some classes. But it seems like something that would be useful beyond gcj and kaffe and having each VM roll their own solution to the same problem seems silly. Unfortunately my build-system-fu is non-existant so I'd be completely incapable of implementing this myself. Perhaps everyone already thinks it's a good idea and the only reason it hasn't happened yet is nobody's volunteered, in which case this mail was kind of pointless ;) Thoughts? Stuart. -- http://sab39.dev.netreach.com/ _______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
