[RFC][icedtea-web:netx]: findbugs "bug"fixes
dlila at redhat.com
Wed Mar 9 07:17:52 PST 2011
The attached patch includes some more fixes for issues
found by findbugs.
Mostly they're just making inner classes static,
making a few members of Serializable objects transient,
removing unused code, and in one case adding type
parameters to a Map.
Some non-trivial changes are:
+ * netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java
+ Remove unused import.
+ (getNativeDir): Improve random int computation.
+ (CodeBaseClassLoader): Make it a static class.
+ * netx/net/sourceforge/jnlp/JNLPFile.java
+ (JNLPFile): Improve random positive int computation.
I replaced new Random().nextInt() with Math.random()*max_int
and (Math.random()*2-1)*max_int. The latter was to avoid
creating the needless Random object, which doesn't produce
good random numbers anyway. The former was because we used
to have abs(new Random().nextInt()), so supposedly we were
trying to get a random positive int. This doesn't work because
abs is not guaranteed to return a positive number, and if we
ever tried to parse the string we were creating we could have
been in trouble. It might have been better to keep a static
Random() object, but for so few uses, it didn't seem worth it
to add a member.
+ * netx/net/sourceforge/jnlp/cache/ResourceTracker.java
+ (lock): Initialize to Object() instead of Integer(0).
Not sure why we were creating an Integer(0) for a lock. An Object
should be enough. Also, I made it final, because most of the time
it does not make sense to have a lock whose only reference can change.
+ * netx/net/sourceforge/jnlp/services/ServiceUtil.java
+ (checkAccess): Replace new Boolean with Boolean.valueOf.
We weren't comparing the Boolean using ==, so getting a cached
object should be fine.
This patch contains changes that I thought would be nice to have
but would trivially not break anything (I built and tested it and
it works). However, they only solve about 30% of findbugs' complaints.
Most of the rest are false positives, except perhaps
6 of "Inefficient use of keySet iterator instead of entrySet iterator",
8 of "Maps and sets of URLs can be performance hogs",
3 of "Method concatenates strings using + in a loop", and
10 of "Method ignores exceptional return value" on delete() and mkdirs()
Should these be handled (in particular the last one, since the
other three are just performance related)?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 13410 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110309/3a036794/netxCleanup.patch
More information about the distro-pkg-dev