SWING losing the Desktop War? A Rant.

[Gregg Bolinger]

Ok, so let's have another SWING debate/discussion. There is no doubt that the SWING API is pretty nice in regards to the current API. There is also no doubt that the API could be a lot easier to use. A simple example of this is why have a JTextArea class that does not have a JScrollPane already? How many time have you used a JTextArea without a JScrollPane? And why have 3 different Text classes? Anyway, I ramble....
Another point I would like to mention is why Sun would choose to go with a Single L&F for every platform? I think Sun should completely rethink and redo the SWING API and what they should do is enhance the AWT. The reason for this I must concede is performance. Making native calls to the OS is faster than drawing all your own components. My point is WHO CARES IF IT LOOKS THE SAME ON EVERY OS!
Now what I do know is that SWING uses the Graphics2D API to draw all of it's components. What I don't know is does the Graphics2D API make native OS calls to do what it does?
It is my opinion that Sun/JAVA has already lost the Desktop war. I have used Netbeans and I have used Eclipse. Netbeans 3.5 performs considerably better than previous versions. However, Eclipse still out performs it. Why? Because Eclipse uses Native DLL's. What would be so hard about Sun using Native calls to render GUI components? They already have platform dependent JRE's. The byte code will still run the same on every platform. The VM just makes the appropriate adjustments just as it already does.
I am almost done ranting on about this, but I would really like some feedback from everyone as to why they believe Sun chose the Universal L&F approach? Why not just extend the AWT? And also, what is Sun doing with the Graphics2D API to help improve SWING with the Tiger release?

[Avi Abrami]

Hi Gregg,

Ok, so let's have another SWING debate/discussion.

No, thankyou!
Good Luck,
Avi.

[Nathan Pruett]

A simple example of this is why have a JTextArea class that does not have a JScrollPane already? How many time have you used a JTextArea without a JScrollPane? And why have 3 different Text classes?

It's because the Swing GUI follows a component architecture... the JTextArea component knows how to handle text and the JScrollPane component knows how to handle scrolling any scrollable component. Sure, you could make some kind of class that is a JScrollPane with a JTextArea inside it, but that's what... like 3 lines of code? Should Sun also provide a class for every other JComponent wrapped in a ScrollPane? No. Because it's simple to just plug the components together to get them to do what you want. There are three text classes (actually more... you are forgetting JTextField, JFormattedTextField...) because one of them handles multiline non-styled (simple 1 font 1 color ) text. The other two handle multiline styled ( multiple fonts, colors, sizes, etc. ) text. One is a superclass of the other.

Another point I would like to mention is why Sun would choose to go with a Single L&F for every platform?

They don't... they provide a Pluggable look and feel. The default look and feel is the platform independent "Metal" look and feel. But you can use platform dependent Windows, Motif, or Aqua look and feels, or use custom look and feels made by anyone.

I think Sun should completely rethink and redo the SWING API and what they should do is enhance the AWT. The reason for this I must concede is performance. Making native calls to the OS is faster than drawing all your own components. My point is WHO CARES IF IT LOOKS THE SAME ON EVERY OS!

The reason I'm sure that Sun went with the Swing API is that it is massively easier to port to any platform Java wants to provide a UI for. You don't have to worry about what widgets the platform supports. You don't have to re-code wrappers for every component. All you have to do is write enough native code to get a window you can draw on. The Swing API is pretty much fully functional from there. Then they write a platform look and feel if they feel like it.

The performance issue isn't as large as almost everyone likes to make it. A GUI isn't really concerned about performance like most other programs are. The operations under the GUI may be, but all the GUI is really concerned about is perceived performance. As long as you model interactions well, and (correctly) use threading the GUI will usually appear to be performing well.

Now what I do know is that SWING uses the Graphics2D API to draw all of it's components. What I don't know is does the Graphics2D API make native OS calls to do what it does?

