Reading time:

16 minutes

Word count:

3470

Java’s Thoughts on Flash

Let me introduce myself. My name is Peter Pilgrim, I am a Java Champion, number 91 in fact, British, living in the United Kingdom. I currently work for a top-tier investment bank in the City of London. Although I am not a chief executive officer, I am an experienced developer, designer and sometimes architect therefore can offer my wisdom on Java.

Java has something to say about Steve Job’s “Thoughts on Flash.” open letter.

First, let’s tackle the issue of “Open” from the perspective of Java world.

Java was the first successful commercially-supported language, once proprietary, invented by James Gosling, who was a chief technical officer / research scientist / patriarch at Sun Microsystems. The Java platform and langauge was created in 1995. Sun, then, took about ten years to open sourced it 2006 under the OpenJDK project. In 2010, Oracle corporation acquired Sun for deal valued at more than $7 billion and therefore became the new stewards of Java. The Father of Java , Gosling, also left the new acquired company in April 2010.

Java is open source. There is no doubt about it. The code for Sun [Oracle] JDK 6, is available at the Open JDK project. However, just because code is in a repository does not make a free-for-all build anything you want in the Java world. Oracle holds the license and copyright for commercial JVM support. Oracle also works on new code for their JDK behind closed doors with the promise that the code will be eventually open source. For instance the up and coming JDK 77 with modularisation support. Oracle’s changes tend to be dynamic, hot changes and innovations to the JDK or platform, therefore are in a constant state of flux.

There, then, is the Java Community Process, of which Oracle may or may not decide the change its politicies and rules this year, which has traditionally attempted to standardise the application programming interfaces that can be delivered with and certified as a Java runtime or stack. In the past, the JCP has had it flaws, warts and all as other Java Champions and commentators could pontificate and debate until tomorrow never comes. Still, Java is still open to the community in comparision to say the Flash platform and the Apple’s iPhoneOS solution.

At least for a few years, now, Java has been known as “open”, code is available and it is free to experiment or develop. There is the Open JDK project and the less known Apache Harmony repositories. Because being “Open” for Java is  major improvement over Adobe Flash in that regard, which is closed source and very proprietary to develop with, allows other businesses and educational institutions to modify and experiment, research and innovate. It is easy to confuse Flash and the Flex builder solutions. Flash is definitely the runtime player that runs on the client side. Flex is the solution that make Flash communicate with the server side. Java has at least four different successful IDE for developers and engineers: NetBeans, Eclipse, IntelliJ and Oracle JDeveloper. Flash in its guise a Flex has only one at the moment, although IntelliJ might be offering a Flex plug-in of its own. Apple on the other hand now forces developers to build only with certified tools namely: Apple’s Xcode, Objective C libraries and/or JavaScript; and of course you now need to own Apple MacOS for target their mobile platform. To top it off, the development and business also must enroll in the Apple iPhone Developer Program. Jamie Kosoy also critiques Apple’s decision on his re-thoughs on flash blog entry.

Let me throw in a firework rocket [no pun intended to Adobe fans] to explode, since we are looking at the mobile platform in this tit-for-tat row between Apple and Adoble. Google has its Android, Open Handset Alliance platform, which to all extents is built with the Java programming languange syntax and semantics. Why did Google choose Java syntax for it’s Android platform? The answer is because it understood by 7 million Java developers, engineers and architects.

For Google these developers were a very important factor, even if there were stock Java engineers, when they launched the Android platform in late 2007. The figure of 7 million Java developers in the world was published by Sun Microsystems at their last ever JavaOne conferences in San Francisco (2008/2009). Android is, of course, different in one very important regard, the Android Dalvik compiler produces unique byte-codes that are processed only by the Dalvik runtime executor. I could also throw in a some sulphuric acid, regarding the Java Mobile Edition (Java ME), which Oracle claims is the most successful and ubiquitous VM runtime on embedded devices ever, and its history, but that is another story for another blog. All you need to really know that Java is a “Open” language, the platform(s) nearly so. 

Second, Java does not say so much about the “full web”.

