Suggestions for Java Generics Semantics in Java Version 7.0 _ Resurrected
Florian Weimer
fweimer at bfk.de
Thu Jun 18 09:04:25 PDT 2009
* Neal Gafter:
> No, we didn't work under that assumption. Generally speaking, it has never
> been a goal to allow code written against one version of the platform
> specification to run on an earlier version of the platform.
Sorry, but without that, what you called "migration compatibility" is
largely pointless.
If I need to branch due to a platform upgrade, it doesn't matter if
the code I compile for the new platform version, after using new
platform features, is theoretically compatible with my old code.
Without tool support, it's not possible to ensure that both versions
are fully consistent. Anybody who swaps one version for the other
might face nasty suprises.
Isn't there even an undocumented/unsupported javac option which allows
to create 1.4 bytecode from generified code? If that were supported,
migration compatibility made lots of sense. Without that, there's
just a theoretic reduction in release engineering complexity (from
something perhaps-not-even-polynomial to
something-definitely-not-sublinear), and to me it seems that the
overhead of keeping both generics and non-generics branches of your
code base really harmed the adoption of generics (in the sense that
the branch never happened and the library still doesn't use generics,
even internally).
Anyway, I think it's simply impossible to introduce reification (of
whatever type) with the same level of backwards compatibility that
generics provided. People write code similar to the implementation of
Collections.emptyList(), and it's not possible to make it type-safe
while still having Collections.<String>emptyList() ==
Collections.<Integer>emptyList() (well, in theory, you could make the
dynamic type a property of the reference, not the object, but this is
probably not very desirable).
--
Florian Weimer <fweimer at bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
More information about the jdk7-dev
mailing list