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?
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: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
