Vous êtes sur la page 1sur 9

AWT AWT stands for Abstract windows toolkit.

Swing Swing is also called as JFCs (Java Foundation classes).

AWT components are called Heavyweight component.

Swings are called light weight component because swing components sits on the top of AWT components and do the work.

AWT components require java.awt package. AWT components are platform dependent.

Swing components require javax.swing package. Swing components are made in purely java and they are platform independent.

This feature is not supported in AWT. These feature is not available in AWT.

We can have different look and feel in Swing. Swing has many advanced features like JTabel, Jtabbed pane which is not available in AWT. Also. Swing components are called "lightweight" because they do not require a native OS object to implement their functionality. JDialog and JFrame are heavyweight, because they do have a peer. So components like JButton, JTextArea, etc., are lightweight because they do not have an OS peer.

With AWT, you have 21 "peers" (one for each control and one for the dialog itself). A "peer" is a widget provided by the operating system, such as a button object or an entry field object.

With Swing, you would have only one peer, the operating system's window object. All of the buttons, entry fields, etc. are drawn by the Swing package on the drawing surface provided by the window object. This is the reason that Swing has more code. It has to draw the button or other control and implement its behavior instead of relying on the host operating system to perform those functions.

AWT is a thin layer of code on top of the OS.

Swing is much larger. Swing also has very much richer functionality.

Using AWT, you have to implement a lot of things yourself.

Swing has them built in.

Differences between Swing and AWT. When to use what?

"Swing" was actually the code name used by Sun during the development and it was planned that on release the extension will be known as JFC (Java Foundation Classes), but Swing managed to beat JFC in popularity even after the release of the package.

Swing package can be used with Java 1.1 as well. For that we need to include three JARs swing.jar, swingall.jar, windows.jar in the CLASSPATH and the packages are named 'com.sun.java.swing.*', 'com.sun.java.swing.event.*', etc. In Java 1.2 the package names changed to 'javax.swing.*', 'javax.swing.event.*', etc. as the concept of extensions were introduced in Java 1.2 (Java 2 Platform).

Main Differences between Swing and AWT

Swing comonents are light-weight as compared to AWT components for the simple reason that they don't make use of the native UI components of the underlying platform. Swing components haven been written completely in Java language. Not the same with AWT as it uses native libraries. Swing components use relatively less number of classes as compared to AWT components not only because the it doesn't depend on native code, but also because it has a better design due to its evolution from AWT. Most of the design flaws got fixed which ultimately led to lesser redundancies. The look and feel of the Swing components is defined only by the Swing extension classes and it's pluggable to have the look and feel of the underlying platform as well whereas the look and feel of the AWT comonents is mostly goverened by the underlying platform. By default, Swing components open up in their own look and feel. Swing extension is completely based on the MVC (Model View Controller) architecture and hence the inherent benefits of the MVC design pattern add more value to the usage of Swing.

In addition there are few other trivial differences as well. For example: Swing extension has a richer set of components as compared to AWT, Swing's JPanel automatically gets double buffered and gets repainted faster, etc.

When to use what?

Due to all these advantages, Swing has almost entirely relaced AWT and you got to have a really strong reason if you are still using AWT in your application which is very hard to find at least for platformindependent applications. Liked the article? You may like to Subscribe to this blog for regular updates. You may also like to follow the blog to manage the bookmark easily and to tell the world that you enjoy GeekExplains. You can find the 'Followers' widget in the rightmost sidebar.

An Adapter class is just a "blank" implementation of a Listener interface. They're convenience classes made so you don't need to implement all of the methods of an interface. A good example is the MouseListener interface. Let's say you want to detect when a user clicks on your Component. You only need to implement the mouseClicked method to get that part working. This will leave you with... public void mousePressed(MouseEvent e) { } public void mouseReleased(MouseEvent e) { } public void mouseEntered(MouseEvent e) { } public void mouseExited(MouseEvent e) { } ...at the end of your implementation. Ugly. So Java gives us the MouseAdapter class (which gives us the same empty implementations as above). We can use this in place of a MouseListener to try to keep our code cleaner.

