Below I have listed (and categorized) the suggestions FindBugs has made which I think may be valid:
=== BEGIN SUGGESTIONS ===
"Dubious" constructor invocations:
Dm: org.apache.bcel.classfile.JavaClass.<clinit>() invokes dubious Boolean constructor; use Boolean.valueOf(...) instead
Dm: org.apache.bcel.verifier.structurals.LocalVariables.toString() invokes dubious new String() constructor; just use ""
Invocations of System.exit(...):
Dm: org.apache.bcel.classfile.Utility.codeToString(org.apache.bcel.util.Byte Sequence,ConstantPool,boolean) invokes System.exit(...), which shuts down the entire virtual machine
Dm: org.apache.bcel.util.CodeHTML.codeToHTML(ByteSequence,int) invokes System.exit(...), which shuts down the entire virtual machine
A number of subclasses of org.apache.bcel.generic.Type define equals(...) but inherit Object.hashCode().
Personally I would suggest adding an abstract equals(Object) and hashCode() to org.apache.bcel.generic.Type.
HE: org.apache.bcel.generic.ArrayType defines equals and uses Object.hashCode()
HE: org.apache.bcel.generic.BasicType defines equals and uses Object.hashCode()
HE: org.apache.bcel.generic.ReturnaddressType defines equals and uses Object.hashCode()
Other major classes that define equals(...) but inherit Object.hashCode():
HE: org.apache.bcel.generic.Instruction defines equals and uses Object.hashCode()
HE: org.apache.bcel.generic.LocalVariableGen defines equals and uses Object.hashCode()
Verifier classes that define equals(...) but inherit Object.hashCode():
(I am less certain as to whether these are actually bugs)
HE: org.apache.bcel.verifier.VerificationResult defines equals and uses Object.hashCode()
HE: org.apache.bcel.verifier.structurals.Frame defines equals and uses Object.hashCode()
HE: org.apache.bcel.verifier.structurals.LocalVariables defines equals and uses Object.hashCode()
HE: org.apache.bcel.verifier.structurals.OperandStack defines equals and uses Object.hashCode()
Serializable classes with non-transient non-serializable members:
Se: Serializable Class org.apache.bcel.classfile.InnerClasses defines non-transient non-serializable instance field org.apache.bcel.classfile.InnerClasses.inner_classes
Se: Serializable Class org.apache.bcel.classfile.StackMap defines non-transient non-serializable instance field org.apache.bcel.classfile.StackMap.map
Se: Serializable Class org.apache.bcel.util.ClassPath$Zip defines non-transient non-serializable instance field org.apache.bcel.util.ClassPath$Zip.zip
Se: Serializable Class org.apache.bcel.util.ClassLoaderRepository defines non-transient non-serializable instance field org.apache.bcel.util.ClassLoaderRepository.loader
Se: Serializable Class org.apache.bcel.verifier.VerifyDialog defines non-transient non-serializable instance field org.apache.bcel.verifier.VerifyDialog.ivjEventHandler
Serializable classes without a declared serialVersionUID:
SnVI: org.apache.bcel.generic.InstructionHandle is Serializable; consider declaring a serialVersionUID
SnVI: org.apache.bcel.generic.InstructionList is Serializable; consider declaring a serialVersionUID
SnVI: org.apache.bcel.util.ClassPath$Dir is Serializable; consider declaring a serialVersionUID
SnVI: org.apache.bcel.util.ClassPath$Zip is Serializable; consider declaring a serialVersionUID
Misspelled method names:
Nm: Class org.apache.bcel.generic.ArrayType defines hashcode(); should it be hashCode()?
Unused field:
UuF: Unused field: org.apache.bcel.generic.InstructionFactory$MethodObject.arg_names
Other minor suggestions:
It: org.apache.bcel.generic.InstructionList$1.next() does not throw NoSuchElementException appropriately
SIC: Should org.apache.bcel.verifier.statics.Pass2Verifier$InnerClassDetector be a _static_ inner class?
=== END SUGGESTIONS ===
I hope these are useful.
- David
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
