In the Feburary 2004 issue of Java Developer's Journal, Joe Ottinger makes a soft case for Java staying pure and against SWT. Whenever I see an article supporting the 100% pure Java mindset, I softly whisper to myself 'you just don't get it'. When I'm writing software, nearly everything is negotiable. The language, the development environment, the team size, the development process, the budet, the delivery date. Everything EXCEPT the user-experience. If one of the factors gets in the way of the user experience, it's out. This isn't about what Java UI looks like or how it deploys. This is about whether Java is a viable way to develop great applications.
This is an area where I don't understand the pure-Java perspective. This isn't a matter of whether my application has a native UI or not. This is about whether Java is going to let me build the best application I can or not. If not, it can go swim in the bit-bucket. I'll write it in C#, VB, Delphi, C++, C, or even assembly if that is what is necessary.
This isn't just my philosophy, this is a pattern in all high-volume software markets, because the development cost is so small compared to software margins. Imagine a discussion about writing XYZApp in Java. First they might talk about how they could save 50% of their developer resources. A quick calculation would reveal that this is 0.4% of their revenue on the product. Then they would discuss all the ways that the resultant UI and performance would suffer. Someone would proove that they could aleviate most of the problems by writing a new low-level library. Just as the discussion is nearing viability, someone from Sun would carry in the 100% pure Java worship alter and tell them they shouldn't build a native library. The team would pull back out their list of required UI compromises and after the marketing folks explained that they will lose 30% marketshare for being so clunky, they would bury the Java discussion.
This happens across the industry. I've been involved in discussions like this a few times. You can recreate one of the highest profile scenerios by just inserting the words 'MSWord', 'JDirect', and 'Microsoft' in the proper places.
This is what Java is up-against. It is not up against weird internal SWT vs Swing philosophical discussions, or Java vs C# debates. Java is up against a viability wall.
SWT folks have felt the pain, and are trying to make Java viable as one of the ways to write the best Windows gui application. The fact that any of the Java community resists this is unfathomable to me. It is tantamount to saying, 'we don't want Java to meet your goals because they are wrong, our goals are better'. To which I say, 'great, then Java is a religion not a development tool and I don't have time for religion, I have an application to ship'.
SWT is really only one of the many hurdles. The next hurdle is garbage collection pauses. Until Java can deliver bounded maximum pause times, it will remain unacceptable for many applications. It's tempting to belittle this is as only affecting a small number of applications, but if you try to use something as simple as a Java word processor or file manager you will see that it affects almost all interactive GUI apps.
I recently rejected Java for a large high-performance web application and used Python/C instead because of problems with
Java garbage collection pauses. Python is dog-slow, and it's pretty ironic that the resulting application meets our requirements in Python but didn't in Java. This is a testament to the simplicity of reference counting and the power of a large core library written in C.
--
Sometime around 1990, Modula-2+ delivered a strong typed garbage collected environment. Since then I've been anxious to move all my application development over to a similar system. I'll do so as soon as that environment gives me a viable way to develop best-of-class
applications. However, the reality is that, even today, with modern
environments like Java and C#, this isn't possible.
This is the battle Java is fighting. The battle for viability.
--
A few responses to comments:
- I have tried every set of garbage collection options there are on Sun's JVM and JRockit. JRockit claims to have lower pause times, but the application itself is perceptably more jerky. Sun's alternate collectors do not solve the problem.
- The maximum acceptable page-render time in my application is 0.5s, which means the maximum acceptable garbage collection is closer to 0.2s. My tests yeilded 300MB heaps with 1s+ worst case pause times. In real-world scenerios the heaps would be bigger. The problem with most of the different GC strategies is that they address average case GC times more than worst case.
- I am not willing to compromise my idea of what a 'best of class' GUI application is like many of you are. I'm not going to list off all the ways in which Swing does not act like a great Windows app, it's a waste of my time. I'll just list the first one. Real-time window resize does not work. When Sun has fixed that one, I'll give you the next 30.
- If you want an example of a Python/C application and the constraints, take a look at one of my recent projects. eGroups.com, now Yahoo! Groups. Pageviews per day in the hundreds of millions, tens of terrabytes of data. No GC pauses.
-
Posted by jeske at February 20, 2004 11:32 AMAgreed.
We recently found ourselves faced with developing and supporting a cross platform GUI application.
Java was selected as the platform, grudginly, only because of the availablity of SWT.
If we have the same choiced to make again in one year? It could be a whole different story. Building rich GUI applications, destributed within the Mozilla browser, using XUL may turn out to be a better option for rapid application development.
Theory is one thing. Building applications that are useful for users is another.
thanks for the excellent post!
ds
Posted by: danny at February 21, 2004 01:58 AMAfter reading this, I expected the date on this to be last year, not Feb 2004 like it is. Garbage collection has changed significantly - (reference: http://www.javaworld.com/javaworld/jw-03-2003/jw-0307-j2segc-p2.html) You can specify a low pause, concurrent garbage collector with the command line option -XX:+UseConMarkSweepGC to the jvm. Strangely, I found using -XX:+UseParallelGC actually seemed to work the best for eliminating pauses myself, go figure. Although it's only my own ancedontal evidence with the applications I use.
I also believe that in jdk1.5 you can specify a maximum length of time for a garbage collection pause, although that means that if the time is exceeded an OutOfMemory exception gets thrown.
Sun also has vastly improved java with jdk1.4.2, making Swing applications on WindowsXP actually look like WindowsXP applications. I'm not sure it's absolutely perfect, but it's close. In my personal opinion, anyone who has used MS Office has learned to deal with minor user interface changes, as they seem to change their own look and feel every couple of releases. (not that that's bad).
I agree with what you've identified as problems. And apparently Sun and a whole lot of other people agree with you as well, as they've put a lot of work into both getting Swing looking native and running fast, and in reducing or eliminating garbage collection pauses. I'm just trying to point out the improvements that have been made.
Posted by: Will Gayther at February 21, 2004 12:50 PMMostly disagree.
One thing about your argument that is different from most SWT vs Swing arguments is that you stated the application domain that you are concerned about; High volume applications. Most SWT/Swing arguments just say "SWT sucks" or "Swing sucks", they don't say that "Swing sucks for high volume applications". And I think that I might eventually agree you about Swing sucking for high volume applications (not quite there yet).
OTOH, I definitely don't agree that being able to create high volume applications with Java is crucial to Java's viability. The vast majority of Java developers are in-house corporate developers. And Swing is mostly irrelevant to most of these developers. They are mostly using Java server server-side technologies to build HTML-based applications.
Now that Microsoft has monopolized the browser and is beginning its push to make the browser obsolete I think that developers will start evaluating rich, thin-client, cross-platform technologies. And here is where Swing wins over SWT. Swing was designed to be cross-platform, SWT was not. Cross-platform here means that widgets BEHAVE the same way on all platforms. SWT does not even attempt to address the hard problem of being truly cross-platform. Now, like you said, vendors that produce high volume software will be willing to put the extra effort into using SWT because their margins are so high, but corporate developers definitely don't have the extra resources to deal with SWT's cross-platform story.
Posted by: ted stockwell at February 22, 2004 07:10 AMBoth problems you describe don't seem to be much of a factor in 1.4.2 and later Java. Well-written Swing GUIs, like EJ Technologies JProfiler, clearly demonstrate that a UI can be equivalent to or superior to an SWT-based UI. Pauses and slowness in Java UIs are pretty much a thing of the past, with modern hardware and proper coding. The inflexibility of SWT, as compared to Swing, rears its head pretty quickly if you try to move outside of Eclipse's Office-like UI.
As far as GC pause times go, I'll say that in my day job we were bitten HARD by pause times...our situation was a 64 bit Java app running at around 12-14 GB of heap...GC times went up to around 30-50 seconds, and nothing would help...
Until we found out that we had missed a close call, and a finalizer that shouldn't have been called was closing OS resources, and the problem went away.
1.4.2 gives good control over pause times, and the concurrent collector performs well to virtually eliminate them. I have yet to see a GC time problem that could not be solved by identifying either excessive allocation bottlenecks or incorrect release of resources. On the other hand, if you have extremely tight time frames for response...your mileage may vary.
Given the rather incredible engineering effort that would be required to create an app like ours in C as opposed to Java, I'd say that the app might never have gotten written in a fiscally possible timeframe. That's inefficient too.
I view Python vs. Java as trading one set of problems for another.
Posted by: Ross Judson at February 22, 2004 07:47 AMThat may all be true, but I'm pretty skeptical. I have often seen people claim that things couldn't be done in pure Java with very little base in reality. Of course that doesn't mean that is the case here.
I would appreciate it if you would answer a few questions.
1) How long are the pauses, and how long would be acceptable?
2) Can the GC problems be created within a small simple program, or only within a large application?
3) What runtimes did you try and on what platforms? There are an amazing number of options including Sun, IBM, GCJ, Excelsior Jet, etc.. I'm sure you've seen the Volano report.
http://www.volano.com/report/
4) Have you experimented with different garbage collection options like "-Xincgc"?
5) What web server are you using? Given the complexity of many web servers, simply changing web servers may solve the problem. That's part of the power of the servlet spec.
6) Since you chose Python/C, it sounds like you weren't attached to servlets. That opens up your web server options even wider.
7) There are various options for Real-Time Java. Check out http://www.rtj.org/ and http://jade.dautelle.com/
Don't get me wrong. I don't mean to imply that you made the wrong choice, or that it wouldn't have been harder for you to meet your goals with pure Java. I've had really good luck with pure Java, however.
"-Xincgc
Enable the incremental garbage collector. The incremental garbage collector, which is off by default, will eliminate occasional garbage-collection pauses during program execution. However, it can lead to a roughly 10% decrease in overall GC performance."
Hi There,
Thanks for the excellent post.
Did you try out JRockit ? It works on x86 platforms and has better control on garbage collection. I'm not sure if it has MAX bounds but you could try it.
BR,
~A
Mr. Jeske - excellent post. I couldn't have said it better myself. Fear not, though... I am developing a clean-room from-scratch java native compiler developed with these sensibilities in mind. Keep an eye out for it sometime in the fall.
I agree about SWT but ... garbage collector pauses? Come on! Did you really run the tools that showed this was happening? Reference counting? Come on! One guy forgets to do it and you leak forever. What about cycles? Reference counting is SLOW. Go read the literature.
have you tried Eclipse yet? Try and reconsider this post.
Posted by: Eli Burmin at February 25, 2004 06:21 PM