Re: KeyListener Interface or KeyAdapter class?


Reply #2 - Posted September 04, 2006 Quote BUT .. since I really want to learn corectly and since my personal conclusions more than often tend to be wrong , any clarifications here?What is the difference between those 2?

First: The Adapter class is some sort of convenience utility. If you are too "lazy" to implement the full interface... or if you just want to keep your code uncluttered, you use the Adapter class. Second: You don't have multiple inheritance in java. A java class cannot extend more than one base class, but you can implement as most interfaces as you like. So if your class extends KeyAdapter, it cannot extend e.g. JPanel anymore. If on the other hand your class implements the KeyListener interface, it can extend whatever base class is needed. As a rule of thumb: You normally use adapter classes as anonymous inner classes, like
1 2 3 4 5 6 // add a anonymous utility class for handling inputs to "panel" panel.addKeyListener(new KeyAdapter() { // implement the method you need }); // (...)

so you use the input functionality. You use interfaces, if you want to create a new type of utility component, like
1 2 3 4 5 6 7 8 9 10 11 12 // This class is a transformation matrix to steer a starship // based on mouse and keyboard input class Steering extends Matrix implements MouseListener, MouseMotionListener, KeyboardListener { public Steering(float minX,float maxX,float minY,float maxY) { // set up your steering algorithms based on the constructor parameters } // implement the different Listener interfaces to compute the transformation matrix }

// (...)

so you extend the input functionality.

vents, listeners, and adapter classes


JavaBeans events are signalled when an activity occurs, such as a button being pressed or a window being closed. The visual editor for Java shows events in the Java Beans view, and you can use this view to add and remove events. The list of defined events for a JavaBean is described in its BeanInfo class, which also controls the commonly used or preferred events. You might want to add an event to a JavaBean if you want something to happen when the JavaBean is generated, such as a database update when a button is pushed. The Java Bean raising the event is the source, and the object that gets called back when the event is raised is known as the listener. Each JavaBean has an interface that allows it to notify the listeners for each event, as well as methods to add and remove listeners. Typically, if the source JavaBean has a method XXX, there is a listener interface, XXXListener, and two methods. It is important that XXXListener extends java.util.EventListener. If it does not, and unless a specific BeanInfo is supplied, the event will not be discovered. addXXXListener(XXXListener aListener) removeXXXListener(XXXListener aListener)

The methods on the XXXListener interface itself depend on the semantics of the event, but the convention is that their signature is void <eventOccurenceMethodName>(<EventStateObjectType> evt);. It is important that XXXListener extends java.util.EventObject. If it does not, and unless a specific BeanInfo is supplied, the event will not be discovered. An example of an event is the JavaBean java.awt.Component, which raises events when the mouse moves over it. The listener interface, java.awt.event.MouseMotionListener, implements the following two methods: void mouseDragged(MouseEvent evt);

void mouseMoved(MouseEvent evt);

To add a mouse listener, the java.awt.Component has the following two methods: public void addMouseListener(MouseListener evt); public void removeMouseListener(MouseListener listener);

The second style of event is generated by a JavaBean when a property value changes. An example of this is the 'enabled' property on javax.swing.JButton. A property that fires an event when its value is changed is known as a bound property. Instead of having a separate listener interface for each bound property, there is a generic listener interfacejava.beans.PropertyChangeListener which has a single callback method void propertyCanged(PropertyChangeEvent evt);The argument PropertyChangeEvent has three methods that can be queried by the receiver of the method:

String getPropertyName() Object getNewValue() Object getOldValue()

The name of the property that was changed on the JavaBean that caused the event fire The new value of the property The value of the property before it was changed

To register interest in a JavaBean's property changes there are two methods: void addPropertyChangeListener(PropertyChangeListener listener); void addPropertyChangeListener(String propertyName, PropertyChangeListener listener); The first of these methods is always present on a JavaBean that has bound properties. However, the second is optional and depends on the style of event registration used by author of the JavaBean. For example, AWT components use the first style of property change registration, while Swing components use both styles. To use an event there are three objects: 1. The JavaBean that raises the event ( the source ) 2. The class that receives notification from the source ( the listener ) 3. The class that implements the logic that occurs when the listener is called back. Usually the last two are combined, so that the class that executes the logic either implements the listener interface directly or uses an inner class. The styles of code that the visual editor for Java recognizes and generates are covered in the section on Event Code Generation.

