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."

Comments

Jave for performance...

[ewhenn]

..faster than a turbo charged yugo.

Native look and feel?

[Violet Null]

Where have I heard of that before? Somewhere...somewhere I've heard about a Java lib that provides components that are platform-dependant. Hrmmm. Ponder ponder.

Oh yeah. AWT.

Re:Native look and feel?

[Anonymous Coward]

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.

Re:Java isolates from other innovations and toolki

[sartin]

The bindings are possible. You can use JNI (Java Native Interface) to hook Java code directly to C or C++. It's a tad contorted, but not nearly as torturous as using CORBA to do it.

SWING kicks AWT's ass!

[zenyu]

I'm so annoyed by this "SWING is slow" canard. As a graphics programmer I can tell you aside from a few glitches in a few select JVM's SWING is much faster. Only poor programmers who try to implement their whole program in the event handler ever have a problem with SWING. Their programs would suck in AWT too, they would simply freeze with the OS redrawing the buttons. With all the work Sun has put into making threads drop dead easy to use there is absolutely no excuse. They have a hook for running things in a thread from a managed pool, and even a utility for running things in the Swing thread when you're done...

Re:SWING kicks AWT's ass!

[zenyu]

When you see doButton1Click() suck 5000 records from a database

Chills just ran down my spine. We had some of those at a custom app house that moved from PowerBuilder to Java. The transition started before SWING and we rolled our own Thread pool and a "run in AWT Thread" utility. We finally did manage to get them out of the event loop on database queries by throwing up an error message if a blocking database call was attempted in the event loop, hehe (never got a complaint on that...they knew better after months of being told not to do it.). We never got them using sensible layout managers though. I should have just disabled the absolute layout manager to begin with, we had wrapped the AWT objects so we could customize them, disabling absolute layout would have been easy, but I worried too many forms had been built badly already. Now, I'd write in a check for legacy classes by name and then assign them a few at a time for upgrade, perhaps giving orphaned ones to trainees. Ah, the mistakes we make when first working with the less able.

Re:SWING kicks AWT's ass!

[(H)elix1]

I'll admit I spend more time on the server side of the Java world than the client, but here is my take on the world.

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...

Re:SWING kicks AWT's ass!

[Hard_Code]

"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).

Re:SWING kicks AWT's ass!

[zenyu]

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?
Did you read my post? One of the things I pointed out was how easy they made it to run things in the event loop when you were done. Not being comfortable writing callbacks is a really scary 'programmer' attribute. It was done for performance reasons, knowing the order of drawing makes alpha blendings much more efficient. Even if alpha is 1.0. It's also more memory efficient, you don't need to buffer all the mostly hidden panels. Double buffering in SWING only needs a single copy per AWT object. (JFrame, JWindow, etc.)

I do not want to implement an entire data model just for a drop-down list thank you!
I agree with this, but it's not the complaint I hear most. It's surprisingly cumbersome to use things like a table. I've implemented ones large enough that their approach made sense, but often I'm just using one for convenience and then the whole stamping thing isn't worth the annoyance.

I looked at the survey and I think they're just considering whether to suck up the gtk/KDE L&F, and whether to make that the default L&F. Someone was telling me the Eclipse IDE does this for gtk to good effect.

Re:SWING kicks AWT's ass!

[ChannelX]

I looked at the survey and I think they're just considering whether to suck up the gtk/KDE L&F, and whether to make that the default L&F. Someone was telling me the Eclipse IDE does this for gtk to good effect.

Umm...Eclipse uses SWT which uses native UI elements on platforms where it is implemented. The only time it emulates something is if there isn't a native widget.

Re:SWING kicks AWT's ass!

[bay43270]

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).

Read this interview with the Sun employees maintaining Swing:
http://developer.java.sun.com/developer/co mmunity/ chat/JavaLive/2003/jl0121.html

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.

Bindings are possible

[jaaron]

Bindings are possible. For example:

Java-gnome Just check out google for others.

desparate times

[ddd2k]

Its unforunate that cross-platform technology is constantly going downhill because it doesn't have a competitive edge, driven by fanatic C elitests only comparing its performance in speed. Thats not what Java was designed to do! Sad to see that Sun is forced to resort to these measures to stay in the market as it moves away from platform indepedence.

Frigthened by C#?

[ptaff]

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...

Re:Frigthened by C#?

[ChannelX]

Hate to break this to you but C#/.NET Framework is no speed demon. Its about the same as Java.

Re:Just Wondering

[sameb]

limewire is free software, if you want it to be. it's open-source. download and see for yourself. or here's the javadocs, if you're so inclined.

Re:Just Wondering

[Wonko42]

I'm not a Java developer and I use jEdit exclusively as my text editor of choice. I also use a cell phone with a Java-based OS.

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.

Cross-platform means non-optimal

