In article <[EMAIL PROTECTED]> Stuart writes:
>My personal opinion is that all of these changes dang well should be
>legal, but I don't know where to look to find out whether they actually
>*are*... can anyone help?
Chapter 13 of the JLS, "Binary compatibility", is the place to look.
The parts of chapter 15 which have to do with compilation and execution
of method calls are also relevant.
One problem with that is that §13 does not explicitly address issues of
overriding (except in the one case mentioned below). It seems to deal
with practically everything else, though.
For classpath, you'll have to think about both "source compatibility"
(which might be the wrong term) and binary compatibility. Source
compatibility is not really specified in the JLS, but, IMO, it should
require that, when compiling against your classes, the symbolic references
in the binary to class members in the library will be the same as if
you compiled against a set of classes exactly as described in the spec.
It might be possible to make an exception to this for overriding a method
which the spec says is not overridden.
Binary compatibility, though, is (mostly) specified in the standard.
>~ Not overriding a superclass method when the spec says it is overridden
> (for cases where I consider that the tiny efficiency gain isn't worth
> the big increase in code size)?
JLS §13.4.23, "Method Overriding", ought to deal with this, but doesn't
seem to. I think this counts as moving the method to a superclass.
There are several places which mention that this is not compatible;
it is stated that you must leave a forwarding method in this case.
Oddly, however, §12.3.3, "Resolution of Symbolic References", which
describes NoSuchFieldError and NoSuchMethodError, was amended in the
"Clarifications and Amendments" document to remove the mention of the
restriction that a reference in a binary to an inherited field or method
will cause an error. I could take this two ways; either as an indication
that the restriction was to be removed, but that someone unfamiliar with
the spec wrote the amendment, or alternatively that it is allowed for a
binary format to allow references like this, but not required. In the
latter case, the JVM spec should say which is the case for the ".class"
file format. (Another possibility is that I've failed to understand
the significance of changing one part of the spec, but not another part.)
>~ Overriding a superclass method (for efficiency) when the spec says
> it is not overridden?
JLS §13.4.23, "Method Overriding", says:
"If an instance method is added to a subclass and it overrides a
method in a superclass, then the subclass method will be found by
method invocations in pre-existing binaries, and these binaries are
not impacted."
So I think this means that you can do this, and the result will be
binary compatible. It may not be source compatible; if I compile
against your classes, I may not be able to run the binary against Sun's
classes, because there may be a reference to the overriding method in
your binaries which doesn't exist in Sun's library. See above, though;
they may have intended to amend this. (There's also an even more obscure
possibility that adding an overriding method might change the meaning of
some source code by making a method call to an overloaded method resolve
to a different signature than it did before. I'm not sure if this is
even possible; if so, it might happen if overloading is heavily used,
but I'd only expect to see it in contrived situations.)
>~ Adding a package-private superclass in between a class and its specced
> superclass (for cases where code can be reused)?
>From §13.4.4, "Superclasses and Superinterfaces":
"Changing the direct superclass or the set of direct superinterfaces of
a class type will not break compatibility with pre-existing binaries,
provided that the total set of superclasses or superinterfaces,
respectively, of the class type loses no members."
So this should be alright. As for adding new non-public classes to a
package, §13.3, "Evolution of Packages", says:
"Changes in class and interface types that are not public and that are
not a superclass or superinterface, respectively, of a public type,
affect only types within the package in which they are declared."
That doesn't mention this case specifically, since you're asking about
making a non-public superclass of a public class, but I get the impression
that it is okay for binary compatibility, and for source compatibility it
should be alright provided that there are no members of the non-public
class which can be referred to from outside that package. If you are
careful to make everything in the non-public class either
- private or package-access only, or
- a method which is overridden in, or a field which is hidden in,
every public class which would otherwise inherit it
then you should be safe.
All in all, this gives an interesting batch of gripes with the JLS.
I'll let <[EMAIL PROTECTED]> know about them sometime (unless I hear
that someone else has done so first), and will let you know what he says.
(This might not be for a while, due to the demands of my thesis.)
>All of these things seem to me to be implementation issues, and they are
>not explicitly described in the spec. [...]
>From context, I take it you mean the javadoc class library documentation,
not the language spec? Is it true that the only specification available
for the class library for 1.1 and later is the javadoc documentation?
If so, I sincerely hope they've improved things since 1.0. The specs
for the core classes in the JLS (which I've been working from for Bock)
are woefully inadequate, at least when compared with the spec for
the language itself. For example, the JLS doesn't specify whether an
enumeration is affected by changes made to the object it was created
from after the enumeration was created... Therefore, in my version,
I've done the opposite of what Sun did. ;-)
Apologies for such a long message; I hope you find it of use.
Cheers,
--
Charles Briscoe-Smith
White pages entry, with PGP key: <URL:http://alethea.ukc.ac.uk/wp?95cpb4>
PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2
