commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [bcel] PLSE changes to BCEL
Date Mon, 26 Jan 2015 18:19:37 GMT
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 <markro@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.bourg@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message