You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bcel-dev@jakarta.apache.org by David Foster <da...@earthlink.net> on 2005/01/23 03:41:40 UTC
Suggestions by FindBugs
A number of minor code anomalies in BCEL were detected by FindBugs
(http://findbugs.sourceforge.net/), a program which looks for bugs in
Java code via static analysis. I realize that a number of the detected
"anomalies" may be false positives, since they were computer-generated.
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: bcel-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
Re: Suggestions by FindBugs
Posted by Henri Yandell <fl...@gmail.com>.
Things were pretty positive on the PMC list about Dave being able to
commit. I'll try to wrap things up there and see how we all want to
handle it.
Trying to restart a community is new (at least to me) and making sure
we have sufficient How-To Apache support for Dave seems an important
step.
Hen
On Sat, 22 Jan 2005 22:10:29 -0500, Dave Brosius <db...@qis.net> wrote:
> Thanks. I have already posted a patch to bcel for the hashCode changes.
>
> Unfortunately, BCEL is sort of in a state of hibernation, as it would seem
> the committers have wandered off to bigger and better things. I am currently
> a developer on FindBugs, and am trying to get committer status for myself to
> BCEL thru the Jakarta PMC, but haven't heard yet. If any devs are still
> around, my apologies, but it would seem that the pressures of real life must
> have gotten to them.
>
> If i do I will address these issues, and others, and try to maintain it more
> regularly.
>
>
> ----- Original Message -----
> From: "David Foster" <da...@earthlink.net>
> To: <bc...@jakarta.apache.org>
> Sent: Saturday, January 22, 2005 9:41 PM
> Subject: Suggestions by FindBugs
>
> >A number of minor code anomalies in BCEL were detected by FindBugs
> >(http://findbugs.sourceforge.net/), a program which looks for bugs in Java
> >code via static analysis. I realize that a number of the detected
> >"anomalies" may be false positives, since they were computer-generated.
> >
> > 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: bcel-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
Re: Suggestions by FindBugs
Posted by Dave Brosius <db...@qis.net>.
Thanks. I have already posted a patch to bcel for the hashCode changes.
Unfortunately, BCEL is sort of in a state of hibernation, as it would seem
the committers have wandered off to bigger and better things. I am currently
a developer on FindBugs, and am trying to get committer status for myself to
BCEL thru the Jakarta PMC, but haven't heard yet. If any devs are still
around, my apologies, but it would seem that the pressures of real life must
have gotten to them.
If i do I will address these issues, and others, and try to maintain it more
regularly.
----- Original Message -----
From: "David Foster" <da...@earthlink.net>
To: <bc...@jakarta.apache.org>
Sent: Saturday, January 22, 2005 9:41 PM
Subject: Suggestions by FindBugs
>A number of minor code anomalies in BCEL were detected by FindBugs
>(http://findbugs.sourceforge.net/), a program which looks for bugs in Java
>code via static analysis. I realize that a number of the detected
>"anomalies" may be false positives, since they were computer-generated.
>
> 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: bcel-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: bcel-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: bcel-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: bcel-dev-help@jakarta.apache.org