[ClosedSource]

"Questions on the survey suggest Sun is considering moving away from a crossplatform look and feel (eg, Metal) towards native looks by default."

Of course, a true cross-platform application should have the same look and feel on every platform.

That's the problem with all these cross-platform technologies like Java, you always end up with an non-optimal solution. If an application can't take advantage of platform-specific features, why bother having multiple platforms?

You can have it now...

[clambake]

Go look for other "look and feel" packages like this one...

Swing is very responsive for widgets

[DeadSea]

Swing excels at having lots of tabs, checkboxes, scroll panels and such. It is very snappy and responsive for that type of app. If you have ever run limewire, you will know how nice a Swing GUI can be.

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.

Training time and associated cost

[LinuxXPHybrid]

I am currently developing an application server (in Java) and clients only communicate with the application using web browser. One of reasons is that I don't have to go through cross platform debugging, optimization and installation nightmare, but I also have another compelling reason. I want to make the UI as similar as possible (ideally exactly the same) on all platforms, while we'll need to use different platforms (Win, Mac, etc.) for various reasons. That way it will be so much easier to train people later on.

Yes, we want to take advantage of each platform sometime, but that is not always the case. If you think about training cost and so forth, there are good reasons NOT TO adjust to every platform.

Marketing as well

[LinuxXPHybrid]

I used to work for a company who was developing a software application for industrial automation system (long sentence). This company had a big contract with a big company, who shall remain nameless. Yes, the main application was developed in C++ (MFC) for performance reasons; however, we also developed a version in Java. I cannot say that it worked great, but it had great potential.

Java version did not sell (while I was staying there) and did not make great progress in terms of marketing; nonetheless, the main reason was not performance. This big company who does industrial automation stuff did not like Java because they were partnered with Microsoft. Before Java really started taking off, Microsoft made sure that Java will not take over their market by partnering and making a bunch of deals.

I am not accusing Microsoft for any wrong doing. The point that I want to make is that many doors were already closed before Java tried to show what it can really do. When we look at today's desktop computer application market, it appears that Java did not succeed because of its performance, but speaking retrospectively, if many doors were open, if Java were tested in many different situations (including this case of industrial automation software), we might be looking at Java very differently. Again, I am just speaking retrospectively.

It is too Fscking Late.

[His name cannot be s]

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" )

Different Strokes

[WeaponOfMassDestruct]

Why is it that people have to think so one-dimensional in situations like this. Why do we have to see posts like:

• Swing is the fastest best GUI ever invented!!!!!! Everything should use Swing all the time no matter what!!!
• Swing is so dog slow it's awful!!! I heard Sun is going to just remove it from the JDK and take all the engineers that designed it and hang them outside Sun headquarters!!

They really both have their place. If you really need an app to look and behave the same across all OS's and JVMs then Swing is the obvious solution. It has its shortcomings, but it is much improved since the 1.2 days.

Alternatively, if you are developing an app for only one platform then your requirements are different and something like SWT might make sense. It also seems to me to be not that important. GUI apps have there place, but if you look at the bulk of the programming work going on right now it is not happening in GUIs. I think Java is winning where it counts.

Re:Have fun

[dingd0ng]

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.

Performance of Java Graphics

[jdfekete]

I have been working quite a lot on trying to improve Java graphics performance, starting from Agile2D [http://www.cs.umd.edu/hcil/agile2d/], a free implementation of Java Graphics2D based on OpenGL made by Jon Meyer for the Human-Computer Interaction Lab of the University of Maryland.

The fact is, using a recent accelerated graphics card (Quadro4 500 GoGL on a Laptop Dell M50), I have speedups of 10 to 200 times compared to the native Java implementation ON THE SAME PLATFORM. These numbers improve on desktops with GeForce 4 or ATI equivalents.

I am currently improving Agile2D and it is getting better at fonts and most other things as well.
However, Agile2D cannot completely replace Java graphics right now because the repaint management of Swing is not designed to be modified, leading to refresh problems that I haven't been able to fix so far.

This means that -- as Apple already realized -- Java graphics can be made much faster in a portable way by relying on OpenGL.

Of course, on older graphics platforms, OpenGL is slower than software rendering. But using the "Object Technology", it should be possible to engineer two different implementations of Graphics2D and choose the right one at startup time, especially in Java.

So there is hope for large speedups if Sun switches to hardware rendering or redesign a little bit the Swing RepaintManager to allow external developers to implement the speedups by themselves.

Re:Have fun

[fredrik70]

well, taste differs. if you want to have VB-like drag-n-drop UI design functionality why not go for Fotre (or it's m,ore on the edge cousin Netbeans) or go and buy JBuilder from Borland. THere're other RAD IDEs that spring to mind as well, VisualCafe' for example (haven't used it for ages though - NetBeans and IntelliJ does all I want)