2.4.0 release date?

Hi all,
Well I finally upgraded from Mac OS 10.8 directly to 10.14 Mojave and was overjoyed to verify that my JOGL based apps still worked ... almost. I googled the error message and was relieved to see that as Bug 1370 it had already been identified and apparently fixed by Sven. I also noticed that the 2.4.0 release seems to be approaching. Before I dive in and try to build things myself I wanted to ask if there is a release date for 2.4.0  that might obviate the need for that.
BTW, Thanks to everyone for keeping JOGL going.
Charles Gunn

PS to previous post. If anyone reading this has successfully built jogamp for Mojave (Mac OS 10.14) and is willing to provide the binaries to me "as is" with no conditions, I'd be interested in hearing from you.

Hello

Maybe a nightly build or a release candidate would help in the meantime.

Sounds promising ... could you provide a link?  I'm quite inexperienced with this level of software acquisition. Before I posted I tracked down a jogl 2.4 mac os build from April 10 2019 at this URL:
https://jogamp.org/chuck/job/jogl/lastSuccessfulBuild/label=macosx-10_6-x86_64-nvidia/
and this build file:
        jogl-2.4-b1483-20190410-macosx-universal.7z
but when I tried to uncompress it I got the error message "the archive file is incomplete".
So I gave up and made my post.

I've just tried to uncompress it with 7-zip 9.20 and it just works.

I'm on a Mac (the post has to do with Mac OS 10.14) and I've tried to uncompress this archive with both TheUnarchiver.app V. 4.1.0  and with keka.app V 1.1.19. Both fail. Both however succeed with an older archive file that I downloaded from jogamp: jogamp-macosx-universal.7z.  That archive however does not contain the fixes that I need for Mojave.

I've just tried under Mageia Linux with Ark and it works too. I've no Mac, sorry. Maybe use another computer to convert the archive into a format that you can use on your Mac but it should work, there is nothing wrong with this archive.

Thanks for the advice, it worked.  I got the .7z file uncompressed with a friend's help.

But it doesn't solve the problem that I hoped it would.

I identified the problem as JOGL Bug 1370 "NSWindow drag regions should only be invalidated on the Main Thread!". The behavior I saw was that the JOGL canvas was not properly drawn in its window but at some offset. And I saw this error message:

2019-11-05 09:12:40.954 java[29310:4710461] WARNING: NSWindow drag regions should only be invalidated on the Main Thread! This will throw an exception in the future. Called from (
        0   AppKit                              0x00007fff3be482e3 -[NSWindow(NSWindow_Theme) _postWindowNeedsToResetDragMarginsUnlessPostingDisabled] + 386
        1   AppKit                              0x00007fff3be4568c -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1488
        2   AppKit                              0x00007fff3be450b6 -[NSWindow initWithContentRect:styleMask:backing:defer:] + 45
        3   libnativewindow_macosx.jnilib       0x00000001a08763fe Java_jogamp_nativewindow_macosx_OSXUtil_CreateNSWindow0 + 398
        4   ???                                 0x0000000111641667 0x0 + 4586739303
)

Even after installing the new .dylib files and .jar files these problems remain.

Note: the distribution that I downloaded does not seem to include any awt support (The provided jar files include:
jogl-all-android-natives-macosx-universal.jar
jogl-all-mobile-natives-macosx-universal.jar
jogl-all-mobile.jar
jogl-all-noawt-natives-macosx-universal.jar
jogl-all-noawt.jar
jogl-test-android.jar)

I was not able to remove the previous jogl-all.jar (which included awt support), since otherwise I got many compile errors.

And the fact that "jnilib" appears in the stack trace above implies to me that it is also not finding the new .dylib libraries but is using the older .jnilib ones (that I tried to remove from view but perhaps are cached in some strange way or appear somewhere on the search path), perhaps because it is linking to the older jogl-all.jar file.

I appreciate any help you can provide.

Yes you have to remove the cached native libraries or you can disable the automated native library loading and use the Java library path, please look at the user's guide.

I have removed as best as I know how all cached library files -- also all existing copies of libnativewindow_macosx.jnilib.

I have also tried to follow all the relevant directions from
https://jogamp.org/jogl/doc/userguide/#localinstallation:
I have turned off automatic library loading via
-Djogamp.gluegen.UseTempJarCache=false
and set the native library directory in various ways in eclipse to point to the new dylib files.

As I said, I can not use any of the jar files in this jogl-2.4-b1483-20190410-macosx-universal.7z distribution since none of them have awt support.  It seems odd that I have to use an old jogl-all.jar file.  Is that intended? Or am I missing something?

I am printing out the "java.library.path" variable so I can see that it is pointing to the folder where the new .dylib files have been placed. But they don't seem to be being used:

Just for testing purposes, I removed ALL the dylib files from the  jogl-2.4-b1483-20190410-macosx-universal.7z distribution from the java.library.path (where Eclipse searches for dylib files) and it didn't make any difference in the execution of the application so it appears that they are not being used at all.

Any bright ideas of what I might be overlooking here?

I realized after making the previous post that I had not attached the
-Djogamp.gluegen.UseTempJarCache=false
option to the correct vm.  I needed to do that inside of Eclipse preferences Java->Installed JRE's->edit...
When I made that change, then the bad link to the old dynamic library disappeared.
And it stopped finding the old code and printing out a stack trace including a libnativewindow_macosx.jnilib entry point.

Now however it's not finding the new dylib files even though java.library.path is pointing to the directory containing these files. I will continue to work on this ... suggestions naturally welcome.  

I still have no Mac, maybe Sven or jmaasing can help. It should look for .dylib if and only if you use Java >= 8. Are you sure that you use Java >= 8?

I was using Java 7 so I switched over to Java 8 and nothing changed.

Further observations:

When I turn off automatic library loading via:
-Djogamp.gluegen.UseTempJarCache=false
as described in previous post, then the test program no longer finds the jogl jarfile (I've tried pointing the Eclipse project "Java build path" at various old and new jogl jarfiles, it finds none of them. I confirm via a print statement that the value of "java.class.path" is correct before the first load of a jogl class is attempted.) So the fact that it's not finding the native libraries isn't surprising since it's not finding the jar files that reference the native libraries.
 
It still seems odd to me that the distribution I'm using appears to include no usable jogl-all.jar.
(The included jars are:
jogl-all-android-natives-macosx-universal.jar
jogl-all-mobile-natives-macosx-universal.jar
jogl-all-mobile.jar
jogl-all-noawt-natives-macosx-universal.jar
jogl-all-noawt.jar
)

Some progress to report:

I downloaded JOGL 2.3.2 (the current stable release). The jogl-all.jar file in this release seems to fix the bug with the "wandering" GLCanvas.  

I still get this warning:
2019-11-05 09:12:40.954 java[29310:4710461] WARNING: NSWindow drag regions should only be invalidated on the Main Thread! This will throw an exception in the future. Called from (
        0   AppKit                              0x00007fff3be482e3 -[NSWindow(NSWindow_Theme) _postWindowNeedsToResetDragMarginsUnlessPostingDisabled] + 386
        1   AppKit                              0x00007fff3be4568c -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1488
        2   AppKit                              0x00007fff3be450b6 -[NSWindow initWithContentRect:styleMask:backing:defer:] + 45
        3   libnativewindow_macosx.jnilib       0x00000001a08763fe Java_jogamp_nativewindow_macosx_OSXUtil_CreateNSWindow0 + 398
        4   ???                                 0x0000000111641667 0x0 + 4586739303
)

That's presumably I'm not using any of the resources in the 2.4.0 build that I started off this thread with.  But since 2.3.2 seems to fix the bad behavior I encountered, I consider the problem solved, until I upgrade to a version of Mac OS that converts this warning, as promised, into an exception.  

I haven't been able to answer the question posed by the subject of this thread.  Is there a target release date for 2.4.0?

Hello

It gives an answer to your question:
http://forum.jogamp.org/JogAmp-2-4-0-Release-Feature-Freeze-amp-Complete-td4040157.html

It's great to see the feature freeze. Could you release a snapshot version of 2.4 to maven? Will make it easier to test.

On 1/3/20 2:50 PM, hrj [via jogamp] wrote:
> It's great to see the feature freeze. Could you release a snapshot version of
> 2.4 to maven? Will make it easier to test.

I have to focus on correctness & functionality first,
then comes the maven deployment.