Important Notice: Our web hosting provider recently started charging us for additional visits, which was unexpected. In response, we're seeking donations. Depending on the situation, we may explore different monetization options for our Community and Expert Contributors. It's crucial to provide more returns for their expertise and offer more Expert Validated Answers or AI Validated Answers. Learn more about our hosting issue here.

Why is the JDOM API defined in terms of concrete classes rather than interfaces?

April 26, 2017API classes concrete defined interfaces jdom terms

0

Posted

Why is the JDOM API defined in terms of concrete classes rather than interfaces?

1 Answer

0

Posted

This issue has been discussed several times on the JDOM mailing list, with several people on both sides. In general, many people feel that a class-based API is better when subclassing is not needed, while an interface-based API is better when subclassing is needed. However, either system can be used in either case. Jason Hunter summarizes the arguments against an interface-based API for JDOM: With interfaces everything becomes a factory, elements have to be ‘imported’ into new documents instead of just added, features like long-term serialization cannot be guaranteed, and the list goes on. We started with interfaces actually. During our pre-release review to some peers we received the feedback we should try concrete classes. We did, and the design was much better for it. Think about java.io.File as an analogy.