ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kev Jackson <>
Subject Re: [Patch] ChangeLogParser - hiding field
Date Mon, 20 Dec 2004 05:12:20 GMT
Jesse Glick wrote:

> Just jumping in here... :-)
Feel free ;)

> 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.

No, I've never worked on a true API project before.

> 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.
Good rule of thumb.

>> 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 {}

I've read many times that declaring a class as final is a farily 
dangerous thing to do with code.  Once you've made a class final people 
are stuck with what you decided at a particular moment was the right way 
to do things.  Can you truly know that the class will never have to 
change in the future?  That's a tough call to make.

> 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.
Thanks for the pointers.  As an aside, I'm very happy to have decided to 
get involved (no matter how little) in an open source project.  The 
amount of extra knowlegde that I'm gaining from just reading the mailing 
list and bug-reports and scanning the code for possible fixes etc is 
immense.  I'm not by any means a Java guru, but I do consider myself to 
be pretty good at Java - and within my company, I almost certainly am 
(aren't all developers ego-maniacs?)

But here I feel like a complete novice, practically every day I'm 
learning something new about a particular idiosyncratic aspect of Java - 
which is great!  I'm trying to convice one of my ex-colleagues to get 
involved on one of the jakarta projects (he's thinking of James as he 
currently uses it), and I can definitely say that one of the benefits is 
the amount that you learn (or can learn) from other developers.

So thanks for your thoughts, they've given me much to think about.

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

View raw message