The Source for Java Technology Collaboration
User: Password:
Register | Login help    



Syndicate this blog (XML)
Alexander Schunk

Alexander Schunk's Blog

«A comment on JPC Project at Oxford | Main | 64Bit Software: A new Java Monopoly? »

Getting rid of AWT?

Posted by alexanderschunk on March 30, 2007 at 07:54 AM | Comments (18)

History

Back in the 90s when Java emerged as a new OOP programming language the Abstract Windowing Toolkit was the only way to create GUI applications or - at that time - Applets for your website.

The Abstract Windowing Toolkit provides a set of classes for Frames, Panels, Dialogs, Menus, Widgets and other things that you need to create an out-of-the-box Applet or GUI application.

However, the AWT API has some drawbacks and today, there are only a few cases left where one would use AWT API for developing Applets or GUI applications yet these cases are still rare.

The present and future

With Java version 1.2 and 1.3 Swing has beend added as an extension API that is written in Java. At that time Swing already offered some GUI componentes that were not supported by AWT such as JTable, JOptionPane etc.

Today, the Swing API has matured and offers a lot of features to create fancy and stable GUI applications. Moreover, with JApplet class it is possible to create Applets with Swing look and feel.

The current version of the Swing API also offers a variety of features - like Drag and Drop, HTML formatted widgets - with which a normal GUI application can be turned into a fancy and cool looking app.

However, Swing has some problems with other APIs like Java3D but I think JOGL works good with Swing. The problems with Java3D come from leightweight and heavyweight component issues which are not yet? fixed.

So I think it would be a good deal to get rid off the old-fashioned Abstract Windowing Toolkit in favor of Swing and support AWT only for backward capability if necessary.



