Is Client-Side Java Dead?

maverick2003 asks: "Just while I was thinking that client-side Java is well and truly dead, here comes along a project, a really large one to boot, that involves developing a 'rich Java based client'. While I'm sure that given the right resources and time-frame, this is certainly possible, I was wondering what kind of experiences the Java community has with developing large Java client side applications. Five years ago, Swing and Java client technology had light-years to go before matching up with native Windoze APIs. Getting Swing to do exactly what you wanted, was a guaranteed trip into pure hell itself, with all sorts of weird bugs and workarounds to deal with. The applications that I've developed since then uses VB/VC++ and will talk to a Java server. This has gotten much easier nowadays with SOAP libraries available for cross-platform stuff. Have things improved since then? If yes, by what degree?" What would you use as an example of a large-scale, real-world, high-quality client-side Java application?

Comments

real-world client side java apps

[HaiLHaiL]

NetBeans IDE
LimeWire Gnutella Client

Having a modern, Swing-enabled JVM included with Windows will hopefully lead to even more Java-based applications. Then again, so would a good IDE with a form-builder. NetBeans and Apple's Project Builder do a pretty good job though.

Re:real-world client side java apps

[UberChuckie]

Not the mention the popular Java IDE Eclipse. Now that Microsoft has to ship the Java VM, you'll probably see more of Java Web Start.

Re:real-world client side java apps

[Randolpho]

SWT combines everything that's good about both AWT and Swing.

AWT used native OS widgets, but it took a least-common-denominator approach -- it only implemented those widgets that were common to all target platforms. Things like frames, and text fields. Many widgets that weren't available on all platforms, like, say, a combo-box, were not implemented. It had little to do with "crappy GUI libraries" and much more to do with *incomplete* GUI libraries.

Swing went the other route, offering a very full set of widgets that is, indeed, cross-compatible for all platforms. Unfortunately, it took a huge hit in performance to do this, as Swing draws the widgets using the JVM rather than making a JNI call to a native (and much faster) widget.

SWT offers the best of both worlds; it offers a robust and standardized library just like Swing does, but that library is, for the most part, a wrapper to a JNI call, just like AWT was. This gives a marked improvement to GUI performance using SWT over Swing, while at the same time offering nearly all the widgets that Swing does. Widgets not available on some platforms are emulated on those platforms, like Swing.

So, with SWT you have all the performance of native GUI widgets, but with the rich library of Swing. And SWT is cross-platform.

Now harking back to my original post, since some moderator thinks I'm a troll, I'll point out what I meant.

Swing is slow when compared to native widgets -- there is no way of getting around it. Talk all you want about how faster computers will sover the problem; native GUI programs will always outperform Swing programs.

Enter .NET's Common Language Runtime, which is really just a Java-ish bytecode. The big difference, the point that will keep Java from really competing with .NET, is that the CLR makes calls to native widgets, just like SWT. And, of bigger importance: .NET is beginning to cross platforms, just like Java. And *those* implementations of .NET are rumored to make calls to native widgets.

If .NET cross-platform-ness takes off, .NET will outperform Java when it comes to GUI applications, *regardless* of platform.

Sun has a big decision to make with Java: it can continue to push the Swing religion that it has built, or it can adopt a model similar to SWT. I clearly think they should persue the latter.

Java is pretty mature

[ObviousGuy]

Sure, it's not popular or common on the client-side in either application or applet form, but it does exist.

Most operating systems ship with some sort of Java VM, you should be able to deploy wherever you want and expect at least some support.

Sure, it's neither as fast as true binary code nor is the GUI as pretty as native apps, but if you wanted those you wouldn't be thinking about Java in the first place.

Java is as dead as Perl on the client. It's dead to all those who don't use it, but for those that do, it's indispensable.

software

[sporty]

eclipse java development software (eclipse.org)
poseidon uml softare (gentleware.com)

Java not an option in my biology research

[RevAaron]

I do computational ecology work, undergrad research assistant type stuff. A couple summers ago, I was hired to create an application for the visualization and analyzation of a few hundred MB of data- ecological, environmental and meteorlogical. While the pressure wasn't as firm as would be if I were doing work for a corporation, there was still some to use a language and toolkit that was relatively known to programmers at large.

Since we wanted the ability for this app to be worked on under a number of platforms and run on even more, we looked at a few different options. Something like {Perl,Python} + {wxWindows,Tkinter} wasn't an option at the time (and still isn't), as it doesn't run on Mac OS 9/X. With those removed, Java and Squeak Smalltalk (with the Morphic GUI environment) were the options I was considering. I did some prototyping in both Java and Squeak to test performance and ease of development for an app that was definately not run of the mill. We had to be able to exert a lot of control on the way things worked, without writing out own widgets from scratch in the areas in which we needed this. At the time, I had about the same amount of experience writing GUI apps in Java+Swing as I did with Squeak+Morphic- perhaps a bit less in Squeak.

