commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: [bcel] perspective?
Date Tue, 06 Oct 2015 21:37:01 GMT
On 06/10/2015 22:30, Stephan Herrmann wrote:
> 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?

Sorry, I've only gone as far as using BCEL to scan Java 8 to extract
annotations. Tomcat ignores 99% of the byte code.

> Anybody using BCEL to transform Java 8 bytecodes?

I believe some the people reporting issues against BCEL are doing
exactly that and reporting bugs when they hit issues.

Sorry I can't be of more help.


> thanks,
> Stephan
> 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:

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

View raw message