Le lundi 17 janvier 2005 Ã 08:29 -0500, Paul Iadonisi a Ãcrit : > On Mon, 2005-01-17 at 13:18 +0100, Nicolas Mailhot wrote: > > Le mercredi 12 janvier 2005 Ã 01:38 +0000, Michael A. Peters a Ãcrit : > > > > > not provide a repo mirror list. Maybe that should wait until jpackage > > > has their free j2sdk done (I understand they are working on one) > > > > Well, this is supposed to be secret stuff;) Please don't block on it - > > there may someday be a redistributable jvm rpm at jpackage, and someday > > may even be next week, but the $VENDOR we're working with obviously has > > its own paying products higher on the priority list so it's taking some > > time... > > Forgive my Java ignorance, but... > > J2SDK > JVM > GCJ > > How do these things intersect/complement each other? And are there > any missing pieces from the above to providing a complete Java > implementation (possibly without the official, trademarked 'Java' > name ;-))? J2SDK = java 1.2/1.3/1.4 JVM by SUN (seems they switched back to the JVM moniker for 1.5) Can we widened to englobe all the java extentions that end up in J2EE for example. gcj (very general term often used to englobe much more than gcj itself) ~ FOSS reimplementation of a JVM. Not 100% complete. Will probably never be 100 % complete or allowed to use official Sun logos. Strives to implement all the stuff FOSS java software cares about (sometimes doing tricks like asking the aforementioned FOSS software to stop using stuff they don't want to reimplement;) JPP is built using commercial JVMs. A growing number of packages are rebuildable using free implementations and that's what ending up in FC/ FC devel right now (sometimes it still works better with a commercial JVM thought). Someday we might hope there will be a 100% overlap, though I suppose FC will start filtering stuff they don't need (like silly games) way before all JPP is gcj-compatible. One of gcj's peculiarities is that it can generate native code instead of bytecode. So another characteristic of the stuff that ends in FC is that it is dual native/bytecode generated while JPP is pure bytecode at this stage. gcj is supposed to be better at executing native code than bytecode. I don't think there is anyone made the argument than gcj + native is faster than commercial jvm + bytecode. Regards, -- Nicolas Mailhot
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
