How JFrame is light weight? - java

JFrame is Extending Frame. Then, How JFrame is lightweight but Frame is heavyweight?
I red this article but still i didn't get how JFrame achieves its lightweight property?
I got from here that JFrame is heavyweight but other Components starts with J* are lightweight. How other Swing components achieves this. I need bit of technical details.

Technically it's not. Both are heavy weight components, but because JFrame has been setup to support the JRootPane, which contains the content pane (and possibly) the glass pane (as well as the JMenuBar), it is consider "light weight", because it's been deliberately configured to support light weight components
Essentially JFrame and JWindow have been modified as light weight containers that support light weight components

it is still a heavyweight component because it(JFrame) inherits from the Frame.And it is not belong to the JComponents which is lightweight components.
Heavyweight means each Java component has a native peer associated with it. A native peer is an OS-specific component... AWT is heavyweight, so if you create a AWT Button, on the Windows platform an MFC button is created, on *nix a Motif button is created, etc.
Lightweight means that there is not a native peer associated with the java component. This is done by having only the top-level component be heavyweight and all the lightweight components are drawn on to it. Swing is lightweight.
Of course, AWT and Swing are specific to standard Java (J2SE). Under J2ME it depends on what sort of device you are using. If you are using a more powerful device, like the Sharp Zaurus, then you have AWT and functionality pretty close to J2SE levels. If you have something like a Java-Enabled cell phone, you don't have all the capabilites that you need for a fully featured GUI, so there are special libraries used for making these applications. You'd need to look at the APIs provided by the device manufacturer most probably.

JFrames are heavyweight, since it's impossible to create a task-view-level window in most OS without creating a "heavy" AWT window. Lightweight components can replace internal widgets with java-based stuff that doesn't require JNI calls, but windows are the special case. JFrame does let you do custom renders, though. Also, if you're using other lightweight stuff, then I suggest using JFrame as well since it makes the rendering more efficient overall than mixing light and heavy components.
It is still a heavyweight component because it(JFrame) inherits from the Frame. And it is not belong to the JComponents which is lightweight components.

Related

How to get Node handle in javafx8

We're building a JavaFX application in Windows.
I've tried to use JNA Native.getComponentPointer() method which works with java.awt.panel, but I can't figure out a good way to do this with a javafx.scene.layout.Pane
Does anyone know of any way to do get hWnd for a Pane ?
Unfortunately, I do not think that this is possible with JavaFX. The only thing that I can see that has a native peer is the Stage. You can verify this yourself by using a ui analyzer tool, such as WinSpy, or "inspect.exe" or "visualuiaverifynative.exe" from the Windows SDK.
From Mixing Heavyweight and Lightweight Components by Oracle:
There are two kinds of graphics components in the Java programming language: heavyweight and lightweight. A heavyweight component is associated with its own native screen resource (commonly known as a peer). Components from the java.awt package, such as Button and Label, are heavyweight components.
[...]
A lightweight component has no native screen resource of its own, so it is "lighter." A lightweight component relies on the screen resource from an ancestor in the containment hierarchy, possibly the underlying Frame object. Components from the javax.swing package, such as JButton and JLabel, are lightweight components.
In this case, JavaFX is just like Swing; a lightweight toolkit where the various ui components are all written in Java and do not have a native peer.
As far as my reading of the doc goes, there is a 1:1 relationship between an hWnd and a window object. Panes and Nodes aren't Windows, so trying to get an hwnd specific node doesn't seem to make a lot of sense.
The most you could ask for is the hwnd of the window containing the node. See:
How can I get the window handle (hWnd) for a Stage in JavaFX?.
Applying the function from the answer to the linked question gets:
Pointer hwnd = getWindowPointer(node.getScene().getWindow());

Why are JFrame, JDialog, JApplet (from JRootPane) heavyweight

I know why these components are called heavyweight components. What I'm really interested in is why they were not implemented as lightweight. Thanks
These components are windows of different kind. If you want to create a window in the operationg system you need to call some OS native code, because there is no way to do it in Java. More than that, all the user input events (mouse, keyboard, etc) are dispatched by the OS to the appropriate OS window. Java components listen to these events in the native code and send them to the java level via JNI. To sum up: it is just impossible to do them lightweight.

