It would be wrong to say that a class or method is somehow
“core”
to the language simply because another class refers
to
it.
There is nothing wrong with that statement taken in
isolation, it is factually correct - I could write a class
referring to
another class, which is not "core" to any
language.
In the context
that they set it, however it is totally
misleading. They are suggesting that if
core classes depend
on other classes then those other classes are not
necessarily to be considered "core".
There is almost a shred of basis
to this argument if they
are considering classes encapsulating other classes
(ie. a
core class "Car" CONTAINS a "SteeringWheel"), as long as the
encapsulated "SteeringWheel" class is only an internal
implementation detail
and never exposed externally.
What they are trying to imply however is
that if a core
class extends another class (ie. a core class "Car" IS A
"Vehicle", then the "Vehicle" class is not necessarily to
be considered a
core class.
That implication is completely and utterly without merit on
any level, and cannot be justified by logic or the meanings
of the terms in
software. To claim that a subclass is core
with the superclass being non-core
would be to make the
software uncompilable in a reference system, and would
break
very basic tenets of OO design.
Also in the encapsulation case,
if any of the inputs or
outputs of the method refer to the encapsulated class
in any
way (such as accessing the "SteeringWheel" in order to turn
the "Car",
adding a new "SteeringWheel", checking the
settings on the "SteeringWheel", or
specifying the
"SteeringWheel" on a newly created car, then the
"SteeringWheel" must be considered a core class.
The class hierarchy
is fundamental to the classes
themselves, and all core classes must have all
their
ancestors as core. Same goes for interfaces.
If it's an entirely
encapsulated (hidden) class within a
"core" class (ie the "SteeringWheel" is
within a totally and
permanently sealed "Car" and can never be observed or
interacted with externally), then it's an implementation
detail, and does
not
necessarily mean the class is necessary for an
independent implementation. In
that case only it is arguable
(but not necessarily reasonable or sane) that the
"SteeringWheel" be considered non core.
Of course the SSO copyright
argument is totally bogus from
so many angles anyway, but even if we accept it,
the naming
conventions of the libraries clearly show that all java.*
APIs are
by definition core to the language (arguably
javax.* too.) If there were any
that were proprietary, then
they would be stored in a separate namespace - as
was done
with sun.* and many many others.
I don't believe there is any
basis to believe anything other
than all java.*
APIs are core, as (to my
knowledge) nobody has ever defined
anything as "core" to the language, and it
is plain that
parts of java.* are required for all programs. Oracle are
trying
whatever they can to remove key functionality from
what is "core" from a purely
legal POV rather than what
makes sense. They deserve to lose this
decisively.
[ Reply to This | Parent | # ]
| 
