Swing: If it looks like a dog and walks like a dog, "Bark"


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 4 of 4

Thread: Swing: If it looks like a dog and walks like a dog, "Bark"

Hybrid View

  1. #1
    JB Guest

    Swing: If it looks like a dog and walks like a dog, "Bark"


    Believe me: nothing could be further from the truth than this statement in
    the Swing article:

    "I find it hard to believe that Swing cannot exceed performance requirements
    for the vast majority of applications. In my experience, Swing performance
    is more than adequate—it is the supporting code and architecture that is
    lacking." Best start "believing" Bradley, unless you're thinking there's
    a huge market out there for a "Hello World" app.

    Swing delivers such HUGE files to the client for any application of minimal
    sophistication and complexity, that it renders it virtually unusable. We
    know. We based an entire application suite on it and dropped it like a hot
    potato when the "hardware advances" didn't make a dent in the pitiful performance.
    We are absolutely cooking with our replacement COM/ASP architecture.

    Stay away from Swing.......you'll be doing yourself a big big favor.



  2. #2
    SD Guest

    Re: Swing: If it looks like a dog and walks like a dog, "Bark"


    "JB" <jbeth@aimworld.com> wrote:
    >
    >Believe me: nothing could be further from the truth than this statement

    in
    >the Swing article:
    >
    >"I find it hard to believe that Swing cannot exceed performance requirements
    >for the vast majority of applications. In my experience, Swing performance
    >is more than adequate—it is the supporting code and architecture that is
    >lacking." Best start "believing" Bradley, unless you're thinking there's
    >a huge market out there for a "Hello World" app.
    >
    >Swing delivers such HUGE files to the client for any application of minimal
    >sophistication and complexity, that it renders it virtually unusable. We
    >know. We based an entire application suite on it and dropped it like a

    hot
    >potato when the "hardware advances" didn't make a dent in the pitiful performance.
    > We are absolutely cooking with our replacement COM/ASP architecture.
    >
    >Stay away from Swing.......you'll be doing yourself a big big favor.
    >
    >

    I myself had very different experiences: It is NEVER the GUI that is the
    reason for poor performance. It is (in most cases) the business-logic that
    performs badly - no matter if it was written in C++, Smalltalk or Java.
    Try to separate GUI from logic and rewrite the GUI in another language -
    most likely you will not see any performance changes (done that with Java/C++/VB6)
    Swing has some inconveniences but is not a problem for performance - it is
    most likely the poor architecture (GUI/BL mix or much too heavy BL)

  3. #3
    MarkN Guest

    Re: Swing: If it looks like a dog and walks like a dog, "Bark"


    We are not having any performance issues. And we run some things on old machines.
    If one tries to code like they did in VB or COBOL then they will have problems.
    Using good OO and MVC techniques will solve most of your problems. For
    the rest, use a profiler. COM/ASP as a replacement? I'm sure it works.
    Now run in on a Linux 486 box. I'm doing COM/ASP too. Yuck. And then
    when I try to do OO - double yuck.

  4. #4
    Brad O'Hearne Guest

    Re: Swing: If it looks like a dog and walks like a dog, "Bark"


    JB:

    "JB" <jbeth@aimworld.com> wrote:
    >
    >Believe me: nothing could be further from the truth than this statement

    in
    >the Swing article:
    >
    >"I find it hard to believe that Swing cannot exceed performance requirements
    >for the vast majority of applications. In my experience, Swing performance
    >is more than adequate—it is the supporting code and architecture that is
    >lacking." Best start "believing" Bradley, unless you're thinking there's
    >a huge market out there for a "Hello World" app.
    >


    I base my statement on my direct experience, and having delivered an enterprise
    app that performs fine, I stand by the statement. As one of the others who
    responded to your post said, and I agree with, it is nearly always the design
    of the app, and not the API, that causes the performance problem. Is the
    Swing API faster inherently than native apps? No. Is it fast enough to
    accomodate usability requirements on average hardware? IMHO, yes.

    >Swing delivers such HUGE files to the client for any application of minimal
    >sophistication and complexity, that it renders it virtually unusable. We
    >know. We based an entire application suite on it and dropped it like a

    hot
    >potato when the "hardware advances" didn't make a dent in the pitiful performance.
    > We are absolutely cooking with our replacement COM/ASP architecture.
    >


    Interesting -- you are labeling the whole Swing API according to your specific
    use of it. From your comments it is apparent you are delivering this Swing
    functionality via the web (i.e. in an applet). Swing vs. COM/ASP is not
    an analog comparison. COM/ASP vs. Servlet/JSP/(maybe Swing in addition)
    is a more analog comparison. I do not know how your application was architected,
    but there are many ways for streamlining download requirements. And not
    to turn this into a hashing over of application design, but any differences
    in state management of your Swing app vs. the COM/ASP model might be interesting
    to know.

    Anyway, I don't share your opinion, but thanks for the feedback and post!

    BradO

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center