Jme 3.5.2

Development
1

We released JMonkeyEngine 3.5.1-stable on 19 March. At the time, there was talk of upgrading LWJGL to v3.3.1, but I argued against it, saying “Blindly upgrading LWJGL is a big risk. Unless it solves some major problem with 3.5.0, it doesn’t belong in JME 3.5.1.”

We now have an additional month of experience with LWJGL v3.3.1 (in our “master” branch). We also have proof that upgrading will solve issue 1710, a notable regression between JME 3.4.1 and JME 3.5. I think it’s time to publish an Engine release that includes LWJGL v3.3.1 .

I propose a v3.5.2 release for that purpose. The release could also include unrelated low-risk/high-benefit bugfixes. However it shouldn’t include any breaking changes.

I believe a v3.5.2 release could be ready by 30 April, perhaps as soon as next week.

What do people think? Any requests, concerns, advice?

16 Likes
2

Thanks for the likes. In the absence of discussion, I’ll read them as support for my proposal.

According to the issue tracker, there are a couple other bugs (besides 1710) that can be addressed in v3.5.2:

If there’s no objection, I’ll act as release manager for JMonkeyEngine 3.5.2-stable.

9 Likes
3

I can run through some VR test cases when a candidate is ready (it would suprise me if anything is broken there though as i was playing around with the master branch and there was no problems)

1 Like
4

OK, I’ll let you know when the time comes.

5

Also; yay! I had started playing with the OpenXR in the new lwjgl in the master branch but this will given me more options.

4 Likes
6

Today, i updated some of my testcases on android to jme-3.5.1 and there was a cryptic bug with JmeSurfaceView that seems to be a problem within Lifecycle, i will post the problem on forums soon for further testing, i just like to let you know before releasing (i didnot do enough investigations to open an issue).

Note : i am currently runnin LineageOS Android-11, before jme-3.5.0, i was running RR-OS android-10 and everything was working fine, android-11 comes with some verbose apis that are able to spot bugs and bad code.

2 Likes
7

Thanks for taking the initiative on Android testing.

About the bug you’re seeing, I’m curious whether it’s something new in Jme-3.5.1—or was it present in Jme-3.5.0 as well?

Please do open a GitHub issue, even if you don’t understand the bug 100%. Forum posts don’t vanish, but they do get buried and forgotten.

1 Like
8

I can run into the same bug when testing on jme-3.5.0, it is something with lifecycle, the intrepretation of logs from jmeSurfaceView shows the premature destruction of surface view and calling onDestroy() on application startup ! I cannot reproduce on jme-3.4, the feature is new with jme-3.5 but can be toggled using bindLifeCycle(), so testing with bindLifeCycle(false) the bug is resolved :slightly_smiling_face:.

1 Like
9

I can run through some VR test cases when a candidate is ready

The release candidate is SHA1 hash=8ab3d24e in the “v3.5” branch. You can install it to your Maven local repo using the following commands:

$ git clone https://github.com/jMonkeyEngine/jmonkeyengine.git
$ cd jmonkeyengine
$ git checkout -b RC1 8ab3d24e
$ ./gradlew clean install -PjmeVersionName=3.5.2-SNAPSHOT

To allow time for testing, I plan to wait 72 hours before attempting to publish JME v3.5.2-stable.

If anyone else (besides @richtea and myself) plans to test the release candidate, please let me know!

Related news:

  • There’s now a v3.5.2 milestone at GitHub.
  • I decided to drop PR 1794 from the release because it depends on PR 1750 and the combination of the 2 PRs seems too risky relative to the benefits.
  • I considered including PR 1786 and the fix for issue 1021, but decided they are both too risky for this release.
2 Likes
10

At this point, this issue is a real bad code ! I still not sure if this is the cause of the bug or not, but this is a duplicate call and needs to be fixed as soon as possible.

i remember when writing jmeSurfaceView, the SystemListener#destroy() docs confused me on should i call destroy manually or delegate to the jme context, when i read it again together with the LegacyApplication#stop(), i understood now that app#stop → context#destroy → SystemListener#destroy() → app#destroy().

1 Like
11

I’ve plugged the new version into my VR test cases and I can report no problems :+1:

I also plugged it into one Million Worlds and similarly see no problems there. :+1:

3 Likes
12

currently building the release

EDIT: JMonkeyEngine v3.5.2-stable has been published in the usual places:

It should appear in Maven Central Repository Search in an hour or two. Expect a blog announcement, a brief e-mail to donors, a README update, and a tweet during the next 24 hours.

11 Likes
13

Hello,
i am testing now on android.
This problem is due to explicitly setting glSurfaceView to null when destroying the app…and unfortunately setRequestOrientation(...) invokes onDestroy() prematurely, so when trying to add it to the screen, the result is IllegealStateException : Cannot add a null object, the final fix i think is removal of explicit nulling…

E/AndroidRuntime: FATAL EXCEPTION: main
    Process: com.jme3.hellojmesurfaceview, PID: 12825
    java.lang.IllegalArgumentException: Cannot add a null child view to a ViewGroup
        at android.view.ViewGroup.addView(ViewGroup.java:4994)
        at android.view.ViewGroup.addView(ViewGroup.java:4976)
        at com.jme3.app.jmeSurfaceView.JmeSurfaceView.addGlSurfaceView(JmeSurfaceView.java:551)
        at com.jme3.app.jmeSurfaceView.JmeSurfaceView$RendererThread.run(JmeSurfaceView.java:207)
        at android.os.Handler.handleCallback(Handler.java:938)
        at android.os.Handler.dispatchMessage(Handler.java:99)
        at android.os.Looper.loop(Looper.java:223)
        at android.app.ActivityThread.main(ActivityThread.java:7664)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)

EDIT:
I will do now 2 PRs, one for fixing the duplicate call and another for fixing premature nullifying in-use objects…would that be okay ?

EDIT2 :
Alright, i did 2 PRs, i hope it gets resolved.

2 Likes