3

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.
Arno C
  • 470
  • 4
  • 18
  • 1
    *"I need -Djava.awt.headless to be both true and false at the same time for my program to run properly"* Why is the `false` state needed? You said it works on Windows. Why does it not show the same problem if both needing `true` & `false`? – Andrew Thompson Oct 30 '17 at 02:12
  • The true statement is needed to work with Buffered images on Mac (see previous post that I linked). But to spawn those JPanels, headless mode is not allowed to be true. EDIT: so the Windows teammates don't need to have the VM setting `-Djava.awt.headless=true` so they can indeed spawn JPanels. – Arno C Oct 30 '17 at 09:41
  • What version of MacOS and Java do you have? – sorifiend Nov 02 '17 at 23:54

1 Answers1

2

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

sorifiend
  • 5,927
  • 1
  • 28
  • 45
  • 1
    Thanks for the detailed answer. I'm currently working on a very time sensitive project so I'm not going to be able to try this out. I do assume this would fix my problem. The most cost efficient solution was to dual boot Ubuntu on my Mac. – Arno C Nov 06 '17 at 14:44
  • 1
    @ArnoC Another similar answer if you do not know how to work with threads: is to distribute two jar files. The first one could be a small normal/headed program that deals with JFrames, and the second one can be launched from the first and it can contain all your headless LWJGL code. You could use a Socket to communicate between the two Jar, or you could simply save the image to file and have the other open it. See here for some info on launching another Jar: https://stackoverflow.com/a/27790046/1270000 – sorifiend Nov 06 '17 at 20:37
  • 1
    "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" I guess one has to be very careful with timing / synchronization when doing this, as system properties are per VM, i.e. shared between threads. When you set `"java.awt.headless", "true"` on your LWJGL thread, other threads will see the changed value as well, if they read it at that time. – Suma Oct 14 '21 at 14:14