nwnx_jvm - native JVM integration

[motu99]

OK, I finally got nwnx_jvm up and running. Works like a charm, although so far I only tried out the preconfigured stuff.

I had some problems setting up things, in particular with the following Quickstart instruction:

- you need to prefix LD_LIBRARY_PATH=/path/to/libjvm.so to your nwserver start script, where the LD_PRELOAD to nwnx2.so is too.

Being relatively noobish to Java, it took me some time to realize, that libjvm.so is the name of the "normal" Java virtual machine library file, which should be present in any installation of the JDK (or JRE). So I searched down /usr for the file libjvm.so and found 5 instances. I took the path to the "server" version. Is that correct? [There was also a "client" version and some three relatively small files < 10kB which obviously couldbe ruled out]

For better ease of use it might be a good idea to supply an example shell script (like the example for nwnx.ini) to start up the server with nwnx and nwnx_jvm. Here is mine:

#!/bin/sh

export LD_PRELOAD=./nwnx2.so
export LD_LIBRARY_PATH=/usr/local/jdk1.4.2/jre/lib/i386/server

./nwserver \
-publicserver 1 \
-servername YourServerHere \
-dmpassword yourpw \
-oneparty 0 \
-pvp 0 \
-difficulty 2 \
-elc 0 \
-ilr 0 \
-reloadwhenempty 0 \
-module "YourModuleHere" \
-maxclients 32 \
-servervault 1 \
-maxlevel 40 \
-gametype 0 \
-autosaveinterval 0 \
"$@"


After that everything went pretty smoothly.

I compiled jvm_token.nss and put jvm_token.ncs into a hak associated with the module [I guess that should work as well as putting it directly into the module; alternatively the jvm_token.ncs could go into the override folder!?]

Added the line

JVM_EVENT("test_event");

to the module's heartbeat script and looked at the messages piling up in the terminal window.

Seems everything is working great.


Two minor things:

The two example .java source files are outdated, although its quite obvious how to "fix" them.

InitExample.java:
The line
NWObject.registerDefaultHandler();
must be removed, as NWObject.registerDefaultHandlers() is gone since Dec 19th.


EventExample.java:
The import statement must be changed from
import org.nwnx.nwnx2.java.*;
to
import org.nwnx.nwnx2.jvm.*;

Also the line
NWScript.sendMessageToAllDMs("Event from Java: " + event + " on OBJECT_SELF = " + self.oid);
must be changed to
NWScript.sendMessageToAllDMs("Event from Java: " + event + " on OBJECT_SELF = " + self.oid());
[oid has been made private; read-access now is via oid()]

Thanks for posting your work here. The possibilities are ... awesome.

Ever since acaos released his nwexalt to the nwnx-community (in the form of nwns_funcs) I have been thinking to port the PRC to Linux. Grating feats and spells directly to a PC (via NWScript - without BootPC+Leto) would make the PRC much more user-friendly, than placing class-feats and spells as itemPropertyBonusFeats on the hide. The code would be much leaner, too. And many so far (nearly) impossible things could be done quite easily. However, I wasn't too keen on writing/rewriting tons of code in NWScript. But now I can do it in Java and learn to do some decent Java-programming at the same time.

[elven]

Changes:
- updated example code to use new classHandlers, eventListeners
- Scheduler.every() shiny new (but not yet efficient)
- NWVector.ORIGIN now NWVector, not Object (duh)
- Anon now generic, scheduleWait returns value after blocknig

[elven]

motu99: Thank you for your detailed post - I'm sure it'll help other people getting things up and running. Thanks also for the bug-report.

For kicks, here's a overview of my currently work-in-progress code:

* nwnxjvm_osgi: Apache Felix (OSGi R4) launcher inside NWServer
* NWNXVJM ObjectHierarchy (OSGi bundle): A tree hierarchy mapping NWN game objects to java classes, implementing all functionality in a clean, object-orientied way.

Upcoming, when I get around to it:
* NWNXJVM ResMan (OSGi bundle)
* NWNXJVM ScoRco (OSGi bundle)
* NWNXJVM Areas (OSGi bundle) - all three above together useable to bundle game resources in OSGi bundles, fully dynamic loading/unloading
* NWNXJVM Chat (OSGi bundle exporting chat service)
* lots more

Also, I really need to write up some decent documentation ..

[elven]

A bunch of changes:

- Scheduler can be configured to map OBJECT_INVALID to null instead of NWObject.INVALID. (This is useful for implementations that map objects to hierarchical classes and do primitive casting.) The default (was and) is to return NWObject.INVALID.
- Experimental SCO/RCO support. May memleak or not work in some cases. Does not run with -Xcheck:jni enabled (will be fixed later, but I suspect some people want to try it out.)

Updated files are at the usual place. (Sorry for rebasing the git repo. Get used to it. :p)

Edit: to test SCORCO, simply look at TestRunner. It's quite simple, you just need to implement SCORCOListener and return non-null values for keys you want to handle.

[elven]

(obsolete information removed)

[Fireboar]

Interesting. I've had a go, but unfortunately can't get any of my code to work: I get a java.lang.NoClassDefFoundError on my initListener class. Do I need to make a jar file? Where should my folder tree be in relation to the org.nwnx.nwnx2.jvm.jar package? Are there any build options I'm likely to have missed?

[elven]

[Fireboar]

Well, working fine now. I kept at it yesterday after making that post and found that I could get either my own classes to be recognised (those not packaged in a jar file) or the ones provided in your package. I tried several things... in the end I found out how to put both the base directory of my classes and the jar file in classpath: by separating them with a colon (. It worked fine after I did that... maybe in the documentation it would be good to be a little more specific about that: I did notice in the nwnx.ini page on the wiki is a brief mention of "pathsep", but nothing on what this is.

Still, that raises the question. Is it possible to have just one entry in classpath, and linking a jar file and non-packaged code? Because if not, that's got to be something for the quickstart documentation, surely.

Anyway, looking good!

[elven]

[Fireboar]

Got it, that makes perfect sense. Next thing to play with: this whole OSGi doohicky. Hooray for programming by trial and error!

EDIT: Oh, wait, hang on. Work in progress. Nevermind.

[motu99]

I love this tool!

So far it works beyond expectations
[I couldn't try out everything I had in mind, because Windows deleted my whole extended partition with all data on it, although it should have only deleted one outdated logical partition within the extended partition - took me quite some time to get everything back... arrgh]

I have written a Java class NWNXFunc (plus some helper classes) that implements all of the functionality in nwnx_func (by using the NWScript.setLocalString / getLocalString calls from within the JVM). Everthing works fine, although I didn't test every single func.

@elven: If you are interested in integrating those into the .jar let me know. I'll send the java source via Email.

Some things are a bit over my head still: OSGi, Ruby, closure, ... [I'll manage, eventually]

Another thing that has been on my mind: Why is ActionDoCommand() not needed? I always thought, that ActionDoCommand() puts a nwscript function (bytecode) in the action queue, which - AFAIK - is different from queue that handles the AssignCommand() stuff. What am I missing?

[elven]

[elven]

[Fireboar]

Initial impressions are very impressive, though there is one thing. Suppose I have a function in a DelayCommand loop, pseudo-heartbeat. How would that translate to Java? Some means of inserting parameters into the e method of Anon classes would be great. OBJECT_SELF seems to get lost in this transition as well.

[elven]