Change how LWJGL path is set. Improves compat with newer JRE

[keturn]

We had our own NativeHelper code to try to manipulate private variables on the classloader. It didn't work very well across JRE versions, as seen in #3742. Fortunately, LWJGL has its own mechanism for dealing with library paths.

In specific, this PR addresses the error that appeared in logs as:

ERROR o.terasology.utilities.NativeHelper - Couldn't link static libraries.
java.lang.NoSuchFieldException: usr_paths
at java.base/java.lang.Class.getDeclaredField
at org.terasology.utilities.NativeHelper.addLibraryPath

How to test

• Run Terasology in a Java 8 environment.
• Run Terasology in a Java 14 environment.

If it still works under Java 8, and it gets to the main screen in Java 14, that's better than it was before!

The other things in natives/ could potentially be affected by this. That includes what, OpenAL, controller support, and Lua?

[keturn]

Sound is working, and it looks like it's using the bundled libopenal. I set another property that took care of libjinput.

Does lua work? So far I have managed to start a world with KComputers in it that hasn't crashed, but I don't know if that proves lua works or not.

[keturn]

Okay. I give up, for the moment, on testing lua. Until I see an easier test plan.

Apparently OpenComputers will fall back to LuaJ if JNLua can't load, so I'm not sure if running a minimal Computer would prove anything? I'd have to specifically test whether the suspend/persistence features work.

or have a specific idea of what to look for in the logs. It might log something when it succeeds or fails in loading the lua engine, but I'm not sure.

Given that the stuff that uses JNLua already needs special launch-time arguments to work (for the permissions requirements), I think testing JNLua is not-release-blocking. JNLua users could do their own path settings at launch time, alongside their other settings.

[Cervator]

Okay, have managed to test this more properly now, we confirmed via chat that there's no LuaJ fallback, and that indeed this PR makes it fail where it worked before (minus an unrelated UI bug if trying to open the display block)

I run with the run config allowing permissive security, CoreSampleGameplay + KComputers, get a bunch of hardware, then turn on the computer. Before this PR you could see it boot up (right on the side of the display block in-world), while after you get the following error in the log:

16:53:41.746 [main] ERROR o.t.m.s.WarnOnlyProviderFactory - Non-permitted permission '("java.io.FilePermission" "C:\Dev\Terasology\Git\NewGradleAndIntelliJ\Terasology\engine\build\classes\ch\qos\logback\classic\spi\StackTraceElementProxy.class" "read")' required by module 'KComputers-1.0.0', class 'class ch.qos.logback.classic.Logger': this should be fixed for production use
16:53:41.747 [main] WARN  KComputers - Error initializing computer!
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
	at org.terasology.kallisti.oc.MachineOpenComputers.<init>(MachineOpenComputers.java:72)
	at org.terasology.kallisti.oc.MachineOpenComputers.<init>(MachineOpenComputers.java:53)
	at org.terasology.kcomputers.components.parts.KallistiMachineOpenComputersComponent.create(KallistiMachineOpenComputersComponent.java:67)
	at org.terasology.kcomputers.systems.KallistiComputerSystem.init(KallistiComputerSystem.java:253)
	at org.terasology.kcomputers.systems.KallistiComputerSystem.computerToggle(KallistiComputerSystem.java:80)
	at org.terasology.kcomputers.systems.KallistiComputerSystemMethodAccess.invoke(Unknown Source)
	at org.terasology.entitySystem.event.internal.EventSystemImpl$ByteCodeEventHandlerInfo.invoke(EventSystemImpl.java:531)
	at org.terasology.entitySystem.event.internal.EventSystemImpl.sendStandardEvent(EventSystemImpl.java:291)
	at org.terasology.entitySystem.event.internal.EventSystemImpl.send(EventSystemImpl.java:282)
	at org.terasology.entitySystem.entity.internal.BaseEntityRef.send(BaseEntityRef.java:205)
	at org.terasology.kcomputers.rendering.nui.layers.ComputerContainerScreen.lambda$initialise$0(ComputerContainerScreen.java:66)
	at org.terasology.rendering.nui.ActivatableWidget.activateWidget(ActivatableWidget.java:46)
	at org.terasology.rendering.nui.widgets.UIButton.activateWidget(UIButton.java:201)
	at org.terasology.rendering.nui.widgets.UIButton$1.onMouseRelease(UIButton.java:92)
	at org.terasology.rendering.nui.internal.CanvasImpl.processMouseRelease(CanvasImpl.java:266)
	at org.terasology.rendering.nui.internal.NUIManagerInternal.mouseButtonEvent(NUIManagerInternal.java:610)
	at org.terasology.rendering.nui.internal.NUIManagerInternalMethodAccess.invoke(Unknown Source)
	at org.terasology.entitySystem.event.internal.EventSystemImpl$ByteCodeEventHandlerInfo.invoke(EventSystemImpl.java:531)
	at org.terasology.entitySystem.event.internal.EventSystemImpl.sendConsumableEvent(EventSystemImpl.java:301)
	at org.terasology.entitySystem.event.internal.EventSystemImpl.send(EventSystemImpl.java:280)
	at org.terasology.entitySystem.entity.internal.BaseEntityRef.send(BaseEntityRef.java:205)
	at org.terasology.input.InputSystem.send(InputSystem.java:503)
	at org.terasology.input.InputSystem.sendMouseEvent(InputSystem.java:476)
	at org.terasology.input.InputSystem.processMouseButtonInput(InputSystem.java:219)
	at org.terasology.input.InputSystem.processMouseInput(InputSystem.java:198)
	at org.terasology.input.InputSystem.update(InputSystem.java:134)
	at org.terasology.engine.modes.StateIngame.handleInput(StateIngame.java:192)
	at org.terasology.engine.subsystem.lwjgl.LwjglInput.postUpdate(LwjglInput.java:55)
	at org.terasology.engine.TerasologyEngine.tick(TerasologyEngine.java:471)
	at org.terasology.engine.TerasologyEngine.mainLoop(TerasologyEngine.java:425)
	at org.terasology.engine.TerasologyEngine.run(TerasologyEngine.java:401)
	at org.terasology.engine.Terasology.main(Terasology.java:162)
