Thomas Fitzsimmons writes: > Audrius Meskauskas wrote: > > Only part of RMIC (direct bytecode generation) is really dependent from > > ASM. That part which supports the source code generation is not > > dependent, was a separate compiler in the past and can be easily > > separated apart again. If we do not like ASM, this should make using the > > alternative replacement easier, as only the bytecode generating part > > needs to be rewritten. The classes being generated are also relatively > > simple. > > The direct bytecode generation is needed for performance and > compatibility reasons. If ASM is replaced with gnu.bytecode, then the > direct bytecode generation RMIC should be ported rather than removed. > > FWIW, porting from ASM 1.x to ASM 2.x was not very involved, and the > update from 2.x to 3.x was even more trivial: > > http://lists.gnu.org/archive/html/cp-tools-discuss/2006-03/msg00000.html > > I'm not sure trivial porting work between versions warrants an all-out > replacement. Sure it does. At the present time, gcj is mostly self-contained, but we're soon to be adding a new dependency: ecj. We also need gjavah to work, and at the moment that needs ASM. That's one more external dependency for gcj, and one with an unstable API. Having gcj depend not only on ASM but also on a *specific version* of ASM is intolerable. If gnu.bytecode will do the job, we should use it. Andrew.
