[jdom-interest] Life or death of the Parent interface

Jason Hunter jhunter at xquery.com
Fri Feb 20 12:02:55 PST 2004

So people seem to like the Content abstract class, but there's been some 
pushback on the Parent interface.  Some have suggested removing the 
interface entirely.  I'm wondering if that might be best.

Its main purpose right now could be described as a generic type for 
setParent() to take and getParent() to return.  There's also the benefit 
when learning the API that you quickly see how Document and Element 
share a core set of methods.  Those benefits are nice, but really not 

What people don't like is that now the various Parent methods -- 
addContent, setContent, getParent -- return Parent instead of the 
specific Element or Document type on which they're acting.  By removing 
Parent we could fix that and simplify the API by one class.  We'd just 
change getParent/setParent to use Object.  As another secondary perk, we 
would avoid the Parent/Content odd naming convention.

In the end I don't think this is a critical design issue one way or the 
other, but I'd like to make sure the situation is fully understood 
before deciding.

Am I right in classifying the pros/cons of each proposal?  Is the 
biggest complaing about Parent how it reduces the ability to chain? 
What about the lost ability to chain a getParent().getParent() sequence?


More information about the jdom-interest mailing list