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
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.
I have been pwned because my
eclipse java development software (eclipse.org)
poseidon uml softare (gentleware.com)
-
ping -f 255.255.255.255 # if only
We develop a large Java application that assists with Air Traffic Management research for a government agency. Our most time-consuming bugs have been in the native C code, and we hope to move most of it to Java. The Java code is easy to maintain when it is written properly, but if an inexperienced programmer circumvents the encapsulation mechanisms, the time required to make changes goes up tenfold. Another advantage to Java is that, at least on x86 Linux, the C code compiles more slowly, and the runtime performance hit is endurable with a modern machine.
I was just reading Petreley's latest article at Linux World where he rambles on about client side Java and how JEdit is the proof that client side Java has arrived. I don't know if I agree although I do think JEdit is a nice editor.
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.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
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.
See this for some (pretty old) info...
No sign of this investment waning either... (knock on wood!).
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.
I'd be really curious to get the answer to this question from one of the "walking wounded" Corel developers that climbed on the client side Java bandwagon half a decade ago (in the Cowpland era), attempting to write an Office suite application.
As I recall, the bandwagon was bumping over a rough dirt road at the time and the project died.
With all the seasoning that's happened to Java, with the new possibility that the courts will make MS bundle a reasonable Java, I'd be curious if the speed, robustness, and cross platform issues have been sufficiently solved from the perspective of developers that hit all 3 of these issues back in 1996.
"Provided by the management for your protection."
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.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.
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.
It's all 0s and 1s. Or it's not.
But you know what? On my non-optimized platform with my web browser's somewhat old Sun JVM, Java is a dog. And the fact that there are a few successful java programs that may or may not work well on my PC is not persuasive.
-- Ken Kinder ken@_nospam_kenkinder.com http://kenkinder.com/
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!
I'm working with a dev team on writing a full featured thin film engineering application (in house) written entirely in Java. Surprisingly, the thing runs fast enough to do all the intensive physics calculations!
:)
I've also found that we were able to utilize the Swing API to get almost everything we wanted, including some very unique and handy components that I have been unable to easily duplicate in other languages.
Well, I would love to tell you more about it, but my NDA strictly forbids it. (In fact, I hope I'm not in violation now!)
-Jeff
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!
Although there are some serious problems with some of the
Java standard libraries (I think especially of java.net.Socket
et filia), the abundance of high-quality library support
for Java really does make a compelling case. The cryptography
libs are cool, the XML support is great, and if you need
to fertilize your mushrooms, there's composting.
-I like my women like I like my tea: green-
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
You may not have understood what was meant, but the rest of us did. ;)
(S)he is saying that Swing is like HTML in that there is no guarantee on exact look and feel. You just say "widget here, widget there, work together, please" and, depending on the version of the VM being run, you may get different-looking widgets, albeit conforming to parameters you set like size, and background color, and the like.
The best example I can think of offhand is JColorChooser. Once upon a time you got a very small, handy little widget to select a color. I rather liked it. Nowadays you have this huge monstrosity with a hundred tabs and bells and whistles and the like, offering dozens of different *ways* of choosing your color. I rather hate it.
"Times have not become more violent. They have just become more televised."
-Marilyn Manson
This is completely laughable. Since its first release (as an add-on package, not even part of the JDK) Swing has been one of the most mature and best designed GUI toolkits available. The only three allegations which can be justifiably levelled against Swing are:
Most developers who complain about the difficulty of using Swing are simply missing the point. I have had developers argue for hours about how terrible the table/tree components are, because you have to do "all that useless shit with models", and you can't just say "table.setCellAt(x, y, value)". Similarly there are a dearth of developers (especially those from the MS Windows world) who understand the need for layout components, as opposed to using absolute dimensions and coordinates.
For anyone who disses Swing, make sure you've read the Java Look and Feel Design Guidelines. Better than a Swing manual or introduction, it investigates building real-world applications with Swing, focusing on user experience and usability.
Swing's support for consistent navigation; centralised control over colours, widget L&F and localization; as well as its powerful and extensible widget set (e.g. TreeTables and the SwingSet2 demo) put it years ahead of most other toolkits, even now. Java's native L&F has improved over the years, to the extent that (for win32 at least) you can create Java apps that look native.
But Swing is not a silver bullet. With any cross platform toolkit you will run into problems. Qt, GTk, and Wx all have issues that need to be resolved when porting the app using them to a new platform. Similarly there is some effort to ensure that your Java/Swing application looks and behaves consistently on all its target platforms. In my experience Swing is far more portable than other toolkits, with the possibly exception of Tk. If performance is paramount in your application, then Swing is not for you; but this certainly doesn't make it unsuitable for an average business application.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
... 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
I spent over a year on a contract at a NASA contractor helping to rewrite the automated documentation/shop floor system. The original system was only about 5 or 6 years old and had been written on the VAX. Of course the platform is dying and machines are getting hard to replace so they decided to port/rewrite the app.
But what platform to choose? You could shoot for Windows NT, but what happens when NT is EOLd? Hope that it still runs the same on whatever new version of Windows you are locked into?
So they decided to go with Java on the client and the server in order to give themselves the greatest amount of flexibility.
Was it a perfect solution? No. There were some issues involving the intricacies of Swing. We were doing some really wacky stuff with Swing though. You haven't lived until you've read "Understanding the Element Tree" five or six times and then finally realizing that if they had just drawn their diagrams a bit differently anyone could have understood it the first time through. That said, I didn't see anything that would cause a problem with your average, run-of-the-mill application.
Do I think they choose the best solution: Yes. They now have a platform that isn't going to evaporate under them. Even if Sun goes away Java is here to stay.
Lasers Controlled Games!
I've already mentioned it in another thread on this story, but I felt it was worth mentioning again in its own top-level post. Many have pointed out the maturity of Swing, and I agree completely -- when it comes to Windows. On any other JVM, it is a dog. Specifically, on MacOS X, a large-scale Swing-based app like NetBeans is unuseable.
It's unfortunate because I'm a huge proponent of Swing, and do make use of it in my own job. Personally I find the Swing model to be quite elegant. But, while I can fire up NetBeans or other big Swing apps on Win2k with no problem, there is zero responsiveness on my equivalently-powered Mac.
And for anyone who pipes up about SWT, I've used Eclipse too, and it is really only marginally faster than Swing (on the Mac).
"First you gotta do the truffle shuffle."
the java client app i always show people to convince them that java on the client is about 100 times faster than they thought is photomesa :
"PhotoMesa is a zoomable image browser. It allows the user to view multiple directories of images in a zoomable environment, and uses a set of simple navigation mechanisms to move through the space of images. It also supports grouping of images by metadata available from the file system. It requires only a set of images on disk, and does not require the user to add any metadata, or manipulate the images at all before browsing, thus making it easy to get started with existing images."
its fast and free (beer) and i use it every day
'Be the change you want to see in the world' - Al Gore