In Pursuit of the One True Programming Language
Cringely had an interesting take on Java. I must confess, I love Java, warts and all. And while it has been awhile since I really got involved with Java development, I've watched from afar and seen that more of its issues are being worked out. I think the thing that drew me to it in the first place was the potential of 'write once, run anywhere'. I say potential because it was never really a reality. Java is still solid on the enterprise server but then that was never really the issue. 'Write once, run anywhere' was supposed to be the promise for client developers to be able to create an app that was truly cross platform. And it works to a point, but still there are problems.
In any event, Cringely clarifies his position that it's the JVM and its potential resurgence that he is considering. i.e. having a single platform which provides solid performance and good flexibility across platforms so that you can target that and call it a day. Moreover he ties that performance in with the promulgation of SSD over HDD and the fact that the bottleneck will cease to be database seek times due to hardware inefficiency and simple runtime inefficiency due to platform. His comparisons are mostly to Ruby but apply to any interpreted language. He notes that the JVM provided threading and memory management at a time when it was mostly done with greater difficulty with existing tools (e.g. C++) at the time.
C++ has been getting more of these features, whether through add-on libraries or through language updates. It is supported on almost any platform you care to mention. What C++ lacks is the enforced standardization of things like data types (which are still in some cases hardware implementation dependent for C++ but have set size definitions in Java) and UI frameworks. There are C++ frameworks which are cross platform capable and allow for a single application to be built for any supported environment but as with Java they must target the lowest common denominator in terms of functionality, often lag behind native enhancements and still do not typically look quite like they "belong" since there is usually a noticeable difference from native apps.
The point here is that C++ is not far behind Java in terms of offering many of the comforts which the JVM provides. Note I say the JVM. It is the JVM and the backing libraries which provide all of the functionality. The Java language is just a front end. JRuby is an example of being able to target the JVM with a language other than Java. Which still ties in with Cringely's point. But here is where I differ.
I don't think the JVM will see a resurgence, as much as I might like it. The biggest point Cringely seems to be making is that as more emphasis is put on CPU performance because disk performance improves enough to make seek times negligible, the JVM will see more projects in lieu of things like RoR and CakePHP. I disagree though. Right now the JVM is already available for those projects for whom performance is so key that it is needed. Right now, database performance is a common factor among all web server implementations. Put another way, optimizations for database access affect all implementations roughly equally. So again, any optimization happening now is still going to determine your deployment language. That won't change with database performance increasing. If anything, it might even make those scripted languages more useful because you've already cut some of the performance bottlenecks and you can afford a little more slack on the logic performance.
Additionally, as C++ evolves, it seems to be closing the gap in the number of toys you enjoy with Java. So the ease of development is decreasingly an issue. Which means you can get your performance gains, with possibly more deployment options, and equal development ease, by switching to C++ in lieu of Java. Not now perhaps but in the timeframe Cringely is considering for JVM uptake.
And while OS X is still not a majority market share, it's numbers are increasing. And Java is in a somewhat nebulous state at the moment. Apple has deprecated their JVM. Java apps are not allowed in the Mac App Store nor on iOS. Oracle has announced Java 7 but has not announced a timetable for availability on OS X. That's a big hole.
All in all, I would love to see Java make a comeback and be more widespread than ever. I truly enjoy developing with it. I just don't see it in the cards.
The Register is reporting that the Firefox team is considering blocking Java in response to the BEAST attack, which allows the attacker to intercept data from an otherwise secured connection. The move would be contentious given the impact it could have on anyone using Java in their Firefox browser, including users of Facebook's video chat as well as Java applets deployed internally at companies who depend on the Java functionality for their business. Without getting into the details of the problem, it seems that the Java plugin, developed now by Oracle, is causing a big headache for Firefox and their options are both limited and unappealing given possible user backlash. It's just another example of why company's are increasingly tempted to not work with other software projects to obtain new functionality, instead opting to fork existing projects, create their own solutions or just go without the new tech altogether.
A recent example involves Amazon's fork of Gingerbread (aka Android 2.3) to power their new Kindle Fire. Many decried the decision, particularly since Honeycom (Android 3.0) was available and targeted specifically at tablets and the newer Ice Cream Sandwich (Android 4.0) was going to be available just around the corner to unify the handset and tablet focused Android versions. More than just forking the code though, Amazon opted to create their own Android App Store meaning users may find themselves needing to repurchase Android apps already purchased elsewhere to get them onto their Kindle Fire or at least having to jump through additional hoops to use all available Android apps. Regardless, the fork means that Amazon is not beholden to anyone else for updates or features and given the open source nature of Android, will be able to pull any choice bits in from newer Android releases without having to work on anyone else's schedule.
We also saw this with Apple's decision to create Safari. Prior to OS X, Internet Explorer dominated the Apple browser market. Given that as connectivity became more widespread, browsing the web became a more prominent activity, Apple was moved to provide a more Apple-esque experience for browsing. The WebKit project provided the core of the browser which resulted in Apple boasting a well known browser of their own on several platforms and no longer relying on another company to provide that key experience.
Apple also showed their desire not to be reliant upon other company's technology in how they have handled Adobe's Flash. Flash has never seen the light of day on an iOS device and is no longer shipping pre-installed on Macs. There were clear performance issues (the 2009 Apple keynote mentions plugins at 10:23 but in retrospect it seems clear the reference was mostly to Flash) but more important were the control concerns. Apple has retained tight control over the user experience of their platforms, control which would only have decreased had Flash become more pervasive on Apple devices. Apple has put considerable effort into providing technologies which developers would have a hard time making use of on a meta platform like Flash, so the less dependence upon Flash by Apple, the more control they retain over their own platform.
Historically we have also seen what happens when companies attempt to coexist with competitor technologies. Witness OS/2's slow death (or lack of uptake) because developers could just develop for Windows and let the OS/2 Windows layer handle running the non-native application. Users never got a taste of what a real OS/2 app could accomplish. And while RIM's PlayBook was practically stillborn, the last gasp effort to renew life by declaring that Android apps would be allowed to run on the device was generally considered a bad idea by pundits since that, as with other similar decisions, would result in less push for developers to target the platform natively.
The lesson here is simple. Only trust third party components to the extent that you can do without them entirely. The more your own platform or project becomes dependent upon the functionality of other plugins or platforms, the more beholden you are to their schedules and priorities. It can be difficult to predict when a shift like that is going to happen (or already has), but it can be crucial.