Suggestions for Java Generics Semantics in Java Version 7.0 _ Resurrected (original) (raw)

Florian Weimer fweimer at bfk.de
Thu Jun 18 09:04:25 PDT 2009

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.emptyList() == Collections.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