Stephen Colebourne asks a simple question, "are you scared of Java language change?" In his blog, Stephen works to debunk arguments used by many to justify their positions against making more changes to the language. The specific arguments addressed are;

• It was designed simple
• Nothing beyond Java
• Just look at generics
• Code isn’t important
• Junior developers won’t understand this

To address the question of simplicity Stephen uses some historical information drawn from Patrick Naughton’s mini-biography written in 1996. In that biography Patrick reveals some of the pressures the Oak team faced prior to the big release. Stephen’s conclusion;

Java's so-called simplicity is a fallacy. Language changes now are simply completing the job that was unfinished back then and meeting the realities of Java as an enterprise language

In his rebuttal to those that use the problems with generics as a call to halt changes to the language, Stephen holds out the FUD card. He recognizes that generics have many weird edge cases but states that changes that are devoid of them should be find. Perhaps the biggest issues is the barrier to entry posed by complex language features. One could look at Stephen’s response as stating that this position is patronizing.

The issue with training and language change seems overblown. Developers are not stupid - even the junior ones or so-called Java-Joes. Every day they interact with multiple frameworks consisting of hundreds of classes which are way more complicated than the language changes being talked about.

The danger of not changing the language is that with more choice, architects that now see life beyond Java and thus move away from Java. Stephen concludes that language change will bring may more upsides. Is Stephen right in his assessment that Java wasn’t suppose to be as simple as it was and consequently we are now only finishing the job?

Is Stephen right in his assessment that Java wasn’t suppose to be as simple as it was and consequently we are now only finishing the job?

Java's object model is clearly simpler than C++'s, even if we only consider the issue of interfaces instead of multiple inheritance. When people said early on that Java was simple, it was partly hype and partly just in comparison to C++. The language has become more complex (as one example, it isn't as easy to parse as it once was). But several papers in type theory have been able to prove things about Featherweight Java. So long as what can be added to Java can still be distilled to that same core, it can remain a simple-language-with-some-extra syntactic-shortcuts. It would only be VM changes not related to performance that I would call it complex. (And it's all relative.)

Most people aren't afraid of change in itself, but rather extremely wary of the often ill-thought out changes being put forward. The "proposed" "features" make no sense, are proposed for the sole purpose of "it works for XXXX so it MUST be good for Java" (read whatever language the writer of the proposal favours for XXXX), or would break large sections of existing codebases for no gain.

Time would be much better spent figuring out how to help companies get from 1.4.2 to Java6 than coming out with Java7. In the Spring project, I would like to have examples of code that uses Java5 (I am working on Java6 but I am not trying to be too picky). I am told that many or most new Spring developers are having to develop on Java 1.4.2 (or 1.3) since that is what their companies have adopted as a supported version since their underlying architectures are not available on a later version of Java. Until this is fixed it seems pointless to introduce Java7 if most people can not use it since they are stuck on 1.4.2 because of the extent of the changes to Java5. In addition, if the language keeps changing, what is the incentive for the system manager to upgrade. If he contemplates an upgrade to Java6, the Java community is saying that he should just wait for Java7 since he will have to convert to it anyway. He can save a conversion by staying on Java 1.4.2 for another year or so. If you want to get a following on the production and tools side, you need to offer managers a reason to move and some assurance that now is the time. A freeze on new versions of Java syntax (no problem with making the JRE smaller and faster) and a concerted effort to help the major Java tool and framework providers get to Java6 would be a much better contribution to everyone's life that some obscure new language option that reduces the amount of code in an application by .001%. In the left pane of this blog, I see an article from a person who is very pleased to have spent the last 6 months using Java5. Hello!!! Java6 is out. Does this indicate a crying need for Java7. I think not. A 5 -10 year moratorium on language changes (at least until everyone is on Java6) would not be a bad idea. Think of the brilliant people who would be freed up for other tasks. With them focusing on applying Java6, Eclipse plug-ins would almost write your whole application. The open source Java-based accounting and ERP/CRM systems that could be produced would make Java the defacto standard for commercial computing. The major frameworks would be astounding in their completeness and ease of use and documentation. World peace would be almost assured and we would all be wondering why the Israeli-Arab conflict took so long to solve prior to the stabilization of the Java spec.