Paul Fisher wrote:
>
> Stuart Ballard <[EMAIL PROTECTED]> writes:
>
> > Adding a package-private superclass in between a class and its
> > specced superclass (for cases where code can be reused)?
>
> This probably is OK, as long as the in-between class is _not_ in the
> java.* namespace.
>
> The reason I say this is because Sun says that we must implement the
> specification without adding "any additional packages, classes or
> methods to the java.* packages". Of course modifying the inheritance
> tree could also be considered "supersetting or subsetting" which is
> also disallowed by Sun.
Ouch. I don't need the class that badly. However... not adding any extra
classes in java.*, even package private ones? What about
java.lang.VMObject et al?
What did Sun do about classes like the one that implemented the
Enumeration of the elements of a Vector, before inner classes? How about
the entries of a Hashtable? Did they really make them public classes in
com.sun? If not, would we have been required to include those classes
too?
And what about methods? This seems to say that we can't have any private
methods that Sun don't specify, too...
I was more worried about the supersetting/subsetting issue, and I think
that if this is disallowed by Sun, it would be pushing it. I've looked
again at the code that I've had to duplicate as a result of this, and it
isn't *that* much, really. It would just tidy and speed things up a bit
in the implementation and remove a couple of bits that are a little
hacky - and that isn't worth a legal battle for.
> For instance, Sun says that we have to pass the JCK (java
> compatibility kit) if one is ever made publicly available, and that we
> can only distribute clean-room implementations that conform to the
> latest version of the Java API.
Which does have good points as well as bad points (though I'm not
denying the bad points). Trying to prevent the standard from fragmenting
and keep implementations up to date with the latest version is a
laudable aim, even if the techniques used are flawed.
