Develop Reference

LWJGL java.awt.HeadlessException thrown when making a JFrame

Hi I'm working on a group project and the code works on my teammate's PCs but I keep hitting MacOS specific errors. And this time I seem to be stuck (no easily Googleable answer).
In a previous post I discovered I need "-Djava.awt.headless=true" as VM setting to properly run my simulation. Now when I try to spawn in some JFrame they are all met with a lovely "java.awt.HeadlessException" Exception because of that VM flag.
Trying to achieve
I want to be able to spawn those JFrames on my MacBook also.
The problem
I need -Djava.awt.headless to be both true and false at the same time for my program to run properly on Mac. Which if I understand my problem correcly, means I have a big problem on my hands.
EDIT: running it in a VM on my Macbook allowed me to run the project properly. This is far from an ideal fix. I'm still searching for a solution to this obscure problem.
What I tried
not running with the VM option: the problem described in previous post occurs. Thus this is not a viable option
running with the VM option: this throws a -Djava.awt.headless when creating a JFrame.

The best way to fix this may be by going back and solving your original problem a different way.
You must make sure that you are not initializing your BufferedImage in the main thread (GLFW thread), it MUST be done separately. It is hard to tell from your original question, but that looks like part of the cause there. Start a new thread to do the image processing instead.
See my solution and recommendation at the bottom of this answer for a quick summary, and also see here for someone else that had the same issue: Java Creating Instance of BufferedImage Freezes Program
A quick note on why your code works on Windows and not Mac: that is because both OS often run different implementations of openGL, and typically Mac can lag behind and miss out on a bunch of updates/changes that may solve problems like this one so that it doesn’t freeze when initializing a BufferedImage on the openGL thread.
If the above didn’t work then lets first look at what headless mode is. (Emphasis mine):
See link at bottom for full article and more info.
Headless mode is a system configuration in which the display device,
keyboard, or mouse is lacking. Sounds unexpected, but actually you can
perform different operations in this mode, even with graphic data.
Where it is applicable? Let's say that your application repeatedly generates a certain image, for example, a graphical authorization code
that must be changed every time a user logs in to the system. When
creating an image, your application needs neither the display nor the
keyboard. Let's assume now that you have a mainframe or dedicated
server on your project that has no display device, keyboard, or mouse.
The ideal decision is to use this environment's substantial computing
power for the visual as well as the nonvisual features. An image
that was generated in the headless mode system then can be passed to
the headful system for further rendering.
So when should headless mode be used:
On a machine that has no display device, keyboard, or mouse.
That is not you is it? However if that is you (LWJGL?), then lets look at how you can work with headless mode:
An image that was generated in the headless mode system then can be
passed to the headful system for further rendering.
This means that you should have a special piece of headless code that does your headless image stuff, but then passes the image back to a normal JFrame with a head.
So why does it fail for you:
Many components are affected if a display device, keyboard, or mouse
is not supported. An appropriate class constructor throws a
HeadlessException
Button
Checkbox
Choice
Dialog
FileDialog
Frame
Label
List
Menu
MenuBar
MenuItem
PopupMenu
Scrollbar
ScrollPane
TextArea
TextField
Window
Solution to the problem:
some classes, such as Canvas or Panel, can be executed in headless mode.
Perfect, so we just need to be careful what is used in headless mode. You asked how you can both use and not use headless mode, well rather than globally setting headless mode with VM option -Djava.awt.headless you can do it programmatically within your code using System.setProperty("java.awt.headless", "true"); where needed. A JFrame should be normal (not Headless), but you can spawn a JPanel as headless without issue.
I recommend:
You create a normal headed main thread with no VM option that spawns JFrames, and then use that main thread to spawn a new child thread and set your LWJGL bits in that thread to be headless, and that way you can run your LWJGL code without issue, and at the same time you can still have JFrames from your main thread. Remember to make sure that the Buffered image is not done in the main LWJGL/OpenGL thread.
Headless info source:
http://www.oracle.com/technetwork/articles/javase/headless-136834.html

focus-follows-mouse with [some] java applications doesn't behave as expected

