Java Tech Demo

[Slapstick 10]

The Java crowd hasn't been getting much love recently, so I thought I would put together a simple "Java Tech Demo" to give people not familiar with Java an idea what will hopefully be in store for us down the road.

I call this a tech demo because I cover too much ground and don't have time to fully explain everything. However, people should be able to follow along without too much difficulty. I was originally just going to write an article, but that quickly turned into a wall of text that most people would likely find hard to follow. So instead I've make a short (11 minutes) screencast.

Acknowledgements

I would like to thank the following people/organizations.

1. BIS for giving me permission to put the jniscripting.jar on my Maven repository.
   
2. [EVO] Dan for permission to use his Convoy Attack as the basis for this demo.
   
3. OFPEC for allowing people to use the ofpec.com domain for Java packages (If you have a tag registered at OFPEC). Since I have registered the tag "SLAP" at OFPEC I am permitted to use com.ofpec.slap when naming Java packages, modules etc.
   

The Video

Download the video: Java Tech Demo (101MB)

Notes

Here is the information you see me enter into the dialog boxes, etc in the video. This won't make any sense until you watch the video, but instead of trying to write down everything I type I've included the information below.

To download the settings.xml file

• Go to http://maven.suderman.com
  
• Right click on the settings.xml file and select Save Link as... (or whatever is appropriate for your browser).
  
• Close your browser.
  
• Open a command prompt.
  
  • mkdir .m2
    
  • copy Downloads\settings.xml .m2
    

  [*]Close the command prompt.

Maven archetype information

• Archetype Group Id: com.ofpec.slap.maven
  
• Archetype Artifact Id: tkoh-archetype
  
• Archetype version: 1.0.0
  
• Repository URL: http://maven.suderman.com/release
  

The Reaper module:

• Group Id: com.ofpec.slap
  
• Artifact Id: reaper
  
• Version: 1.0.0
  

The Vehicle Respawner module:

• Group Id: com.ofpec.slap
  
• Artifact Id: respawner
  
• Version: 1.0.0
  

Modifying the mission

Remove all SQF code from the init fields of the four helicopter.

Give each helicopter a variable name (I used helo1, helo2, helo3, helo4).

The init.sqf script

Comment out the line that calls cly_removedead.sqs

Add the following two lines:

GameManager = jLoad "com.ofpec.slap.examples.convoy.GameManager";
GameManager jCall ["init", [helo1, helo2, helo3, helo4]];

Conclusion

I have not tested this mission or the Java code. The mission may not work as advertised and may cause frequent CTDs. The intent is not to provide working code, but to give an overview of some the features available during Java development. In particular we use Maven to build our source code and handle dependency management. We don't have to edit a single line of XML, and we automagically have the source code and documentation avaiable for the "third party" modules (reaper and respawner) that we use.

Enjoy!

Edited April 11, 2012 by Slapstick
Added link to YouTube video

[Sealife 22]

Thanks for your Hard work there

the video is very good and any insight into TOH and Java is always appreciated :)

I am sure when BIS combine elements of Arma2 and TOH this page will be visited alot more ;)

[Slapstick 10]

Thanks Thromp. Hopefully there will be better resources than this by the time Arma and TOH come together. I was just bored waiting for the next Java update *cough* and wanted to stir up a bit more excitement in the Java community.

However, after re-reading my "Conclusion" above, I think I ended on the wrong note. I have tested the mission and the Java code, I just haven't tested it extensively and I've not done any MP testing. But anyone should be able to follow along with the video and have a working TKOH mission that they can run. The bit I wanted to highlight was how easy it is (can be) to import and use external Java modules.

[.kju 3244]

Well done Slapstick :)

I am wondering if it is possible to extract the archetype information to a file and let eclipse import the definition.

Similar for the modules (dependencies) used - even more I would have expected a drop down list to select the one you want to use

or some kind of drag and drop of a definition file. The manual typing seems error prone to me and you don't get a good sense of overview.

That said from what I can tell this is simply Maven/Eclipse interface design and unrelated to TKOH/Java FM usage itself.

[DnA 5138]

Very informative insight into getting started with Maven and TKOH Java Slapstick! Would you consider uploading the video to Youtube, so that it's more easily shared? My downloaded version cut out for some reason.

[Slapstick 10]

I am wondering if it is possible to extract the archetype information to a file and let eclipse import the definition.

You could create a template mission and then simply import that into Eclipse. So you wouldn't actually "extract" anything from the archetype.

Similar for the modules (dependencies) used

You could, but you would be making a lot of unnecessary busy work for yourself. For instance, I didn't talk about transitive dependencies. That is, the reaper and respawner modules make use of the com.ofpec.slap.core module, yet we never actually included that module in our project. Maven figured out that we needed it, downloaded it for us, and added the classes to the compiled output.

Further, every time a module is updated you would have to download the new module, plus its transitive dependencies all over again. With Maven you simply update the version number in the pom.xml and let Maven worry about everything else.

even more I would have expected a drop down list to select the one you want to use

or some kind of drag and drop of a definition file. The manual typing seems error prone to me and you don't get a good sense of overview.

I'm glad I didn't use Gradle for the demo then as Gradle requires even more error prone typing. (I almost used Gradle, but Gradle support isn't built in to Eclipse like Maven support is and I didn't want to start with a tutorial on installing extra plugins). However, once Eclipse/Maven has an index for a repository you can select modules from a drop down list. I just forgot to show that in the demo.

