> > I recently tried to build Classpath and discovered that to build > > gjavah and grmic, ASM is required. "No problem", thought I, and > > downloaded the latest version. Oddly, that didn't work. > > > > So, I downloaded a few more versions of ASM until I found a version > > that did work: version 2.3. This looked very odd to me, as I would > > have expected such a utility library to be backwards compatible. But > > no, it isn't, and there have been discussions about this on the ASM > > mailing list. To summarize, they have no intention of providing a > > stable API, ever. Their response when someone points out that they > > have conflicting requirements for different versions of ASM in the > > same application, is "Tools and frameworks that are using ASM for > > bytecode processing (e.g. Hibernate, CGLIB, AspectWerkz) should > > repackage ASM code within their own name space. This can be automated > > with Jar Jar Links tool." > > > > We don't want to package an ASM binary file within Classpath. I > > imagine we don't want our own copy of the binary either. gcj Version > > 4.3 will require gjavah, so I want to find a clean solution for this > > problem. > > > > I suggest that we give up on ASM and move to a bytecode manipulation > > library whose public API isn't going to incompatibly change with every > > release. I imagine that gnu.bytecode would be a good choice, but am > > open to other suggestions. Perhaps gnu.bytecode could be part of > > Classpath.
> > Audrius Meskauskas writes: > 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. OK, that's good. So, my main problem is to free gjavah from ASM. I'll have a look at what might be required. Per, if you're listening: may we incorporate gnu.bytecode within classpath? It surely makes more sense there than as part of Kawa. Andrew.
