Guest post by In this exclusive interview, Rich Sharples, Product Management Director at Red Hat, talks about OpenJDK. the free and open source implementation of the Java SE platform. The IcedTea project, one of Red Hat’s major contributions to the OpenJDK ecosystem, has done a great deal to enable upstream adoption of Java on the Linux platform; however, the question remains whether Java would’ve been more ubiquitous throughout the Linux universe had Sun open sourced Java much sooner than it actually did. Rich discusses some of these issues and talks about some of the new features in OpenJDK 7, as well as the impact that dynamic languages, increased modularity and virtualization will have on the Java platform. He also describes the impact he thinks Oracle’s acquisition will have on licensing options around OpenJDK.
Does this actually matter now? Seriously? Everyone can discuss what ifs all they want to but it doesn’t change the past. Instead of wondering if Java would have been more ubiquitous on Linux if it had been open sourced sooner, perhaps they should be wondering what they can do now to make Java more ubiquitous on Linux now that it is open source. Hint: Java bindings for a lot of major libraries might go a long way… oh, and a native widget toolkit that is simple and straight forward would go a long way as well. Currently SWT is the only option in that area, and it is anything but simple and straight forward.
The other issues discussed, however, are quite interesting.
I could not agree more. Java still could turn the negative trend around, but they have to act rather fast.
Not that either one is wildly popular. But I have to wonder how Microsoft .Net of all things managed to get the jump on Java for FOSS development under Linux. Miguel de Novella, I guess…
Simple answer to that actually, it made development of native-seeming apps very simple, at least for GNOME. Bindings to all the major GNOME libraries were provided and are quite extensive, and their C# API is extremely straight forward. Java has the language, but nothing really native around it–very few bindings to native libraries, no native toolkits other than the overly complex swt (not even part of Java itself in any case). Java apps just don’t integrate well with most of the native environments–they don’t act quite the same, they look out of place, and a lot of functionality is not available to them. That’s why Mono got the drop on Java, a very unfortunate thing imho. It seems rather typical of Sun (pre-Oracle at least)products in recent years… huge potential, thrown away by a string of bad decisions. Java on the desktop needs a massive improvement before most will seriously consider it for desktop apps, and unfortunately is confined for the most part to backends of enterprise applications. Great language, not so great libraries for the desktop.
I don’t dislike Java and I don’t mind apps looking different – I may even like it.
However, one interesting thing about .Net and Mono that sets it apart is the plethora of languages available for use. I don’t think this played any role in its adoption on Linux, but at least the feature is there for people wanting to experiment with different languages. Being in scientific computing now, I’m not really among this crew anymore (its either Python and its wrappers, C/C++, and if I can’t avoid it Fortran & Perl). Java in my area tends to be reserved for big projects where you need a nice GUI.
Must resist… urge…
🙂
Edited 2009-08-01 13:28 UTC
There are certainly some bad examples out there, usually older projects. Here is a good example of a nice GUI (IMO):
http://www.cytoscape.org/screenshots.php
They seem a bit cluttered, but most of it uses native toolkit. Which takes away the worst eye-sore.
Edit: typo
Edited 2009-08-03 07:21 UTC
Regarding bindings for native libraries, I’ve recently had the pleasure of trying out JNA (https://jna.dev.java.net/) which makes it really easy to call native libraries. Instead of writing heaps of ugly c/jni code you only need to define an ordinary java interface that matches (a subset of) the library’s header file. All the stuff like pointers, structures, function pointers, etc is handled quite naturally. I haven’t tried it on anything very complex though (or anything c++).
That looks quite cool – will have to take it for a spin some day