That said from what I can tell this is simply Maven/Eclipse interface design and unrelated to TKOH/Java FM usage itself.

I'm not sure what you mean. I don't actually make any calls to RVEngine in the GameManager class, but the core, respawner, and reaper modules do. So the code will not work outside of TKOH. However, the intent of the demo was to showcase Eclipse and Maven and not TKOH/Java.

Would you consider uploading the video to Youtube

I'll update the first post with a link to the video on YouTube.

[[evo] dan 79]

I will have a good look at this and maybe have a go at using Java for my next new mission (might be a little test one though before making a bigger one). Awesome work though!

[.kju 3244]

Slapstick you misunderstood me somewhat.

In terms of the modules (dependencies) used I was only suggesting to replace your manual typing with a definition file for this specific text - no more.

Of course we want to continue to let Maven handle the management of everything else.

To give you an example. Right now you download a script file (or a set somewhat) to integrate it in your mission.

The idea would be to click on a link on a website, it will given you a file the defines the reaper module.

Now you import that into your java/maven project and maven does the rest - vs you did all the typing yourself.

You even provided the classic case with manual typing is not perfect - your typo. :)

My argument at the end is that the ecplise/maven design is lacking in that regards.

Not your demo/approach or anything related to TKOH etc.

[Slapstick 10]

No, I misunderstood you completely ;)

Part of the reason I had to do so much typing is because my Maven repository isn't actually a real Maven Repository, it is just a directory structure on my web server that Apache serves file from. In particular it lacked a proper index so Eclipse/Maven didn't know what artifacts were stored on it. I've since generated the index so adding dependencies is much easier and more closely resembles the way it would work once a real repository is set up.

Now to add a dependencies simply type a few letters from the name of the module (any part of the groupId or artifactId) in the Enter groupId, artifactId, or sha1 prefix or pattern (*) field. For example, if you enter com.ofp you will see all modules that contain com.ofp in the name, which is currently only the modules I've deployed. Then double click on the module you want to include and the latest version will be added to the pom.xml file.

Unfortunately you still have to do all that typing to add an archetype. At least in general, for first time users I could include the archetype-catalog.xml that Maven generates/uses. Also, since I started from a brand new Eclipse install Eclipse didn't have any history to work with. But now if we want to add an updated tkoh-archetype all of the information we typed in the first time will be available in the drop down boxes so we don't have to do all that typing again.

I may re-shoot the video, or at least parts of it, to reflect these changes.

Dan;2133340']I will have a good look at this and maybe have a go at using Java for my next new mission

We might have to wait for some documentation and bug fixes from BIS before we can do anything really useful. I can see lots of really interesting things in the Java API but I have no idea how to use them...

[Salakka 1]

@Slapstick

I actually made some question to http://forums.bistudio.com/showthread.php?133646-Java-API-questions&p=2138393 .. but after video some are already answered :)

So correct me if I'm wrong .. but I can basically embed jetty and start inside init() and it should work correctly right?

About events from engine, are those async ones and not keep engine waiting java parts or do I need to make it async in java side (spawn another thread for example) .. like for slow writes to databases.

And how to hook on for example player events (die,take hit, etc) .. I can only see onPlayerConnect/onPlayerDisconnect handler methods directly in RVEngine class.

[Slapstick 10]

Well, I don't know how much TKOH would like it if the Java code started a server like Jetty; TKOH does use a security manager and opening a socket is likely not allowed (although I've never tried). Of course, you can always try tinkering with the java.policy file and see if you get anywhere. However, there are some class loading issues as well that might cause problems for now (see here and here). I have also tried using SLF4J/Logback to do some logging and didn't get very far, although to be honest I didn't try very hard.

About events from engine, are those async ones and not keep engine waiting java parts or do I need to make it async in java side

That is a good question. I suspect it works the same as it does in SQF, so if event handlers are asynchronous in SQF they are likely asynchronous in Java as well. However, I don't know SQF very well so I have no idea. I always assume if I want something to be async I have to do it myself.

And how to hook on for example player events (die,take hit, etc)

With RVEngine.addEventHandler. However, addEventHandler takes a GameCode object, and the only way I've found to create a GameCode objest is with RVEngine.compile, which compiles a bit of SQF code into a Java object. So you end up doing something like:

GameObject player = ...
GameCode code = RVEngine.compile("SLAP_GameManager jCall ['handleEvent', [1, _this]");
RVEngine.addEventHandler(player, Arrays.asList("killed", code));
...
public static Object handleEvent(Object[] args) {
int type = ((Float) args[0]).intValue(); 
Object[] eventArgs = (Object[]) args[1];
switch(type) {
	case KILLED:
		...
}
}

This does work, but it seems a little silly to use Java to compile SQF that does nothing but call Java code. Hopefully, this is one of the things that will get streamlined in a future Java update.

Edited April 22, 2012 by Slapstick
Edited for grammar and spelling.

[Salakka 1]

This does work, but it seems a little silly to use Java to compile SQF that does nothing but call Java code. Hopefully, this is one of the things that will get streamlined in a future Java update.

I'm not too familiar with SQF, but I hope there will be more direct java handlers as it looks quite mixed setup if need to compile those SQF parts.