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. Andrew.