Comments
Comments are listed in date ascending order (oldest first) | Post Comment

  • I think you misunderstand the purpose of AWT. You can't get rid of it, it is most definitely needed for anything you need to do on the underlying platform. This is the reason the new System Tray functionality in Java 6 is in the AWT package.

    Posted by: fiath on March 30, 2007 at 08:51 AM

  • Right. This is because the Swing classes are derived from the AWT classes. For example JFrame and other classes are derived from Frame and thats also the reason why the Swing components offer the same functionality.

    The approach I mentioned would involve to cut off this alliance between AWT and Swing and build Swing on a smarter basis.

    Posted by: alexanderschunk on March 30, 2007 at 08:59 AM

  • Sigh. Unless you're living in the nineties, one wouldn't really consider AWT as a rival to Swing for UI development. What is "out of the box" GUI application in any case?

    Posted by: kirillcool on March 30, 2007 at 09:24 AM

  • It should be possible to redesign the API in order to use the native C++ classes as a basis for the Swing API.

    So instead of heaving two underlying layers - native classes and AWT API - you would only have the native classes which implement the Swing features.

    Posted by: alexanderschunk on March 30, 2007 at 09:25 AM

  • AWT will always be needed by Swing.

    The way it's designed, AWT is the native-to-java layer when it comes to graphics and user interface components. Swing is the next level that is pure Java, but uses AWT, because at the end of the day ... it has to render to the screen. It's similar to the relationship between SWT and JFace.

    Maybe what you are suggesting is getting ride of the AWT peer components that exist today, like Button, Canvas, etc? That's ok, but not necessary.

    You can use Java3D with the JOGL pipeline and this should solve the AWT/Swing issue.

    Aside from that, the only way to solve the heavyweight/lightway problems is to either implement Swing natively (not going to happen), or to have a bridge that renders native components into Java image buffers.

    Augusto

    Posted by: augusto on March 30, 2007 at 09:31 AM

  • What efforts would it coust to build a bridge in order to into JAva image buffers?

    I think it would be cool if you could use Java3D features with Swing apps, say if you want to add a tiny animation in a JLabel or JPane.

    Posted by: alexanderschunk on March 30, 2007 at 09:43 AM

  • you would only have the native classes which implement the Swing features - what exactly does this mean? That a JButton would be implemented by pure native code? Sounds like AWT to me. The Windows and GTK LAFs already use native APIs to render the controls - is this the bridge you're talking about?

    Posted by: kirillcool on March 30, 2007 at 09:54 AM

  • What efforts would it coust to build a bridge in order to into JAva image buffers?
    I think this is what JOGL does to interact with Swing, don't quote me on that.

    For general purpose heavy weight components, I think it would be very complex, and maybe not worth it.
    I think it would be cool if you could use Java3D features with Swing apps, say if you want to add a tiny animation in a JLabel or JPane.
    You can do this today, with JOGL. Java3D can now use JOGL, I would imagine that would enable this too.

    Augusto

    Posted by: augusto on March 30, 2007 at 10:07 AM

  • Augusto,

    Thanks for the insights and clarifying information.

    If I look at the JOGL / Java3D controversy I think that JOGL will be the Java 3D API for the future.

    The current version of Java3D is build on top of JOGL however both APIs do coexist today.

    The JOGAL approach is a bit more flexible and easier in use compared to Java3D and the scenegraph. Time will show which of these two APIs will remain.

    Posted by: alexanderschunk on March 30, 2007 at 11:06 AM

  • Dropping AWT would make sense if you want to break backwards compatibility in favor of simplifying the Swing API. Otherwise, you would only add even more overhead emulating the AWT layer access through Swing (since they would not be directly related anymore). All AWT classes ans methods are still accessible, and should still work.

    BUT breaking backwards compatibility is not an option. One of the reasons for the success of Java is the solid stability of the API (well, Java is also a victim of its own success, but this is another issue...).

    On the Java3D issue, I don't know it's compatible with Swing, but if not, it's not AWT's or Swing's fault, but Java3D's. It it's APIs are designed in such a way that it's fundamentally incompatible with Swing, then it's just broken, and it is J3D that should be fixed. Anyway, I don't think that is the case, as others already pointed out.

    And, as fiath said, AWT still have a role in the platform, besides being legacy code. It's the package where, the classes you know are highly coupled with the underlying platform, are located (systray, robot, browser, clipboard, imaging). Swing is just a GUI toolkit.

    Posted by: ronaldtm on March 30, 2007 at 11:13 AM

  • Kirill, why do you seem so shocked about the idea of dropping AWT. Mikael Grev proposed exactly just that in one of his threads on the Javalobby.org, as a way of having Swing get rid of the excess baggage that it is stuck with, and move toward a simpler Swing 2.0. Below is the link to that discussion: http://www.javalobby.org/java/forums/m91817100.html

    Posted by: mikeazzi on March 30, 2007 at 11:29 AM

  • >If I look at the JOGL / Java3D controversy I think that JOGL will be the >Java 3D API for the future. What controversy ? >The current version of Java3D is build on top of JOGL however both >APIs do coexist today. It's because they serve different purposes especially with regard to ease of use and level of control depending upon the problem domain. >The JOGAL approach is a bit more flexible and easier in use >compared to Java3D and the scenegraph. Time will show which of >these two APIs will remain. They both will remain. At least I hope so. FYI, and just so that you will get a measure of the significance of a scenegraph oriented approach to 3D graphics, there have been several other scenegraph APIs created atop jogl and in existence today.

    Posted by: nvaidya on March 30, 2007 at 03:36 PM

  • i'm sure you are right that everyone uses Swing rather than AWT components. But as people have pointed out, Swing is built on AWT, and i think it would be quite a big job to "refactor" Swing to cut ties with AWT, and/or to refactor AWT into a foundation for Swing and nothing more. (And this would break compatibility, so is not something would enjoy everyone's support.) With Java going opensource, some people somewhere might embark on these type of projects (hopefully), which are interesting research exercises, even if the practical rewards are not obvious or immediate.

    Posted by: evanx on March 30, 2007 at 05:02 PM

  • Quote from James Gosling:
    When asked what he would get rid of, if designing Java again from scratch: “Braces! And AWT!”
    seen at
    http://neilbartlett.name/blog/2007/03/15/an-evening-with-james-gosling/


    I have a solution to code in Swing without AWT. Swing on Flash :)
    www.aswing.org

    Posted by: nopjn on March 30, 2007 at 06:17 PM

  • Hello Alexander

    This blog has an incorrect date
    it should be the next day - 1 April

    alexp

    Posted by: alexfromsun on March 31, 2007 at 01:33 PM



Only logged in users may post comments. Login Here.

This work is licensed under a Creative Commons License.
Creative Commons License

Powered by
Movable Type 3.01D
 Feed java.net RSS Feeds
Feedback  | FAQ  | Press | Terms of Use
Privacy  |  Trademarks | Site Map
 
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
 
Copyright © 1995-2008 Sun Microsystems, Inc.
Oreilly LogoCollabnet Logo
Powered by Sun Microsystems, Inc.,
O'Reilly and CollabNet