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 AM