Slashdot Mirror
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?
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.
reech bee-yond ur clip-0n
eclipse java development software (eclipse.org)
poseidon uml softare (gentleware.com)
-
ping -f 255.255.255.255 # if only
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.
When I want your opinion I will beat it out of you.
I've worked on many enterprise scale solutions for several Global 500 companies, all of which have used Java for client applications (as well as J2EE backends). Just because you don't happen to see Java in your workplace or in the media as much as you used to doesn't mean that it's not there. A lot of companies decided that when "thin-client" was the in thing to do, to ditch Java in favour of trying to produce sophisticated client applications using HTML/DHTML/JavaScript/CSS/etc. and failing miserably because of the problematic issues between not only different browsers but also different versions of the same browser (for example, an app isn't going to be very "cross-platform compatible" if it only runs on Version xyz of Browser ABC with options 1,2 and 3 on but 4 turned off).
For those large Global 500 companies, usually operating in many sites, quite often operating out of different countries, it's not difficult to imagine that the makeup of their enterprises in terms of deployment environment can be pretty mixed, from Win9X,XP,NT through a range of *nix type environments which still do get used for desktops. Java offers the only true platform independant, scalable, reliable to use when tackling these kinds of solutions, trying to explain to a company of these kind of sizes that they all have to upgrade to some new OS just because there's some DLL that will only run on that platform that is needed for the end solution is not going to happen in a lot of cases.
I would say that if you are concerned about GUI performance and Swing, you should really take a lookat the SWT toolkit. It's available at eclipse.org.
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.
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.Yep, and don't forget jext.
Since the VM is assumed to translate Java calls to the underlying OS without requiring the developer to know anything about that OS, you lose the platform independency advantage of Java if you have to deal with the VM because you want to bundle it.
For Mac OS X, quite a lot of Java applications are available (ProjectSCIM, Mac2Phone, just two examples out of many); sometimes you don't even notice it's Java (although the experienced user distinguishes the somewhat "rough" interfaces easily from the native ones).
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.
Stupidity is mis-underestimated.
This was a few years ago, and things haven't gotten much better, unfortunately.
First of all, you didn't bother to mention this until half way through your screed. That's misleading.
Second, your information is dated and inaccurate. Java/Swing has come a long way in terms of performance, especially with the 1.3 and 1.4 JVMs. So while this was a valid criticism a few years ago, it is not today.
Third, if you're doing visualization in Java and your using the Graphics object directly (without the aid of Graphics2D or Java3D), you're screwed. Low level AWT graphics is a black art in terms of performance. And that would also not be taking advantage of 2D/3D acceleration.
This looks remarkably like ServerStudioJE, which is a database administration tool for Informix databases, which incidentally, IBM now owns. I find it to be an excellent application!
A complete development environment made of Java, by Java developers, for Java development.
Any questions?
(free developer license too)
Maw! Fire up the karma burner!
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.
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.
Hogsquat. In fact, if you had this assignment today, it wouldn't take you much coding at all. Batik is an excellent Java based SVG toolkit that includes a Java SVG Brownser called Squiggle. Use java regular expressions to parse your data into some nice internel format (or jdbc if it's from a database). Then use the SVG DOM in the Batik toolkit to spit out SVG XML and render it using Squiggle.
As someone else noted, there are Smalltalk systems which let you make apps that look and feel more like traditional WIMP apps.
As far as open source, there is GNU Smalltalk which in many ways isn't great. Mostly because it's a lot slower than the other options and it's relatively unfinished. But it has access to Tk and Gtk+, although they're a bit of a pain to get working even on a vanilla x86 system.
All the main commercial Smalltalk systems exist in seperate host windows with regular windows, including IBM VisualAge for Smalltalk, Cincom VisualWorks (there's a free non-commercial version for download running on OS X, OS 9, Linux, a bunch of Unices, and all the Windoze > 3.1), Smalltalk/X (Unices and Windoze), Smalltalk/MT and Dolphin Smalltalk. The last two have very good Windows integration, and only run on Windows.
The dialect I use, Squeak Smalltalk, runs in its own one window by default. In the case of my app, there was only one main window, along with various dialogs, so it wasn't so unnatural for my users, who are all scientists.
There has been versions of Squeak which use native widgets and seperate windows, including bindings to Qt, GTK+ and OS/2. Due to the authors falling off the 'net, they are no longer maintained. In my case for this app and my general use, I'd prefer using the Morphic GUI system than native widgets because of the enormous flexibility provided. This is imortant to me both as a developer and as an end-user. That is, I'd personally prefer all of the non-Squeak apps I used conformed to Squeak's look, feel and working-style than vise versa. But I'm a minority in that.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
... is a real world, large scale client side Java example, IMHO. At least my bank luckily provides a Java applet for online banking (in three versions: one that can be installed, one that is always loaded from the net and one specifically for Macs).
;-) And this is were Java shows it true power: the people at my bank don't support Linux, but that doesn't matter to me because they support Java :-)
If they wouldn't provide this applet I'd have a problem, since I don't have any Windows versions installed anymore, for years now... not even at work