Java is inspired the “full-web”. Duke (the Java Mascot) only says that his/her/their recent success is running on server side. Historically Java is there in the “cloud” so to speak. Where as once, Java ran was originally pushed as a client side solution, including building a clone of the Mosaic browser inside Java (Remember Sun Microsystem’s HotJava product solution.), today’s web standard world is completely different to that one Java was attempting to solve back in 1996. The power of web standard is now self-evident.

Java failed abysmally on the client side for several early web developers. Java fell short at the turn of the new century, because of innovation, corporation uptake, change to the server side computing. The vision was with server side then. Java Applets had given way to Swing Applets, the ill fated and misimplemented Java Plug-in solution and the belief in Java Servlets, Java Server Faces, the explosion of Java web frameworks. (This author is the organiser and founder of a Java User Group [Java Web User Group].) This was followed by application server, EJB 1.x and 2.x debacle, the launch of the anti-EJB brigade, the foundation of Spring Source, the Spring Framework and various other non-client side Java technologies. I could go on.

Hence, there was opportunity for Flash to move in the position that Java Applet vacated in 1999. Unsurprisingly there was explosion of Flash inspired web sites and abilities from 2000 to 2004. Adobe eventually acquire Macromedia, the original company that made the Flash plug-in successful and almost ubiquitous. Flash and Adobe did very well in the mindshare of the web design agencies and web developers. As the American say, Flash hit a home-run with the explosion video sites, with YouTube at the forefront of the bringing video to consumer demand. During the same period, what is not lost on Apple is that Adobe prioritised to supporting applications on Windows. Hence, there is a bit of wounded pride with Steve Jobs and Adobe,  I feel, when Apple were really hurting financially. Remember that their MacOS based desktops iMacs machines were battling in the consumer markets against Windows XP Home Edition, then so. Pain is certainly felt when a decent friendship suddenly becomes emotionally strained.

However, as Flash was being successful, there were web developers such Eric Meyer who banging their heads attempting to solve browser incompatibilities. Web site owners marched to web standard bodies (W3C) demanding action not talk. There was change and may start to predict web standards would solve many of the solutions that Flash, proprietary, was being used to solve.

Smashing Magazine has a great post called the Gradual Disappearance of Flash Websites. There are real good links to web sites built with HTML, CSS and JavaScript, including a delicious 3-D Cube Demo example. There, I do agree with the jist of the latter article that Flash will decline in the future if your future is based only by looking throught the eyes of a web browser!

Ah ha! In Steve Job’s open letter, I believe he is confusing consumers. There are web applications and there are native applications. There is a different in how these applications are running on consumer devices and desktops machines. Web applications run only through a web browser (Safari or Opera on the iPhone). Native applications are programs targeted to the instruction set of the microprocessor of the device, which are dependent on the operating system that runs on that target device. In other words, native application do not require a web browser to run.

Adobe is due release a Creative Suite 5 cross compiler (Flash to iPhoneOS)  that is supposed to take code written in the (proprietary) Flash language (ActionScript 3) and produce a native iPhoneOS application. Every computer scientist knows that the object code can only then run natively on the target device. You cannot take the same object code and then run it on a different device e.g. Symbian or Android phone device.

Now here is the really good thing. Java is a portable, secure and Internet accessible language [and platform]. It runs a byte code instruction interpreted or processed by a virtual machine. If you can port the virtual machine to the target device in question, and if the platform owner allows this, crucially then you can in theory run any pure Java program. The second part is that the Java runtime library must also be ported to the native operating system so that Java access device I/O, peripherals, magnetometer, USB, bluetooth, RAMdisk etc. Presumbly program interfaces to the outside world, hence input and output is essential. In other words Java was designed from the beginning to be cross platform in such Sun Microsystems thought saving developer time, time-to-market and dollars, pounds and euros. Before cross platform one had to make an expensive port of program from one operating system to another. However if you can enrich the runtime to such as extent as it supports a great deal of features and introduce a platform capability API then you have a runtime platform with real power and production line engineering. I believe this fact is deliberately ignored by Apple,  who want to control, of course, their mobile platform completely.

