Smeltet Kerne Oracle This is What You Need to Do With Java..
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.
Swing
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.
Modules
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.
- Login or register to post comments
- 7158 reads
- Printer-friendly version
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Artur Biesiadowski replied on Sat, 2010/03/13 - 4:53am
> all those varied concepts equals high complexity and makes code much harder to maintain and extend.
I wonder - have you got a chance to try maintaining and extending program written in C# 3.0 or scala (one using 'varied concepts'), or you just feel that it makes code harder to maintain and extend? Anyway, most steam goes now into JVM extensions to allow other languages rather than expanding java-the-language (with notable exception of lamba/closures added to the plan on 1.7 at the last moment).As far as Swing is concerned, for me, main issue is startup/classloading issues - which impact perceivd speed of the swing applications (you click on menu item, 100 classes have to load - it looks like menu is slow). Properly written swing app can be reasonably fast when warmed up. I don't see any real difference between resizing/min/maximizing Azureus versus Firefox or Open Office. If you compare Netbeans versus Visual Studio, it is not really about swing versus native...
Jay Huang replied on Sat, 2010/03/13 - 11:20am
Swing is pretty fast with warm start and it’s probably the most flexible GUI tool around. It’s a little complicated but not as so as MSVC. I hope that Oracle can add more native supports for Swing. For instance, the file chooser GUI is pretty bad with Swing. There is no type-ahead support for JFileChooser nor does it support native file chooser functions. I think that I read somewhere that they are going to fix it in 1.7.
Gagandeep Singh replied on Sat, 2010/03/13 - 1:34pm
Andy Leung replied on Sun, 2010/03/14 - 12:14am
Besides, Swing is actually very fast if you just look at NetBeans itself, even the windows framework it created when you create Swing app in NetBeans, it lets you create something in different ways than in the past, for example, when you create action, the tutorial and the code generation itself show you "Action" rather than implementation of coding in Dispatch Thread.
I personally don't want any native support because if that is the case, it introduces high cost in JRE/JDK maintenance, and we may experience more experimental code ever.
But...just My 2C.
Dennis Cheung replied on Sun, 2010/03/14 - 11:17am
Peter Bliznak replied on Sun, 2010/03/14 - 12:24pm
"I won't join the quireboys singing scala"
Listen just because you don't understand something that other do doesn't give right to use this kind of language.
Behave as a professional ok?
Joonas Koivunen replied on Sun, 2010/03/14 - 1:03pm
What you are saying here is:
Hopefully many will ignore this post.
Fabrizio Giudici replied on Sun, 2010/03/14 - 8:56pm
Michael Urban replied on Mon, 2010/03/15 - 12:09pm
> Swing is not fast enough.
Seriously? In 2010 you are going to try to use the tired, old, and flat out false "Swing is slow" argument? Hint: It's not 1999 anymore. And Swing is not slow anymore. Almost all performance problems with Swing applications these days can be traced back to programmers not knowing how to use Swing correctly, not understanding how event dispatching in Swing works, not understanding how to properly create graphics objects in a way that can use hardware accleration.
>Make either Native or Nimbus the default look
>and feel for JavaSE 1.7. I prefer Native - dont
>delay this tough decision!
Absolutely NOT! That would break backward compatibility for thousands of applications that rely on the fact that if you don't specify otherwise, you get the cross-platform look and feel. And if you don't want that, how hard is to add a UIManager.setLookAndFeel() call to your source code?
>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.
When was the last time you looked at Swing in GNOME? I'd be willing to bet you can't tell a Swing application from a native GNOME application. Swing in Java 6 has extremely good GNOME L&F support. As far as KDE support, the vast majority of Linux distributions use GNOME. And GNOME is the default desktop on Solaris. So I doubt we are going to see KDE support anytime soon unless a third party steps up to the plate and provides something.
>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.
uh... Swing using native L&F picks up the DPI settings from Windows just fine. So it doesn't need fixing because it isn't broken. And if the cross platform L&F picks up the DPI settings, well... It's no longer cross platform is it? Cause you can't guranteee it will look the same on all platforms. That kind of defeats the purpose of the cross platform L&F.
You said you've been "dabbling in Java clientside lately", which I guess probably explains why all of your statements about Swing are basically completely wrong. 72 DPI might be so 15 years ago. But your complaints about Swing are so 8 years ago as well. Virtually none of the problems you complain about in Swing have actually existed for at least 3 years now. Stop "dabbling" with it, and actually learn how to use it, and you will see what I mean about all of these complaints being invalid and not having applied for at least a few years now.
Jay Huang replied on Mon, 2010/03/15 - 12:10pm
in response to: fabriziogiudici
Costantino Cerbo replied on Mon, 2010/03/15 - 12:52pm
I list some of them:
Give a look to this blog post http://elliotth.blogspot.com/2006/04/gtk-laf-in-java-6.html to visualize how the GTK L&F still disappointing is (I've also tried with OpenJDK 7, but the problems are the same).
Tom Wheeler replied on Mon, 2010/03/15 - 4:02pm
in response to: hksduhksdu
FWIW, I happen to know a fair amount about NetBeans internals and I can tell you that it's able to achieve this impressive speed through a lot of clever optimizations, such as declarative configuration to defer classloading. Since it's tough for developers to replicate that sort of thing on their own, it's just another reason why many Swing developers are using the NetBeans Platform as the foundation of their applications.
I wanted to also add that it's good to see that nearly everyone in this thread mentioned how Swing is important to them. I think it's been neglected for the last few years, but hopefully that will change soon. At least for me and my clients, integrating generics into the Swing classes or finally seeing JWebPane would be a million times more valuable than anything related to JavaFX.
Thierry Milard replied on Tue, 2010/03/16 - 5:37am
JNLP :
Agree with you 300%.
- JNLP has yet to be improved.
I will add something her :
1) Good : one file many OS
I think the good thing about JNLP is that (theoricly at least) with this packaging-language you can target you web-software from linux to windows and Apple.
2) JNLP Problem : it is an almost-full-langage to learn
The biggest hurdle for jnlp is that even if it is not that complicated to learn (well ... ), developers like us use this JNLP stuff only once every 4 months. I mean not on a dayly basic like java.
The consequence is that I often forget about the JNLP syntax. Each time I have to learn a "kind-of-new" language just to use it two days a year. Painfull. This is really bad because I forget every year the syntax, and I always loose 3 days to get use to jnlp again.
So my advice : The easier JNLP it is to master, the better it is.That is the botomline for sucess in packaging
3) Urgent (and easy) To be made : an XML version of JNLP
The bad thing about JNLP is that it was defined before the XML trend. I think it is difficult and not standard to read. Honestly if I could have a JNLP-XML-TAG version I would love it. Because I am used to reading XML file and XML tags.
Wish someone could do it at SunOracle. And I am almost sure it would not be so complicated : it is just the parser to change not the JNLP engine ... but it would be so nice for users like us.
4) (the perfect touch) . A web service that package jnlp by itself.
Let's dream a bit . I am a developer, I have my jar package. Now I want to publish on the web this jar (jnlp yea !) But I am so lasy.
- 4-a) so I go to java.easywebpublish.com
- 4-b) I log in with my email
- 4-c) the nice looking web service ("wha! Sun is getting good now at this ! ") asked me to upload my jar file. Ok done.
- 4-d) A few nice and simple on the site ask things like if i want publish on Mac, windows, ect...If I have logos, librairies.
- 4-e) Later it ask me if I want a to buy for 10€ a "freedom certificate" that prevants the "security waring" windows to display. Oh boy I buy it with my Visa card !
- 4-f) I clik on the "Publish" button after I added the ftp login of my internet site.
And yes it is done.
Later on I test my web-software on a windows machine, Apple, ect.... everythings works fine.
The dream, a world with no packaging language to learn.
Ps for 4):
Now I can hear what people are Sun are going to say : "Ya ya you dummy but we are doing this for javaFx, a good packager".
You are right.
My question is now :
"you guys don't you think it's kind of ... well idiot ... to have done all this work with javaFx (that has by the way 0% makteshare today) and not with the few thousands of java-front-end-developer (your clients by the way) that struggle every month to package swing applications.
Good question indeed. No ?
Rael G.C. replied on Tue, 2010/03/16 - 7:32am
Gauthier Willia... replied on Thu, 2011/07/07 - 3:05am
In time all these things will improve and java will be updating new software’s for programmers to use. For me swing has been lacking something even though I am not use to not like some of the guys here but it has been improved and lately it really is getting faster if you really knew how to use it properly. Senior Healthcare Consultants
Nabeel Manara replied on Fri, 2012/01/27 - 9:23am
Great list except for the last point. I started to write in a more functional style when I learned Groovy and Scala. The biggest advantage of functional capabilities in a language is:
- abstraction of “do the following with a perfectly set up resource”