Attaching a patch (or pull request) to a JIRA would be a great way for one of us to take a look at what you have. This is great stuff, man! We are always glad to have new folks come in and provide patches.
Out of curiosity, what was the reason you rolled your own as opposed to engaging with the community on these changes? On Mon, Jan 26, 2015 at 1:02 PM, Mark Roberts <mar...@cs.washington.edu> wrote: > 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. > > 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. > > Here is a list of files and reasons we differ from standard BCEL: > (The 'reason' codes in left hand column are enumerated below the file list.) > > C /bcel/classfile/AnnotationDefault.java > I /bcel/classfile/AnnotationEntry.java > D,I /bcel/classfile/Attribute.java > I /bcel/classfile/AttributeReader.java > BM,JD /bcel/classfile/BootstrapMethod.java > BM,JD /bcel/classfile/BootstrapMethods.java > I /bcel/classfile/ClassParser.java > I /bcel/classfile/Code.java > BM,ID,TS /bcel/classfile/ConstantCP.java > ID /bcel/classfile/ConstantInvokeDynamic.java > P /bcel/classfile/Constant.java > T /bcel/classfile/ConstantLong.java > BM,ID,TS /bcel/classfile/ConstantPool.java > BM,ID /bcel/classfile/DescendingVisitor.java > BM,ID /bcel/classfile/EmptyVisitor.java > C /bcel/classfile/EnclosingMethod.java > I /bcel/classfile/Field.java > I /bcel/classfile/FieldOrMethod.java > TS /bcel/classfile/InnerClasses.java > TS /bcel/classfile/InnerClass.java > T /bcel/classfile/JavaClass.java > JD /bcel/classfile/LineNumber.java > JD /bcel/classfile/LineNumberTable.java > TS /bcel/classfile/LocalVariable.java > TS /bcel/classfile/LocalVariableTypeTable.java > I /bcel/classfile/Method.java > T /bcel/classfile/RuntimeInvisibleParameterAnnotations.java > T /bcel/classfile/RuntimeVisibleParameterAnnotations.java > TS /bcel/classfile/SourceFile.java > S,I /bcel/classfile/StackMapTableEntry.java > I /bcel/classfile/StackMapTable.java > V,I,ID /bcel/classfile/Utility.java > BM,ID /bcel/classfile/Visitor.java > T /bcel/Constants.java > TS /bcel/generic/BranchInstruction.java > ID /bcel/generic/ConstantPoolGen.java > ID /bcel/generic/EmptyVisitor.java > P,ID /bcel/generic/FieldOrMethod.java > ID /bcel/generic/GETFIELD.java > ID /bcel/generic/GETSTATIC.java > ID /bcel/generic/InstructionFactory.java > P,U /bcel/generic/Instruction.java > ID /bcel/generic/INVOKEDYNAMIC.java > ID /bcel/generic/INVOKEINTERFACE.java > ID /bcel/generic/INVOKESPECIAL.java > ID /bcel/generic/INVOKESTATIC.java > ID /bcel/generic/INVOKEVIRTUAL.java > ID /bcel/generic/InvokeInstruction.java > D /bcel/generic/LineNumberGen.java > H /bcel/generic/LocalVariableGen.java > B,LV,TS /bcel/generic/MethodGen.java > ID /bcel/generic/PUTFIELD.java > ID /bcel/generic/PUTSTATIC.java > ID /bcel/generic/Visitor.java > M /bcel/PLSEMarker.java (new file) > P,TS /bcel/util/BCELifier.java > ID /bcel/util/CodeHTML.java > ID /bcel/util/InstructionFinder.java > D /bcel/util/SyntheticRepository.java > D /bcel/verifier/statics/Pass1Verifier.java > ID /bcel/verifier/statics/Pass3aVerifier.java > ID /bcel/verifier/structurals/ExecutionVisitor.java > P /bcel/verifier/structurals/Frame.java > D,ID,UT /bcel/verifier/structurals/InstConstraintVisitor.java > C,P,ML /bcel/verifier/structurals/LocalVariables.java > P /bcel/verifier/structurals/OperandStack.java > RS /bcel/verifier/structurals/Subroutines.java > > > B - BCEL bug #39695 (and #44083) (now BCEL-79) > BM - add support for BootstrapMethod(s) > C - better support for clone/copy methods > D - add some debugging code > H - fix problem with hash function > I - finish/complete change from DataInputStream to DataInput > ID - add/improve support for InvokeDynamic > JD - javadoc additions > LV - correct problem with missing local vars to anonymous init methods > M - marked class to identify our version of BCEL > ML - deal with superclass of type Object in merge of local variables > P - make some methods public (or not deprecated) for our use > RS - reduce JustIce restrictions on subroutines > S - improve StackMap support > T - fix typo, source formatting or cut/paste error > TS - improve toString or other output formatting > U - we need instructions to be unique > UT - allow unitialized types in PUTFIELD (can happen in a constructor) > V - add support for TypeVariable Signature > > > A few additional thoughts: > > You will definitely not want change 'M', probably not change 'P' either. > > 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. > > 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.) > > ‘B’, ‘H’, and ‘LV’ are important bug fixes. > > 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. > > 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. > > Sorry for length of post and amount of information. We can divide into > separate threads If you wish. > > Mark > > > -----Original Message----- > From: Emmanuel Bourg [mailto:emmanuel.bo...@gmail.com] On Behalf Of Emmanuel > Bourg > Sent: Friday, January 23, 2015 2:11 PM > To: Commons Developers List > Subject: Re: [bcel] new to list - introduction > > Le 23/01/2015 20:55, Mark Roberts a écrit : >> My name is Mark Roberts and I work in the Programming Languages and >> Software Engineering group (PLSE) at the University of Washington. >> (http://www.cs.washington.edu/research/plse) >> >> Our team develops and supports a number of open source tools. One of the >> main ones, Daikon (http://plse.cs.washington.edu/daikon/) makes extensive >> use of BCEL to manipulate Java class files. We have been using BCEL since >> 2001 and have made a few changes along the way. I have just completed >> re-merging our BCEL source tree with a fairly recent mainline version >> (r1646789 2014-12-19). >> >> I have exchanged email with Torsten Curdt and he suggested I join this >> mailing list as a first step in sharing our changes and fixes. > > Hi Mark and welcome to Apache Commons. We are about to release BCEL 6.0 but > it's still time to commit some minor changes. I plan to merge the recent > verifier improvement contributed by Jérôme Leroux and cut a new release > candidate shortly after. > > What kind of improvements would you like to contribute? We can start > discussing them on the list and then open related issues in JIRA. > > Emmanuel Bourg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
