Hi all, Sometimes we can use some moral support. So let me share the following with you all. Normally we are a bit hesitant to recommend people to "just switch" since we cannot guarantee that everything "just works". But we are getting better and better. The following email was just sent to the i2p mailinglist. i2p is an anonymous network (both message and stream based support). See for more information http://i2p.net/
There were some small bugs (Calendar seems difficult to get all the corner cases right) and two performance issues (the SecureRandom one looks nasty, but I know Andrew is looking at the memory use of gcj native compiled applications already). All in all the transition seemed to have gone smoothly and as jrandom said: In any case, this is quite kickass, as it means we'll be able to both integrate more cleanly with other languages AND ship whereever GCJ ships (DFSG friendly!) Thanks go to the GCJ and GNU Classpath folks for their hard work! Go team! Mark
--- Begin Message --------BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks to mjw's prodding, I pulled the latest (4.0.2) gcj last night and tried my hand at getting I2P up and running under it. End result is that overnight, I've had my test network pushing gigs upon gigs of data with half of the network running under sun's JVM, and the other half GCJ'ed :) There were three issues of varying degrees of complexity to get there though: * 1) Calendar problems The first is a bug in GCJ (or maybe GNU Classpath, haven't tested on Jam or Kaffe yet) - when working with a java.util.Calendar, not all of the fields were being set correctly when they should be: import java.util.*; public class t { public static void main(String args[]) { Calendar cal = new GregorianCalendar(); cal.setTime(new Date()); cal.set(Calendar.HOUR_OF_DAY, 0); cal.set(Calendar.MINUTE, 0); cal.set(Calendar.SECOND, 0); cal.set(Calendar.MILLISECOND, 0); long midnight = cal.getTimeInMillis(); System.out.println("Midnight: " + midnight); cal = new GregorianCalendar(); cal.setTime(new Date()); // workaround for fields not set cal.set(Calendar.YEAR, cal.get(Calendar.YEAR)); cal.set(Calendar.DAY_OF_YEAR, cal.get(Calendar.DAY_OF_YEAR)); // continue as normal cal.set(Calendar.HOUR_OF_DAY, 0); cal.set(Calendar.MINUTE, 0); cal.set(Calendar.SECOND, 0); cal.set(Calendar.MILLISECOND, 0); midnight = cal.getTimeInMillis(); System.out.println("Workaround: " + midnight); } } Both JVMs (Sun and GCJ) display the workaround properly, and Sun's displays the original Midnight: properly, but GCJ's cal.getTimeInMillis() returns 0 (the YEAR and DAY_OF_YEAR fields are not properly computed). There are a few places in I2P's code where we use Calendar in this sort of way, but the latest I2P CVS includes workarounds for these issues. * 2) xerces problems The xerces we ship with won't compile cleanly under GCJ - it complains about missing references to some sun.* functions. We aren't using the latest xerces though, and since mjw told me that it should work, I'll grab the latest and give it a go, upgrading our CVS xercesImpl.jar if it works (and causes no regressions). In any case, xerces isn't technically necessary for I2P operation - its only used by Jetty for the router console (a really, really useful application, but not technically necessary). * 3) prng problems We gobble random bits like crazy. To get a functional system, I had to disable our PRNG pool (which pulls data out of java.security.SecureRandom) and enable the weak PRNG (which pulls data out of java.util.Random). This is not necessarily entirely GCJ's fault, but more of an issue with the OS which GCJ doesn't hide. Shipping with the weak PRNG wouldn't be prudent though, so we'll need to go back and revive the Fortuna integration effort before shipping GCJ'ed routers. Overall, this is fantastic news - I'm glad mjw convinced me to give it another shot. The I2P SDK, the streaming library, and the client apps all build fine under GCJ, completely compatible with ones running on Sun's or IBM's JVM. I've had a GCJ'ed version of i2psnark running overnight, doing swarming file transfer with normal i2p-bt and azneti2p peers without problem. One of the really interesting things here is how this affects SAM - with the I2P SDK and streaming libraries built into libi2p.so (or even libi2p.a), there is no reason why Python/C/C++ apps couldn't link against those objects and use net::i2p::client::streaming::I2PSocket directly! If someone wants to explore this avenue, it does sound very promising. A side note regarding GCJ. I realize everyone always complains that Java uses up tons of memory, and if only we had native apps it'd magically allocate out of thin air ;) Unfortunately, while the overnight router test did well - the VM size did not grow during operation - the virtual size is larger than with Sun's jvm: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 23171 i2p 16 0 535m 49m 11m S 0.0 5.7 93:58.80 router 23435 i2p 18 0 263m 80m 11m S 0.0 9.2 55:48.84 java The GCJ operational speed was sufficient, though as it uses the weak PRNG, so its not really a reasonable comparison. In any case, this is quite kickass, as it means we'll be able to both integrate more cleanly with other languages AND ship whereever GCJ ships (DFSG friendly!) Thanks go to the GCJ and GNU Classpath folks for their hard work! =jr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDV5icWYfZ3rPnHH0RAnn8AJ9MuDJFpzGup+gPpecBMerNg+x13wCdE9Po 0ALZZ2knBGYm5J9+kjCnZlU= =aSJz -----END PGP SIGNATURE-----
--- End Message ---
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath