[FIXED] OSX / Java 7

[kappa]

@avm1979 hmm, seems like there are still a few AWT dependencies in LWJGL's OS X code (Sys.alert(), clipboard, obtaining available device resolution, etc), not a major problem as they can all eventually be replaced by equivalent Cocoa replacements, however its better to come back to this task later after we've sorted out some of the more serious issues (like the native crashes). In any event for now you should try to have a look at why JNF isn't being found by Java itself. A little online searching shows that JavaNativeFoundation is a required dependency for Oracles Java 7 on OS X, so you'll need it in any event, this snippet comment below says a bit more:

JavaNativeFoundation is only present in /System/Library/Frameworks/JavaVM.framework/Frameworks. There is no private copy in OpenJDK, and OpenJDK itself relies on the version in /System. It's full and proper Mac OS X API.
...
You shouldn't have any problems by just using the built-in system one. It's system API, just like Foundation and AppKit.

So do check your system, maybe you've moved this folder or something?

@abcdef - yup, those are used now in the build.xml
@mc78 - getting a warning with the new build.xml "[available] DEPRECATED -  used to override an existing property." so might need a little tweaking to to use newer ANT api.

[kappa]

Also looking further into the JavaNativeFoundation situation, its actually a framework that we shouldn't try to avoid, its there to help make working with Cocoa easier and will make LWJGL's OS X code a lot cleaner and smaller. Its a dependency that Apple Java 6, OpenJDK7, Oracle Java 7 all also depend on so no real harm in using it.

[ajr_1]

I dropped the latest version into my app, and it's giving the following exception:

Process:         java [5132]
Path:            /usr/bin/java
Identifier:      net.java.openjdk.cmd
Version:         1.0 (1.0)
Code Type:       X86-64 (Native)
Parent Process:  eclipse [2877]
User ID:         501

PlugIn Path:       /Library/Java/JavaVirtualMachines/jdk1.7.0_09.jdk/Contents/Home/jre/lib/server/libjvm.dylib
PlugIn Identifier: libjvm.dylib
PlugIn Version:    ??? (1)

Date/Time:       2012-11-06 11:22:15.551 +0000
OS Version:      Mac OS X 10.8.2 (12C60)
Report Version:  10

Interval Since Last Report:          170701 sec
Crashes Since Last Report:           8
Per-App Interval Since Last Report:  226 sec
Per-App Crashes Since Last Report:   6
Anonymous UUID:                      777A5CFF-5023-3FFC-8172-15FDEF497E3C

Crashed Thread:  24  Java: AWT-EventQueue-1

Exception Type:  EXC_BAD_ACCESS (SIGABRT)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000028

VM Regions Near 0x28:
--> 
    __TEXT                 000000010033b000-000000010034c000 [   68K] r-x/rwx SM=COW  /Library/Java/JavaVirtualMachines/jdk1.7.0_09.jdk/Contents/Home/bin/java

Application Specific Information:
abort() called

......

