On Sat, 2004-11-13 at 19:49, Tom Tromey wrote: > >>>>> "Bojan" == Bojan Antonovic <[EMAIL PROTECTED]> writes: > > Bojan> Java 5.0 has some new language extensions. Many (?) of them, like > Bojan> generics, are compiled in the way that the byte code binary is > Bojan> compatible to older versions. While extending GCJ to support the new > Bojan> language extensions can take a while, it should be easier that GIJ can > Bojan> run them. Does anybody know when those new binaries will be supported? > Bojan> Can it be done for GCC 4.0 ? > > Here are the minimal changes required to support 1.5 bytecode. > > * Make sure we recognize the new class file version number. > > * Change the bytecode verifiers to accept "ldc <class>" when the > bytecode in question came from a 1.5 file. (For the libgcj > verifier I already have a patch for this, it is in gcjx. It could > easily be merged.) > > * Change the interpreter and the bytecode front end to the compiler > to recognize this opcode. > > This set of changes is pretty easy. > > > Note that 1.5 adds many new classes. Code using these classes still > won't work on libgcj, at least until they are written. There is some > work in this area in the `generics' branch of the Classpath CVS > repository. > > In particular, attributes won't work properly at runtime, enums won't > work at all, the new enhanced "for" loop will only iterate over arrays > (since libgcj doesn't have Iterable), and auto-boxing will not work > (this requires new methods in the primitive wrapper classes). > > Static import is purely source-side, and varargs is also implemented > that way, so these will work fine. Generics ought to work fine as > well. > > Tom
If this is the case, then is there a good reason for not starting to include 1.5 changes, that will compile with pre-1.5 compilers, into the HEAD branch? There is a fair bit of code created by Tom in the generics branch, that would work fine in HEAD, AFAICS. This would mean: * better testing (as it gets used by all Classpath users, and included in distributions) * less problems with keeping generics in sync with the HEAD branch, especially when the point of merging finally does arrive * greater possibility of support for 1.5 bytecode by Free VMs It seems a shame to not support 1.5 bytecode, largely because it just calls methods that are absent from GNU Classpath (and, in the case of some of the most frequent ones, implemented in the generics branch). This does, however, conflict with the idea of getting to a 1.0 branch pretty soon. Comments? Cheers, -- Andrew :-) Please avoid sending me Microsoft Office (e.g. Word, PowerPoint) attachments. See http://www.fsf.org/philosophy/no-word-attachments.html "Value your freedom, or you will lose it, teaches history. `Don't bother us with politics' respond those who don't want to learn." -- Richard Stallman "We've all been part of the biggest beta test the world has ever known -- Windows" -- Victor Wheatman, Gartner
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
