Inspection is confused by 'interesting' code.

Perhaps the tool is indirectly pointing out poor code, but it does say this nor does it handle poor code well in some 'real world' cases.

0) For library writers, it would be useful to be able to include all public/protected methods as entry points. (possibly public/protected members as well)

1) The inspection tool reports volatile members which do not change as potentially final. When adding 'final' it does not concider the volatile thus producing a 'volatile final' member which results in a compiler error.
e.g. java.nio.MappedByteBuffer.isAMappedBuffer

2) The inspection tool can be smarter then the compiler. The tool believes a member could be final but the compiler complains. I agree with the tool, perhaps this is compiler bug ??
e.g. com.sun.corba.se.internal.orbutil.RepositoryId.defaultServerURL

3) The tools is confused by static variables being initialised in a constructor. Perhaps there should be an inspection tool for this!
e.g. All members of. java.swing.plaf.gtk.motif.MotifTreeUI.MotifExpandedIcon

4) The tool has a number of warnings about java.io.FileSystem . It states the members useCanonCaches and useCannonPrefixCache can be final. Again the tool is smarter than the compiler here. It could be refactored to be final, but the compiler will not acces the quick fix.

5) The tools do not concider the impact of native method calls. Variables which are not changed in the java code could be changed in the library. It would be useful to turn off some checks for classes which contain native code.

Great tool by the way. To scan the src.zip you only need 2 GB memory :)

1 comment
Comment actions Permalink

Great tool by the way. To scan the src.zip you only need 2 GB memory :)


I'm not sure are you trying to be sarcastic? I also wonder how much
memory (and time) do you need to make full code review of src.zip?

regards,
Dimiter

0

Please sign in to leave a comment.