Adapter classes Many listener interfaces have more than one callback method. An example is java.awt.FocusListener that has two methods; focusGained(java.awt.FocusEvent event) and focusLost(java.awt.FocusEvent event). When creating a listener class that implements the interface the Java compiler insists that all of the interface methods are implemented, which often results in many empty methods being created to satisfy its requirements when only one or some of its methods actually contain code. The following statement shows a FocusListener being used to perform some logic when a Java bean gains focus. However, an empty focusLost method must be provided.

javaBean.addFocusListener(new java.awt.event.FocusListener() { public void focusGained(java.awt.event.FocusEvent e) { doFocusGainedCode(); } public void focusLost(java.awt.event.FocusEvent e) { } });

To avoid having many empty listener methods for many listeners, Adapter classes are provided. These implement the listener interface, and provide empty no-op implementation of its methods. The advantage is that the listener can extend these, and only specialize methods of choice without having to provide default implementations for the rest ( these are inherited from the Adapter ).

javaBean.addFocusListener(new java.awt.event.FocusAdapter() { public void focusGained(java.awt.event.FocusEvent e) { doFocusGainedCode(); } });

pplet is a java program that can be embeded in a web page,i.e it is a program that can run on Html web page,where is frame is an application that run on local machine.

Applet : Its an Program used to work with Internet Basis ... As its is Embeded in an Web page ... To work with Applet we need a Browser ... Appliacation ... This is a Stand alone Application to fulfill any task ..These type of applications cannot be used for Internet purposes ... To Exeucute an Application we need an Intrepreter called ... java filename that'sit

Those classes are common extension points for Java UI designs. First off, realize that they don't necessarily have much to do with each other directly, so trying to find a relationship between them might be counterproductive. JApplet - A base class that let's you write code that will run within the context of a browser, like for an interactive web page. This is cool and all but it brings limitations which is the price for it playing nice in the real world. Normally JApplet is used when you want to have your own UI in a web page. I've always wondered why people don't take advantage of applets to store state for a session so no database or cookies are needed. JComponent - A base class for objects which intend to interact with Swing. JFrame - Used to represent the stuff a window should have. This includes borders (resizeable y/n?), titlebar (App name or other message), controls (minimize/maximize allowed?), and event handlers for various system events like 'window close' (permit app to exit yet?). JPanel - Generic class used to gather other elements together. This is more important with working with the visual layout or one of the provided layout managers e.g. gridbaglayout, etc. For example, you have a textbox that is bigger then the area you have reserved. Put the textbox in a scrolling pane and put that pane into a JPanel. Then when you place the JPanel, it will be more manageable in terms of layout.

Posted 28 January 2010 - 04:45 AM

e: what is the difference between applet and Japplet

When java was first being created they made the AWT which is based off of C. Later on they brought in something called Swing which was created entirely by java. Swing is a little more flexible in some peoples eyes and is used by JApplet as opposed to AWT which is used in Applets. Applet = AWT JApplet = Swing Class

1. Frame is part of java.awt package and exists since JDK1.0. JFrame is part of javax.swing package and exists since JDK1.1.3 or something. 2. Frame extends Window. JFrame extends Frame. 3. You can directly add components to Frame. You add components to JFrame.getContentPane(). 4. JFrame implements javax.swing.RootPaneContainer and javax.accessibility.Accessible interface. Frame does not. By virtue of that JFrame gets all the benefits that you get from JRootPane using a delegation model. e.g. you can set the border on ((JComponent) JFrame.getRootPane()).setBorder(...) 5. JFrame directly supports javax.swing.JMenuBar. 6. JFrame supports setting of close operation.

JFrame extends Frame as a root for Swing applications. It introduces a basic infrastructure for the swing component hierarchy, menus, tooltips etc. and establishes smart repaint strategies (lightweight rendering) for them.

Vous aimerez peut-être aussi