Is Client-Side Java Dead? 109
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?
real-world client side java apps (Score:5, Informative)
NetBeans IDE [netbeans.org]
LimeWire Gnutella Client [limewire.com]
Having a modern, Swing-enabled JVM included with Windows [slashdot.org] will hopefully lead to even more Java-based applications. Then again, so would a good IDE with a form-builder. NetBeans and Apple's Project Builder do a pretty good job though.
Re:real-world client side java apps (Score:4, Informative)
Re:real-world client side java apps (Score:2, Informative)
Oracle JDeveloper (Score:2, Informative)
Any questions?
(free developer license too)
Re:real-world client side java apps (Score:2, Troll)
Java requires native-code widget performance and look/feel. Without it Java will not compete with
Re:real-world client side java apps (Score:5, Informative)
AWT used native OS widgets, but it took a least-common-denominator approach -- it only implemented those widgets that were common to all target platforms. Things like frames, and text fields. Many widgets that weren't available on all platforms, like, say, a combo-box, were not implemented. It had little to do with "crappy GUI libraries" and much more to do with *incomplete* GUI libraries.
Swing went the other route, offering a very full set of widgets that is, indeed, cross-compatible for all platforms. Unfortunately, it took a huge hit in performance to do this, as Swing draws the widgets using the JVM rather than making a JNI call to a native (and much faster) widget.
SWT offers the best of both worlds; it offers a robust and standardized library just like Swing does, but that library is, for the most part, a wrapper to a JNI call, just like AWT was. This gives a marked improvement to GUI performance using SWT over Swing, while at the same time offering nearly all the widgets that Swing does. Widgets not available on some platforms are emulated on those platforms, like Swing.
So, with SWT you have all the performance of native GUI widgets, but with the rich library of Swing. And SWT is cross-platform.
Now harking back to my original post, since some moderator thinks I'm a troll, I'll point out what I meant.
Swing is slow when compared to native widgets -- there is no way of getting around it. Talk all you want about how faster computers will sover the problem; native GUI programs will always outperform Swing programs.
Enter
If
Sun has a big decision to make with Java: it can continue to push the Swing religion that it has built, or it can adopt a model similar to SWT. I clearly think they should persue the latter.
Re:real-world client side java apps (Score:2, Informative)
Java is pretty mature (Score:5, Insightful)
Most operating systems ship with some sort of Java VM, you should be able to deploy wherever you want and expect at least some support.
Sure, it's neither as fast as true binary code nor is the GUI as pretty as native apps, but if you wanted those you wouldn't be thinking about Java in the first place.
Java is as dead as Perl on the client. It's dead to all those who don't use it, but for those that do, it's indispensable.
software (Score:5, Informative)
poseidon uml softare (gentleware.com)
ATM research tool (Score:3, Interesting)
Funny you should ask... (Score:4, Interesting)
Re:Funny you should ask... (Score:2, Informative)
Java not an option in my biology research (Score:5, Interesting)
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.
dated = not accurate (Score:3, Informative)
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.
Re:dated = not accurate (Score:3, Interesting)
About Smalltalk... (Score:2)
Re:About Smalltalk... (Score:1)
Re:About Smalltalk... (Score:3, Informative)
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.
Re:About Smalltalk... (Score:2)
Or was something else even more silly to made some little Lenucks haxor upset?
Re:Java not an option in my biology research (Score:4, Informative)
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 [apache.org] is an excellent Java based SVG toolkit that includes a Java SVG Brownser called Squiggle [apache.org]. 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.
Re:Java not an option in my biology research (Score:3, Insightful)
Good thing he didn't use Java then. Rather than waiting for Java to catch up, he did it in something that was ready.
Java is still in the process of catching up. They're adding stuff which should have been standard long ago (rather than tons of other junk). Unfortunately since it started crap and big, the added stuff means it's becoming tolerable but bloated.
Due to the "write once run anywhere" hype they need some semblance of backward compatibility so they have to keep a lot of crap stuff around as standard. Deprecating everything would make them look like idiots not to mention those who bought the hype.
Re:Java not an option in my biology research (Score:2)
I'm not sure what it means for a language to be "bloated". What are you talking about? Are you saying have a rich class library is BAD?
Maybe a few more buzzwords... (Score:1)
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.
Re:Maybe a few more buzzwords... (Score:2)
The fact is that (1) hundreds of megabytes is a small data set and should fit whole in memory on a reasonable modern workstation (2) the limiting factor of processing file based data is typically IO (3) I'd expect one row of data to be read in at a time and the RE applied to that (4) the average time to apply a modest RE to a single row is much less than the avg time per row of IO
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.
Hmmm. Obviously you missed Session 7 at the 2002 SVG Developer's Conference [svgopen.org], which was titled "SVG for (scientific) visualization". That's a complete crap argument anyway. XML compresses very well, typically 5-to-1. A
alive and well (Score:1)
Never died and won't (Score:1)
... because never been alive (Score:2)
OTOH, DHTML usually is a pain for both users and developers.
Once more. This time with feeling. (Score:5, Informative)
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 [intellij.com], or Eclipse [eclipse.org]. Yes I know that both of those are IDE's, but they are fairly large in scale, and have a fairly sophisticated windowing env.
Re:Once more. This time with feeling. (Score:3, Insightful)
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.
Re:Once more. This time with feeling. (Score:2, Informative)
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 [projectscim.com], Mac2Phone [nikotel.net], 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).
Re:Once more. This time with feeling. (Score:2)
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"...
Re:Once more. This time with feeling. (Score:2)
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...
Re:Once more. This time with feeling. (Score:2)
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.
Swing (Score:2)
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.
Re:Swing (Score:1)
It's like saying apples are like M&M's because you can eat them both.
Re:Swing (Score:3, Interesting)
(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.
Re:Swing (Score:1)
Re:Swing (Score:1)
Re:Swing (Score:1)
Re:Swing (Score:1)
IBM's database admin tools are all written in Java (Score:3, Interesting)
See this [ibm.com] for some (pretty old) info...
No sign of this investment waning either... (knock on wood!).
Re:IBM's database admin tools are all written in J (Score:2, Informative)
Couldn't be further away from the truth.... (Score:3, Informative)
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.
SWT (Score:4, Informative)
Re:SWT (Score:2, Interesting)
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.
Re:SWT (Score:2)
Corel Java Office Developers ? (Score:4, Interesting)
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 [sunsite.tut.fi].
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.
Re:Corel Java Office Developers ? (Score:1)
The JNLP community is a good place to look (Score:4, Informative)
There is a list of JNLP enabled applications [slashdot.org] at the OpenJNLP [slashdot.org] site. Other JNLP related information can be found at VampHQ [slashdot.org] 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 [slashdot.org] or OpenJNLP [slashdot.org] 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 [slashdot.org] 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.
Re:The JNLP community is a good place to look (Score:2, Interesting)
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...
Quality Java Client Apps are possible (Score:5, Informative)
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 [javaworld.com] 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.Re:Quality Java Client Apps are possible (Score:1)
Re:Quality Java Client Apps are possible (Score:1)
While I think code generation is a sign that a database (or collection) should be used to store boat-loads of attributes instead of app code, IDE's are better for visual layout. Boss's and users like to tweak screen positioning to the N'th degree, and a visual pointing system is better for this than code-based nested flow layouts IMO.
From the link: "So what, exactly, is an object? You may have read in a book somewhere that an object is a datastructure of some sort combined with a set of functions, called methods, that manipulate that datastructure. Balderdash! Poppycock! First and foremost, an object is a... "
As an OO critic, I have heard plenty of fights among OO fans about exactly what an "object" or OOP is. This sounds like Yet Another My Definition Is Better Than Yours claim.
OO seems like Barbara Walter's leafy mind-tree: it was whatever a celebrity wants it to be in their mind.
I guess I have been doing OO wrong all this time (Score:2)
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?
Several Java apps developed (Score:4, Interesting)
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.
Still Waiting for Java Applications? (Score:2, Interesting)
Just my 2c, in comparison to Visual Basic (Score:1)
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.
Bring out yer dead? Hope not -- I'm using it. (Score:5, Interesting)
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 [eclipse.org] 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 [joelonsoftware.com] the user's operating system, and that's a great thing.
And heck, I'm using it [webhop.org]. At least I'm putting my money where the keyboard is.
Re:Bring out yer dead? Hope not -- I'm using it. (Score:1)
Re:Got cher test case right here... (Score:1)
The amount of development invested in the certification tests is astounding. To toss it all for some other toolkit is not something I see Sun doing any time in the near future.
Even with Mono, Sun can still claim broader cross-platform support both at the library level and at the developer level. It's debatable, of course, but it's not beyond them to claim it as truth.
Re:Bring out yer dead? Hope not -- I'm using it. (Score:1)
It's the posts up above that seperate the wanna be hackers that bone up on "Dummies guide to
not big ones, but good examples... (Score:2)
Gallery [sourceforge.net] (specifically Gallery Remote, and the thumbnail applet)
Editize [editize.com] (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.
large-scale real world java application (Score:1)
limewire [limewire.com]
ant [apache.org]
J2ME apps for mobile phones & stuff [sun.com]
AWT, Swing, SWT (Score:5, Informative)
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.
Re:AWT, Swing, SWT (Score:2, Interesting)
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
There is no alternative to client-side java (Score:1)
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
Re:There is no alternative to client-side java (Score:1)
Re:There is no alternative to client-side java (Score:1)
Mod me to hell and back, for I have sinned.
Re:There is no alternative to client-side java (Score:1)
I like java servelets, not too fond of many java stand alone clients... but I think that Java applets for browser might see their day still, for the reasons you mention, and also because in that context they are small applications, which Java seems to do well enough. The large stand-alone apps are much more difficult to make responsive GUIs with Swing. Though I admit I've seen it done.
Re:There is no alternative to client-side java (Score:1)
Speed-wise, I've been quite impressed with the graphic toolkit used by Eclipse. If I remember right, it's called SWT, and drops AWT totally. It also pretty much drops the idea of giving all platforms the same uniform look, going instead with what feels right for each platform: you compile SWT with motif, you get a motif look. compile with gtk, you get a gtk look, etc, etc..
Client-side Java is dead (Score:1, Funny)
Believe it or not... (Score:2, Interesting)
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
Java's client-side future and J2ME (Score:1)
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.
other cool client Java API's (Score:1)
Java 2D [sun.com] For doing lots of fun stuff with antialiased text, fonts, composting, etc.
Java Advanced Imaging [sun.com] For advanced image processing
Java Media Framework [sun.com] For capture, playback, and streaming of audio and video.
Re:other cool client Java API's (Score:3, Interesting)
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.
tradeoffs (Score:2)
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.
rethink the client .... (Score:1)
Re:rethink the client .... (Score:1)
FYI. ISAPI is IIS plugins. They are the lowest level of communicating with IIS and have a very simple C interface.
Laughable (Score:4, Insightful)
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 [sun.com]. 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 [sun.com] 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.
Re:Laughable (Score:1)
zerg (Score:2)
Get a move... (Score:1)
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 [eclipse.org] is going to play and I'm really interested on that issue... (because SWT looks promissing to me)
Online Banking (Score:3, Informative)
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
Short answer: No! (Score:3, Interesting)
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.
Swing on MacOS X (Score:3, Interesting)
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).
photomesa (Score:3, Interesting)
"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
Java is not Swing (Score:1)
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.
Partly because of client side application is dead (Score:1)
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 even reliable (Score:1)
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.
Java (Score:2)
Large Client-side Java apps (Score:1)
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.
ILog JViews (Score:1)