|
Authored by: Anonymous on Friday, May 04 2012 @ 11:40 AM EDT |
IMO the answer is "Yes", it includes all of java.lang,
java.io and java.util. The Java Language Spec version one
reads:
"The subpackages of package java named lang, util, and io
(whose fully qualified package names are therefore
java.lang, java.util, and java.io) are a standard part of
every Java implementation and are specified in Chapters 20,
21, and 22."
- JLS 1.0 section 7.1, from
http://titanium.cs.berkeley.edu/doc/java-langspec-1.0/
Arguably this inclusion of java.lang, .io and .util extend
through JLS 3 (at least the packages described in version 1
and all java.lang packages from version 2.) Here's how:
The quoted text does not appear in later JLS versions. But
in version
3 of the JLS (the version that applies to Java 5 - I used
the copy at http://psc.informatik.uni-
jena.de/languages/Java/javaspec-3.pdf) there are 212
instances of the word "compatibility". The preface
underscores the need for compatibility between versions.
From the preface:
"This book attempts a complete specification of the syntax
and semantics of
the language. We intend that the behavior of every language
construct is specified
here, so that all implementations will accept the same
programs. Except for timing
dependencies or other non-determinisms and given sufficient
time and sufficient
memory space, a program written in the Java programming
language should compute the same result on all machines and
in all implementations.
We believe that the Java programming language is a mature
language, ready
for widespread use. Nevertheless, we expect some evolution
of the language in the
years to come. We intend to manage this evolution in a way
that is completely
compatible with existing applications. To do this, we intend
to make relatively few
new versions of the language. Compilers and systems will be
able to support the
several versions simultaneously, with complete
compatibility."
Note that while "should" is used instead of "must",
incompatibility is clearly an unusual exception, not the
rule. So it is reasonable to expect that with few
exceptions, any program written against JLS 1 or 2 will run
on JLS 3. And the preference seems to be towards supporting
a migration period where in these edge cases, the old way
continues to work for a time. An example of this thinking
is found in a discussion in section 4.7.
And finally, if you look at version 2 of the JLS, it
requires java.lang:
"Every compilation unit automatically and implicitly imports
every public type name declared by the predefined package
java.lang, so that the names of all those types are
available as simple names, as described in ยง7.5.3."
JLS 2, section 7.3,
http://web.archive.org/web/20110514004733/http://java.sun.co
m/docs/books/jls/second_edition/html/packages.doc.html#26535
So at a MINIMUM, to meet the "compatibility" meta-
requirement in JLS 3, you need to include ALL of java.lang,
java.io and java.util (found in JLS 3 chapters 20-22) from
JLS v1, and
ALL of java.lang as prescribed by JLS v2.
And finally, per question 8, to determine how much of the
Java API (class, interface, method, field, etc) is required
by JLS 3, using the above logic, you would need to make a
list of:
- all java.lang, java.io, and java.util APIs from JLS 1.0
- all other APIs that are required in the body text of the
JLS 1.0 specification
- all java.lang APIs from JLS 2
- all other APIs that are required in the body text of the
JLS 2 specification
- all APIs that are required in the body text of the JLS 3
specification
- all APIs that the APIs above use
And since something breaks if you don't include all of this,
then yes, all of these APIs need to be considered as part of
the "core" (though I think "core" to a programmer is
*anything* they need to make their program run that would be
expected to be found in a Java implementation.)[ Reply to This | Parent | # ]
|
|
Authored by: Anonymous on Friday, May 04 2012 @ 02:44 PM EDT |
Just because Sun's implementation of the standard ClassLoader uses a particular
thing, doesn't necessarily mean that *all* possible implementations of the
standard ClassLoader would need to use it.
However, I agree in general that most or all of the things on your list, are
"essential" to use any Java or Java-like platform, notwithstanding the
fact that you can easily write programs that do not _directly_ refer to them.
Android copied (via Apache Harmony) the interfaces of most or all of these
things, because that was the only way to achieve compatibility with most of the
existing code and with the existing knowledgebases in programmers' heads (as
well as future compatibility for any new code written with the intention to run
it as part of applications on both Java and Android platforms).[ Reply to This | Parent | # ]
|
|
|
|
|