Java is an excellent example of how you start out with a design that is rather “impure”, and has to be, in order to survive the initial competetive struggle; and then later, when there would be enough resources to realize some of the Real Cool ideas, you realize you can’t because you’re stuck with what and how you started.
One such example is the handling of primitive types. Auto-boxing is just a hack, trying to introduce “Everything Is An Object” through the back door. But the special cases introduced in the beginning stay in place.
A more recent example is the closures for Java / CICE discussion, where everyone agrees it’s going to be an addition to the Java language; no way you could replace some old feature made redundant by the new stuff. You cannot even extend the existing interfaces, because that would break implementations of those interfaces that exist out there in the wild.
There are fundamental decisions that cannot be changed easily once people have started building upon them. Operating Systems, Programming Languages, Platform APIs, Off-The-Shelf Software, they all have more than just a little legacy compatibility problem. The current anti-intellectual “agile” trend is good enough for applying those flexible, mature and well-thought-out processes and tools, but trying to develop and maintain a programming language in such a light-footed way means asking for desaster (or at least, bad quality).
A platform won’t stay competetive for long if you bolt on new things where they get in your way. If Saint-Exupéry is right, you need to remove things to increase consistency, making the language and platform more understandable and more usable.
The way to save your investment is to modularize, parallelize, interoperate, and deprecate. You can’t take things away from the Java platform, but you can provide increasingly consistent alternatives for parts of it (“nio”), interoperate with the old stuff for the time being, and hope for the old stuff to fade away. Note that this is not an agile approach – it does not involve a closed world assumption, it aims to keep long-term promises, and it ties significant resources (for maintaining several alternatives plus interoperability between them). Agile projects do not have a history; platforms do.
Most parts of Java will be with us for years to come. So please, don’t spoil the Java language and syntax with a mix of redundant, overlapping, complex features; don’t add something you may want to remove later. If it’s not proven yet, it doesn’t have to be part of the platform; just provide the hooks for others to provide it and experiment with it. I’d rather have a mix of language environments that Play Well With Others, with a JVM that acts as a “Common Language Runtime”, than a monolithic superplatform that assimilates every feature under the sun.
I wonder if at some point in the future it becomes worthwhile to split – make 2 java versions. The old, to be phased out, and the new, which -breaks- backward compatibility.
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.
I worry that such a new Java language would take the webdav vs. FTP route: a more cleanly defined replacement that does essentially the same will have a hard time.
@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.
You convinced me. Without a more telling “Just can’t possibly be done right but would be oh-so-powerful” killer feature this is not a good plan.