Oracle This is What You Need to Do With Java..
Join the DZone community and get the full member experience.Join For Free
I think its safe to assume that most Java developers feel some in trepidation as Oracle take over the stewardship of Java. Will Oracle's agenda be compatible with the current diversity of the Java ecosystem? So far Oracle has done its best to avoid alienating the community in this webcast on the future strategy for Java and Oracle has also claimed that it will continue to invest heavily in Java. But there's certainly a PR job ahead for Oracle - the Java community has grown up with the goofy ponytalied engineers at Sun, but now Java is controlled by a company best known for its hostile takeover of peoplesoft and hirering detectives to dig through their competitors trash.
But laying all fears aside this could also mean new fresh prioritization of the investments that go into Java. Many bloggers have pitched in on what Oracle should do with Java and here is my view.
Java Web Start
Its been around for a very long time and it has great potential as it offers much smoother download, installation and launch of client-side applications than native applications and its also much safer for the user because of the security sandbox. Unfortunately every time I revisit this technology I find myself wading knee deep in a bug-infested swamp. JWS must be brought on par with the general high quality of JavaSE.
- Put lots more developers on JWS and put things right once and for all.
- More automated tests. Judging from the number of regression bugs in JWS my guess is there's either no or very few automated tests.
- A change of mentality. It's not OK to break central features and leave them broken for months or years. A huge rewrite like 1.6.0_10 should live in a private branch until its robust enough to make it into public.
I'm a serverside programmer but I have been dabbling in Java clientside lately. Swing is actually a pretty cool GUI platform. In my latest project I have been building a Swing application with per-pixel alpha blending and heavy modification of standard Swing components. I'm amazed how flexible Swing really is. But I also recon Swing is a huge complex beast that needs continuous attention and investments:
- Swing is not fast enough. Fixing the grey rect problem and double buffering should not be the last word in that debate. For instance maximizing and minimizing the main window of my Swing application is like watching a movie in slow motion and resizing the window turns it into a horror movie. We need more speed in every aspect of Swing. Perceived speed of Swing applications is very important to Java at large because Swing is the show window of Java. People who are only fleetingly acquainted with Java will form their opinion on what they can see with their eyes (not the abstract idea of whats going on in the belly of a JavaEE server). If the majority of Java GUI application use the very unsexy Metal look and feel and blink and freeze regularly people will equate that with the general state of Java.
- Make either Native or Nimbus the default look and feel for JavaSE 1.7. I prefer Native - dont delay this tough decision!
- Put more developers on Look and feel. Build look and feel for Linux Gnome and KDE on par with the quality of Windows look and feel.
- My windows desktop is running 140 DPI which is probably in the high end but Java assuming 72 DPI is so 15 years ago.. It makes the font tiny compared with native apps. It needs fixing.
I hope Oracle has their best and brightest on this project - the implications for Java is so far reaching.
From a clientside aspect modules will hopefully improve launch time by leaps and bounds as the dependency mess of Javas runtime is straightened out. Google showed that an extra 0.5s latency can cause a 20% drop in traffic. How many potential users and customers do I lose because my Swing application take 10-20s to load on a freshly booted PC?
From a general Java perspective I hope Oracles module system will have a high degree of usability. How class dependencies are resolved today in a classloader hierarchy is rocket science. A few months ago I spent more than a week together with another consultant trying to make a bunch of JavaEE applications play nice together in a IBM WebSphere app server. They all required different versions of the same logging framework - a recipe for Java dependency hell. In the end we had to throw in the towel and create separate server instances for the applications. A very costly affair for the customer. All I want to define in my application is that it depends on module named "X" version "Y". I don't want to have to analyze visibility of dependencies based on hierarchies, classpaths, customized classloades etc.
- Spare no cost in the Java modules project.
- Make usability a prime goal. I want to be able to ask the server administrator, who has no clue about Java, to install the Log4J version 1.2.3 dependecy such that it will be available to my application without having to explain classloader hierarchies to him (from experience I usually end doing serveradministration at this point). I want to be able to list Log4J as a dependency of my public downloadable application such that any non technical user can download that dependency from a separate site, double click it to automatically add it to the local module repository and thus make it available to my and other applications. And don't stop at the end users - developers need usability too. Modules and their dependencies should be out of sight for most of the time - not something that requires a dedicated position on the development team.
- Set some goals as to how fast a clientside application should load if it contains 1000, 2000 or 5000 classes and so on. Make load times acceptable for realistic clientside applications.
- Delivering a Module system is very urgent. It should have been available in Java 1.0!
- Notice how I didn't mention OSGi. Thats because it doesn't go in a sentence with usability.. :)
Hybrid functional and imperative programming
Oracle don't go there! Javas high ground is big enterprise applications in banking and insurance with hundreds of thousands or millions of lines of code. Java is there among other reasons because its maintainable and extendable even at that scale. I won't join the quireboys singing scala or c#3 because the personal styles of programming they allow are too varied and the crossproduct (new IT complexity term) of all those varied concepts equals high complexity and makes code much harder to maintain and extend. Java is a simple and very verbose language. Lets keep it that way.
- Continue the same conservatism that Sun showed in introducing new language concepts.
Published at DZone with permission of Smeltet Kerne. See the original article here.
Opinions expressed by DZone contributors are their own.