SQL Zone is brought to you in partnership with:

Smeltet has posted 3 posts at DZone. View Full User Profile

Oracle This is What You Need to Do With Java..

03.13.2010
| 8611 views |
  • submit to reddit

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.
References
Published at DZone with permission of its author, Smeltet Kerne. (source)

(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

I think that Oracle has put some of issues mentioned onto their priority list, at least that’s what they are saying.  We need to see a fast Java cold start time as well as Flash.  For client Java, it seems that the only way that I can make sure my applications run well is to bundle the applications with the particular JRE being used for testing so I like a smaller JRE that I can bundle with.   For instance, my application was broken with printDialog after 1.6.0_12 release since they have made some changes with printDialog since 1.6.0_12. There is Bug ID: 6921598 on this.

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

I do agree with the author on the improvements desired especially the Swing framework. I would like it to be much faster than it is now. I don't care what is makeing it slow , if it is the classloading so be it but I should not be bothered by the internals otherwise what is the use of having a framework?  Something like SWT has much faster response time.

Andy Leung replied on Sun, 2010/03/14 - 12:14am

I think there is something to do with application design rather than Swing? Because if you build a Notepad type of app with Swing (just like the demo in Netbeans), it loads immediately. Now if you say this is not complicated enough to be benchmark, then why did you say it has to load 100 classes before showing a menu? Or on the other than, loading a Notepad or a NetBeans, when you click "File" menu, it still loads 100 classes, it should not make any difference between them, but in my experience, both notepad and NetBeans load menu instantly, so perhaps that's the developer's job to speed it up?

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

The real problem of Swing, is not about "redraw" performance nor classloader (but I agree they are important) 1. It is not stable. I mean, Swing app can run stable, but not the library versioning. In @Jay Huang example, a single stupid bug will break your application. Developer will have to find ways to workaround, or forced the JRE version., which are stupid and supposed to be forgotten from application developer. Java not only "Debug everywhere", but also "Debug every version" 2. It is not (network) optimized. I mean, VNC or RDP, or else Why it brother? because they are going to be "virtualized", many company are already shutting down PC and replace them with Virtual PC, Terminal Servers, Xen, VMware, and etc. Nothing programming can do too much to stop them to save money and power. It will be meaningless how fast Java it's own, but forget overall performance and response time in the platform. When I scroll something, does it keep redrawing the area or just keep change the offset of visible area of offscreen butter to the presentation layer? Is the performance really optimized or just offloading to the platform?

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

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) [1]. 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 [2]. 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. [3]

What you are saying here is:

  1. linux style package management, already implemented by debian, redhat/fedora and almost everyone else
  2. "I want to be able to list log4j as a dependency of my public downloadable app such that any non tech user can download that dep" -- why on earth would you like to have your user to do that -- if anything, those jars could somehow be cached, if there was a way to reliably get an SHA1 from a file through HTTP
  3. developers have this kind of usability already with maven

Hopefully many will ignore this post.

Fabrizio Giudici replied on Sun, 2010/03/14 - 8:56pm

There are many things that Oracle could do with Swing, but frankly I don't see speed at the primary priority. I mean, the more speed the better, but Swing is *not* slow. Especially for the use cases cited by the author, I'm not seeing any kind of performance problems - I suspect that they are related to bad design of some application. In any case, Swing is absolutely not slower than SWT.

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: Fabrizio Giudici

I agree that not much Swing performance will be done by Oracle soon but certainly I hope that the code start time for Java in general can be improved.  Overall I hope that Oracle will deliver on their promises.  Sun had a lot good intents and promises in the past but they just couldn't deliver what they promised.  The Java Store was announced at last JavaOne as a new and exceting thing from Sun, however it's still in beta after almost a year and no progress update can be found anywhere.

Costantino Cerbo replied on Mon, 2010/03/15 - 12:52pm

I strongly agree that the GNOME L&F still needs a lot of improvements.

I list some of them:
  • Compared to the other L&F is the slowest one.
  • The JFileChooser is outdated (see here for an alternative: http://code.google.com/p/gtkjfilechooser).
  • Combobox doesn't look native.
  • Table header doesn't look native
  • Tabbedpanes are always too taller.
  • Background/Foreground colors aren't always settable.

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: Andy Leung

Or on the other than, loading a Notepad or a NetBeans, when you click "File" menu, it still loads 100 classes, it should not make any difference between them, but in my experience, both notepad and NetBeans load menu instantly, so perhaps that's the developer's job to speed it up?

 

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

Modules - have you heard about Jigsaw project?

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”

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.