"Wu, Gansha" wrote: > libgcj implements callReadObject, callWriteObject in java, but classpath >demands native to > do them; Yes, In this case I dont see why it shouldn't be done in Java unless there is a compelling performance advantage in doing otherwise. In fact I suspect that all of Serialization can be implemented in pure Java, it is probably just for legacy reasons that we have native methods in there at all. This would require some significant reworking of the code but I think it would be worthwhile. > BTW, because of legacy problems, we couldn't port to libgcj's implementation >so easily. > We really like those changes like BigInteger, libgcj removed native dependency >in BigInteger, and > we hope BigInteger (and the like) in classpath will be merged back into classpath >ASAP; It should be trivial to merge the BigInteger stuff into classpath. For java.util.zip as you know it is more difficult for us due to the native code dependency. I believe there is now a pure-Java implementation of this which we should look at for classpath if copyright assignment etc can be taken care of. > We also like libgcj will add those parts classpath haven't implemented into >classpath, e.g, > java.util.zip.*, it's very important to run some biz apps; > But to those which involved changes of native interfaces, it's a burden for us >to change VM part. One thing I know we'd love to do is to port ORP to run on the libgcj runtime. This would mean using the ORB JIT with libgcj's GC etc. This will allow JIT'ed bytecode to be mixed with pre-compiled object code. We already do this with libgcj's interpreter so in principle it should not be hard to implement, but we'd need to change ORP to be compatible with GCJ's object and vtable layouts, and I don't know how difficult that would be. regards Bryce. _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