How does a Swing code turn into a real graphical application

This question might not seem very technical but, out of curiosity,I want to know that:
How does bare/raw Swing code written by me, turn into a wonderful graphical application?
For example:
Like when we make a JFrame visible, or when we place a JButton on it. Who makes it happen? OS or Java or JVM.
Who makes the colors come up?
What is the process going on behind the scenes?
I ask this maybe because its the first time in my life that I made a RealWorld graphical application and these questions popped up in my mind!
Thanks in advance!
In Swing, all the GUI components are written entirely in Java and are rendered using Java. For example, JButtons would be drawn by Java and not by any internal OS stuff. Thus, Swing components are called "light-weight components" because they are managed and rendered by Java instead of by the OS (or any native widget toolkit).
Note that Java also has a toolkit called AWT. Swing is based on nested and inherited methods from AWT, except that it creates native widgets using the OS.
So at some point, Swing will have to create a window on the screen and draw on it. The magic that actually creates the window is handled by AWT. Notice that JFrame extends from java.awt.Frame which means that although JFrame may be rendered mostly by Java, it is backed by a heavy-weight native OS window.
In short, there's an AWT toolkit, which is the layer that does all the window management and drawing. It is calling native platform specific code inside the JVM. It is also responsible for java2d drawing. It can use accelerated directx or opengl pipelines.
Swing is developed on top of it. Swing actually draws every button and every object with plain java code. The drawing is handled to a current look and feels that decide how to draw components. So you can override their paint methods, and add some extra things without any problems.
Metal and Nimus LaF are 100% java2d drawn, so inside of them you will find things like drawRectangle and drawLine to draw components. Native look and feels, like windows, gtk, access current operating systems theme to draw something that looks similar to native widgets. That is why they do not always look like native applications.
There are also other gui toolkits for java, like SWT, used, for example, in Eclipse. What it is doing, is getting the window from the AWT, and then putting 100% native widgets on it. It is much better integrated with the OS, looks better, works faster, uses less memory. But with it, you'd have to distribute your application with os specific native libraries and it is less customizable, compared to Swing.
I don't know all the details, but the actual graphics are displayed/rendered via the swing/awt packages through the JVM itself.

UI Change in Swing application across platforms

My Swing Application's GUI is built using Window Builder Pro GUI editor. Layouts used are MigLayout and AbsoluteLayout. Application is developed using Windows Machine, So UI is well aligned and neat in Windows, but when I run the same application in Mac OS X, Application's Frame couldn't accommodate the components inside its bounds. I mean, size of Components inside the frame changes across platforms. When I give extra space(Increased frame bounds), it looks nice in Mac but weird in Windows. Is there any way to have Frame or Panel to grow with respect to its contents or Components.
Don't use the absolute layout. Layout managers are used precisely to avoid the kind of problems that you're facing.
Assuming you used AbsoluteLayout because none of the existing layout managers suited your needs,
Have a look at Creating a Custom Layout Manager and use one instead of AbsoluteLayout.(Before that make sure none of the present layout managers suit your need)

Any way to embed a Swing JFrame in the AWT Frame from the SWT_AWT bridge?

I'm integrating a Swing application into an Bioclipse/Eclipse plug-in, and since Eclipse uses SWT, I have to use the SWT_AWT bridge somehow.
The problem is that the starting point I get from the SWT_AWT bridge is an AWT Frame, like so:
java.awt.Frame awtFrame = SWT_AWT.new_Frame(composite);
... (which can be filled with AWT components), but the situation is that the Swing application contains much of it's functionality in it's main JFrame component. Now, a Swing JFrame can not be integrated as is into an AWT Frame.
Refactoring of the original Swing application has been discussed with the developer of the original application. Just wanted to make sure we didn't miss any obvious workaround for this?
This is an excellent article on how to use Swing inside your SWT/RCP apps. This should be helpful.

Categories