decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Answer to 6 (and 8): see Java Language Spec | 451 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Answer to 6 (and 8): see Java Language Spec
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 | # ]

implementation dependencies, or public interface dependencies?
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 | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )