Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: pass (hermes.apache.org: domain of jak-ant-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@ant.apache.org
From: Jesse Glick <jesse.glick@sun.com>
Subject: Re: [Patch] ChangeLogParser - hiding field
Date: Fri, 17 Dec 2004 19:06:21 -0500
Organization: Sun Microsystems
Lines: 54
Message-ID: <cpvs9t$hda$1@sea.gmane.org>
References: <41C2514B.8080109@it.fts-vn.com>	 <m3u0ql6u3i.fsf@bodewig.bost.de>
 <1103284226.4266.40.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020
In-Reply-To: <1103284226.4266.40.camel@localhost.localdomain>
Sender: news <news@sea.gmane.org>

Just jumping in here... :-)

kj wrote:
>>>-class ChangeLogParser {
>>>+public class ChangeLogParser {
> 
> No really, just habit - company standards where I've worked in past etc.

Did your company produce Java components with publicly visible APIs they 
were committed to preserving indefinitely? Seriously, making and keeping 
a decent Java API is *hard* and almost no "good style for programmers" 
books give you workable recommendations. I've been working on NetBeans 
core APIs for several years and often regret some method that seemed 
harmless four years ago and was made public without careful planning. 
Not to mention the mess that is javax.swing.** Javadoc that it is too 
late to fix.

It is a bit unfortunate that the Ant team never published guidelines 
separating real APIs (intended for task authors, embedders, listener 
creators, etc.) from implementation (e.g. task classes). So now we are 
stuck with the situation that anything which is technically accessible 
in the Ant codebase is considered a full API automatically.

Generally, assume everything should be private and final unless you know 
how it should be called or overridden. In practice, static methods are 
usually not much of a burden to maintain public; instance methods and 
constructors more so; and nonfinal classes are very hard to maintain 
compatibly, since there is a huge amount of runtime semantics which 
subclasses typically rely on and which has to be documented explicitly 
and probably can never be changed.

> I suppose it could expose the class more than was intended, but again
> the only real rationale for this was that I was looking at the class and
> it's completely automatic (for me) to specify an exact access modifier
> for everything as shows your exact intentions.

For a top-level class, lack of a written access modifier *is* the one 
and only way to specify that it should be package-private, which is the 
most restrictive mode for it. When writing a new class, start with

static final class Foo {}

or for a nested class

private static final class Foo {}

and go from there. It is just unfortunate that the Java language has 
unsafe defaults for these modifiers.

-J.

-- 
Jesse Glick <mailto:jesse.glick@sun.com> x22801
NetBeans, Open APIs  <http://www.netbeans.org/>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org