The dream of writing a language and being able to run it on several machines was a slogan coined by Sun Microsystems “Write Once Run Anywhere”. It is sadly now just simply a Java ideal. Sad, but true! Where Java has won a battle on the desktop, because Java SE runs on Windows, MacOS and Linux machines, it is clear that in the mobile phone / embedded device space cross-platform developers will be wringing their fists for a long while to come as the manufacturers, phone carriers , platform engineers, independent service provides and tool providers about face and run headlong in random directions.

Java has plenty to say about “Reliability, Security and Performance”.

The Java Virtual Machine has improved year-on-year after each successive major release of the Sun (now Oracle JDK), the performance has shot upwards and never downwards. Other vendors of Java Runtime Environment can claim the same, and Oracle’s own JRockit JVM have outstanding records of reliabilty and performance. There is no question about the JVM performance, whichever vendor, IBM or Oracle, there are the best in class. Java is said to faster than C++ for some classes of instructions. Performance some Flash and JavaScript are behind us and not in front of us.

Java’s design already had a security in mind at conception. From the very beginning of the language and platform, James Gosling and Henry McGilton thought seriously hard about robustness and security of then interpreted byte codes. The Java platorm also offered to developers the revolution of a platform with a built-in garbage collector and thread concurrent programming for the masses. These were major innovation on the abstraction curve for developers who were only dreaming of becoming C++ gurus back in the mid-1990s.

Not to be with reclaim, the advances of performance of the HotSpot mean that the Java is fast, and industry pundits no longer dispute the performance of Java. Disastrous crashes on the Java applet has been consigned to history, since Sun Microsystems introduced the brand new Java Plug-in architecture in 2008. Java Applets run in a separate process to the browser and therefore if the applet ever crashes it does not take the browser with it. The first browser to sanction the new plug-in architecture was Google’s Chrome browser.

Business rely on Java on the server every single day, hour, minute and second of the year. Diverse sets of companies use Java and license the technology from Oracle. The licensee include IBM, JBoss, Facebook, eBook, Salesforce.com and mobile / wireless companies such as Nokia, Sony Ericsson, Research in Motion and Samsung and others. Java’s record as the foundation technology in several e-commerce business, investment banks , Fortune 100 corporations, Times Rich List business and its staple of server side computing speaks for itself. Even Adobe recognises this with it Flex products, including BlazeDS connectors to de-facto standards such as Hibernate OR/M providers and TopLink. Java is great on the server-side. However, it is now the client-side and on the future of the “open” mobile platform that Java must now consider itself. Apple is now guaranteed not to own this market for itself, because it has now forced a division between enterprises who are considering the mobile market as a platform. Apple may be the most innovative company in the space, but this may not always so in the next few years.

Sun Microsystems, famously, announced at JavaOne 2007 its strategic decision to reinvigorate Java on the desktop. In 2010 however the times have moved on. Java on the desktop made a come back of sorts with a better browser integration, the new JNLP and the runtime allows applications to be dragged and dropped from the browser on to the user’s desktop. However, Java’s history of poor functionality has hurt it and bad memories in architects and top manager are difficult to change. However all is not lost in the rich internet application place, especially as a time-saver and the ability, in theory, to target more than one end-device. For example, I heard rumours about the Matrix product at Morgan Stanley built on Flex/Flash is now running late as a e-Commerce project. In June 2009, Matrix was trumpeted as a show case for Flex development and as a real-life financial trading application. Your author is now writing this blog in May 2010 and there is still no release of the Matrix platform. I would say that this is real chance to push JavaFX for the the enterprise, and really push JavaFX on an Android platform! There are  other stories in the grapevine: apparently there are many investment banks in the city that are now thinking about deploying Microsoft SilverLight as their strategic e-portal offering on their internal and customer workstations. I believe these large companies backing Silverlight [and to a lesser extent Flex] are most likely not thinking of a mobile platform, which perhaps with the advent of the first consumer tablet device, the Apple iPad, is a poor foresight into future professional consumer behaviour.

Everyone now knows that Flash (Flex) is never going to work on the iPad, iPhone and iPod devices. Apple’s runtime decision against cross-compilation and cross-platform runtime also precludes SilverLight and Java runtimes or any sort of virtual machine. However, since the consumers of these trading services will most likely not use an Apple devices or have a native iPhone application to do work with, this may not be an issue in the long run. Another solution for banks would be develop a cross platform application in JavaFX instead. Thereby saving the development cost for a web and native application. I believe core functionality and development teams can be saved by only adopting one virtual machine solution. Instead of disparity between Silverlight/dotNet or Flex and server-side Java engineers.