Thread 24 Crashed:: Java: AWT-EventQueue-1
0   libsystem_kernel.dylib        	0x00007fff8db39212 __pthread_kill + 10
1   libsystem_c.dylib             	0x00007fff88b25af4 pthread_kill + 90
2   libsystem_c.dylib             	0x00007fff88b69dce abort + 143
3   libjvm.dylib                  	0x000000010081a073 os::abort(bool) + 25
4   libjvm.dylib                  	0x000000010090882e VMError::report_and_die() + 2306
5   libjvm.dylib                  	0x000000010081b767 JVM_handle_bsd_signal + 1073
6   libsystem_c.dylib             	0x00007fff88b128ea _sigtramp + 26
7   liblwjgl.jnilib               	0x00000001323c9596 Java_org_lwjgl_opengl_MacOSXContextImplementation_nCreate + 214
8   ???                           	0x00000001010f3f90 0 + 4312743824
9   ???                           	0x00000001010e8333 0 + 4312695603
10  ???                           	0x00000001010e89e1 0 + 4312697313
11  ???                           	0x00000001010e8158 0 + 4312695128
12  ???                           	0x00000001010e8158 0 + 4312695128
13  ???                           	0x00000001010e8158 0 + 4312695128
14  ???                           	0x00000001010e8158 0 + 4312695128
15  ???                           	0x00000001010e8158 0 + 4312695128
16  ???                           	0x00000001010e8158 0 + 4312695128
17  ???                           	0x00000001010e8806 0 + 4312696838
18  ???                           	0x00000001010e8158 0 + 4312695128
19  ???                           	0x00000001010e8158 0 + 4312695128
20  ???                           	0x00000001010e8158 0 + 4312695128
21  ???                           	0x00000001010e8158 0 + 4312695128
22  ???                           	0x00000001010e8333 0 + 4312695603
23  ???                           	0x00000001010e24f7 0 + 4312671479
24  libjvm.dylib                  	0x00000001006ed93f JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557
25  libjvm.dylib                  	0x00000001006ed70c JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40
26  libjvm.dylib                  	0x00000001007287c3 JVM_DoPrivileged + 560
27  ???                           	0x00000001010f3f90 0 + 4312743824
28  ???                           	0x00000001010e8333 0 + 4312695603
29  ???                           	0x00000001010e8333 0 + 4312695603
30  ???                           	0x00000001010e89e1 0 + 4312697313
31  ???                           	0x00000001010e8333 0 + 4312695603
32  ???                           	0x00000001010e24f7 0 + 4312671479
33  libjvm.dylib                  	0x00000001006ed93f JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557
34  libjvm.dylib                  	0x00000001006ed70c JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40
35  libjvm.dylib                  	0x00000001007287c3 JVM_DoPrivileged + 560
36  ???                           	0x00000001010f3f90 0 + 4312743824
37  ???                           	0x00000001010e8333 0 + 4312695603
38  ???                           	0x00000001010e89e1 0 + 4312697313
39  ???                           	0x00000001010e8158 0 + 4312695128
40  ???                           	0x00000001010e8158 0 + 4312695128
41  ???                           	0x00000001010e8158 0 + 4312695128
42  ???                           	0x00000001010e8158 0 + 4312695128
43  ???                           	0x00000001010e8158 0 + 4312695128
44  ???                           	0x00000001010e8158 0 + 4312695128
45  ???                           	0x00000001010e24f7 0 + 4312671479
46  libjvm.dylib                  	0x00000001006ed93f JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557
47  libjvm.dylib                  	0x00000001006ede1c JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) + 256
48  libjvm.dylib                  	0x00000001006edf56 JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*) + 74
49  libjvm.dylib                  	0x00000001007248d0 thread_entry(JavaThread*, Thread*) + 169
50  libjvm.dylib                  	0x00000001008dd694 JavaThread::thread_main_inner() + 134
51  libjvm.dylib                  	0x00000001008deb7a JavaThread::run() + 440
52  libjvm.dylib                  	0x000000010081a595 java_start(Thread*) + 173
53  libsystem_c.dylib             	0x00007fff88b24742 _pthread_start + 327
54  libsystem_c.dylib             	0x00007fff88b11181 thread_start + 13

[kappa]

I suspect the native crashes are occurring because of threading issues between the JNI thread and the Cocoa thread (Thread-0). This is because the Cocoa calls are currently running on the JNI thread. Will have an attempt at trying to fixing it tonight.

[mc78]

@Kappa: yep, my bad, forgot Ant doesn't like property overrides. Patch below, it's uglier but keeps Ant happy. Also noticed the line endings for build.xml on the branch now are Mac OS which seems to break svn diff and regular diff too. Maybe convert to UNIX line endings ?

Patch adds:
- Only set build.xml properties once to keep Ant happy
- Print which gcc, JavaVM.framework and Mac OS SDK is used for Mac OS natives

[macdonag]

I suspect the native crashes are occurring because of threading issues between the JNI thread and the Cocoa thread (Thread-0). This is because the Cocoa calls are currently running on the JNI thread. Will have an attempt at trying to fixing it tonight.

I'm inclined to agree.  I built the latest code, and ran the coloured quad example.  It seems to crash with the mutated collection during enumeration problem most of the time, but occasionally it runs without any problems.

(Still got the missing header files problem I mentioned earlier though - are there some files that need to be checked in?)

[kappa]

(Still got the missing header files problem I mentioned earlier though - are there some files that need to be checked in?)

