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

12 of 88 comments (clear)

  1. Native look and feel? by Violet+Null · · Score: 3, Funny

    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.

  2. 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 Hard_Code · · Score: 3, Insightful

      "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?
    2. Re:SWING kicks AWT's ass! by ChannelX · · Score: 3, Informative
      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.

      --
      My blog: http://jkratz.dyndns.org/~jason/blog/
    3. Re:SWING kicks AWT's ass! by bay43270 · · Score: 4, Insightful

      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.

  3. Bindings are possible by jaaron · · Score: 4, Informative

    Bindings are possible. For example:

    Java-gnome Just check out google for others.

    --
    Who said Freedom was Fair?
  4. Frigthened by C#? by ptaff · · Score: 3, Insightful

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

  5. Re:Just Wondering by Wonko42 · · Score: 3, Insightful
    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.

  6. You can have it now... by clambake · · Score: 3, Informative

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

  7. Swing is very responsive for widgets by DeadSea · · Score: 3, Insightful
    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.

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

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