|
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
core:
Packages
SCO JDK 1.1.7B is distributed in the following
packages:
* jdk117 (size: about 14MB)
* jdk117pls (size:
about 39MB)
Package jdk117 includes the
essential execution engine of Java, that is,
what you need to run Java
applications:
* java, the Java virtual machine (JVM)
*
appletviewer, the Java Applet Viewer
* basic API
libraries
- language support
- I/O
- AWT
- networking
- utilities
- images,
media
- math
- compression
-
security
* the just-in-time (JIT)
compiler
Package jdk117 also includes some Java
development tools:
* javac, the Java Compiler
* 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
(JAR) tool
Finally, package jdk117 also includes additional
components to support
distributed applications and database
access:
* Remote Method Invocation (RMI)
* Java Beans
(component object model)
* JDBC (database access)
Package
jdk117pls is an optional supplement to jdk117 that includes several
kinds of
additional materials useful in Java development work:
* 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);
* Many interesting Java demo applets and
applications including some
native method demos;
* Debugging
versions (_g-suffixed) of many of the commands and libraries.
In
addition to Sun's documentation in the jdk117pls package, SCO JDK
1.1.7B
provides UnixWare 7 users with documentation integrated with SCOhelp
in
these packages:
* 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.
* jdkman: Includes manual
pages for the JDK commands; these manual pages
are available from the
command line as well as SCOhelp.
The JRE Package
Not included
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).
This
package matches Sun's product configuration of the Java Runtime
Environment
(JRE). The JRE is the minimum standard Java platform for running
Java programs.
It contains the Java virtual machine, Java core classes, and
supporting files.
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
directory.
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
machines.
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
English.
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
a USAian).
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
word, java.nio)
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
language?
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?
For Google?
A: answer B
B: Yes
C->G: don't really care, doesn't matter, not applicable to android
For Oracle?
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 | # ]
|
|
|
|
|