I'm sure that at some level the Graphics2D APIs use native graphics operations. I'm not sure at what level thins are done though, either...

It is my opinion that Sun/JAVA has already lost the Desktop war. I have used Netbeans and I have used Eclipse. Netbeans 3.5 performs considerably better than previous versions. However, Eclipse still out performs it. Why? Because Eclipse uses Native DLL's. What would be so hard about Sun using Native calls to render GUI components? They already have platform dependent JRE's. The byte code will still run the same on every platform. The VM just makes the appropriate adjustments just as it already does.

You are still comparing 2 Java technologies... I don't see how SWT is making Java loose the desktop war. (Sun maybe... but doesn't Sun win if Java wins...with either SWT or Swing?) There are multiple reasons why Java isn't big on the desktop -

When Java came out there were already many, many GUI toolkits for almost every platform. There were already lots of legacy applications (and application programmers) out there. Compare this to Java's use in web-based programming. Web-based programming was relatively new... there were Perl cgi-scripts and stuff, but servlets were massively more powerful. No Java GUI toolkit offeres a big reason for legacy GUI applications or GUI developers to switch. The only reason to switch is if you need platform independence or dynamic distribution.

Most GUI application developers really don't care too much about platform independence. GUI programming in general is still tied to "the computer is the computer" approach as opposed to Sun's "the network is the computer" approach.

The JVM... you either have to package it with your app, or you have to assume the user has it installed or will install it. This has always been a big pain... though it may not be as bad now with some compter suppliers now shipping systems with a modern JVM pre-installed, and high-speed internet not making the JRE download so bad.

JVM issues. Like each application requiring a new JVM to be launched - this takes up more memory, startup time, resources, etc., some of which could be shared between Java applications.

These issues pretty much affect Java in general on the desktop as opposed to a specific GUI toolkit.

I am almost done ranting on about this, but I would really like some feedback from everyone as to why they believe Sun chose the Universal L&F approach? Why not just extend the AWT? And also, what is Sun doing with the Graphics2D API to help improve SWING with the Tiger release?

I believe Sun went with a Swing style API because of the issue I noted above - it's easy to port to new platforms.

I've played around with SWT, too, and there are parts of both Swing and SWT that I really like. Both have advantages and disadvantages. I'd really like to see SWT keep growing. Since it's open source, the developers don't really have to worry about time spent porting to new environments like Sun did. If someone wants SWT on a new environment, they take the time to port it. I'd also bet that SWT is making Sun consider improving AWT too...

[Gregg Bolinger]

They don't... they provide a Pluggable look and feel. The default look and feel is the platform independent "Metal" look and feel. But you can use platform dependent Windows, Motif, or Aqua look and feels, or use custom look and feels made by anyone
My mistake. A "pluggable" look and feel. But I still say WHO CARES? Most of the better looking L&F's (like kunstoff) perform horribly anyway. And when I say perform, I mean the same app compared with different L&F's.

The performance issue isn't as large as almost everyone likes to make it. A GUI isn't really concerned about performance like most other programs are. The operations under the GUI may be, but all the GUI is really concerned about is perceived performance. As long as you model interactions well, and (correctly) use threading the GUI will usually appear to be performing well.
So then the performance hit is JAVA and not SWING? You cannot say that a SWING Component performs as well or dare I say better than say an SWT app. And the reason I compare a one JAVA app with another (Eclipse vs Netbeans or SWT vs SWING) is for the very reason that they both are JAVA. SWT is faster (I think) because of the native OS calls for rendereing the GUI. Am I wrong? And I have yet to come accross a situation where I was like "I wish SWT had this component". Most modern OS's provide all the components you would ever need. (IMHO)
JVM issues. Like each application requiring a new JVM to be launched - this takes up more memory, startup time, resources, etc., some of which could be shared between Java applications.
I have noticed that the first time you launch a JAVA Application the iniital load time is a bit slower than all reoccuring launches. Don't really know why though. I realize that for security purposes sharing a VM between applications is not the best thing in the world, but it would be nice if SUN maybe figured out a secure way to share some resources within a single VM. But that is another thread all together
When Java came out there were already many, many GUI toolkits for almost every platform
Agreed. And my favorite thus far is QT. A multiplatform GUI Toolkit for C++. You can take your Code and compile it on whatever platform you need. So it's a step further than JAVA where the compiled byte code works on any platform. QT has compilers for ever platform including MAC now.
Nathan, I really respect your input and I don't disagree with you because I think you are wrong. I just want to make sure all the points are made and that I understand the reasons for everything
I also realize that this thread is not going to change the way Sun does anything. But the more WHY that I know, the better programmer I can become. Thanks.