Java could definitely make it big in the mobile / tablet device space, if only Oracle got its business strategy correct. It would appear that Java badly needs a mobile platform advantage, which to my mind is today’s high performance Android phones, rather than Java ME, and the ability to target a runtime on both mobile and desktop devices. So Java as a platform had better get it ass in gear!

Java has work to do with Mobiles “Battery Life”

Java ME has been running on phones for a long time. Android is built with the Java language. It is those pesky Android application pinging the server every 10 seconds that are probably responsible for draining the life on HTC Desire, say. However no application, if carefully written, can eclipse the bad hardware design. I felt that the Steve Job’s criticism of Flash on phone was a little harsh. Granted Java ME engineers have fine tuned the runtime or Android developers can pretty do the same. However, if the phone itself has a AMOLED display that drains the battery then it cannot be purely the apps fault.

Also as I said in the cross platform section above paragaphs, the runtime can be enrich with the native capabilities of the platform. Application can be permitted to create dynamically the capabilities of the device that they are running on. It makes perfect engineering sense to do so. If the underlying device has hardware acceleration for graphics, video and/or audio then it is up to the device manufacturer to provide decent API for developers (platform , operating system engineers and not application engineers) to use them. Witness the debacle years ago with Linux Kernel developers with the various graphic card vendors. It was not until the vendors, ATI and NVidio, really accepted open source or provided drivers for Linux system did accelerated graphics really shine on Linux. The situation will be same for phone manufacturers regardlessly of Apple, HTC or Nokia. The buck stops with the manufacturer to provide open and fair APIs and guidelines that explain how to utilise their hardware for the best power efficency and economy ratios.

Java has not said anything really on “Touch”

I believe Java has fallen short on this issue with multi-touch support. There is no known or de-facto acceptable Touch or Gesture API on the Java platform, apart from one that Simon Ritter, technological advocate has been showing off on various sites around the globe. This is not good for Java. And when I speak off Java, I am speaking of JavaFX on mobile devices.

Clearly, Steve Job’s has this one, for now, in the bag. In any case how does a web application take advantage of multi-touch, for instance a pinch zoom gesture, when the necessary API has not (yet) been approved by the web standard bodies? As far the author knows, Apple is the only companies with widely known and published Touch application programming interface. Not surprisingly, Apple is the leader in touch screen innovation outside of the Microsoft Surface not productisation curve. However, Microsoft predates Apple by at least a year with a public touch gestures product on full view and yet never delivered a mobile touch screen device to compete with Apple, even when the iPhone was announced.

I find that course of history changed. I believe it is Java’s job to understand the nascent Touch API’s available in Apple, WebOS, Android platforms and the wider research and build an acceptable API for the general messses of developers. This is job for Java developers with itch and a brand new Java Community Process. As these form factors appear in the decade, 2010 onwards, these iSlates and their burgeoning application development markets, including “app store” will require a cross-platform API of sorts. Even if every agrees to disagree, there a vacancy for a common Touch UI framework, idiomatic paradigm or design pattern. 

Ah! Via Motus

In conclusion: Java is cross platform. Java is moving back to the desktop in a huge way. Standard Java needs to provide a better story on mobiles. JavaFX is getting there. Java can be proud of its legacy is reliability, security and performance, but Duke, the teenage boy, must keep pushing the innovation curve. Java and JavaFX need a story on Touchscreen API with gestures. JavaFX needs to be ported to Android platform, in order to at least proof a point to both corporation, Adobe and Apple, then cross platform Java (JVM and JRE) can still do it, continues do it and will do it in the future. Java can learn lessons from this early battle of the mobile platforms. It is but an early skirmism of yet more tactical fields of deployment in the decade. As we move and live through this decade the success of Java needs to be built on. The platform must on through these increasing competitive times.

(Edited on a moving Train *PP* 30/04/2010. Will tidy whenever)

Peter Pilgrim writes for the ACCU UK Magazines, CVu and Overload.