Next release(s) of the Engine

Running through the apps in the jme3-examples subproject, I’ve already discovered several issues. (Apparently these apps are seldom run. Or if they are, those who run them never file issues at GitHub.) I believe the issues I’ve discovered are all in the examples themselves. In any case, the issues are not yet fixed in master, so they shouldn’t delay 3.2.2-stable.

Does anyone testing 3.2.2-beta1 (or planning to test it) want more time?

I run on master without exception, but rarely run into issues - if at all. I don’t often run the examples so much as refer to them for learning, else I’d happily report anything I find.

1 Like

Thanks for trying to get this out, Stephen. :+1:

I’ve tested 3.2.2-beta1 with my game, and everything works fine.

The only issue I encountered was with Nifty:

java.lang.NoClassDefFoundError: org/bushe/swing/event/EventServiceExistsException
	at com.jme3.niftygui.NiftyJmeDisplay.<init>(NiftyJmeDisplay.java:262)
	at botwar.menu.MenuAppState.initialize(MenuAppState.java:29)
	at com.jme3.app.state.BaseAppState.initialize(BaseAppState.java:124)
	at com.jme3.app.state.AppStateManager.initializePending(AppStateManager.java:251)
	at com.jme3.app.state.AppStateManager.update(AppStateManager.java:281)
	at com.jme3.app.SimpleApplication.update(SimpleApplication.java:236)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop(LwjglAbstractDisplay.java:151)
	at com.jme3.system.lwjgl.LwjglDisplay.runLoop(LwjglDisplay.java:197)
	at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:232)
	at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.ClassNotFoundException: org.bushe.swing.event.EventServiceExistsException
	at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:338)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	... 10 more

It seems this is because the nifty.jar in jME3.2-beta1.zip doesn’t contain the org.bushe package (or the org.jgfont package, for that matter). So, I could only get 3.2.2-beta1 to work if I used the 3.2.1 version of that JAR (nifty-1.4.2.jar).

1 Like

That’s interesting. I wonder what could’ve caused that change.

I’m looking at the ZIP files now. They seem to have all the same JARs. Which JARs are the org.bushe and org.jgfont packages contained in?

In 3.2.1 they’re in nifty-1.4.2.jar. So, in jME3.2-beta1.zip, I would expect to find them in nifty.jar. Everything else that’s in nifty-1.4.2.jar is in nifty.jar; it’s just the org package that’s missing.

1 Like

I’m looking at a “jMonkeyEngine 3.2.1 stable” ZIP file, freshly downloaded from GitHub, and I don’t see nifty-1.4.2.jar. I do see nifty.jar in the lib folder.

This 3.2.1 libraries you’re using … where did they come from?

Please compare with the jME3.2-stable.zip at
Release jMonkeyEngine 3.2.1 stable · jMonkeyEngine/jmonkeyengine · GitHub

1 Like

Ah, yes, so the JARs in both ZIPs are exactly the same. It’s probably OK then.

nifty-1.4.2.jar is in the jmonkeyplatform installation: C:\Program Files\jmonkeyplatform-3.2.1\jmonkeyplatform\libs\nifty-1.4.2.jar. It’s exactly the same as nifty.jar, except it also contains these org.bushe and org.jgfont packages.

1 Like

Cool. Then I think I’m ready to build the 3.2.2-stable release.

I had a busy morning, with lots of issues filed against master branch. Many of these might be candidates for a 3.2.3 release.

But there’s been only one substantial change to v3.2 branch since 3.2.2-beta1:
fix to TestConeVSFrustrum which was buried in commit 83aef82 · jMonkeyEngine/jmonkeyengine@97a26c4 · GitHub

3.2.2 is built and deployed. Now for step 10:

@pspeed would you care to do the honors?

6 Likes

Done: “166 new files will be publicly available shortly”

8 Likes

You guys ROCK…

Happy new year to all.

:fireworks:

3 Likes

Happy new year!

Would it be possible to do a 3.2.2 release of the SDK? This could just be the same version of the SDK that was in 3.2.1, but including version 3.2.2 of the engine.

2 Likes

I’m sure it’s possible. I trust @Darkchaos will release a 3.2.2 SDK at his convenience.

1 Like

He is already working on it after seeing your post this morning James :slight_smile:
Let’s just cross fingers that building works on the first attempt

4 Likes

Ah, thanks a lot, dude! :+1:

2 Likes

Release v3.2.2-stable-sdk1: All the latest SDK Bugfixes, a new node editor, improvments to GLSLSy… · jMonkeyEngine/sdk · GitHub should work

3 Likes

Running jmonkeyplatform-windows-x64.exe, I seem to be getting the following exception (and then the installation rolls back):

java.lang.NullPointerException
	at org.mycompany.ConfigurationLogic.setExecutableContents(ConfigurationLogic.java:215)
	at org.mycompany.ConfigurationLogic.install(ConfigurationLogic.java:202)
	at org.netbeans.installer.product.components.Product.install(Product.java:358)
	at org.netbeans.installer.wizard.components.actions.InstallAction.execute(InstallAction.java:155)
	at org.netbeans.installer.wizard.components.WizardAction$1.run(WizardAction.java:123)
1 Like

How I love that :frowning:

Neither can I imagine any reason for such an Exception nor does it make any sense: new File() cannot return null, File#listFiles() should not return null but an empty array and pure iterating over an array shouldn’t cause any trouble at all.

Can you try backupping and then deleting your contents in C:\Users\James\AppData\Local.jmonkeyplatform (-installer)?

That’s the only thing I could imagine, apart from that maybe sdk/reporting_issues.md at master · jMonkeyEngine/sdk · GitHub and hoping for the best

1 Like

Unforunately, File.listFiles() can return null in some cases. From the javadoc:
“Returns null if this abstract pathname does not denote a directory, or if an I/O error occurs.”

I’ve seen this in my day job from time to time and it’s a pain. For us it was always file permission issues.

2 Likes