Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Java Programming Sun Microsystems

Sun to Amp Java for Desktop Performance? 88

Posted by chrisd 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."
This discussion has been archived. No new comments can be posted.

Sun to Amp Java for Desktop Performance? More

Sun to Amp Java for Desktop Performance?

Comments Filter:

  • Jave for performance... (Score:3, Funny)

    by ewhenn ( 647989 ) on Wednesday April 02, 2003 @10:06PM (#5649946)
    ..faster than a turbo charged yugo.

  • Sun on the desktop? (Score:1, Insightful)

    by Anonymous Coward
    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).

  • Native look and feel? (Score:4, Funny)

    by Violet Null ( 452694 ) on Wednesday April 02, 2003 @10:15PM (#5649987)
    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? (Score:2, Insightful)

      by 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 pre
      • God, it's great to see some intelligent thought here. These are exactly the criteria that need to be considered.

        I especially think that point #7 is very important. It's clear to me that separating the GUI design from the code is the way to go. GUI design and programming are very different tasks -- sometimes people are godd at one and not the other. Plus, GUIs should be done in a different language than programming -- something descriptive, not procedural.

        I've used GLADE (for GTK/GNOME) and it makes a nice

      • Have fun (Score:1, Interesting)

        by Anonymous Coward
        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 t

        • Re:Have fun (Score:2, Insightful)

          by dingd0ng ( 660596 )
          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.
          • You have it backwards.

            Writing simple GUIs using drag and drop is easy.
            Writing complex GUIs using drag and drop (VB's style of drag and drop) is a pain.

        • Re:Have fun (Score:2, Informative)

          by fredrik70 ( 161208 )
          well, taste differs. if you want to have VB-like drag-n-drop UI design functionality why not go for Fotre [sun.com] (or it's m,ore on the edge cousin Netbeans [netbeans.org]) or go and buy JBuilder [borland.com] 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)
  • You can't link Java to gtk, gnome, kde, qt, or any other useful development base. I know there's CORBA, but that's so indirect compared to a direct link.

    Until the bindings are possible, it's going to be a niche product.
  • Are there any popular, mainstream Free Software projects implemented in Java, other than stuff only useful in Java development shops? (Stuff like IDEs, text editors, web server add-ons, and XML validators don't count. Limewire doesn't count either -- it's not Free Software.)

    That isn't a rhetorical question. If you've got 'em, post 'em.

    • Why don't IDEs and text editors count? Those are two instances where there happen to be many popular, mainstream Free Software projects implemented in Java that really kick ass.
      • Wonko42 asked, "Why don't IDEs and text editors count?"

        Them's the rules -- for the sake of this posting, they just don't. (You can probably figure out a good reason if you think about it.)

      • Becaue Java apps that create other Java apps tells us nothing about Java. Where are the Java apps that non-Java developers use?

        • Re:Just Wondering (Score:4, Insightful)

          by Wonko42 ( 29194 ) <(ryan+slashdot) (at) (wonko.com)> on Thursday April 03, 2003 @01:26AM (#5650810) Homepage
          I'm not a Java developer and I use jEdit [jedit.org] exclusively as my text editor of choice. I also use a cell phone with a Java-based OS [danger.com].

          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.

        • Hunh? jEdit rocks, since when it has to be used to only create other Java applications? I though a text editor is text editor is a text editor dependless of what language it's written with.

          I've used it to do some simple xml & html documents, some c(++), and sure, some Java as well. Amongst other things.

          Same holds true for eg. Eclipse, even if it's optimized for Java there are plenty of features for writing software in other languages.

    • Re:Just Wondering (Score:2, Informative)

      by sameb ( 532621 )
      limewire is free software, if you want it to be. it's open-source [limewire.org]. download and see for yourself. or here's the javadocs [limewire.org], if you're so inclined.
    • OK, I was wrong, Limewire is under GPL. (Not that you could tell, looking at limewire.com -- but limewire.org [limewire.org] reveals all.) Somebody else posted about something called DVArchive [sourceforge.com], something for fooling with your ReplayTV. Moneydance [moneydance.com] was announced recently, and might get popular. Anything else?
    • Freenet [sourceforge.net]
      • Sorry, we can't count Freenet. It hasn't been anything like a popular success.

        When I last tried it, it was excruciatingly slow, and eventually got stuck in an infinite loop that gradually consumed all of swap (or tried to, until I killed it). That might have been the JVM, but what difference does it make, really?

  • SWING kicks AWT's ass! (Score:5, Interesting)

    by zenyu ( 248067 ) on Wednesday April 02, 2003 @11:17PM (#5650273)

    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...
    • I'll have to agree with that. But what do you expect from the drag and drop developers sucked over from the VB world. When you see doButton1Click() suck 5000 records from a database in the event loop, you know your are in trouble.
      • 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
    • 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 o

    • Re:SWING kicks AWT's ass! (Score:4, Insightful)

      by Hard_Code ( 49548 ) on Thursday April 03, 2003 @08:01AM (#5651782)
      "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).
      • 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 m

        • Re:SWING kicks AWT's ass! (Score:4, Informative)

          by ChannelX ( 89676 ) on Thursday April 03, 2003 @02:09PM (#5654537) Homepage
          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.

      • You don't have to implement your own data model for a dropdown list. JComboBox can take an array or a Vector of items as a list. Thats a far cry from having to implement your own data model.

      • Re:SWING kicks AWT's ass! (Score:5, Insightful)

        by bay43270 ( 267213 ) on Thursday April 03, 2003 @02:53PM (#5654987) Homepage
        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.

  • desparate times (Score:2, Interesting)

    by ddd2k ( 585046 )
    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.
  • April fools's was on the 1st.

    Stop posting these ridiculous stories...

    Oh... it's... not.. a joke...

  • Frigthened by C#? (Score:4, Insightful)

    by ptaff ( 165113 ) on Thursday April 03, 2003 @12:48AM (#5650688) Homepage
    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...
    • 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,
    • 80%+ of the users/developers are on Wintel

      Be careful lumping users and developers together so sloppily. It seems the latter at least have other plans, Linux developers are coming from Windows [slashdot.org] in large numbers. There are many things to love about Java programming on Linux [javalinux.net].

    • Re:Frigthened by C#? (Score:3, Informative)

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

  • Cross-platform means non-optimal (Score:3, Interesting)

    by ClosedSource ( 238333 ) on Thursday April 03, 2003 @02:11AM (#5650934)
    "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?

    • Training time and associated cost (Score:4, Interesting)

      by LinuxXPHybrid ( 648686 ) on Thursday April 03, 2003 @06:32AM (#5651471) Journal
      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.
      • Well, running on a server is a different scenario. If the UI is a web browser, and the server app doesn't need to run under different OS's, it doesn't really matter what language is used to implement the app as long as it can deliver html to the clients (at least from a cross-platform point of view).

        Of course, a web browser UI is a compromise in itself. As you say, sometimes there are good reasons not to adjust to every platform, but you always lose something in the trade-off.
  • I've been learning JAVA since the start of this year and am just starting to deal with gui button type things. I'd love to have an Aqua interface on a WindowsXP app... one day!

  • Swing is very responsive for widgets (Score:4, Insightful)

    by DeadSea ( 69598 ) on Thursday April 03, 2003 @06:07AM (#5651437) Homepage Journal
    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.

  • It is too Fscking Late. (Score:3, Insightful)

    by His name cannot be s ( 16831 ) on Thursday April 03, 2003 @09:29AM (#5652266) Journal
    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" )

    • 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.
      I used PVCS in 1998. A fucked up Java Swing client app would be an improvement over the fucked up win32 client app with all hand-coded widgets they used to have.

      -Richard.
      • You underestimate their ability to fuck up clients. The PVCS Version Manager 7.0 Java Swing client app is 10 times worse (both speed and usability) than the 6.0 win32 client. No one on our team will use the 7.0 client.

        I know, I know, we need to migrate to CVS or something else.
  • It's worth mentioning that even Sun comes down hard on AWT/Swing, and shows some of its flaws in their own report, The AWT Focus Subsystem [sun.com].

    Sun even has the guts to plainly state that Windows GUI techs in C++ and VB are improvements over Java options in the following section:

    In addition, many developers noted that the APIs for FocusEvent and WindowEvent were insufficient because they did not provide a way for determining the "opposite" Component involved in the focus or activation change...

    Since Microso
  • 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

  • Performance of Java Graphics (Score:4, Interesting)

    by jdfekete ( 316697 ) on Thursday April 03, 2003 @04:24PM (#5655783) Homepage
    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.

  • I've never coded in Java, but I've used a lot of programs that were. In my experience, the vast majority of them had dog-slow and butt-ugly UI.

    Java might be capable of generating very responsive, pretty UI, but it must not be very conducive to it. Otherwise the vast majority of Java apps wouldn't have such atrocious UI.

    If the language isn't designed in such as way so as to encourage good program design and implementational practice, then it's not designed well, IMHO.

Slashdot Top Deals

"I've finally learned what `upward compatible' means. It means we get to keep all our old mistakes." -- Dennie van Tassel

Close