ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Glick <>
Subject Re: [Patch] ChangeLogParser - hiding field
Date Tue, 21 Dec 2004 00:56:53 GMT
Kev Jackson wrote:
>> 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.

Well, think of it from the other side - if you *don't* make it final, 
you're essentially inviting anyone to subclass it for any reason, and 
promising that whatever they do, any changes you make to the class will 
work with their subclass. Do you know how they're going to subclass it? 
Which methods are they going to override, exactly, in which combination? 
Are any of the overridable methods called from the constructor? If you 
use a synchronization monitor, are they going to use the same one? If 
you decide to deprecate one method in favor of a new one you add, how 
will the class behave if subclasses are still overriding the old one? Is 
the class comparable, or does it use equals(), is it clonable or 
serializable or externalizable? There's a surprisingly large number of 
ways you can get into a royal mess as APIs evolve, at least in my 
experience, and nonfinal classes are much harder to reason about.

An example: javax.swing.tree.TreePath is nonfinal. The authors of the 
class were polite enough to even provide a no-arg subclass constructor 
and things like this. So this sounds cool - you can make a special 
TreePath that is specialized to unusual JTree storages! Well, 
unfortunately, no - it turns out that it is not possible to subclass it 
usefully, since you can't get rid of some of the fields in the 
superclass, and you can't make equals() work correctly with 
non-subclassed TreePath's, and in fact the Javadoc for the class lies 
about which methods you really need to override together. But you would 
never notice this kind of thing looking at the class casually.

On the other hand, if you make a class final, and it turns out later 
that there is a good reason to subclass it, and it seems safe and 
effective, you can remove the final modifier then, without breaking 

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

Oh yes... I still feel pretty clueless about a lot of Ant internals - 
e.g. macrodefs! - so I wind up posting about something I can recognize. :-)


Jesse Glick <> x22801
NetBeans, Open APIs  <>

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

View raw message