Well, Java blew in my tests. That's not to say it doesn't work well for some things, but in the case of this client-side app, it just wouldn't have worked out. It was slow and a pain to develop for. This was a few years ago, and things haven't gotten much better, unfortunately. For the stuff we were doing- Smalltalk was working out pretty well. And it was working for us, whereas the Java prototype was wasting more and more of my time. This was supposed to be a pretty simple prototype. The last straw was when a new build of the Java version stopped working on Windows 2000, but still worked under OS X and Linux, even though it built fine under Windows and worked 30 lines of code before this build.

Being in science, not business, I luckily had the freedom to be able to dump Java for Squeak Smalltalk even though Java was a much bigger player with millions of dollars of hype behind it (as opposed to Squeak's $0). Unfortunately, most people aren't as fortunate as I, but I'm glad I did it. I learned a lot in how to build apps in Squeak, and build them pretty quickly. The flexibility of the environment and the programming system is unparalleled. Well, a good Common Lisp system may go beyond it, but that wasn't an for us.

Squeak provided an identically working app and a homogonous development environment across all the platforms I used and worked on it under, mostly Mac OS X, Mac OS 9, Linux/x86, Linux/PPC, Windows 2k and Win98. For an app like this, I preferred having a consistent L&F rather than some emulated widgets that never quite fit into the host environment, but close enough to make the situation confusing for my users. While this may be a drawback for certain types of apps, it was good in this case.

The outcome may have been different if I was just building a form-based business app, no doubt.

Once more. This time with feeling.

[Ouroboro]

The short answer to your question is yes, you can really do in java whatever you might otherwise want to do with vb/vc. Most people's complaints at this point are unfounded, and usually based upon unfamiliarity with the latests versions of java, and the vast sea of tools that are available to make java development easy.

The long answer is yes, if you can choose to not support retardedly old jvm implementations. If you are going to try and support microsoft's jvm, then you are going to have a hell of time getting things to work well. I've found that if you support 1.3+ you are usually ok. What would be even better is if you were able to control the jvm under which your application runs, ie bundle the jvm with your application, and use it. That in general would save 99.9% of those types of headaches.

As far as examples of applications that are fairly large scale, and are implemented in java, you might want to look at Intellij's IDEA, or Eclipse. Yes I know that both of those are IDE's, but they are fairly large in scale, and have a fairly sophisticated windowing env.

The JNLP community is a good place to look

[smackthud]

If you're looking for the "latest" stuff going on in the client side Java world, a good place to start looking IMO is at some of the Java applications being written which are using JNLP as a means of distribution.

There is a list of JNLP enabled applications at the OpenJNLP site. Other JNLP related information can be found at VampHQ and at SUN.

JNLP is essentially a chunk of XML which describes the parts of an application, what security settings are requested by the app, who wrote it, a description, etc. Using this file, a program such as Sun's Java Web Start or OpenJNLP can be used to automatically download and launch the application. This is great for developers, because users can simply click on a link in a web page and launch an application, which is cached for the next time its needed, or until a newer version is needed. Just replace a jar on your server with a newer version, and your users will all automatically download and use it. Automatic upgrades! Once cached, JNLP applications can run standalone (meaning, no server) and without network access.

A good example of using JNLP is the texteditor JEXT which I run all the time on my laptop on plane trips.

I hope this is helpful when looking for modern client side java applications.

Quality Java Client Apps are possible

[redelvis]

I've been writing Client side Java GUI programs for about 3 years now. Some have been small interactive graphing tools, but more recently I've been working on a large Debugging Tool API program. In my experience, it is possible to create Swing applications that are:

• Visually pleasing
• Fast and Responsive
• Scalable

However, I have found to achieve these goals at a high level of quality has taken significant experience and many dead-ends. Java Swing GUI's are NOT for "rapid GUI application" the same way that VB is marketed as for instance. It takes solid knowledge of the Swing API - which in my opinion is a very powerful flexible GUI API, but one which comes with lots of "gotchas" to watch out for.

In my experience I would say that a good Client side Java GUI can be developed, but the following pitfalls need to be avoided:

• Avoid GUI Code Generator tools to design your GUI layouts. They lead to highly unmaintainable GUI code but more importantly to less consistent screens (have a read of Building user interfaces for object-oriented systems for more details
• Build a decent framework that sits ontop of Swing to automate and standardise the process of view creation. I've found Swing GUI work can be made significantly more productive and easier to maintain if Swing screens are being automatically generated from data objects. For example, I use a Field builder to generate appropraite Swing fields (text box, combo box, check box etc) depending on the Type of the data field (String = text box, Boolean = check box etc). This way the interface remains constant and up to date with any chances to the data model.
• Know when to deligate work to a background thread, instead of tying up the AWT Event thread ... this is a common mistake in Java GUI's that gives the perception of an unresponsive or frozen application
• For large applications, distribute a decent Java Runtime for your application to run on. This is the approach Borland takes with JBuilder. You are distributing a big app, so why not bundle with it a robust JVM that you have tested your app on?

Just my 2c - happy App building.

Several Java apps developed

[knightwolf]

We've got an inhouse development team for database applications and we're totally dependent on Java. Part of this is it's really simple to develop an app that's very functional, fast. Libraries are easy to find (no stupid DLL annoyances), the API is very well documented, etc.

Swing right now has a few quirks, but works well for the most part. Drag & Drop is still a pain, but is doable. The best part though is the database support. That's easy to implement, powerful, can use JNDI, and allows you to tie a client application to a middle tear or backend easily.

LDAP support is also great, especially using Novell's LDAP drivers. Novell eDirectory has great java support, so does openldap, Oracle, DB2, etc.

I've worked on eDirectory, Oracle, and MySQL using java, with over 60,000 lines of code, 7 or 8 applications, etc. The big thing is doing development on linux, and then having it run on my powerbook or on the windows machines. That's VERY nice from a portablity and usability aspect. Java does some things really really really well, and I'd highly recommend looking more into client development.

Bring out yer dead? Hope not -- I'm using it.

[mactari]

Swing (Sun's tech that lets you create GUIs the same xplat) stinks. But even Sun admits it, and (see the same link) they are doing something about it. Swing is no longer "a way for database apps to display debugging information in X11".

I'm still hoping for a Swing replacement from Sun that'll ship with its java virtual machines, but until then we have IBM's SWT which ties the widgets much more closely to native counterparts and Apple's attempts to merge Swing directly to native GUI widgets. We're nowhere close to Windows.Forms yet, but Swing's not so bad that you can't get the hang [notice I didn't say Swing] of things quickly.

The point being that you have options. Once you get the hang of Window Managers (doesn't take long) and creating some sort of Model for everything (from sorting tables to adding new values to lists), you can do complicated layouts that work xplat more quickly in the text editor of your choice than you could hack up a static UI (ie, that doesn't resize well) in the Visual Basic IDE -- which, as everyone knows, is really what makes VB GUIs "so easy".

(Aside: Even more importantly would be a standards-compliant parallel to what Microsoft's Web Forms does for IE... a quick, smart widget toolkit for the web. A "JWeb Forms" for JSP would do a lot to enable smart web-enabled UIs to Java web services.)

And there's nothing about Java that stops it from being a great client-side language short of Swing. Moore's Law and clever JIT VMs have pretty much done away with any show-stopping speed issues. Another hurdle is the fact that Java only compiles to bytecodes, making [even commercial] apps trivial to decompile, but if you look at VB 7 (aka, VB.NET) and C#, Java's most closely related competitors, they've got the same problems.

And sure, Java is more "Write once, test everywhere" than "... run everywhere", but you're not going to find an easier port from one platform to the next than Java. It commoditzes the user's operating system, and that's a great thing.

And heck, I'm using it. At least I'm putting my money where the keyboard is.

AWT, Swing, SWT

[Phouk]

For Java, the three most prominent GUI libraries are AWT, Swing and SWT. Though I'm not an expert, here's what I understand of their differences.

AWT was Sun's first attempt, what you see in applets and early apps. AWT uses Java proxies for native widgets, but suffers from the "lowest common denominator" problem - it only offers a small number of widgets available on all platforms. Supposedly, it had to be developed in a hurry because of a requirement from Netscape (remember them?), and it shows. AWT is available in most built-in browser VMs, and it's not so large to learn.

Swing is Sun's replacement for AWT (which, AFAIK, is still supported but not being significantly enhanced). To avoid the problems with AWT, with Swing the pendulum is now, uhm, moving in the other direction: Swing uses graphics primitives to draw it's own widgets. So, they were able to provide a lot of them, and they really look the same on all platforms, with a set of different looks to choose from ("pluggable look and feel"). Swing has a reputation for being slow, but with current VMs and on non-ancient computers, IMHO that is no longer true. The Swing API is better designed than AWT, but large.

When the guys at IBM developed Eclipse (GREAT IDE, now open source, see www.eclipse.org), they wanted it to be competitive with the GUIs of Microsoft's IDEs, which Swing wasn't back then. So they rolled their own, SWT, which is also available as open source. I only know it as a user and having read a little, but from what I understand, they use native widgets where possible, but draw their own where the target platform lacks a specific widget, and thus avoid AWTs lowest-common-denominator problems. Because of the native widgets, and judging from Eclipse, SWT apps feel snappier and much more native (like real GTK2/Motif/XP/...) than Swing apps. I heard SWT has its own problems, among them it's not being part of Java's standard libraries, but I don't know enough about those to talk about them - here you will have to do your own research.