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?
Dunno.
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
Heh, that M$ .NET ad is sooo ironic.
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
... and poised to dominate the new mobile applications market.
Client-side Java is nice. It is getting increasingly popular for cross-platform solutions. It is 'balsam' for those like me who have been frustrated by the limitations of DHTML. Even deployment issues (where the web is king) are gone with the 'smart-client' model.
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.
As I see it swing is like HTML. You give guides to what the window should look like, and the person running the program gets to see it best for his screen (mobile phone screen, text only, or widescreen monitor).
Work arrounds are as evil as , on a green background. You have no idea your end user is color blind. Style sheets, and logical HTML tags, allow the use control. Swing allows the User control.
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.
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
I am using my experience at a particular client site where I am consulting. Utilizes a VB client application to track persistent inventory (i.e. a resource that isn't used up permanently, such as seats on an airliner) versus inventory reservations (e.g. someone books a flight, gets seat 8A in first class, etc.).
My observation is that a Java/Swing version would force front-loading of the work, and would penalize a crappy design much, much sooner than a VB implementation.
It's just that once you run into something the VB toolset doesn't let your app do, you realize that you have to rip a whole lot of stuff out.
"The Devil does not know a lot because He's the Devil, He knows a lot because he's old." -- unknown
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/
Sun won't be replacing AWT any time soon. They've got so much development invested in writing the AWT certification tests (VM certification, that kind of thing) that they'd be hard pressed to come up with a new test suite for a completely different GUI toolkit. The current certification test suite has thousands upon thousands of tests, to duplicate that effort just to support a new toolkit would require the expenditure of quite a bit of capital. It would take a really strong case to change the status quo.
I have been pwned because my
These aren't ones with wide distribution, but they're very useful for what they do:
Gallery (specifically Gallery Remote, and the thumbnail applet)
Editize (nice HTML editor for replacing <textarea> tags)
They're not huge applications suites, they're small, useful apps that fit a niche need - and that's what makes them successful.
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).
limewire
ant
J2ME apps for mobile phones & stuff
purrrlease! What kind of newbie would try to use a GUI toolkit to talk directly to something back end? -- "Swing is no longer "a way for database apps to display debugging information in X11""
....." from the people who truely know what they're doing.
It's the posts up above that seperate the wanna be hackers that bone up on "Dummies guide to
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.
It would take a really strong case to change the status quo.
I believe that test case is going to be called the Mono project. If this is successful, I believe you're going to see xplat Windows.Forms and then code you make in VS.NET is going to work right nearly anywhere.
Keeping the status quo means falling behind. I think Sun will give GUIs at least one more shot.
Do note that you can build whatever you want on top of AWT (that's what Swing does, as you implicitly said), and it doesn't have to be Swing.
Hence, Java will not die, not until another technology can cover all of the same ground it does.
.NET equivalent of the java sandbox for web browsers. Chances are it will be out soon.
.NET sandbox becomes available on IE, it will not be immediately available to other platforms (not until mono and others write a netscape plugin wrapper), so Java still has an edge.
I'm already wondering why MS hasn't made publicly available a
In the meanwhile, Java is the only way to:
- have complete control over a TCP socket connection
- have a UDP connection at all
- have serious non-SSL crypto in the browser
- have computation intensive raster graphics
- a lot more. Java is a full featured language, not a quick scripting glue playing with a few loose objects.
Flash is on its way though.. their so-called "XML" socket allows to send arbitrary data over TCP, but still has a few weird restrictions (each chunk of data must be null-terminated), and their strong point is graphics after all, even though computations are inherently limited by the not-so-fast actionscript interpreter.
Note that even after the
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!
Client-side Java is dead. Because my company believes this, we are migrating from client-side Java to Flash MX and XHTML.
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
You've said you have finally used Smalltalk. Is Smalltalk appropiate for normal applications? From what I've seen everything runs in ths big, square Smalltalk window, and you don't run just your app. You run the whole environment (as apps become part of it). Is this true?
Just wait for the first MMORPGs to hit the java enabled mobile phones, and we should get a good idea of Java's short term future in client-side apps.
Having mentioned games, I believe we must wait a bit longer to see that it's business applications that might show how J2ME is here to push Java client-side applications further than AWT and SWING have done so far. A hint is, someone, somewhere, maybe writing the first lines of code that will make SMS obsolete.
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!
In addition to Swing and SWT there are also other cool Java client API's.
Java 2D For doing lots of fun stuff with antialiased text, fonts, composting, etc.
Java Advanced Imaging For advanced image processing
Java Media Framework For capture, playback, and streaming of audio and video.
Lots of good Java apps exist, but there aren't any general
use killer apps done in pure Java, not because of any deficiency
in the platform, but because such apps are rare and focussed
and generally don't care about cross-platform or rapid
development. The IDEs are large-scale apps, for example, but
are hardly general-use (NetBeans, JBuilder, Eclipse).
There are tradeoffs to be made in developing a GUI app in Java.
If you can work within the performance boundaries of Swing, it
gives you the best x-platform results. If sluggish response
on low-end client machines is unacceptable, you need to look
elsewhere. SWT is excellent in every regard, except one:
It only runs on major platforms (posix-alike, windows, and OSX,
to my knowledge).
If you don't care about x-plat, Java is still a great choice,
using gcj native compilation, with an SWT GUI, but you should
also look at Kylix/Delphi.
-I like my women like I like my tea: green-
Most folks are probably thinking browser Applets and mega-apps like Office. These aren't where you'll see Java. Heck, the same is true of .NET. Mostly you'll see these frameworks used for in-house development, to fit a business need. This is where development most matters, (in terms of $$ spent and value gained) but is where you'll find the least exposure.
The best thing about a boolean is even if you are wrong, you are only off by a bit.
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
I would like to state, for the record, that combining Swing and Java3D leads to an end result that is slow as balls. If you have to do 3D, use SDL or something else.
[o]_O
...you lose the platform independency advantage of Java if you have to deal with the VM because you want to bundle it...
Nothing stopping you from offering multiple downloads, one for each platform, with a bundled and tested JVM. Not a tidy solution and not the way it's meant to be but at least you can be confident it will work.
I don't see why it's impossible to get the L&F things right on the line under Windows like Apple did in OS X...
Apple provides real native L&F for Swing-Apps running on OS X. (By backing it with native Cocoa bindings) This should be possible under Windows too.
Besides all, I'm still rather confused about the role SWT is going to play and I'm really interested on that issue... (because SWT looks promissing to me)
... 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
OTOH, DHTML usually is a pain for both users and developers.
Programming can be fun again. Film at 11.
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
Uhh, dude, you're so fucking clueless I don't even know where to begin..
Swing is a GUI toolkit that is part of J2SE. This is what most people are talking about when they say 'client-side Java'. But Java is a fine language apart from the whole Grand Unified Platform bit. A Java program talking to QT, wxWindows, Cocoa or something like that, has no major impedements, and performence is not an issue.
Swing, on the other hand, is brain-dead, ugly, and slower than cold tar. Never, ever use Swing. You're giving Java a bad name. Swing is obnoxtous for programmers, and frustrates users by being unresponsive (prime example: ArgoUML, which is so slow it's literally unusable on my i686). JEdit is also too slow. Furthermore, Swing programs don't fit correctly in desktops, especially Mac OS X.
Use QT or wxWindows with Java or Python, and you'll be fine.
And what if we just write a nice fast fat Windows client? By which I mean to say, I choose not to support retardedly old *NIX-based operating systems.
Before you label this flamebait (I know the trigger fingers are itchy), pause to consider that I believe my statement isn't any more flippant than the assertion made by the parent. If you're going to introduce arbitrary limits, you might as well take the easy one and build something that will run fast and smooth on 95% of the machines on the planet -- good old Win32. Indeed, someone is more likely to know that "I run Windows" or "I run Linux" than "I run a JVM which is compatible with Swing 1.24"...
Slashdot quality declines as the number of hot grits posts decreases. - Provolt's Law, Apr-09-2005
"usually based upon unfamiliarity with the latests versions of java, and the vast sea of tools that are available to make java development easy"
Translation:
Oh the old version was terrible, despite Sun saying it was so wonderful when it came out not too long ago, you should switch to the new one (it's really wonderful) and buy/get new tools and software.
Hmm, sounds familiar.
What happened to Sun's "write once run anywhere" hype? Or are you going to push the latest version of Java to every client? How many MBs is that?
Unless they chuck tons of old junk (totally breaking their promise of write once etc) it's likely to get more and more bloated.
Fool you once shame on Sun, fool you twice...
With the interest shift to building web based applications in the last few years, client side application is not as important as it use to be. Even MFC is somewhat dead.
I hope the court ruling on bundling up-to-date version of JVM would bring more life to client side Java. I like to see it fulfill the cross-platform promise. I'm looking forward for a great, secure email client to replace MS outlook.
Not to flame, but the guy said he was processing hundreds of megabytes of scientific data. Depending on the structure of the data (likely it is either very simple or very complicated), regular expressions aren't the right tool for the job - if it's just reading in a bunch of vectors, RE's would add significant overhead. If the structure is complex, REs will likely get more complicated than they're worth, simply because expressing complicated structures in terms of recursion and iteration is much faster and simpler, and REs don't do either very well. And of course if the data is in a binary format, then the whole point is moot.
Now when it comes to scientific visualization, vector formats aren't exactly all the rage. Neither is XML, since those files tend to be rather large and there tend to be a lot of them - no one wants to waste bandwidth and space on closing tags.
In the great CONS chain of life, you can either be the CAR or be in the CDR.
Let me see if I have this straight. I have this object, this thing, that has the employee salary attribute. I am not supposed to touch that object to know what the salary is, and I am not supposed to know if salary is a float or perhaps a string because that is too implementation dependent. If I want to display salary on a form, the display capability for salary has to be wired into the employee object -- the employee object has to be able to output salary to a widget or perhaps dynamically create a widget capable of displaying salary?
You know, I don't care how pure OO one is, a person still has to get data from point A to point B. Some THING that represents salary has to be transmitted to some other THING that displays some pixels.
So I guess you are telling me that it it not OK to export an attribute as a float or even as something as universal as a string. I am supposed to transmit attributes as a bunch of calls to AWT (of all things in light of the discussion on this topic) to blt stuff across? And that directly poking at AWT is a purer abstraction than passing a string out of a data object and into a viewer widget?
Maybe a year before Swing came out I wrote a UI in Java that demonstrated a critical problem with AWT - it was single-threaded but some control elements - different ones each time - would fail to display. Because I was with a very prestigous company, I was able to speak to a JavaSoft engineer... who said, "Yes that's a problem, and we have no schedule to fix it." But this hadn't been a lab experiment, so Java was out as a platform.
Last month I wrote a digital photo gallery creator (http://pictpage.sourceforge.net) in Java using Swing. Guess what... same type of problem, different area. Some JPEG operations sometimes fail... but retrying them repeatedly generally fixes it. Seriously. As long as you can determine that it -needs- retrying. Look for the method bufferedImageSanityCheck() in my source for how I did that.
So no, Java is not ready for Prime Time on the Client. As a long-time programmer, I blame myself before I blame the tools, but with Java that's no longer a safe assumption. Pity too because I really like the language - but I can't trust the implementation.
Translation:
Oh the old version was terrible, despite Sun saying it was so wonderful when it came out not too long ago, you should switch to the new one (it's really wonderful) and buy/get new tools and software.
Thanks for putting words in my mouth, but what you are saying is not an accurate reflection of what I was trying to get accross. I was merely trying to indicate that many peoples reaction to java is based on old data, and data that has been intentionally skewed by the fact that they have only seen java through the lens of microsoft's ancient vm. This is of course not suns fault. And yes why wouldn't you want to upgrade to the newest version of the jvm. It's free. And why wouldn't sun want to continually enhance their software. If they were to have just left the the environment as it was introduced in the late 90's then yeah it would have fizzled very quickly. But no. They have addressed many if not all of peoples objections to java, and it has become the leading platform for developing business software.
What happened to Sun's "write once run anywhere" hype?
I really don't consider it hype. I write java for a living, and take advantage of this property of java daily. My local dev environment is a shitty old dell nt workstation running apache's tomcat. My stage and production environments are HP bluestone on solaris. We are in the process of migrating code off of bluestone to Weblogic. This process is not requiring us to recompile. About the only way I could make those environments any more different, is If I were to dev on a motorolla 68hc11 and go to production on an origin 2000.
Or are you going to push the latest version of Java to every client? How many MBs is that?
Um sure, microsoft does it with product updates constantly. And 8MB. I've seen windows updates take way over that much space. I mean seriously, do you not patch your software?
Unless they chuck tons of old junk (totally breaking their promise of write once etc) it's likely to get more and more bloated.
I really don't think they've broken their claim of write once run anywhere. I just think you are choosing to misinterpreted what is mean by that. Write once for a given jvm version (not using some stupid proprietary extensions) and your code will run anywhere that that jvm is implemented. What's more is, your code will run anywhere where subsequent versions of the jvm run. The reverse is of course not true. If I develop using jvm version 1.4 and then try and run using an earlier version, well then what dumbass would expect that to work every time.
Fool you once shame on Sun, fool you twice...
Oh please. Grow up.
When I want your opinion I will beat it out of you.
Apple's not "merging Swing to native widgets", because they don't match - that was the problem with AWT. It's using the native widget drawing for Swing.
write once, crash everywhere.
sulli
RTFJ.
No I'm not an employee, but I use it every day. Would "native code" be faster? Of course, but not enough to make a difference to me.
Besides the well known examples like netbeans and eclipse I think Ilog JViews is a great Java Client example too. This package of reusable Java Swing components and SVG based browser components really amazed me!