[Nathan Pruett]

Nathan, I really respect your input and I don't disagree with you because I think you are wrong. I just want to make sure all the points are made and that I understand the reasons for everything
I also realize that this thread is not going to change the way Sun does anything. But the more WHY that I know, the better programmer I can become. Thanks.

Yeah... Up front I want to say up front that I don't really think you are wrong either... I'm mostly just supplying a counter-opinion. There are cases where each approach to a multi-platform GUI is the right one, so in some cases the Swing-type will be better, and in some cases the SWT-type will. Just trying to have a friendly flame war...

My mistake. A "pluggable" look and feel. But I still say WHO CARES?

I agree... PLAF is a kinda cool idea, but I've never seen an actual use for it... other than that it supports the "low portage" idea put forward in my last post. I really can't think of a reason it benefits the application programmer.

Most of the better looking L&F's (like kunstoff) perform horribly anyway. And when I say perform, I mean the same app compared with different L&F's.

Yeah, 'cause the view layer has to do more processing to draw cool gradient buttons and semi-transparencies and stuff. Hmmm... this brings up another idea. Most PLAFs have gone for the "eye-candy" approach. ("Sure, it'll take a 9GHz machine to run... but it looks so COOL!") I wonder if anyone has done a minimal PLAF that was focused on using the least amount of resources... ?

So then the performance hit is JAVA and not SWING? You cannot say that a SWING Component performs as well or dare I say better than say an SWT app. And the reason I compare a one JAVA app with another (Eclipse vs Netbeans or SWT vs SWING) is for the very reason that they both are JAVA. SWT is faster (I think) because of the native OS calls for rendereing the GUI. Am I wrong? And I have yet to come accross a situation where I was like "I wish SWT had this component". Most modern OS's provide all the components you would ever need. (IMHO)

Yes, SWT is faster because it uses a native GUI layer. My argument wasn't that Swing was faster, my argument was that it doesn't matter if a component reacts in .35 or .45 ms, there is no way for the user to really notice the difference.

There are some places where I have seen Swing apps react horribly slow. Though I don't know if it was because the way the programmer programmed the app, the programmer used a default Swing component, when he could have used a different one optimized for his task, or whether it was actually Swing's fault. I have done some programming in SWT and there are ways you can make SWT respond horribly slow, too.
Removed concurrent JVM stuff....

Agreed. And my favorite thus far is QT. A multiplatform GUI Toolkit for C++. You can take your Code and compile it on whatever platform you need. So it's a step further than JAVA where the compiled byte code works on any platform. QT has compilers for ever platform including MAC now.

I don't see that as a "step further" than Java... I see that as a step behind... You only have to compile your source to bytecode once. Then it runs in any interpreter. This step basically automates the platform dependent compile that you have to do with QT.

BTW... a link you may be interested in : QTJava.

[Gregg Bolinger]

I agree with you on your last post Nathan. As far as:

I don't see that as a "step further" than Java... I see that as a step behind
What I meant was you have to take an extra step. It is a step behind, but in my opinion, not a vital step.

[Joe McIntyre]

I want a cross platform look and feel so that I can test it on one computer and know that its appearance will be to my satisfaction regardless of what platform it runs on.