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. Mark > > 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 >>> -- >>> https://projects.eclipse.org/users/stephan-herrmann >>> >>> >>> [1] http://www.eclipse.org/objectteams >>> [2] http://www.eclipse.org/orbit >>> [3] https://issues.apache.org/jira/browse/BCEL-267 >>> >>> --------------------------------------------------------------------- >>> 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] >> > > > --------------------------------------------------------------------- > 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]
