@Deprecate is no problem for backwards compatibility, it’s just an annotation after all. An option would be nice that automatically masks all deprecated methods from class signatures. With an alternative version of the JDK that does not contain these methods and classes at all.

Writing “=” for “equals”" is similar to writing “for” instead of Iterator.next etc. - both introduce syntax for specific library features, and grant language status to an idiom. I think it’s very much in the spirit of Java. Such a change would certainly be compatible at the byte code level, and could be handled just like the syntax change when “assert”, “enum”, generics etc. were introduced.

Java has already switched successfully once from Enumeration to Iterator. Something similar could be done for further changes to the Collections APIs. There’s the pattern: provide an alternative and ask people to migrate. Admittedly the gain/pain ratio may be too low for most changes… maybe some more fundamental support is needed to make different interface versions interoperable…

A lot of stuff could really be done incrementally. I’m still looking forward towards some “killer feature” or paradigm that would warrant the introduction of a completely new language.

That would allow taking care of a number of library mistakes (finally @Deprecate or remove Vector/Hashtable, kill java.util.Date and java.util.Calendar in favour of joda-time (which, what with the GPL stuff, can just be inserted verbatim now), and re-designing a lot of things to work better with for example the CICE proposal), as well as updating the language specs themselves (eliminate arrays altogether in favour of list and map literals, redo ’switch’ to use code blocks instead of labels, graft ‘empty’ and ‘completed’ blocks onto ‘for’ and ‘while’, change ‘a == b’ to mean (a == null ? b == null : a.equals(b)), and use ‘a === b’ to replace the old == (or better yet, use := for assignment, = for .equals(), and == for identity (pointer) equals), and a couple of others.