Now I should make it clear that until recently, I regarded myself as a C# and ActionScript programmer. I’m new to Java. This isn’t strictly true, as I used Java back in its Java 1.1 days, but its changed so much since those days (and I’d forgotten most of it anyway), that in practice I’m a Java newbie. As a result, I naturally judge Java against C# (and to a far lesser extent, against ActionScript).
C# owes its existence to Java. Languages prior to Java may have had garbage collection, reference types rather than pointers, bytecodes, just-in-time compilation etc, but Java bought these technologies into the mainstream. As it came after Java, C# was able to adopt all the good points of Java, and scrap the bad stuff (the getter and setter mess of Java is replaced with elegant properties for example). Whether it did this successfully or not is a matter of opinion of course. From my point of therefore, Java automatically deserves respect, but it doesn’t deserve automatic authority. People grow old and wise, but also grow set in their ways. Programming languages appear to do the same.
Despite its seniority, Java has some clear advantages over C#. Breaking to labels is a glaring omission in C#, which Java has. C# requires the use of the evil-incarnate “goto” to simulate breaking to labels. Also the XML mess that is documentation comments in C# is pure farce compared with the simple elegance of Javadoc. Java has a whole raft of deficiencies though, and the two biggest ones are the lack of anonymous functions (let alone closures) and the lack of properties. Both have been proposed for Java 7, but – according to Sun’s presentation yesterday – neither will now appear. On a lesser note, Java 7 will not support operator overloading either, so string comparisons will remain using the grossly messy .equals() method to compare string value. This is a minor issue in comparison with properties and closures.
Why are anonymous functions/ closures and properties such a big deal? Both can be worked around in Java. Properties are after all just a neater way of doing getters and setters and people have come up with bodge simulations of delegates for Java. The big deal is that these are basic features of modern languages. Even the somewhat “noddy” scripting language, ActionScript, manages to implement both. Every other JVM-based language that I know of – JRuby, Jython, Groovy and Scala – all support closures.
Java is old and is becoming set in its ways. Language developers always run into problems with balancing feature advancements with avoiding breaking legacy code and Java is no exception. Perhaps we need to accept that closures and properties will never come to Java as it is just too difficult to implement both neatly, without breaking backward compatibility in too big a way. If this is the case, then perhaps Java 7 should be the last version of Java and it ought to be retired and replaced with a younger, more adaptable language.Whether the growth in alternative JVM languages is a sign that people are already moving on from Java to newer languages is difficult to judge. JRuby, Jython, Groovy and Scala are all dynamic languages. Dynamic languages have seen a general resurgence in popularity recently. What is needed though is a static language replacement to Java. One that can seamlessly interact with legacy Java code, whilst supporting modern programming principles such as closures, operator overloading, properties etc, along with support for dynamic types (without being inherently dynamic), functional language principals such as currying and lambda expressions.
The more astute of you may spot where I’m heading here. Just as C# was born of Java, so perhaps we need a new version of Java, born of C#. Being a English tea addict, who is pretty indifferent to coffee, I propose (not very seriously) that we call it Lapsang. C# itself is starting to get old, and many of the new features – such as extension methods – have been implemented in an inelegant manner to avoid the backward compatibility issues that new keywords bring. So just as C# took Java’s good bits and added more of its own, Lapsang could take C#’s good bits, add a few new bits of its own (build concurrency into the core of the language for example) and give the JVM another 10+ years of life.
Java proberly is a dying language and it risks taking the JVM with it. If Sun (or IBM perhaps, if they buy Sun) bite the bullet and retire it as the prime JVM language, then there is no reason why the JVM cannot thrive and grow for many more years.
Fun, if somewhat pointless 🙂
Recently I came across something that Java is soon to offer that .NET would really benefit from: Java 6 SE Update 10. This rather cumbersomely entitled release has the somewhat more snappy title of “Consumer JRE”. This new consumer runtime has a bunch of really nice features, the two key ones in my view are the Java Kernel and draggable applets.
Like .NET, the Java runtime is a huge download. The first time you try and run a java application on a machine that doesn’t have the JRE installed, in must be downloaded. The Java Kernel is a clever – and oh-so-simple – idea: break the JRE up into lots of bits and only download what is needed. So the first time you run a Java application, the basic – small – kernel is fetched, plus any other parts that the application needs. At that point the application can run. The rest of the JRE is then downloaded in slow-time in the background.
The graph below (from http://java.sun.com/developer/technicalArticles/javase/consumerjre/) highlights this:
Back in the days before Flash, Java Applets were the way to do programatically complex stuff in web pages. In recent years, they have declined in popularity, but this feature may bring them back into favour. If you visit a web page and see an applet that you like, then you’ll be able to drag it out of the browser window to the desktop. It then runs as a fully fledged desktop application, rather than just a browser applet.
When these features will be released is anyone’s guess (early betas of the Consumer JRE were “hot news” last year  and it is still in beta), but they are great features none the less. And so this brings me to .NET 4. When Silverlight 2 is released (I’m still predicting late July or very early August for this release, ie just in time for the Olympics), Microsoft will have an obvious starting point for the equivalent of both of these features. The Mono team have their Moonlight desklets, which Microsoft could take and turn into Silverlight applications that can be dragged out of the browser onto the desktop. And the cut-down .NET framework that forms the kernel of Silverlight 2 would make a great starting point for a piecemeal downloadable .NET 4 kernel.
The “big chief” of .NET – Scott Guthrie – is a man who is happy to take great ideas from anywhere and shamelessly add them to .NET, so I fully hope and expect to see such features in the .NET realm sometime soon(ish).
The new job will involve ActionScipt 3 (which I love already; it is such a huge improvement over ActionScript 2) and Java. This blog has been very Microsoft-centric (especially with regard to C#) up until now, but I may not use C# again for some time. This raises some issues for me:
- Do I abandon the C# tutorial series?
- Do I scrap the Arno# name?
- Do I scrap my plans to get involved in Pash?
- How will I convince my new boss that sending me to Mix:UK this year would be worth their while?
- Do I write some decent documentation on flexunit?
The last question is a no-brainer. I’ve started experimenting with flexunit, and it is a good unit testing framework for flex. The documentation for it is utterly crap though. I’ve worked out how to use it mainly by reading through the source code! So watch this space for some tutorials on using flexunit.
As for the others, time will tell…
I stumbled across an article on the Dr Dobbs site today on this subject. As an aside, I was amazed that Dr Dobbs was still going; it was a must-read magazine twenty years ago, but I’d assumed it had long since vanished. The article does read like a Sun advert, but is interesting none the less. The UltraSPARC T2 Plus processor that Sun is shipping in its servers today has eight cores, each of which is capable of concurrently executing eight threads. And two such processors can exist on a single server. That means that we have servers capable of running 128 concurrent threads available now in 2008.
Anyone who thinks that concurrency is an optional aspect of programming, really needs to wake up and smell the coffee. As I’m changing jobs soon and will be switching to a Java development role, “Java Concurrency in Practice” is already on my essential book list. Perhaps it should be on yours too?