I ran into that the first time i checked out but didn't see it again as I copied the headers over from emu's src files, anyway found the cause of the problem. The native headers for two classes weren't being generated, made the changes to the main lwjgl build.xml, latest svn code should compile for you now.

Also added mc78's latest build.xml changes to svn.

[avm1979]

@kappa: Checked, looks like I have JNF where it should be (in /System/Library/Frameworks/JavaVM.framework/Frameworks). Not sure why it's not finding it, I'll poke around a bit more.

[mc78]

@avm1979: which version of Mac OS are you trying to compile on ? which version of XCode do you have installed ?

Unless you're running 10.6 or prior, you shouldn't be trying to link/compile against anything in /System/Library/Frameworks. The patch I made for build.xml addresses these issues. If it's not working for you, please share the result of your ant build as well as the results of running "xcode-select".

I will be travelling over the next few days, but I'll try to check these forums as I can.

[avm1979]

Not trying to compile it myself - just trying to use the build kappa posted with Java 7, on OS X 10.6.

[Matzon]

(Still got the missing header files problem I mentioned earlier though - are there some files that need to be checked in?)

I ran into that the first time i checked out but didn't see it again as I copied the headers over from emu's src files, anyway found the cause of the problem. The native headers for two classes weren't being generated, made the changes to the main lwjgl build.xml, latest svn code should compile for you now.

Also added mc78's latest build.xml changes to svn.

I removed the files when I was checking in, because they were part of the standard autogenerated headers. Since I can't compile, I didn't notice this issue. Sorry about that.

[foibleless]

mc78 really nice job, patch committed, keep them coming

@macdonag try now with the latest svn code it has mc78's patch applied.

@avm1979 thanks for continuing to test and provide updates, looking into the OS X implementation of LWJGL's Sys class, there was actually some old code in there that started the AWT Toolkit to work around a bug in OS X 10.3, removed it, hopefully there won't any be other dependancies on AWT when running just the native Display.

Latest build for testing: https://www.dropbox.com/s/b6gj27dmoyo0h0j/macosx.zip

Kappa this fixed the issue I was having with my Minecraft game crashing any time I opened a window.  It was having some issues with the mouse pointer afterwards.  I'll be running this version while playing and if I run into any crashes will let you know.  Thanks everyone that has put time into this to fix these bugs as well as keep me from having to build the LWJGL source.

[foibleless]

Found a bug if your app that is using the lib (minecraft in my case) locks the mouse into it, and you hit esc and get your mouse out of it, then alt+tab back into the application, it doesn't refocus your mouse to inside of the app.  So when I try to click, it actually clicks OUTSIDE of the app.  Let me know if I need to describe this better...


edit:Okay so that's not the only time the bug happens.  Anytime I need to actually click on something in the app with my mouse pointer, my mouse ends up being WAY outside of my app on my other monitor.

edit2: Tiago on Mojang's Jira put it a lot better than I did.

"I only tried this in windowed mode, but it seems like the window sometimes loses focus of the mouse and I'm actually clicking other windows instead of the Minecraft window. Usually clicking outside of it and back again fixes it, but sometimes the mouse buttons stop performing any actions after this."

[Grum]

There is some difference in behavior. Minecraft on 'release of the cursor' does the following:

    public void release() {
        Mouse.setCursorPosition(parent.getWidth() / 2, parent.getHeight() / 2);
        Mouse.setGrabbed(false);
    }

I'm not exactly sure where it is going wrong, but it used to drop the cursor dead-center in your active window. According to the javadoc the x,y setCursorPosition uses should be relative to the origin to the window origin. From what I can see it now drops it relative to the desktop-origin (topleft).

[kappa]

More bug fixes in now, hopefully two more of the native crashes are fixed, one of the startup ones (the "Collection <__NSSetM: 0x7fa13b485c50> was mutated while being enumerated.") and another on exiting the app (although there is now a different crash on exit which only happen when using the red x close window button, can be silenced but better to fix the root cause once found).

Also implemented missing functionality on Display.getWidth() and Display.getHeight() calls as they were not updating on Display resize, special thanks to Grum for reporting, narrowing down the bug and helping with testing.

Latest experimental build here: https://www.dropbox.com/s/b6gj27dmoyo0h0j/macosx.zip