Naked dot - accessing object fields through unqualified

Joseph D. Darcy Joe.Darcy at Sun.COM
Thu May 14 22:26:56 PDT 2009

Derek Foster wrote:
> Replies inline.
> -----Original Message-----
>> From: Reinier Zwitserloot <reinier at>
>> Sent: Mar 31, 2009 9:03 AM
>> To: Derek Foster <vapor1 at>
>> Cc: coin-dev at
>> Subject: Re: Naked dot - accessing object fields through unqualified "." [C1]
>> 'Self-assignment is forbidden' would not be backwards compatibile.  
>> Yes, such code would most likely be a bug, but its still an issue. It  
>> would have to be a warning, at best.
> Personally, I think it should be an error, since there seems to be no valid reason to do it, and it almost certainly indicates a bug. I think that compilers should default to being in a 'strict' mode where things like this that have been found to be bad ideas with virtually no upside are treated as illegal, even if that makes them not fully backwards compatible. For backwards compatibility, there could be a command-line switch to turn off strict mode if necessary for compiling old code.
> Some other things I'd like to see in this category:
> * Having an abstract class with a constructor that has 'public' or 'private' access.
> * Using C-style array declarations. (int x[] instead of int[] x)
> I could probably think of a few more.


Some checks like this could be added as javac's lint analyzes and the 
lint warnings can be turned into errors using another flag to javac on 
an opt-in basis.

You can implement fatal warnings yourself using annotation processors in 
javac which access the javac-specific tree API; in a running annotation 
processor, the javax.annotation.processing.Messager object can be used 
to raise an error just as if javac itself did.


More information about the coin-dev mailing list