Caused by: java.lang.reflect.InvocationTargetException: null
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at org.terasology.kallisti.oc.MachineOpenComputers.<init>(MachineOpenComputers.java:67)
	... 31 common frames omitted
Caused by: java.lang.UnsatisfiedLinkError: no libjnlua-5.3-windows-amd64 in java.library.path
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1860)
	at java.lang.Runtime.loadLibrary0(Runtime.java:870)
	at java.lang.System.loadLibrary(System.java:1122)
	at org.terasology.jnlua.NativeSupport$DefaultLoader.load(NativeSupport.java:123)
	at org.terasology.jnlua.LuaState.<init>(LuaState.java:280)
	at org.terasology.jnlua.LuaState.<init>(LuaState.java:276)
	at org.terasology.jnlua.LuaState53.<init>(LuaState53.java:35)
	... 36 common frames omitted
16:54:28.949 [main] INFO  o.t.p.i.ReadWriteStorageManager - Auto Saving - Creating game snapshot

To get the hardware:

• give display
• give computer
• give ROMOCBios
• give CPULua53
• give GPUOCType
• give FloppyDiskOpenOS
• give RAM256 5

Place the computer and display blocks adjacent to each other in the world.

Open the computer block with e and plop all the hardware in filling in the leftover space with memory modules. Hit the "Activate" button

As for why it doesn't work ... that's trickier, especially since JNLua's natives are in the same spot. I guess they get loaded via the module whereas the others just get pulled in at engine init? We might want to try to poke around some more and see if there's a way.

[keturn]

Okay @Cervator, I've added examples of how to set the native library path.

• for gradle, in :facades:PC:game
• for IDEA, in the permissive security run config. Requires going to Settings / Path Variables / TERASOLOGY_NATIVES to set.

having to manually set that variable value is a stopgap, but streamlining how the build handles the natives directory is for another time.

[Cervator]

Okay tested around a bit more and updated KComputers with extra details including the potential workarounds: Terasology/KComputers@7b2c93c

Still thinking we should remove from lineup right now, but at least this way it'll be more doable to play with it anyway, and hopefully later recover it fully and move forward :-)

Thanks @keturn