Environment: Windows 7, JRE 8.65, observed with both yEd 3.14 and GanttProject 2.7.1 (also previously observed on Win XP.)
Can the program's main window take focus (not auto-raise) without being atop other windows and without clicking in it? (nothing found in 917 results from a StackOverflow search on the words "Java" "window" and "focus", though I was getting bleary-eyed by the end.)
The problem is that when I move the pointer into or across the program's window, that window does not activate, though it activates the icon in the "task bar" (which is auto-hidden.) It is clear that the program recognises the pointer's existence and focus change, but the main window never actually takes the pointer (i.e. the main window remains inactive, and requires that I click in it to activate it; which raises it, which is exactly the behaviour I try to avoid with F-F-M.)
This is more troublesome because when the icon in the task bar activates, the task bar covers a chunk of my screen and won't go away until the main program window is activated by clicking in it. Simply moving the mouse from one place to another on the screen has about a 30% probability of touching (and half-activating) one of these program windows, forcing me to locate the window, click in it, minimise it, then get back to what I really was trying to do. (Yes, my "desktop" is a jumble, but everything has its place and normally I can rapidly navigate among the dozen or so windows that are truly useful.)
Thanks for any pointers or advice. (Though suggestions that I change my behaviour probably won't be followed.)

This problem occurred to me as well. The only workaround I got so far is using JRE 6 if possible since this annoying behavior started with JRE 7.

Memory leak of LightweightFocusRequest in KeyboardFocusManager?

I'm seeing a memory leak in a java swing application. It's leaking LightweightFocusRequest objects connected under a HeavyweightFocusRequest in the DefaultKeyboardFocusManager. The application runs in an undecorated, alwaysontop JFrame. (i.e. full-screen).
The application appears to have focus. Users can click on it, and interact (all via mouse as it's a kiosk w/o a keyboard). But each interaction that produces a focus request such as showing a dialog, etc, leaks the LightweightFocusRequest object.
I was able to determine this via a heap-dump and the Eclipse Memory Analyzer tool. As a workaround, if the application is switched out of fullscreen mode and the user clicks on another app, and back on our app, then the leaked memory is reclaimed as the outstanding focus request events are all cleared.
It's acting as if the java application missed a focus gained event.
I've seen this problem under Windows with jre version 1.6.0_35 (and _27). Not all users suffer the issue, so I don't know what other factors contribute. I also can't say for sure that it happens or doesn't happen under the latest 1.7 JRE, as the JRE versions used are beyond my control. The majority (90%+) are 1.6.0_20 to 1.6.0_39.
All attempts to reproduce the problem have failed.
My next strategy as a workaround is to add a check in the application on a timer to examine the focus request queue via reflection. If it looks like it's leaking (100+ outstanding items?) then create another window, give it focus, re-request focus and close the other temp window.
Has anyone seen a problem like this before or have a better workaround? My searching for something similar in the java bugdb and google wasn't fruitful.

Unloading dll rxtx before exit to avoid jvm crashes or hide hs_err_pid.log files

Well, I'm on a project that uses rxtxSerial.dll (very buggy by the way).
Anyway, I made a modification on the GUI to make it more user-friendly, initially the program shows up the main window and it's possible to open some other frames where the user can monitor certain devices designed by the company I work for. So when the user wanted to close the hole program and any windows where openend it showed up a dialog asking for the user close the oppened windows himself and then close the program, that was really ugly so I thought: let's make it better; and that's what I made:
when JDialogs that use serial communication are opened I just save a reference for it for future use if the user prompt to close the program than before exit, the program performs the following code to ensure that the respective listeners are called like stop reading from the serial port:
for (Window w : openedWindows)
{
w.getToolkit().getSystemEventQueue().postEvent(
new WindowEvent(w, WindowEvent.WINDOW_CLOSING));
}
The program doesn't crash when the dialogs are closed by the user so there is no problem on the WindowListeners that are responsible for shuting the communication down, and sometimes it crashes when prompt to close while online windows are oppened (in serial communication aspect), actually the crash itself is not visible for the user (just if he look into program's folder the hs_err_pid.log files) and happens about 20% of the closes with online windows. The crash in hs_err are like: siginfo: ExceptionCode=0xc0000005, writing address 0x17adfa88 so what I suppose it's happening is that the dll tries to write to java's memory after it was already closed so the jvm crashes (correct me if I'm wrong).
What I want is a way to not generate those error log files, it can be made fixing the problem or just a way to hide those files, if possible that I thing the answer is not.
One of the possible fixes I thought possible is to force unload the dll before shutting down the jvm itself or "ask for" unload the dll and wait until it's unloaded.
Any ideas?
Thanks in advance.

Solved my problem migrating from rxtx to jSSC: http://code.google.com/p/java-simple-serial-connector/
Now everything is working smooth! Integrated dlls into .jar for Windows, linux, mac and solaris with system auto-detection.
saved my a lot of work!
Still have no clear reason for those crashes.

Display another modal dialog box on top of other modal dialog boxes in Java

I have a rather strange question:
I have a Java application which uses "applications" (plugins) run in different threads.
Most of these plugins will be written by other people and I will have no control over the code. The application requires a permanent connection to the Internet as information is constantly transferred between the server and app. What I want to do is have a thread which runs in the backround checking to see if there is a Internet connection. If the connection drops I want the ENTIRE application (and all its threads) to pause, display a message and when reconnected resume. I want this dialog box to be displayed above all other dialog boxes (modal or not). I'm thinking of something like the Windows Vista User Account Control Alerts.
How can I do this?

To solve this at all reasonably, you need to use Java 6, as previous versions simply don't give you the granularity of modality you need.
Here are the modality options.
For this to work effectively, you would have to have each plugin honor a contract to not use Toolkit modality (the default behavior is that a modal dialog box locks everything up, to keep backwards compatibility). Application modality would seem to be a great fit for you, but I don't see that you can implement this in Java. This seems to be up to the JVM vendor, as far as I could find.