I am writing an application with GUI using Java Swing drag-and-drop in NetBeans IDE. But when I add a component in a small space, it looks correct in the design preview but when I run it, the size is different.
As you can see in the picture, windows 1 and 2 are the same, but when I run the code, the gap on the right side is different (3). Why is that?
I am writing the code in java 8 (1.8.0_05-b13).
This is probably a consequence of the look-and-feel used in the preview as opposed to the actual execution. Try executing the following at the start of your program to set the LaF to the system one (windows-looking one on Windows):
UIManager.setLookAndFeel(
UIManager.getSystemLookAndFeelClassName());
You'll want to catch and handle UnsupportedLookAndFeelException, ClassNotFoundException, InstantiationException, and IllegalAccessException.
Related
I'm working on a Java Swing project,
I have an issue with some component while running projects vs running the interface here's some screen shoot :
This look when I run only the jFrame
This is when I run A Frame that lead to this
and this when i run the full project
I want to know why this look difference and how to resolve it.
I'm Using netbeans 12.2 with jdk 15.0.2 on a windows 64 bit machine
Java Swing by default uses native GUI components. The upside of this is that when done correctly, your Java application will have a Windows style on Windows and a Linux on Linux etc. To get a fixed style, you can set the Java Look And Feel to a LAF that is always available, such as the built-in METAL LAF. This page contains much more specifics on Java Look And Feels, how to set them and even how to create your own if you wish.
I have gone through
Setting java.awt.headless=true programmatically
http://www.oracle.com/technetwork/articles/javase/headless-136834.html
and
Some other links too.
Nowhere it is explained the benefit of using this flag.
Is it a performance benefit? If yes, is there even a rough quntization how much performance benefit there will be? (I know that answers to performance questions totally depend upon case to case, but it would be nice to know if someone reported a good benefit from doing this).
There is no performance benefit of setting java.awt.headless=true if you're not using AWT features. AWT features are loaded on-demand.
As explained in the linked article, headless mode is useful for accessing some Java graphics features which are normally delegated to the graphics host:
After setting up headless mode and creating an instance of the headless toolkit, your application can perform the following operations:
Create lightweight components such as Canvas, Panel, and Swing
components, except the top levels
Obtain information about available fonts, font metrics, and font settings
Set color for rendering text and graphics
Create and obtain images and prepare images for rendering
Print using java.awt.PrintJob, java.awt.print.*, and javax.print.* classes
Emit an audio beep
For example, in headless mode you can create and write image files:
BufferedImage img = new BufferedImage(200, 100, BufferedImage.TYPE_INT_RGB);
Graphics2D g = img.createGraphics();
g.drawLine(80, 30, 120, 70);
g.drawLine(80, 70, 120, 30);
ImageIO.write(img, "png", new File("image.png"));
When run with -Djava.awt.headless=true, will produce an image file:
When run with -Djava.awt.headless=false (and without an X window server) will throw an exception instead:
java.awt.AWTError: Can't connect to X11 window server using ':0.0' as the value of the DISPLAY variable.
Note that the JVM contains heuristics that determine the value of java.awt.headless if it's not explicitly set. For example, on Linux if the DISPLAY environment variable is not set, java.awt.headless automatically becomes true.
Headless and non-headless modes are different, they have different set of features. If you only need to do some simple things like font rendering then yes, you will be able to do it in headless mode.
You can always check the guts of the JDK sources and see for yourself, what methods are dependent on non-headless mode. But in my opinion, even if the performance gain is negligible, it's best to pass java.awt.headless anyway (if you do not need "full" GUI mode).
Any vendor can use this property. You never know if they are going to do something if you have the full GUI. So, my rule of thumb is: always use java.awt.headless for the console apps and the servers. It won't harm.
One possible benefit is that if you are invoking the application while trying to do something else in a window perhaps invoking the application multiple times, it will not disrupt your keyboard/mouse focus if the application runs in headless mode.
At least on a Mac I have had huge problems running a script which repeatedly runs a java app every few seconds while trying to edit in another window. Headless mode fixes that.
Headless mode is mainly useful in those systems that don't have a graphical display, typically the servers.
Many applications use graphical displays to do things that are not necessarily needed to be seen, for instance drawing an image and then saving it to disk.
if you run such a program on a server (ssh connections only, no graphic endpoint), you get an exception when in default mode, while you get the program ran when you enable the headless mode.
Headless mode essentially means virtual display, the graphical components do their operations on a generic/transparent display interface, eg, they draw a circle on a grid, then the result is either actually displayed, when in headed mode, or it is treated differently in headless mode, eg, the grid is a memory object, which is changed so that it would represent the drawn circle on a real display, the same grid can be used for tasks like saving everything as an image file.
As suggested by one of the comments, Oracle has a number of details about it.
As I run Java programs (like DbVisualizer and OpenProj) on my computer, some UI components like buttons, images, check boxes, scrollbars, etc. show as blank boxes. Not rarely some of these components first appear normally when you open the program and then go blank as you mouse over them.
I have already updated JRE and video drivers and also tweaked JAVA_OPTS with -Dsun.java2d.noddraw=true;-Dsun.java2d.d3d=false;, as recommended in Java forums, but none of these proposed solutions have worked so far.
I don't believe this is an OS specific issue, since I checked some other PCs with the exact same configuration of OS (Windows Vista) and hardware and many of them don't present that problem.
A screenshot of this situation can be seen here:
Any ideas?
Those JAVA_OPTS must be separated by spaces and not semi-colons!
Connect to the application with jVisualVM and verify that the "JVM Arguments" section contains all your desired options.
While using windows basic theme I would often find numerous graphical glitches. Moving a window would create a trail behind itself over background windows and UI controls at times would not appear until moused over.
As already suggested, try using the windows aero theme and just turn off transparency if you don't like the aero look.
This does seem more like a graphics driver issue. Note how things that are missing are images (icons, checkboxes) which are drawn by transferring the bitmap data directly to the graphic card. The sun.java2d.noddraw=false and sun.java2d.d3d=false are more of a hacks in this case, really.
What I would do is:
check if I am using the latest version of Java (wouldn't hurt to switch to a 64-bit java if you are using a 64-bit system)
check your graphics drivers, make sure they are the latest version
check Windows service packs
Also try using changing the Look and feel; maybe this will help.
I suspect that disabling DirectDraw will fix this and your attempt to disable it was unsuccessful.
As noted by Ryan, the options appear to be formatted incorrectly. Remove the semicolons and put a space between, or better still, only use sun.java2d.d3d=false. The sun.java2d.noddraw flag was obsoleted Java SE6u10 and setting to true now has the same effect as setting sun.java2d.d3d=false. There is no need to set both.
The effect of the incorrect formatting can be seen in the code below:
public class WrongArgs {
public static void main(String[] args) {
System.out.println("sun.java2d.noddraw: " + System.getProperty("sun.java2d.noddraw"));
System.out.println("sun.java2d.d3d: " + System.getProperty("sun.java2d.d3d"));
}
}
Running this code with args: "-Dsun.java2d.noddraw=true;-Dsun.java2d.d3d=false;" produces:
sun.java2d.noddraw: true;-Dsun.java2d.d3d=false;
sun.java2d.d3d: null
Running with args "-Dsun.java2d.noddraw=true -Dsun.java2d.d3d=false"
sun.java2d.noddraw: true
sun.java2d.d3d: false
In my Java application I have a window which holds a JTextArea within a JScrollPane with scrollbars policies set to AS_NEEDED.
As I run my application I see that JTextArea this way:
Why am I seeing the scrollbars with that cutaway knob (which doesn't reflect a "standard" representation like this)?
The Layout for the frame is GridBagLayout, and I'm on Mac OS X 10.8.2, should that matter.
This is based on the Look and Feel your app is using, and the limitations of Java's integration with the native OS layout components. The one in your screenshot looks like Nimbus.
Swing applications always custom-render the look and feel, and don't do a very good job of using the native OS widgets everywhere. The result is that you get weird looks that might be consistent the OS only some of the time, or only with certain layout components.
Welcome to developing cross-platform desktop apps in Java. :(
To attempt to get the system look and feel when your application starts you can do this:
try {
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassname());
} catch (Exception e) {
// Handle exception
}
This will set the look and feel to that of the system regardless of what you run it on.
And as mentioned, the default look and feel for your application appears to be Nimbus and not OSX's Aqua, which again can be fixed with he above snippet and you could (should you care to) offer a UI option to the user to change the look and feel of the application to whatever they chose.
You are with Nimbus LookAndFeel
http://docs.oracle.com/javase/tutorial/uiswing/lookandfeel/nimbus.html
I am building an application in java swing and I am using the following code to give the UI a native OS look
try {
UIManager.setLookAndFeel(
UIManager.getSystemLookAndFeelClassName());
} catch (Exception e) {
e.printStackTrace();
}
On a OS X, the look is fine, but on windows (XP and 7) the buttons look like this.
alt text http://img710.imageshack.us/img710/8735/buttonsoc.png
I have used this exact same code on other projects and it works fine. But in this particular project I get a completely different look.
I am using Java 1.6
Thanks in advance!
Are you possibly creating your GUI elements before actually setting the L&F? If you already created (e.g.) JButton instances and called methods on them, they allocate their UI peer - changes to the L&F after that won't affect the already created instances.
This would explain why it works on Mac (the L&F defaults to Mac on Apple's JVM IIRC), but not on Windows. You can test this quickly if you move setting the L&F directly into your main method as the very first call (this assuming your main class does NOT contain any statically initialized GUI instances of course).