Win a copy of Programmer's Guide to Java SE 8 Oracle Certified Associate (OCA) this week in the OCAJP forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Private methods unused are a matter of performance?

 
Eduardo Yañez Parareda
Ranch Hand
Posts: 93
IntelliJ IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello, in a project I'm working on are private methods that are used through reflection by Hibernate and another propietary framework.

The source code has been inspected by Findbugs. Since those private methods are not called from
any other project's class, Findbugs has reported performance issues because those are not used, but they are used...

The error reported by Findbugs is:

Performance - Private method is never called
Plugin: findbugs Key: UPM_UNCALLED_PRIVATE_METHOD
This private method is never called. Although it is possible that the method will be invoked through reflection, it is more likely that the method is never used, and should be removed.


Why could be considered a performance problem?.

However, I'm trying to convince developers to change those methods to protected or package-protected, but they don't
want because those methods don't have to be called by any class within the project but by Hibernate and the propietary framework. Any ideas?
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24212
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"Firebug" is a Javascript debugger for Firefox; I think you're talking about "Findbugs", which is a static source code analyzer, yes?

Anyway, if you had a thousand classes, and each of them had ten unused private methods, and the compiled code for each of those took up 100 bytes, then your JAR file would be one megabyte larger than it needed to be. A larger-then-needed JAR file will take longer to load than a smaller one; that's honestly the only measurable performance problem that I can imagine due to unused private methods.

Findbugs has many, many, MANY checks that it can do; please don't fall into the common trap of believing that each of those checks is actually useful for your team. Use the checks that make sense; ignore (turn off) the ones that don't. This one definitely doesn't.
 
Eduardo Yañez Parareda
Ranch Hand
Posts: 93
IntelliJ IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ernest Friedman-Hill wrote:"Firebug" is a Javascript debugger for Firefox; I think you're talking about "Findbugs", which is a static source code analyzer, yes?


Yes, it was a lapso



Anyway, if you had a thousand classes, and each of them had ten unused private methods, and the compiled code for each of those took up 100 bytes, then your JAR file would be one megabyte larger than it needed to be. A larger-then-needed JAR file will take longer to load than a smaller one; that's honestly the only measurable performance problem that I can imagine due to unused private methods.

Findbugs has many, many, MANY checks that it can do; please don't fall into the common trap of believing that each of those checks is actually useful for your team. Use the checks that make sense; ignore (turn off) the ones that don't. This one definitely doesn't.


Well, I think it's very important to detect unused private methods, because in large projects it's a matter of maintainance. I have downgraded the priority of this rule from critic to major, but that rule is not useless.
 
Tim Holloway
Saloon Keeper
Pie
Posts: 18277
56
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To the best of my knowledge, the Java compiler's optimizer is thorough enough that when it detects an obviously unusable resource, it will simply refuse to waste time or space compiling that resource. YMMV, however, depending on whether you compiled with debugging enabled.

A variation on this is automatic inlining. C++ was developed with an "inline" qualifier that notified the compiler that the qualified code was small enough and lightweight enough that the compiler could avoid setting up the call/return overhead and simply expand the code in-place at the point where it was "called". Java doesn't have this feature and it's my understanding that one reason why is that when the compiler detects that a method meets certain specified criteria, it will be inlined automatically. Short private methods are good candidates, for example.
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34839
369
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Eduardo Yañez Parareda wrote:I have downgraded the priority of this rule from critic to major, but that rule is not useless.

In general, it isn't useless. If it gives you a large number of false positives, it is. Who is going to keep going through the warnings to see when a real one shows up?
 
Eduardo Yañez Parareda
Ranch Hand
Posts: 93
IntelliJ IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeanne Boyarsky wrote:
In general, it isn't useless. If it gives you a large number of false positives, it is. Who is going to keep going through the warnings to see when a real one shows up?


Yes, I know it could be useless, but as you said sometimes it isn't, that's why I lowered the priority. Who is going to look it?, developers!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic