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?
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
See this for some (pretty old) info...
No sign of this investment waning either... (knock on wood!).
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."
There's too many interoperability problems with SWT and Swing/AWT, which means that for anyone that uses 3rd party components (eg. JClass) it becomes a pain to have to integrate. Not that it's impossible, but you end up putting in a lot of effort into it which just isn't needed.
As with many things, there's a dozen ways to reach the same end point with Java. There are best practices to ensure that you arrive at efficient solutions. The problem with Java is not with the language itself, but with some of the "developers" that use it. Because Java held the promise of being an easier to learn language, lots of people started hacking away at problems with nothing more than the javadoc to get them through it, people who prior to coding their 1,000,000 line masterpiece had only got as close to coding as some JavaScript and thought that as it had a similer sounding name that it would be just as easy. The developers that have had a proper grounding in patterns, etc. that have been coding for some time realise that Java in essence was just another way express an answer to a solution and that the same ways of solving the problem where still apparent, just the language was different, and they go on to show the newbie that their 1,000,000 line monster can really be accomplished in just a dozen or so lines, if only they'd thought about the problem more and less about the tool they're trying to solve the problem with.
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.
I remember back in 95/96 when Java was the bold new revolutionary programming language that all programming would be done in by 2000. Back then the corporate IT nazis at several large corps decided to enforce "java only" policies at the corps. I was a real case of hype not being lived up to. Back in 95/96, your average IT desktop was too slow for Java. Not only that, you couldnt find any programmers. Soon I started seeing job ads for "java programmer, 10 years experience". The PHBs didn't "get it" obviously. Cross-platform is the biggest non-issue I have ever seen when it comes to the arguement for Java apps.Write once, run anywhere _never_ worked. Either your jvm was too old, too new, your platform didn't have one, or some other excuse. Also frustrating to me was that at the time there were tools that let you write once for their own api, and would platform specific code for windows/x11/macos. In other words, java offered you the choice of writing once and having the same crappy app on all platforms versus using an IDE that would produce apps in the native platforms toolkits. Still waiting for client-side JAVA apps? You might as well wait on Duke Nukem Forever. Or for Sylvia Browne to answer the JREF challenge.
Never overestimate the end user. -jeramy b. smith
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.
Moving from an applet in Java 1 using AWT+third party widgets (Swing was a big, leaky pig in Java 1) to a Java Web Start (JNLP) application in Java 2 using Swing was a big win for us in terms of better control over our evironment (control over the JRE version), better Java VMs (we used the MS JVM in Java 1 because the SUN implementation wasn't very good; SUN's recent Java 2 implementations are much better), and write-once run-anywhere is a lot closer to reality (it was pretty much marketing hype for non-trivial GUI applications in Java 1).
The downside with Java 2 is that on Windows you need to get a plugin (if you want to integrate with portals and launch from the browser; for applets or for Java Web Start) and a JRE down to the client. The combination of locked down machines (which make this hard to do for those companies without good software push models), IT managers who feel their job is to not install software on client machines (what? support new software? that will make my job harder...), and Microsoft not providing Java 2 can cause you serious problems. And let's not forget those forward thinking individuals who believe that the browser provides the only UI you will ever need.
Java has come quite a long ways from where it was a few years ago and provides an excellent software development environment, platform independence, and good performance.
Java, it's not just for servers anymore...
Dr. Rick
- "It's such a fine line between clever and stupid" (Nigel Tufnel)
- Zort! (Pinky)
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
SWT is a toolkit that IBM has been trying to impose on the Java developer community ever since it's first incarnations of VisualAge for Java. They ditched it because of its incompatibilities, and because the problems they were trying to address were fixed when Swing was redesigned.
:)
IBM thought they would dust off the same old toolkit (they've changed practically nada - still haven't updated the code to follow bean practises), in an attempt to get people to use it for Eclipse plugin development. Hello.....same old crappy toolkit, no improvements, just a lot of hinderances, when will they learn?
Don't you think it's funny that IBM's product is called Eclipse btw, as in something that blocks "Sun"
-- never take anyones word for it but your own
My use of the word "few" is misleading in and of itself. The initial prototypes and evaluation was done 1.5 years ago, summer of 2001. We looked at it again last summer (for another, but very similar project) and came to similar conclusions. Java has matured a little more between those summers, but still wouldn't be the best thing for our application.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
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-
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
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