Hi Stephen, The PROPOSAL was never to "terminate" BCEL, but instead to put up a warning to new users that ASM is generally regarded as being a better tool.
Right now the situation is that there are a fair number of BCEL users, but almost no BCEL developers. And, as you say, BCEL has a fair number of serious problems; some of them fixable via patches and some of them fundamental architecture stuff. It's not fair to "acquire" new BCEL users if we know that BCEL really isn't the best choice - and the general consensus seems to be that ASM is better than BCEL. BCEL is certainly going to "be kept alive" in the sense that the source code is not going to be deleted from the Apache servers, and the mailing lists and forums aren't going anywhere. So in that sense you're already better off than if BCEL was a commercial library. And the license entitles you to fix problems yourself and include the fixed stuff in your product, so again better than depending on a commercial library. Hopefully we (the existing BCEL committers, and the Jakarta community in general) can maintain enough developer enthusiasm to ensure basic patches are applied when users submit them. Whether anything more occurs depends on members of the user community (that includes you) becoming the development community by first contributing enough patches to prove ability, then being willing to become maintainers themselves. Over the last year or two this hasn't happened enough; quite possibly because people prefer to contribute to ASM instead. It would be very much appreciated if you could describe the "classes of applications that would be suitable for BCEL but not ASM". This question was asked on this list just a few weeks ago, and no-one could describe one. As you're clearly an experienced developer dealing with java bytecode stuff, have you considered becoming a BCEL maintainer yourself? You could then fix those things that you need directly in the product (rather than having to submit patches and wait, or maintaining your own patched copy of the source). If you want to submit a couple of patches, I would definitely make sure they get processed promptly, and then we can talk about making you an official maintainer. Of course that would need the agreement of the existing BCEL maintainers. The alternative, of course, is for you to consider enhancing ASM to include the features you need but which are missing. Is that more or less work than you becoming a BCEL maintainer and fixing the issues in BCEL that you need fixed? Regards, Simon On Fri, 2005-05-27 at 23:38 +1200, Stephen Cheng wrote: > Simon and Torsten, > > I have a bit of mixed feeling about this "termination" of BCEL development. > Our product mBooster (www.innaworks.com/mBooster.html) makes use of BCEL as > its input/output adapter. When we started work on mBooster, ASM was not > mature enough. We had our share of minor issues with BCEL, but on the whole > it served us well. > > Sections of BCEL are extremely buggy: The verifier is a joke if you are > serious about specification compliance. Someone else mentioned repository. > The Jasmin converter generates incorrect code. CCK has one of the worse UI > ever, and has some insidious corruption bugs as well. We have not relied on > the support on the mailing list, as we had not particularly found it useful. > We have occasionally submitted bug patches, but again we found the > committers generally not too interested. > > However as a user I would not like to see BCEL terminated. I still think > there are classes of applications that would be suitable for BCEL but not > for ASM. mBooster is one of them. In general BCEL is stable, and does what > it needs to do. It is unlikely we need to add new features to BCEL, aside > from keeping up with JVM specification update. So my suggestion is to: > 1. Keep BCEL alive > 2. Strip out/remove the parts that are useless/very buggy > 3. Fill in remaining functionality that we need to add - I can't think of > much really > > For your interest, you might like to know mBooster is the first commercial > J2ME bytecode optimizer implementing a full blown SSA compiler framework and > advanced optimization technologies. > > Kind regards, > Stephen > > -----Original Message----- > From: Simon Kitching [mailto:[EMAIL PROTECTED] > Sent: Thursday, 19 May 2005 2:42 p.m. > To: BCEL Developers List > Subject: Re: proposal to post deprecation notice on BCEL webpage > > On Thu, 2005-05-19 at 11:51 +1000, Torsten Curdt wrote: > > > Given the nearly universal opinion expressed in the recent email thread > > > titled "comparison between BCEL and ASM": > > > http://marc.theaimsgroup.com/?l=bcel-dev&m=111149200909727&w=2 > > > I think it would be a good idea to update the BCEL welcome page to note > > > that while BCEL will continue to be maintained, new users are encouraged > > > to use ASM. > > > > ...only bugfixing the last release? > > Probably. Not *necessarily*, but it depends upon developers stepping up > to do stuff. > > Right now, we have a tiny bit of your time, and a tiny bit of Dave's > time. That's the entire development commitment. > > And I can't see anybody else stepping up, as ASM is already better than > BCEL - why would anyone want to waste time improving BCEL? I can see > minor fixes going in from existing BCEL users, as projects that already > use BCEL strike problems. But if a BCEL-using project wants *major* new > features, it is probably easier for them to move to using ASM than to > fix BCEL. And no-one is going to fix BCEL for them. > > So I feel that letting people believe that BCEL will have any kind of > future significant development is just misleading them unless you know > something I don't. > > > > > > Are there any objections to me doing this? If I don't hear any within > > > the next 3 days I will make this change to the website. > > > > Hm... that's quite a big thing. > > We should do a vote on that. > > Ok, fair enough. > > > > > Maybe it would be worth also > > asking on bcel-user what they > > think about that. > > Well, their opinion is irrelevant unless they volunteer to do > significant development on BCEL, or are willing to provide funds to hire > someone to do BCEL development. See my comment re developer time above. > > I guess we could do a "wake up" call on the user list to see if anyone > is actually motivated enough to become a BCEL developer.. > > > > > I personally would like to play > > a bit with ASM before casting > > my vote. > > Please do. > > There's no hurry on this, so I'll wait until you've made up your mind > before calling a vote. Will you be able to do this within the next 2 > weeks? > > Regards, > > Simon > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
