Sun to Amp Java for Desktop Performance?
mactari writes "Java client application developers should take a look at Sun's J2SE Client Developer Survey. Swing's relative slowness has always made a Java app with a GUI look and feel slow, and Sun might finally be doing something about it. Questions on the survey suggest Sun is considering moving away from a crossplatform look and feel (eg, Metal) towards native looks by default. If Sun is going to follow the suit played by IBM's native widget toolkit, SWT, or do things on individual platforms like Apple has done with its hardware accelerated version of Aqua-Swing, Java might finally find its way to becoming a competitor on the desktop."
Maybe Sun is feeling that a "cross-platform" "oriented-object" environment a la C#/.NET means danger. They should.
Microsoft, apart from marketing universal support for its platform, really is only interested in taking Java's piece of the cake.
You look at Java, it's one of the greatest OOP languages. Why would make developers switch? What's wrong with Java?
Performance.
As 80%+ of the users/developers are on Wintel, C#.NET will look like a nicer alternative to Java developers; Microsoft won't bother adding a graphical abstraction layer ontop of its API...
Just because an IDE or a text editor is written in Java doesn't mean it can only be used to create other Java apps. That's the silliest thing I've ever heard.
Swing is not so great in a few other areas. Its canvas drawing abilities can be quite slow. Its document model doesn't handle large documents well. Its table model doesn't handle tables with rows that are various heights.
"Only poor programmers who try to implement their whole program in the event handler ever have a problem with SWING."
First off, "SWING" is not an acronym. It's "Swing", or "JFC". Secondly, since Swing is NOT THREADSAFE it is already mandatory to implement any code that touches the UI in the event handler. What. You didn't know that? Most developers don't. It is awful and stupid, and I suspect it was done for performance reasons (which begs the question, if the majority of apps *are not* written this way, why do they appear to work fine?).
I like the idea of Swing. I like the APIs on the edge. But everything inside is a bloated sandwich of layers of cruft. In Swing, hard things are easier than in other toolkits, but *easy* things are often very cumbersome to implement (no, I do not want to implement an entire data model just for a drop-down list thank you!).
I like Swing in general, but it could certainly use some speedups and tweaks. In general I think the problem with Java is not so much that it is "slow" but that it is a memory pig (sorry to say), and that has a tendency to reveal itself in performance (i'm not sure much can be done by this...Moore's law will probably solve it faster than more code).
It's 10 PM. Do you know if you're un-American?
If your going to be condescending, at least be correct. Swings components are not thread safe, true. That does not mean that all code needs to be implemented in the event thread! If fact, that is a classic rookie mistake (as the grandfather post points out).
o mmunity/ chat/JavaLive/2003/jl0121.html
Read this interview with the Sun employees maintaining Swing:
http://developer.java.sun.com/developer/c
Here's an interesting quote:
"I think the single biggest difference between so-so and really great Swing apps has to do with the way developers handle threading issues. As everyone knows, Swing is "single threaded," and this often leads developers to avoid using multiple threads. However, this is a BIG MISTAKE. The fact is that you can use many threads in your Swing app; you just need to follow the rules."
The REAL problem with Swing is that the simplest way to implement any solution is usually also the wrong way. Too many people use DefaultTable model rather than building their own. Too many people subclass components because they 'don't get' UI Delegates. Too many people out there think that since Swing isn't thread safe (and they don't really understand threads enough to know what that means), they should let all their code run from the event thread. Swing's greatest weakness: bad programmers.