Tom Tromey writes: > >>>>> "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes: > > Andrew> In particular, the type system and the rules for exception > Andrew> regions are different. Also, a "slot" in the .class format > Andrew> doesn't necessarily correspond to a variable in the source > Andrew> language. > > One way to look at this is: we really want to fix these things,
We can't. They're inherent. As far as I'm aware all bugs caused by this difference have been fixed in the current bytecode compiler (after much rewriting :-), but it's an "impedance mismatch" that doesn't go away. > because, e.g., we'll probably be compiling all the java code in FC to > objects from class files for the foreseeable future anyway (to avoid > huge divergences from upstream build setups). > > Moving to gcjx would turn "writing a 1.5 compiler" from a project > taking all of my time for the next year into a project that takes all > of my time for 2 months. Then we'd have more time to fix other > things. I understand that, but I don't believe it. IMO, integrating ecj in such an inelegant way would lead to perpetual maintenance problems, especially with bootstrapping. The great thing about the possibility of gcjx is that it's possible to get things right, with a clean separation of interfaces. I would contrast your proposed ecj interface with a "correct" (IMO, YMMV, etc) way to do it -- pass the parse trees from ecj to gcj, with none of this messing about with bytecode. I'm sure that's possible with ecj. But it still would lead to some fairly painful problems bootstrapping. This wouldn't affect us, because we always have a Java compiler of some kind on every system we use. > Andrew> In particular, > Andrew> .class files don't contain the full pathnames to source files. Apparently (says Per) there's a JSR around that we can use to fix this in a standard way. Andrew.
