On Mon, 2005-05-30 at 15:42 +1200, Stephen Cheng wrote: > Simon, > > I guess for most application ASM is fully adequate. (This is from my age-old > memory, so I might be wrong) ASM is light-weight, i.e. it does not generate > objects for each instruction. This is a great architecture for a lot of > applications, but not for all. For our application, the heavy weight BCEL > approach is actually a plus. For simple peephole optimization, code > insertion, instrumentation generally a lightweight approach suffice. However > for heavy duty DFA, CFA, and whole method manipulation, sometimes a heavy > weight approach is better, since every instruction is an object. Mind you, > it won't be too difficult to add a heavy weight layer to ASM.
I'm not sure what you mean by "light weight" and "heavy weight". XML parsers commonly provide a SAX parser that simply emits parsing events to an arbitrary "listener" object. Users can use just this part if they want. And many XML parsers then provide a pre-built "listener" that takes these events and builds a DOM tree that represents the whole input in memory. Splitting the tool into layers allows people to use only the lower layer when that suits. ASM does exactly the same; a fairly small parser that emits "parsing events" (invokes "visitor" objects). And an optional listener (visitor) class that builds a complete tree representation of the input. When you use this visitor, every instruction is indeed represented as an object as far as I know. See: http://asm.objectweb.org/current/doc/javadoc/user/org/objectweb/asm/tree/package-summary.html Is this separation between event-based parsing and tree representation of the input what you meant by "light weight" vs "heavy weight"?\ See also: http://jroller.com/page/eu/20050517 > > I would consider BCEL a "marginally better" solution than ASM for some > limited classes of applications - especially those that need explicit > control all aspects of a method/class file. BCEL maintainers would be > totally "morally responsible" if the limitations of BCEL are spelt out, and > suggest when NOT to use BCEL and when to. Yes, honestly describing when and when not to use BCEL is what we would like to do. The problem is that we're struggling to find any cases where we *could* recommend BCEL as better than ASM. If you could take a few minutes to describe more fully how BCEL provides "explicit control (of) all aspects of a method/class file" where ASM does not we would all appreciate that. > > Anyway, we would be happy to consider becoming BCEL committers. What would > be commitment and responsibilities of a BCEL committer? There are no explicit "responsibilities", in that no committer is *forced* to do anything. However someone is likely to be accepted as a committer when: * They are willing to spend at least a couple of hours a week evaluating user patches or working on their own enhancements for the project. Someone who has less time than this available is probably better off not becoming a committer, though of course they are welcome to subscribe to the dev email list and comment on issues. * They respect the opinions of other developers on the project, eg by discussing potentially controversial changes openly on the development lists before committing changes to the source code repository. This can take a bit of getting used to for developers used to working in a commercial environment where people "own" the piece of code they work on. * They are willing to follow general open-source good development procedures. In particular, jakarta projects (and many others) make heavy use of unit tests, as this is the only feasable way to ensure product reliability in the absence of a commercial QA department. [even with a QA dept it is a good idea of course!] * They are aware of the issues related to breaking backward compatibility when there are (potentialy many) unknown users of the code. * They have general coding "good taste" The benefits of being a committer are: * you help speed up the flow of user patches into the product. And this results in a better project for *your* use. * you get a bigger say in how the project evolves -- again resulting in a better project for your uses. * you get your changes into the code with less delay and effort. Any possibly controversial changes still need to be discussed on the mailing lists, but you don't need to wait for some existing committer to get around to reviewing and committing your patch. * you get to return a little benefit to the community that (presumably) provided you with a useful tool. * you get to tell people that you are a maintainer of the product. > Due to our various changes over the years, our internal tree is no longer > compatible with BCEL. We have stripped portions of BCEL away, and also added > various bits to overcome problems of BCEL (repository for one :-) Well, if your code really has diverted from the main line to the point where maintenance of the main line code doesn't directly benefit you then becoming a maintainer would only fall under the charitable "returning something to the community" category. But if you still use the BCEL trunk code for at least some parts of your product, then helping BCEL with your time will help you too. Open-source projects are simply about providing a common forum where multiple people facing the same problem can join their efforts together instead of each inventing the same tool separately. It only works, though, when everybody *does* contribute. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
