|Authored by: PJ on Sunday, May 06 2012 @ 04:22 PM EDT|
|I got it into my head to take a look at UNIX APIs. And I bumped into another
package, jdk117, and the release notes include javaRN.text, and here is what I
find -- would this not indicate an answer to the judge's question of what is
SCO JDK 1.1.7B is distributed in the following
* jdk117 (size: about 14MB)
Package jdk117 includes the
essential execution engine of Java, that is,
what you need to run Java
* jdk117pls (size:
* java, the Java virtual machine (JVM)
appletviewer, the Java Applet Viewer
* basic API
* the just-in-time (JIT)
- language support
Package jdk117 also includes some Java
* javac, the Java Compiler
Finally, package jdk117 also includes additional
components to support
distributed applications and database
* jdb, the
command-line Java debugger
* javah, the C Header and Stub File Generator
for native methods
* javap, the Java Class File Disassembler
javadoc, the JAVA API Documentation Generator
* jar, the Java Archive
* Remote Method Invocation (RMI)
jdk117pls is an optional supplement to jdk117 that includes several
additional materials useful in Java development work:
* Java Beans
(component object model)
* JDBC (database access)
* The Sun
documentation which contains a full description of the
different parts of
the JDK (this documentation is in stand-alone format
and is not integrated
into documentation browsers);
addition to Sun's documentation in the jdk117pls package, SCO JDK
provides UnixWare 7 users with documentation integrated with SCOhelp
* Many interesting Java demo applets and
applications including some
native method demos;
versions (_g-suffixed) of many of the commands and libraries.
* jdkdoc: Includes JDK API documentation, JDK
guide to new features,
Sun's release notes, and links to other information,
all tailored to
the UnixWare 7 platform.
The JRE Package
* jdkman: Includes manual
pages for the JDK commands; these manual pages
are available from the
command line as well as SCOhelp.
with the SCO JDK 1.1.7B distribution material, but available
separately from SCO
if required, is the SCO JDK 1.1.7B JRE package jre117
(size about 7MB).
package matches Sun's product configuration of the Java Runtime
(JRE). The JRE is the minimum standard Java platform for running
It contains the Java virtual machine, Java core classes, and
The JRE does not contain any of the development tools
(such as appletviewer or
javac) or classes that pertain only to a
development environment. It also
contains a different configuration, with
different file names, of the Java core
classes. In addition, it uses the jre
command rather than java to execute the
Java virtual machine. See Sun
documentation for full details or browse jre.html
in the JRE installed
The purpose of the JRE package is so that
independent software vendors
(ISVs) and others can bundle it with their Java
application, if desired.
That way, the application and the Java version it has
been tested on, can be
installed together on customer machines, rather than
relying on whatever
Java version is currently installed on those
This document is copyright SCO 1999, for a time frame,
since the judge asked about 1996.
[ Reply to This | Parent | # ]
|Authored by: Anonymous on Sunday, May 06 2012 @ 06:41 PM EDT|
|(I hope that we've agreed Google "could" have eliminated the SSO)|
Once you've taken the decision that there is a way to enable your platform to
attract a huge number of developers, Java is the only answer and anything else
does suck (Either in hindsight when you've been sued, or when you're trying to
negotiate a license)
Java (with it's VM) has built in platform security (sandboxing) whereas with the
NDK (I imagine, I've never used it, they advise against it), sure you can code
for android in C/C++, but like all of these 'to the metal' languages the
potential for disaster from coding mistakes is enormous.
Apple manages that problem by being the gatekeeper, Google chose not to adopt
that role, to 'open' the platform, going with a VM minimizes the risks (from
programming errors, not necessarily from malware), as Schwartz(?) said
Microsoft(.net) was the only alternative or roll your own.
Most of the (programming) world speaks Java or at least can understand it even
if they've never seen it before, much as most of the world (can) speaks
The Founding Fathers could have chosen to write the Declaration of Independence
in a brand new language suitable for a new nation, they did not do so.
(Setting aside the usual difference such as color/colour. +disclaimer I am not
Ditto Google, Android/Java.
The 'APIs' in question are little more than new words for the language, their
implementation is expressed using existing words.
('Internet' did not exist when the Declaration was written, 'XML' did not matter
when Java was first developed)
As the story grows the language develops to express new concepts.
An API is only a concept (what does that make a bunch of APIs grouped together)
Everything under java.* is a new word for the language
Everything under javax.* is a new word that is being tried out, or that might
break something if it got put in java.* so it needs to be kept apart (The N
Everything outside that is not Java. (as indeed et cetera is not actually
English though frequently used)
Not using the SSO would be like writing the Declaration in Klingon.
Possible, but also extremely stupid.
[ Reply to This | Parent | # ]
|Authored by: Anonymous on Sunday, May 06 2012 @ 08:41 PM EDT|
|continuing while I'm in a de-constructive mood|
Q13, How many questions?
Is there another bomb/trap in here....
A: When discussing use of the SSO in the 37 API packages in Android to achieve
“compatibility,” what exactly are the parties referring to?
B: Is it “compatibility” with programmers who write in the Java programming
C: Or compatibility with pre-existing programs?
D: If so, approximately what percent of pre-existing programs written for the
Java platform are compatible with Android?
E: Is it compatibility with the TCK?
F: Or Java virtual machine?
G: Or java compiler?
A: answer B
C->G: don't really care, doesn't matter, not applicable to android
Yes *all* of the above! none, they destroyed it, they don't have a license, none
of the programs work, they're not compatible with TCK/javac/JVM
Is E: a submarine License minefield?
That's the only time you need a license to use the ideas in the Specification
(if you want access to the IP, which you don't need if your implementation is
independent and not Java)
[ Reply to This | Parent | # ]