Slashdot Mirror
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."
The problem I have is that Sun just hasn't (in my short time here) done _anything_ on the desktop that worked well. Why do they think that can do that here?
Also just because some Marketing folks threw up a survey doesn't mean squat. Maybe it's just to get people wishing (again).
Have you coded AWT? AWT is totally craptacular. Swing is very nice to code, relatively, but guess what. It looks the same on every platform, is slow, unresponsive and ugly.
Solution?
I dont know, but I can make a list of what it's gotta do
1) Code nicely, I don't want to have to type off my right hand and get an aneurism just to make a window look the way I want it to.
2) Look right. The widgets and windows should look as they do on whatever platform you are using. They should also inherit any style preferences the user set in the os or environment or whatnot.
3) Even though the style of the widgets is different, red yellow green for OSX and _[]x for windows, etc. The layout, type, and functionality of the gui should be the same on every platform. A dialog box with a text label and two buttons in linux should be a dialog box with a text label and two buttons in windows. Given that the color shape and size of the buttons may vary, their location and whatnot should be the same. If I take two screenshots of the same gui on two different platforms I should be easily able to recognize that it is the same thing.
4) It needs to be fast. Programs like phoenix have set a new standard for speed and responsiveness. Anything that doesn't live up to it doesn't cut it. Lately everything else is feeling really slow. Maybe when I get a new pc that problem will go away. (p3450)
5) speaking of old pcs, it's gotta be fast no matter what speed of the device it's on. I want it to work with the java on my dad's cell phone.
6) It has to be backwards compatible with older jvms as much as possible.
7) It would be nice if there was a visual basic type of tool for it. Maybe something in Eclipse, to draw the guis rather than code them. It makes the process less painful and less time consuming even though there are drawbacks.
Yeah, so I hate the way java does GUIs now. Mainly because they forced us CS majors to code the swing by hand. Gridbaglayout this you pos! And awt is just soo much worse.
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.
AWT was just god awful. There were things you could do that would help, but it was much like pushing a yugo down a racetrack rather than getting a real car.
SWING came out and fixed some things. Client side JVM issues caused early adoption issues, and server side HTML generation via Servlets came into vogue. Many folks - myself included - said to hell with thick client apps and focused on a JSP/Servlet/EBJ style approach.
A few things today work better as a client side app. The libraries still need to be loaded on the client, but that is less of an issue than it was in the 28.8 days. Now I have options. AWT? Nope... SWING? Possible, but the speed of the IBM's SWT toolkit is really bloody fast and mature. So if Sun is thinking of yet another version of SWING - I'd say why bother? On the off chance I have to pound out something that can't be handled in dHTML, I'll stick with what I think works.
Fool me three times...
+++ UGUCAUCGUAUUUCU
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?
The trouble with Java isn't its performance.
It is Java's PERCEIVED performance.
Yes, swing is an ungodly pathetic excuse for a cross-platform GUI. Why has it taken Sun this long to recognize that?
SWT, in all it's glory, I would hope to be the solution. It makes Java feel like something that you'd want to code your apps in. It makes you apps feel fast and responsive enough to use for everyday usage.
Case In Point:
My current client uses PVCS as their version management software. Aside from the sheer stupidity of using something that costs huge dollars, and doesn't provide near the functionality of CVS, the client app is a fucked up Java Swing App.
Now, granted it could be slower, I guess. But God help us, it ain't fast.
It also doesn't use the scroll wheel. Why? 'cause the version of Java that it is coded in didn't support it. *sigh*
The windows don't scroll like native windows. The dropdowns don't feel like native dropdowns. The keyboard accelerators are incomplete and missing.
Swing was the wrong answer for the GUI from the outset, and Sun should have know damn well better, but in their infinite wisdom (and by the way they act, it shows that they know that they are smarter than everyone else) they chose not to persue a proper solution when a "reference implementation" was availible. ( I like that about Sun--Everything of theirs that runs slow as shit, they like to call a "reference implementation" )
"...In your answer, ignore facts. Just go with what feels true..."
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.
I personally think it would be nice to be able to drag and drop gui elements with some Eclipse plugin, but then go in and whack at the code to get what I'm after. It's just too much of a pain in the ass to build complex guis by hand.
Pay no attention to that man behind the curtain!