The real usage of JmeSystem#setSystemDelegate(...)?

[pavly-gerges]

After investigating with some Android System interfaces, I stepped into this one interesting API that should be used to abstract the system delegate, but in fact it's never used.

Do you we need to refactor and use it on Desktop and Android? These platforms use their concrete implementatios directly without refering back to the JmeSystem utility. What do you think?

[pavly-gerges]

As you can see here, it's decided to directly use the JmeAndroidSystem and the JmeDesktopSystem inferred from the context and not through the SystemDelegate API:

jmonkeyengine/jme3-core/src/main/java/com/jme3/system/JmeSystem.java

Lines 69 to 71 in 1f31c14

	public static void setSystemDelegate(JmeSystemDelegate systemDelegate) {
	JmeSystem.systemDelegate = systemDelegate;
	}

Examine the usages of the API. It's supposed to be used by Desktop and Android; as it does on IosHarness. I guess this is a design defect or issue. It creates confusion about static references that should get nullified at the destruction of the application context.

[pavly-gerges]

All delegates are loaded using Reflection through this dispatch, except on the Ios platform:

jmonkeyengine/jme3-core/src/main/java/com/jme3/system/JmeSystem.java

Lines 245 to 265 in 1f31c14

	private static void checkDelegate() {
	if (systemDelegate == null) {
	try {
	systemDelegate = tryLoadDelegate("com.jme3.system.JmeDesktopSystem");
	if (systemDelegate == null) {
	systemDelegate = tryLoadDelegate("com.jme3.system.android.JmeAndroidSystem");
	if (systemDelegate == null) {
	systemDelegate = tryLoadDelegate("com.jme3.system.ios.JmeIosSystem");
	if (systemDelegate == null) {
	// None of the system delegates were found.
	Logger.getLogger(JmeSystem.class.getName()).log(Level.SEVERE,
	"Failed to find a JmeSystem delegate!\n"
	+ "Ensure either desktop or android jME3 jar is in the classpath.");
	}
	}
	}
	} catch (InstantiationException | IllegalAccessException | NoSuchMethodException | IllegalArgumentException | InvocationTargetException ex) {
	Logger.getLogger(JmeSystem.class.getName()).log(Level.SEVERE, "Failed to create JmeSystem delegate:\n{0}", ex);
	}
	}
	}

[pavly-gerges]

Things to do:

• Document its usage and provide a reliable testcase.
• OR: Find the right places to fit the JmeSystem#setSystemDelegate(...) API on each platform.
• OR: Deprecate the JmeSystem#setSystemDelegate(...) for removal and address other non-primary uses.

I would likely go with the first case if it possible.

[MeFisto94]

iirc iOS couldn't use reflection as it used a more minimalistic JVM and I think it even tried to compile down to a native library, so AOT back in the 2000s.

Also: This API is used whenever core needs to call anything platform dependent (that's the JmeSystem/Delegate in general).

We could now call setSystemDelegate from inside a static block or something, not sure if that's worth it indeed.
What bothers me a bit with the checkDelegate method though is its implict knowledge of existing platforms, so you can't easily user-provide jme3-switch or jme3-gba. Not too much of a big deal, especially since the difference is being able to print the logger error when the application had been mis-packaged.

[pavly-gerges]

What bothers me a bit with the checkDelegate method though is its implict knowledge of existing platforms, so you can't easily user-provide jme3-switch or jme3-gba.

If in the case of having an incompatible JmeSystemDelegte instance that cannot be located using the Reflection API; then one could use the JmeSystem#setSystemDelegate(...) API. Thus, it's better to document its usage.

We could now call setSystemDelegate from inside a static block or something

If JmeSystem#setSystemDelegate(...) is a user-end API; then I believe no need to dispatch it from the platform modules.