ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Glick <>
Subject Re: [Patch] removed deprecated methods and changed variable scope (private-protected) ProjectHelperImpl
Date Fri, 10 Dec 2004 21:02:42 GMT
Peter Reilly wrote:
>> OK, I agree that all fields *should* be private, but in these
>> cases, the fields are in inner classes (I never declare more than
>> one class in a source file, so I'm not sure that all of these are
>> inner classes, but bear with me), so the visibility of the field is
>> restricted to the Class that the inner class is in correct?  And as
>> such it is actually "private" to other classes even if it's
>> declared protected.
> Yes you are correct about the visiblity, however it is not necessary
> to do this (even if eclipse does whine!).

1. The issue is not so much one particular compiler whining (e.g. PMD 
also displays the same warning, I think), as that you really are 
bloating the bytecode a bit by forcing use of a generated accessor method.

2. What about using package-private access? It should remove the need 
for a generated accessor, since the legitimate uses (within the same 
*.java) are certainly within the same package; yet the field does not 
become visible to clients of the Ant "API" such as custom tasks (unless 
they are super-evil and declare themselves to be in some Ant package).

> The problem is that there will be a big pile of "good" protected
> keywords when one is looking for "bad" protected keywords, the rule
> "no protected fields" is easier to follow than "no protected fields,
> except where eclipse whines!"

Do you really look for the keyword "protected" as such? Wouldn't it be 
better to examine actual Javadoc, which filters out everything from 
private nested classes, for example?


Jesse Glick <> x22801
NetBeans, Open APIs  <>

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message