Thanks for your observation @kappa, it actually works, confirmed on Mac OS X Yosemite, however I'm also getting the same message that you got.
2015-01-02 12:44:59.969 java[1291:10205] [JRSAppKitAWT markAppIsDaemon]: Process manager already initialized: can't fully enable headless mode.
Just ignoring this, is working, thanks again for spotting it.
@spasi
I tried initializing AWT first by creating an instance of Toolkit with Toolkit.getDefaultToolkit(); When I create this before launching GLFW, GLFW asks me to use -XstartOnFirstThread, even though I was having that flag enabled. The solution for now is to use the headless mode, but initialize GLFW before any AWT things.
I spent a few hours trying to figure out what exactly is going on.
- With -Djava.awt.headless=true, AWT after GLFW works, but there's the warning message.
- With -Djava.awt.headless=true, AWT before GLFW does not work for two reasons:
a) The JVM sets the JAVA_STARTED_ON_FIRST_THREAD_<pid> environment variable when -XstartOnFirstThread is specified. AWT then detects it, sets an internal flag and removes the environment variable. When LWJGL checks it (on glfwInit), it's already gone. I think I can replace this check with an alternative implementation.
b) With the check removed, glfwInit fails with "No monitors found".
- Without -Djava.awt.headless, AWT after GLFW does not work. AWT initialization hangs because
isRunning returns NO (for reasons I don't understand).
- Without -Djava.awt.headless, AWT before GLFW does not work because AWT goes into embedded mode (calls it "SWT or SWT/WebStart mode") and when that happens it calls
NSApplicationLoad(). SWT knows about this and somehow injects its NSApplication implementation, so everything's fine. GLFW obviously fails to initialize properly.
- Without -Djava.awt.headless and with a very small fix inside GLFW, AWT before GLFW works perfectly. I could even have a GLFW window side-by-side a JFrame. Only limitation: any AWT windows must be disposed before GLFW, otherwise the AWT windows hang without an event loop.
Anyway, it's a freaking mess, I don't know why I'm still wasting time on this. This can only reliably work if we make changes to GLFW to work more like SWT.
On freetype, I had a quick look and it seems straightforward. It's a simple C API with great documentation. On font rendering in general, an alternative approach would be building everything you need offline (glyph metrics, kerning info, texture/vector data in a custom binary format) and not have to depend on AWT or anything else at runtime.