commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Herrmann <>
Subject Re: [bcel] perspective?
Date Tue, 06 Oct 2015 21:30:55 GMT
Thanks, Mark,

This is very helpful information!

Please don't read my questions as demanding.
I know the tragedy of the commons.

As an Eclipse committer I'm used to time-boxed releases, but I understand
that things work differently at Apache. OK.

After playing a bit with an RC of BCEL 6.0 I have one more question:
I see that progress has been made to support the mandatory StackMapTable,
but BCEL does not automatically update this when modifying / creating an
instruction list.

So, how are people using (going to use) BCEL 6 on a JVM 8, in particular,
tools that need to create new byte codes? Are you happily adding new
Frames to the StackMapTable as you insert instructions?
In our existing implementation we forced the class file version of
modified classes to be 50.0 so that falling back to the old verifier
would still work. This probably won't work as soon as bytecodes
contain lambdas, right?

Anybody using BCEL to transform Java 8 bytecodes?


On 10/04/2015 11:22 PM, Mark Thomas wrote:
> On 04/10/2015 17:56, Stephan Herrmann wrote:
>> Hence, my primary question: can we realistically expect a release of
>> BCEL 6.0 any time soon?
> Define soon. Progress is being made. The more folks that contribute
> (particularly patches and reviews of proposed patches) the faster that
> progress will be. There is no set date I am aware of.
> I'll note at this point there has been an awful lot of people demanding
> more progress in BCEL and very few actually stepping up and contributing.
>> Secondly, what happens when future versions of Java introduce new
>> bytecodes? Currently it seems like Java 9 will only introduce one new
>> access flag and a new attribute, but of course future additions can
>> never be ruled out. Is there any commitment in the BCEL team to
>> support future bytecodes? I would be happy to help by way of bug
>> reports, possibly patches, but obviously some committer(s) would need
>> to drive this process. Is this something I could expect?
> As long as BCEL is in Commons proper then that is a reasonable expectation.
> Tomcat depends on BCEL so it is a safe bet that BCEL will be updated to
> handle any parsing issues that emerge with new bytecodes. However,
> Tomcat depends on fork of the source so it doesn't drive BCEL releases.
>> Lastly, already in version 5.2 we had to patch two files, because two
>> mutable static fields in BCEL prohibit the use in a multi threaded
>> application [3]. Note, that I'm not asking to make BCEL thread safe,
>> just to make client-side synchronization possible (without forcing
>> "stop-the-world-we-want-to-call-into-bcel"). As we have a modified
>> version of the two affected classes in use for several years, I wonder
>> if the proposed change could get some support?
> Sounds reasonable to me. Open a Jira, provide the patch and someone
> should take a look.
>> In all those years we were quite happy with BCEL. Unfortunately, we
>> have to make a hard decision pretty soon. From what I saw on this list,
>> I'm not sure, if staying with BCEL is viable.
> Only you can make that choice.
> Mark
>> Can anyone comment?
>> TIA,
>> Stephan
>> --
>> [1]
>> [2]
>> [3]
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message