javac -Xlint And Its Many Friends

-Xlint and its variations - so many to choose from! 1st -Xlint:unchecked

Or should I just use them all? Pick and choose? Just the one I'm interested in? What to do? What to do?  Like many I came across Xlint^(*1) when hitting the following message in one of my Ant builds a while back:

[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.  

Huh....I thought to myself....there shouldnt be any errors with my last change. Well looking closer this is just a warning not Ant reporting on a compilation failure.OK. But why does it appear. There doesn't seem to be any location information reporting to me what causes it like a good 'ole stack trace does.  So like countless others I looked up how to use this -Xlint:unchecked thingy and stuck it into my Ant build and re-ran my ant script build.xml......and was promptly swamped by 100's of lines of warning messages (all pretty much saying the same thing) complaining about my absolute poor lack of etiquette in the use (or lack thereof) of generics throughout my (what I thought up until then was) pristine code.  Turns out it wasn't and I was seriously thinking of taking the pesky compile option out since its 'only a warning anyways' and hence thereby effectively getting rid of all that nasty mess and clutter in my build output. 

Now, okay....I didn't go down that path of just sweeping things back under the rug when they happen to fall out ... and furthermore these days things aren't quite that bad and when I write new code generics are used properly and by default as required throughout the code so this really is more of an issue when converting legacy code or upgrading from Java 1.4 to 5/6+ etc. When I do come across these issues I promptly modify the code to resolve them, thereby not only removing a pesky warning from my pristine build output, clearing up my Netbeans GUI of warnings and .... well .... also as a tiny little almost insignificant side note ..... making the code more robust and providing a higher-level of compile time type safety checking (which is really what generics are all about aren't they!!).

-Xlint, naked without its ':unchecked' param!

So now you know all about -Xlint:unchecked for type-checking issues related to generics. It is however possible to simply use just:

-Xlint

....without the :unchecked option. A little naked the poor tool feels now. This effectively says to the compiler use the lint tool (via the -X property) and just call it without any parameters. This has the effect of calling lint and using all of its checks rather than, like in our case above for :unchecked, using just the generic checks/warnings (by passing through the 'unchecked' parameter to the lint tool.

-Xlint and all of :unchecked's many, many friends!

So then, what checks are possible? When calling -Xlint what is it that we are actually doing (besides popping up a huuuuuge amount of warnings in most cases).  Well, calling -Xlint is effectively the same as passing in several parameters to the lint tool. What are these parameters....well Ive listed them below as to what it is that you can add to the -Xlint call as arguments to determine what checks the javac compiler should make when compiling the code and what warnings it should then report back on.

-Xlint:{all,cast,deprecation,divzero,empty,unchecked,fallthrough,path,serial,finally,overrides}


Thats a lot of options. Here is some info about them from the javac compiler options page:

-Xlint

Enable all recommended warnings. In this release, all available warnings are recommended.

-Xlint:none

Disable all warnings not mandated by the Java Language Specification.

-Xlint:-name

Disable warning name, where name is one of the warning names supported for -Xlint:name, below.

-Xlint:unchecked

Give more detail for unchecked conversion warnings that are mandated by the Java Language Specification.

-Xlint:path

Warn about nonexistent path (classpath, sourcepath, etc) directories.

-Xlint:serial

Warn about missing serialVersionUID definitions on serializable classes.

-Xlint:finally

Warn about finally clauses that cannot complete normally.

-Xlint:fallthrough

Check switch blocks for fall-through cases and provide a warning message for any that are found. Fall-through cases are cases in a switch block, other than the last case in the block, whose code does not include a break statement, allowing code execution to "fall through" from that case to the next case. For example, the code following the case 1 label in this switch block does not end with a break statement:

switch (x) {
case 1:
       System.out.println("1");
       //  No  break;  statement here.
case 2:
       System.out.println("2");
}
     

If the -Xlint:fallthrough flag were used when compiling this code, the compiler would emit a warning about "possible fall-through into case," along with the line number of the case in question.

-Xlint:{all,cast,deprecation,divzero,empty,unchecked,fallthrough,path,serial,finally,overrides}-cast,-deprecation,-divzero,-empty,-unchecked,-fallthrough,-path,-serial,-finally,-overrides,none}Enable or disable specific warnings

Links
http://download.oracle.com/javase/6/docs/technotes/tools/windows/javac.html#nonstandard
http://mark.koli.ch/2009/04/configuring-ant-to-use-javacs--xlintunchecked-option.html

*1 - Well not quite....you see thinking back....Ill admit that lint I remember vaguely from my C Programming days back at university (in the dawn of the age in the mists of time back somewhere during the time period range in 1995 - 1999/2000).