> From: Stephane Bortzmeyer <[EMAIL PROTECTED]>
.. > On Tuesday 14 September 1999, at 23 h 11, the keyboard of Julio > <[EMAIL PROTECTED]> 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
