Tag List report – Apache Commons BCEL (original) (raw)
org.apache.bcel.Constants
Line
mutable public array!!
org.apache.bcel.PLSETest
Line
need for real assertions here
org.apache.bcel.classfile.AccessFlags
Line
not used externally at present
org.apache.bcel.classfile.AnnotationEntry
Line
return List
org.apache.bcel.classfile.Annotations
Line
Auto-generated method stub
org.apache.bcel.classfile.Attribute
Line
make private (has getter & setter).
org.apache.bcel.classfile.BootstrapMethod
Line
should this throw?
org.apache.bcel.classfile.BootstrapMethods
Line
this could be made final (setter is not used)
org.apache.bcel.classfile.Code
Line
this could be made final (setter is not used)
this could be made final (setter is not used)
org.apache.bcel.classfile.CodeException
Line
should this throw?
unused
unused
org.apache.bcel.classfile.CodeExceptionTest
Line
--No comment--
org.apache.bcel.classfile.Constant
Line
should be private & final
should this throw?
org.apache.bcel.classfile.ConstantCP
Line
make private (has getter & setter) This field has the same meaning for all subclasses.
make private (has getter & setter)
org.apache.bcel.classfile.ConstantPool
Line
should this throw?
org.apache.bcel.classfile.ConstantUtf8
Line
these should perhaps be AtomicInt?
org.apache.bcel.classfile.ElementValue
Line
isRuntimeVisible
should be final
should be final
org.apache.bcel.classfile.InnerClass
Line
should this throw?
unused
unused
org.apache.bcel.classfile.InnerClasses
Line
this could be recoded to use a lower level constructor after creating a copy of the inner classes
org.apache.bcel.classfile.JavaClass
Line
Check if assignment compatibility is sufficient. What does Sun do?
make protected?
org.apache.bcel.classfile.JavaClassCyclicTest
Line
Use the test method once ClassCircularityError is implemented for this case test(cyclicTestClass::getAllInterfaces); TOOO Remove once the above is used
org.apache.bcel.classfile.LineNumber
Line
should this throw?
org.apache.bcel.classfile.LineNumberTable
Line
could use the lower level constructor and thereby allow lineNumberTable to be made final
org.apache.bcel.classfile.LocalVariable
Line
should this throw?
unused
unused
unused
unused
org.apache.bcel.classfile.MethodParameter
Line
should this throw?
org.apache.bcel.classfile.ModuleExports
Line
should this throw?
org.apache.bcel.classfile.ModuleOpens
Line
should this throw?
org.apache.bcel.classfile.ModuleProvides
Line
should this throw?
org.apache.bcel.classfile.ModuleRequires
Line
should this throw?
org.apache.bcel.classfile.ParameterAnnotationEntry
Line
isRuntimeVisible
org.apache.bcel.classfile.StackMapEntry
Line
unused
unused
org.apache.bcel.classfile.StackMapType
Line
should this throw?
org.apache.bcel.generic.BranchHandle
Line
could be package-protected?
org.apache.bcel.generic.CPInstruction
Line
could be package-protected?
org.apache.bcel.generic.ClassGen
Line
Sometime later, trash any attributes called 'RuntimeVisibleAnnotations' or 'RuntimeInvisibleAnnotations'
could be package-protected - only called by test code
could be package-protected - only called by test code
org.apache.bcel.generic.CodeExceptionGen
Line
could be package-protected?
could be package-protected?
could be package-protected?
org.apache.bcel.generic.ConstantPoolGen
Line
should this be handled somehow? } else if (c instanceof org.apache.bcel.classfile.ConstantMethodHandle) {
should this be handled somehow? } else if (c instanceof org.apache.bcel.classfile.ConstantModule) {
should this be handled somehow? } else if (c instanceof org.apache.bcel.classfile.ConstantPackage) {
should this be handled somehow? } else { // Not helpful, should throw an exception. assert false : "Unexpected constant type: " + c.getClass().getName(); }
org.apache.bcel.generic.ElementValueGen
Line
isRuntimeVisible ??????????
org.apache.bcel.generic.FieldAnnotationsTest
Line
L...;?
org.apache.bcel.generic.FieldGenOrMethodGen
Line
could this be package protected?
could be package-protected?
could be package-protected?
could be package-protected?
org.apache.bcel.generic.GeneratingAnnotatedClassesTest
Line
L??;
org.apache.bcel.generic.Instruction
Line
check range?
org.apache.bcel.generic.InstructionHandle
Line
remove this method in any redesign of BCEL
org.apache.bcel.generic.InstructionList
Line
could be package-protected? (some test code would need to be repackaged)
should this be an error?
org.apache.bcel.generic.JavaHome
Line
Apache Commons 2.14.0: Use FilesUncheck
org.apache.bcel.generic.LDC
Line
useless check?
org.apache.bcel.generic.LineNumberGen
Line
could be package-protected?
could be package-protected?
org.apache.bcel.generic.LocalVariableGen
Line
could be package-protected?
could be package-protected?
org.apache.bcel.generic.LocalVariableInstruction
Line
could be package-protected?
org.apache.bcel.generic.MethodGen
Line
could be package-protected?
could be package-protected?
could be package-protected? (some tests would need repackaging)
could be package-protected? (some tests would need repackaging)
could be package-protected?
org.apache.bcel.generic.ReferenceType
Line
Above sounds a little arbitrary. On the other hand, there is no object referenced by {@link #NULL} so we can also say all the objects referenced by {@link #NULL} were derived from {@link Object}. However, the Java Language's "instanceof" operator proves us wrong: "null" is not referring to an instance of {@link Object} :)
Is there a proof of {@link #OBJECT} being the direct ancestor of every ArrayType?
Above sounds a little arbitrary. On the other hand, there is no object referenced by {@link #NULL} so we can also say all the objects referenced by {@link #NULL} were derived from {@link Object}. However, the Java Language's "instanceof" operator proves us wrong: "null" is not referring to an instance of {@link Object} :)
Is there a proof of {@link #OBJECT} being the direct ancestor of every ArrayType?
The above line is correct comparing to the vmspec2. But one could make class file verification a bit stronger here by using the notion of superinterfaces or even castability or assignment compatibility.
Check if this is still valid or find a way to dynamically find out which interfaces arrays implement. However, as of the JVM specification edition 2, there are at least two different pages where assignment compatibility is defined and on one of them "interfaces implemented by arrays" is exchanged with "'Cloneable' or 'java.io.Serializable'"
org.apache.bcel.generic.Select
Line
could be package-protected?
org.apache.bcel.generic.Type
Line
should be final (and private)
org.apache.bcel.util.BCELifierTest
Line
detect if JDK present and skip test if not
org.apache.bcel.util.Class2HTMLTest
Line
assertions on generated HTML code
org.apache.bcel.util.ClassQueue
Line
not used externally
org.apache.bcel.verifier.statics.Pass1Verifier
Line
Maybe change Repository's behavior to throw a LoadingException instead of just returning "null" if a class file cannot be found or in another way be looked up.
org.apache.bcel.verifier.statics.Pass2Verifier
Line
rework it.
implement. Are there any restrictions?
org.apache.bcel.verifier.statics.Pass3aVerifier
Line
From time to time check if BCEL allows to detect if the 'count' operand is consistent with the information in the CONSTANT_InterfaceMethodref and if the last operand is zero. By now, BCEL hides those two operands because they're superfluous.
Make this a binary search! The instructionPositions array is naturally ordered!
--No comment--
Check how BCEL handles (and will handle) instructions like IMPDEP1, IMPDEP2, BREAKPOINT... that BCEL knows about but which are illegal anyway. We currently go the safe way here.
see the do_verify() comments. Maybe we should really work on the byte array first to give more comprehensive messages.
Review Exception API, possibly build in some "offending instruction" thing when we're ready to insulate the offending instruction by doing the above thing.
Implement as much as possible here. BCEL does _not_ check everything.
org.apache.bcel.verifier.structurals.ControlFlowGraph
Line
implement caching!
remove. Only JustIce must not use it, but foreign users of the ControlFlowGraph will want it. Thanks Johannes Wust. throw new AssertionViolatedException("DID YOU REALLY WANT TO ASK FOR RET'S SUCCS?");
Can be performance-improved.
Put information in the brackets, for example Is this an ExceptionHandler? Is this a RET? Is this the start of a subroutine?
org.apache.bcel.verifier.structurals.ExecutionVisitor
Line
could be package-protected?
could be package-protected?
One could use a sophisticated analysis here to check if a type cannot possibly be cated to another and by so doing predict the ClassCastException at run-time.
org.apache.bcel.verifier.structurals.InstConstraintVisitor
Line
could be package-protected?
could be package-protected?
This can possibly only be checked using Staerk-et-al's "set-of-object types", not using "wider cast object types" created during verification. Comment it out if you encounter problems. See also the analogon at visitPUTFIELD|visitPUTSTATIC.
One day move to Staerk-et-al's "Set of object types" instead of "wider" object types created during the verification. "Wider" object types don't allow us to check for things like that below. constraintViolated(o, "The referenced field has the ACC_PROTECTED modifier, "+ "and it's a member of the current class or a superclass of the current class."+ " However, the referenced object type '"+stack().peek()+ "' is not the current class or a subclass of the current class."); }
Could go into Pass 3a.
--No comment--
Do we want to do anything with it? ConstantInterfaceMethodref cimr = (ConstantInterfaceMethodref) (cpg.getConstant(o.getIndex()));
This can only be checked when using Staerk-et-al's "set of object types" instead of a "wider cast object type" created during verification. if ( ! rFromStack.isAssignmentCompatibleWith(rFromDesc) ) { constraintViolated(o, "Expecting a '"+fromDesc+"' but found a '"+fromStack+ "' on the stack (which is not assignment compatible)."); }
This can only be checked if we're using Staerk-et-al's "set of object types" instead of "wider cast object types" generated during verification. if ( ! Repository.implementationOf(objRefClassName, theInterface) ) { constraintViolated(o, "The 'objRef' item '" + objRef + "' does not implement '" + theInterface + "' as expected."); }
This can possibly only be checked when using Staerk-et-al's "set of object types" instead of a single "wider cast object type" created during verification.
Could go into Pass 3a.
This can only be checked if using Staerk-et-al's "set of object types" instead of a "wider cast object type" created during verification. if (! (objectref.isAssignmentCompatibleWith(mg.getType())) ) { constraintViolated(o, "Type on stack top which should be returned is a '"+stack().peek()+ "' which is not assignment compatible with the return type of this method, '"+mg.getType()+"'."); }
org.apache.bcel.verifier.structurals.LocalVariables
Line
if ((locals[i] instanceof org.apache.bcel.generic.ReturnaddressType) && (lv.locals[i] instanceof org.apache.bcel.generic.ReturnaddressType)) { //System.err.println("merging "+locals[i]+" and "+lv.locals[i]); throw new AssertionViolatedException("Merging different ReturnAddresses: '"+locals[i]+"' and '"+lv.locals[i]+"'."); }
could be package-protected?
org.apache.bcel.verifier.structurals.Pass3bVerifier
Line
Throughout pass 3b, upper halves of LONG and DOUBLE are represented by Type.UNKNOWN. This should be changed in favor of LONG_Upper and DOUBLE_Upper as in pass 2.
the "oldchain" and "newchain" is used to determine the subroutine we're in (by searching for the last JSR) by the InstructionContext implementation. Therefore, we should not use this chain mechanism when dealing with exception handlers. Example: a JSR with an exception handler as its successor does not mean we're in a subroutine if we go to the exception handler. We should address this problem later; by now we simply "cut" the chain by using an empty chain for the exception handlers. if (v.execute(new Frame(u.getOutFrame(oldchain).getLocals(), new OperandStack (u.getOutFrame().getStack().maxStack(), (exc_hds[s].getExceptionType() == null ? Type.THROWABLE : exc_hds[s].getExceptionType())) ), newchain), icv, ev) { icq.add(v, (ArrayList) newchain.clone());
This is buggy, we check only the top-level return instructions this way. Maybe some maniac returns from a method when in a subroutine?
org.apache.bcel.verifier.structurals.Subroutines
Line
refer to the paper.
Implement caching.
can this be made private? CHECKSTYLE:ON
org.apache.bcel.verifier.tests.TestArrayAccess02Creator
Line
why is this not used
why is this not used
why is this not used
why is this not used
why is this not used
why is this not used
org.apache.bcel.verifier.tests.TestArrayAccess03Creator
Line
why is this not used
why is this not used
why is this not used
why is this not used
why is this not used
org.apache.bcel.verifier.tests.TestArrayAccess04Creator
Line
why is this not used
why is this not used
why is this not used
why is this not used
why is this not used
why is this not used
org.apache.bcel.verifier.tests.TestReturn01Creator
Line
why is this not used
why is this not used
why is this not used
why is this not used
org.apache.bcel.verifier.tests.TestReturn03Creator
Line
why is this not used
why is this not used
why is this not used
org.apache.bcel.visitors.CountingVisitor
Line
Auto-generated method stub
Auto-generated method stub
Auto-generated method stub