goals for fc4?

[Nicolas Mailhot]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Ceci est une partie de message
	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20050117/3123f8ca/attachment-0002.bin