Slashdot Mirror

← Back to Stories (view on slashdot.org)

Sun to Amp Java for Desktop Performance?

Posted by chrisd on from the slow-sometimes dept.

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

8 of 88 comments (clear)

  1. SWING kicks AWT's ass! by zenyu · · Score: 4, Interesting


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

    1. Re:SWING kicks AWT's ass! by zenyu · · Score: 2, Interesting

      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.

  2. desparate times by ddd2k · · Score: 2, Interesting

    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.

    --

    Great Atrocit
  3. Cross-platform means non-optimal by ClosedSource · · Score: 2, Interesting

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

  4. Training time and associated cost by LinuxXPHybrid · · Score: 3, Interesting

    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.

  5. Marketing as well by LinuxXPHybrid · · Score: 2, Interesting

    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.

  6. Have fun by Anonymous Coward · · Score: 1, Interesting

    So you want Java GUIs to become VB?
    Believe me when I tell you you're in a minority.

    One of the features of Java I appreciate most is coding GUIs by hand. Its one of the few languages that gives me the control over the look, feel, and layout that I simply can't get in other platforms.

    I find that people who dont like the system simply haven't tried some of the (much much worse) alternatives.

    if you want a click-a-button-to-get-a-button gui design system, careful about it. It can easily limit your abilities to make an effective app.

  7. Performance of Java Graphics by jdfekete · · Score: 4, Interesting

    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.