Thank you for the detailed summary Mark.
Le 26/01/2015 19:02, Mark Roberts a écrit : > I'm currently not familiar with your release process and, hence, not sure > what sorts of changes you are willing to consider at this time. I thought I > would start with a rough outline of all of our changes and then the group > could suggest which ones I should open in JIRA. An important rule that drives many design decisions is that we never break the binary compatibility. And if we really have to, well... we don't :) Instead we roll out a new version under a new package name. Considering that we would like to publish BCEL 6.0 soon we will probably not merge involved changes now, but smalls fixes are welcome. > We cloned a version of the BCEL sources at Revision 1514334. > We updated to Revision 1646789 (2014-12-19) week of January 19-23, 2015. I don't know if you are familiar with Git but BCEL also has a mirror on Github. You may find it useful to rebase your changes as the trunk evolves. https://github.com/apache/commons-bcel > I was surprised by 'U' as that change had a huge side effect, possibly due to > a design flaw in how Targeters work; I was unable to find any discussion in > your archives. Could you elaborate a bit on this change? > During the past year, both the Apache Commons BCEL team and our group here at > UW independently completed the support for InvokeDynamic . Some things we > chose to do the same way, but there are a few items that are quite different. > Trying not to be too biased, I believe our method is better. One of the > larger differences is your decision to add the abstract class > NameSignatureMethod between FieldOrMethod and CPInstruction and then have > InvokeDynamic extend from that instead of from InvokeInstruction. To me this > seems wrong. In addition to forcing InvokeDynamic to duplicate all the > methods from InvokeInstruction and FieldOrMethod, it is awkward that it is > the only form of the Invoke Instruction that doesn't derive from > InvokeInstruction. (‘ID’ and ‘BM’ as well.) Good point, this should be investigated. > ‘B’, ‘H’, and ‘LV’ are important bug fixes. Isn't BCEL-79 already fixed? > I not sure why you chose not to complete the change from DataInputStream to > DataInput (‘I’). This was another item we did here at PLSE independent of > your work. Going all the way is nice, because tools that use BCEL can then > backup and reprocess the input class file. I stopped because some changes touched the public API. I reviewed that again today and managed to replace more occurrences, but the one in the AttributeReader interface can't be changed without breaking the binary compatibility and this affects some other classes. > A lot of the ‘TS’ changes were to make the BCEL output look more like the > ‘javap’ output; you may not care, but this was useful to some of our clients. This is a good idea. > Sorry for length of post and amount of information. We can divide into > separate threads If you wish. That's fine. These changes sound excellent, could you open one JIRA issue per change please? Thank you, Emmanuel Bourg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
