What is the 'J' in JFrame in Java?
The J identifies all Swing components.
Swing used to be marketed as Java Foundation Classes, before it became an integral part of the JDK.
Joachim Sauer's answer is correct. Read on only if you need more in depth overview of the various Java GUI approaches and evolution.
First Java GUI was (is) called AWT (Abstract Window Toolkit). AWT is a very simple tool kit with limited GUI components, layout managers, and events. An example of an AWT class is java.awt.Frame.
Then a more complex solution was developed by Sun -> JFC Swing (Java Foundation Classes, a.k.a. Swing). In Swing, Sun created a very well-engineered, flexible, powerful GUI tool kit. Unfortunately, this means Swing takes time to learn, and it is sometimes too complex for common situations. Swing is built on parts of AWT. All Swing parts are also AWT parts. Swing uses the AWT event model and support classes, such as Colors, Images, and Graphics. An example of a Swing class is javax.swing.JFrame. Here you see your "J" which prefixes all Swing GUI components.
SWT is a low-level GUI tool kit comparable in concept to AWT. JFace is a set of enhanced components and utility services to make building GUIs with SWT easier. The builders of SWT learned from the AWT and Swing implementations and tried to build a system that had the advantages of both without their disadvantages. In many ways, they succeeded.
Note that both, AWT and Swing, are part of the J2SE package. While SWT is a separate third-party library which grew up with the Eclipse IDE (org.eclipse.swt).
This overview was taken from http://www.ibm.com/developerworks/grid/library/os-swingswt. See that link for more detail.
It is a naming convention for all Swing GUI components: JPanel, JLabel, JTextField, JCheckBox...
All of the swing things are named that way. JFrame, JLabel, JButton, JTextField, etc.
Related
I'm developing on a legacy Java desktop application mixing Swing and AWT controls. I can successfully apply the system look and feel to Swing controls of course, but can I do the same for AWT ones? If not, can I implement some bridge in any way?
The basic answer is "no". The AWT components are backed by native OS components, either directly (via OS supplied libraries) or indirectly (via AWT based native components). It's possible that AWT will be linked to "older" component libraries so some of the components won't match the current OS "look and feel", which will be using newer component libraries.
In either case, you can't effect how these components look (and certainly not through Swing's Look and Feel API).
Ok, this might be a little hear say, but The Story Of Awt says "Java's GuiToolkit had to use the native widgets provided by the host window system, whether Windows, Motif, or the Mac. Mimicking the look-and-feel in Java wasn't good enough; it had to be the real native components."
I've got a question today and would like to know which would be better to use in Java development. Which would be better to use: Java Swing OR Java Applet. I am new to Java development and have been confused between the two.
If you were creating a game which would be better to use.
Which is better to understand and uses less lines ect.
Which is light weight?
Any questions would be awesome!
Java Swing OR Java Applet
There is some confusion here.
AWT has Frame for desktop applications/Applet for applets.
Swing has JFrame for desktop applications/JApplet for applets.
Other matters:
AWT/Swing. Why AWT rather than Swing? See this answer on Swing extras over AWT for many good reasons to abandon using AWT components. If you need to support older AWT based APIs, see Mixing Heavyweight and Lightweight Components.
Applet vs. application. Why code an applet? If it is due to spec. by teacher, please refer them to Why CS teachers should stop teaching Java applets.
Many of the components in javax.swing.* have made other still accessible JDK components obsolete, such as AWT. Swing is actually built on top of AWT, and is a large improvement in performance, features, and usage over AWT.
This tutorial on custom graphics with Swing may help:
http://www.ntu.edu.sg/home/ehchua/programming/java/J4b_CustomGraphics.html
As for Java Applets, these are unrelated to Swing in terms of normal application development. Java Applets are small applications that can run in a web browser.
Swing is a set of platform independent UI tools (JButton, JScrollBar, etc.). It guarantees that your user interface design will look the same on different platforms. An applet is an app that runs inside a browser or other hosted environment. An applet can use Swing UI, but doesn't need to.
Personally, I wouldn't develop a game in either if it's graphics intensive. If you want lightweight, I would suggest using JavaScript in Chrome's V8. Check out Chrome's developer showcase. They're doing amazing things with Javascript these days.
What is the difference between JPanel and JFrame and relationship to lightweight, heavyweight?
JPanel is container that allows to put several UI components together. JFrame is a window written using Swing.
All Swing components are so-called "lightwight" components because they are written in java. If for example you run Swing application and try to analyze it using UI analyzing tool (e.g. WinSpy in windows) you see only one element: the window (JFrame) itself. All other components are drawn from OS point of view.
Heavyweight API - AWT uses portable elements provided by OS. Since java must be portable among various operating system AWT is very limited. It implements only the minimal subset of screen elements supported by all platforms. However the AWT elements are mapped directly to the appropriate platform elements, so UI discovery tool will see them. These elements are named "heavy weight".
Heavyweight components like "AWT" components must be drawn using native GUI on a specific platform.
Where lightweight components like "Swing" components are drawn by java and don't rely on native GUI.
The basic difference between Swing and AWT is that Swing APIs are purely Java libraries i.e. they don't at all depend on the native libraries to draw graphical components. Because of this feature they provide a consistent look and feel on all platforms. AWT libraries require the support of native graphics libraries and some of their GUI components look different on different platforms. Moreover, Swing components are not inherently Thread safe, you explicitly have to write synchronized code to manipulate or redraw them whereas AWT components can be trusted in a multithreaded environment. AWT Components are called heavyweight components because of their dependency on native libraries. Swing components are called lightweight due to their independence of native libraries. Hence Swing operations are much faster because each and every operation is taken care by the Java runtime env and no delegation of events or commands to the native libraries is required.
A JFrame is a Swing container with an interface box, and can be a standalone application (it has the top box with abilities to minimize, maximize, and exit) whereas a JPanel is everything a JFrame is (a Swing container) minus the ability to be a standalone. For a JPanel to work, it must be inside something like a frame, like a JFrame.
The other answer has a good definition of lightweight and heavyweight components.
use:
I use JPanels within JFrames to easily run multithreaded programs that integrate together (I have a JPanel runnable class inside my class that extends JFrame, I run that as its own thread and the JPanel class can change the value of variables in the JFrame class). I use it to easily get different threads to interact with each other.
**You can have multiple JPanels within a JFrame.
I am looking into developing an Java GUI for a biological analysis tool. My question is, Can I use both AWT and SWING libraries under the same Model View Control design pattern? Or,are they two libraries controlled in a distinct way? I would like to know If I can bring them in under the same roof for purposes of reusing existing code written with both libraries. Thank you very much for your time.
Swing is built on top of AWT, you can mix Swing and AWT and it will technically work, but with some limitations:
heavyweight vs lightweight components: components in AWT are heavyweight - they correspond to a native OS window. This means that all AWT components appear above sibling Swing components. (E.g. put a awt List and a swing JList in the same container, and the List will always appear above the JList.)
Look and Feel: the AWT components look and feel native, since they are native components. The Swing components have a pluggable look and feel, which defines their appearance and behavior. If you choose the L&F to match the native platform, these components are only "immitations" of the native look and feel, and can behave differently from their AWT counterparts. (E.g. JButton vs awt Button.)
For these reasons, it might be wise to use just one UI library, presumably Swing.
EDIT: JDK 6 (Update 12) offers seamless integration of heavyweight and lightweight components, so mixing will work seamlessly. So the first point is no longer true - but having inconsistent look and feel between the two UI toolkits still stands.
Hi Yes you can use both. But there is no need, even more it is highly not recommended to mix these two.
For example you can have some serious problems as AWT doesn't have 'depth' concept. No different layers, etc. Other problems are for example, look of components of these frameworks differs.
EDIT:
I am loving this resource. Go ahead and read it there are all issues mentioned, with illustrative examples, which you have to be aware of when you are going to mix these two. http://java.sun.com/products/jfc/tsc/articles/mixing/
Oi,Boro.
In java, Swing has more features than the AWT components.
For example,
In AWT,
TextArea ta;
Button btn;
But its same in Swing as,
JTextArea ta;
JButton btn;
But swing component has good in look.
Then what's the need of AWT. Is there any useful feature?
Swing and AWT both provide user interface components, however Swing is built on top of AWT. It provides richer tools like icons, tool tips, etc. which are not available in AWT. Also, Swing is meant to be portable, while AWT (in theory) will match more of the system's look and feel.
Most IDEs that give you GUI building features (NetBeans, etc) will do so using Swing components. AWT is useful since it provides the foundation on which Swing is built.
More details here.
AWT is useful if you want truer O/S fidelity and can accept a lowest-common-denominator for widget support.
It's also immensely useful for building your own light-weight GUI on (suppose, for a game engine). For example, we needed a GUI system which would run on handhelds in JME PP 1.0 as well as desktops and thin clients, where we needed only a few basic components, but really minimal overhead, so I built a GUI toolkit which runs within an AWT Panel. It worked out really well.
AWT was the GUI package available in Java, then along came Swing, which was built on top of AWT in an attempt to make things look nicer and consistent across platforms. The problem is, they both look terrible. I am stuck with AWT in my project unfortunately, because it is a Windows Mobile project and our VM only supports AWT.
If you want a java GUI that actually looks nice (well nicer than Swing or AWT) then you want to check out SWT from IBM.
AWT was the first try on UI for Java, later Swing provided a better alternative because they use "light" components ( the component draw the UI them selves instead of relaying on native code ) and those light components were way lot flexible and maintainable then AWT.
AWT still has it's place as the underlying "technology" that interface Swing and the OS ( JComponent inherits java.awt.Container after all) , so, its place in the low level of UI. For instance, things like translucency, shapes etc. are placed in AWT package and they are used by Swing components.
New platform UI features will be added to Java in the following releases and many of them will be added to the java.awt. package.
AWT is still commonly used for applets! Most web browsers support AWT classes, so AWT applets can run without the Java plugin. Swing applets, however, require the Java plugin. Swing is not supported by older JVMs.
AWT is slighter faster because it uses native OS peer components, whereas Swing draws all its own components at the bit level. Swing components may not look and behave exactly like their native counterparts. AWT applications, however, will look like native apps and so will look different on different platforms. In contrast, Swing apps will look the same on all platforms (although this can be changed with code).