Re: ASM and gnu.bytecode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Kernel]     [Linux Cryptography]     [Fedora]     [Fedora Directory]     [Red Hat Development]

  Powered by Linux