Re: org/w3c/dom duplicates in lib-dom-java and lib-openxml-java,libxerces-java!
0> In article <01053013545202.00861@catv6142>,
0> Egon Willighagen <URL:mailto:egonw@subdimension.com> ("Egon") wrote:
Egon> Stefan argued that interface and implementation should not be
Egon> seperated:
Egon>
Egon> "The classes for interfaces might be identical for all
Egon> containers but at
Egon> least the exception classes will differ - so it is very
Egon> difficult to put the common classes in another JAR/package
Egon> ans share them between all implementations."
If an implementation changes the the interface such that additional
(checked) exceptions may be thrown, then it's no longer the same
interface, and the implementor has no right to continue using the same
name for it, IMO. Similarly, the implementor has no business adding
classes (including exception classes) or interfaces in someone else's
namespace. If additional interfaces or classes are required, they
belong in the implementor's namespace.
AIUI, the packages in question simply bundle W3C's interfaces[1]
(unchanged - W3C's licence may require this) to avoid a dependency
(this is what the upstream sources do).
[1] or SAX's, or whatever.
Egon> But it might indeed be "good" to place the interface classes in a
Egon> seperate jar/package... this would enforce that the implementation
Egon> *does* implement the actual interface, and not some lookalike...
That's my position on this, but I'm aware that there are different
opinions.
Here's an example of what I imagine; Package A needs Xerxes parser
and won't work with anything else, whereas B will work with any
implementation of the DOM.
Package A Package B
| |
| |
| (libdom-java-virtual)
| |
| +-----------------+------+-----------+
| | | |
libxerces-java lib-openxml-java lib-dom-java
| | |
+-----------------+ | +--------------+
| | |
dom-interfaces
Reply to: