Jim Pick wrote:
>
> Because the set of Java APIs is so large, trying to develop a set of
> class libraries that works as a drop in replacement for Sun's libraries
> is a very large task. In reality, it's going to be a long time before
> the free java class library projects manage to reimplement 100% of the
> Java2 API, and it's a moving target.
> ...
> I think part of the problem is that there isn't enough granularity in
> Sun's Java specifications to make it easy for free software JVM/class
> library implementors to implement the whole thing (eg. "J2SE or J2EE").
> Sun has broken the API up a bit for J2ME applications
By following several guidelines based on historical and pragmatic
considerations, the problem of implementing the huge numbers of
APIs can be made more manageable. Here are the guidelines.
1. Develop and release APIs in historical progression.
2. Drop all Sun-deprecated classes and methods; conform only to the
latest non-deprecated version of an API spec
3. Focus on J2SE first, and J2EE/J2ME later
This leads to the following "priority roadmap" (lower number
is higher priority):
Priority Roadmap
JDK J2SE J2EE J2ME
1.0.2 1 n/a n/a
1.1.8 2 n/a n/a
1.2.2 3 6 9
1.3.1 4 7 10
1.4.x 5 8 11
For example, highest priority would be all API names that appeared in
1.0.2 (which is no longer a moving target), but IMPLEMENTED USING THE
1.4.x VERSION OF THOSE SPECS. Thus, event handling would use the 1.1,
not the deprecated 1.0, event model. Classes like Vector, which changed
in their implementation from 1.0.2 to 1.4, would be implemented using
the 1.2 Collections approach. For the 1.0.2 equivalent functionality
release, only Vector and the Collections interfaces directly supporting
it would be implemented, not the entire Collections package. Thus,
what is being implemented is always the latest version of the Sun spec,
but with priorities set by historical evolution.
There are many practical reasons for the 3 guidelines and the resulting
priority roadmap. I will not waste space listing them here because they
become obvious on reflection.
> If we introduce software into Debian that runs on one implementation
> (eg. Kaffe), but not on another (eg. gcj), then we are introducing
> breakage. What do we do in that case? Do we hold back software unless
> it runs on all the JVMs/class libraries in Debian? Or do we introduce
> the software as soon as it runs on just one JVM in Debian (and breaks on
> all the others).
Subset the 1.4.x (or latest version) JCK tests according to the above
priority roadmap. Require an implementation to pass its "level" of JCK
(e.g., the 1.0.2 test subset for a 1.0.2-equivalent implementation)
before admitting it into debian. Sun will not grant certification for
anything that does not pass all JCK tests, but the immediate goal here
is not certification but interoperability at a given "JCK equivalent
capability" level. The JCK tests can be highly useful for this. If
interoperability problems are found among (for example) different
1.0.2 implementations that all pass the 1.0.2 -level subset of the
1.4.x JCK, then develop additional "GNU-JCK" supplemental tests to
verify conformance of the implementations in the problem areas and
require implementations to pass these additional tests as well before
admitting them into debian.
> I think it would be incredibly useful if we, as the free software
> community, came up with our own set of specs for Java, documenting and
> advocating which APIs we feel are appropriate to use (based on the
> availability of free software implementations).
When it comes to Sun-defined functionality (API, tool, etc) the Sun
specs and conformance tests should be followed rigorously so that a
1.4.x (or latest version) can be certified by Sun when it finally is
available. This will make it interoperable with non-free
implementations
to the extent Sun requires it to be.
However, Sun does not preclude creating additional packages outside the
java.*, javax.*, org.omg.* etc trees released with the standard JDK.
For example, applications and tools such as IDEs do it all the time.
Hence, it would also be possible to include a gnu.lang along with the
standard java.lang package. gnu.lang might include things like the
Measured Units Conversion Package at
http://www.jreality.com/downloads.html
and other functionality that will likely never be included in Sun's
APIs.
These 'gnu' APIs would have to carry a LGPL-like license that permits
their use in non-free environments as well as free environments so
(1) code that uses them can be transported, and (2) users of Sun and
other non-free implementations would also be able to use them. This
would avoid any basis for Sun saying they illegally "extend" Java
They would just be additional APIs that ANYONE else could also use.
These APIs would come with "GNU-JCK" tests to verify conformance of
implementations that support them (including non-free implementations,
who then would have to be "certified" by the free community for
conformance!)
This approach would allow the free community to develop their own
_supplemental_ set of API specs for Java, effectively an alternative to
the JCP, without in any way compromising the portability of Sun-standard
Java code to free environments, or visa versa.
Rick
--
Rick
Lutowski
|[EMAIL PROTECTED]
\ oo \____ http://www.jreality.com/ _______
__\ ____________________________________________________________ /_
| _____/
`------------------------------------------------------'
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
