build tool to detect autoboxing?

Question

Does anyone know of any style checkers or build tools that would flag autoboxing and unboxing from the build server?

I already have the eclipse option to flag it on my end, but not everyone in the project uses the same IDE or same settings. Finding it on the build side seems the only way to detect where it might creep into the project.

Phiphenomenon

Would this be some sort of tool to do static analysis on Java source code? – Squires

Answer 1

Findbugs will identify many specific cases of potentially problematic boxing issues. I linked directly to one example, but if you Ctrl-F for "box" in that page, you will find the rest quite easily. I think looking for specific boxing problems is better than wholesale flagging of everything. (in other words, I agree with 280Z28)

Pluralize

Answer 2

If you are using Eclipse, bring up the Preferences and go to Java - Compiler - Errors/Warnings. In the Potential programming problems section one of the options, you can turn on auto-boxing/unboxing as warning or error. This static analysis could be very useful when used with a profiler.

As 280z28 mentioned, it would be better to have a tool that found auto-boxing/unboxing cases which are called very frequently and therefor affect performance. I don't know of such a tool though.

Convalescent

Original poster did say that he was looking for something that would not require everyone on his team to use Eclipse. I'm in the same boat, where I have a team of developers that would like to prohibit use of autoboxing across the team without enforcing a particular IDE across the team. Unfortunately, I have yet to find a tool that does this outside of any particular IDE. – Mccollough

Answer 3

A better tool would be one that highlights auto-boxing on code paths that a profiler proves is slow due to boxing. Forcing explicit boxing is like avoiding garbage collection because it might be slow in an edge case. Let the tools do their job - compiler and language at expressing the actual problem you're working on, and profiler at catching performance issues. Explicit boxing is unnatural in the context of solving a problem because it shows language nuances that aren't part of the solution description.

Edit: Is this type of commentary appropriate here? I am actually trying to be helpful - in fact I've specifically thought in the past about a tool to identify instances of the CLI box opcode on hot paths.

Viipuri

@28OZ28: re commentary - I think it is appropriate. – Playback