Re: Versions for java-virtual-machine
> From: Stephane Bortzmeyer <bortzmeyer@pasteur.fr>
..
> On Tuesday 14 September 1999, at 23 h 11, the keyboard of Julio
> <julio@pobox.com> wrote:
>
> > Can a virtual package have a version (to be set by a 'real' package that
> > implements it)? If so, it'd be useful to have java-virtual-machine packages
> > to set their jdk-compliance versions (1.0, 1.1, 1.2)
>
> You mean using the JDK as the reference? A non-free thing? I don't like the
> idea. If we have such dependencies, it can be to the Java Language
> Specification, not to a particular implementation.
Using a specification vs. an implementation is right, but using just
the _language_ specification is insufficient (except possibly when
you're talking about just a compiler).
A full Java implementation implements not just the language specification
but also the Java virtual machine specification and the supposed API
specification.
(Of course, Sun's Java API documentation, besides being quite incomplete
even just for users (programmers), is nowhere near being a real
specification. Come to think of it, even the Java Language Specification
sucks as a specification. (Try figuring out precisely how to parse the
following, whether it is legal, and exaclty what it means:
"import p1.p2.C1.C2", where C2 is the name of a nested class declared
inside a class named C2 in package p1.p2.))
Anyway, I think we're going to have to refer to JDK version numbers
to identify levels of Java support.
You could define multiple compliance versions: one for the JLS, one
for the JVM, and one for the standard APIs. That would at least
partially separate things.
Also, are we going to differentiate between levels like J2ME, J2SE,
and J2EE?
Daniel
Reply to: