Take On Java

[Serclaes 0]

Any addons I make with Java (and I will get involved) will have the source as I think it's important to keep things open.

+1

Making it open source helps others and it would help me make better code by feedback or changes from others. It's imo a win-win, even if there is no credit.

[kylania 568]

+1

Making it open source helps others and it would help me make better code by feedback or changes from others. It's imo a win-win, even if there is no credit.

There's already enough people in the community who want to hide, obfuscate or otherwise disable sources that making compiled only the default is just going to make that worse. The more I see about this Java thing the less I like it. :(

[mahuja 12]

I've noticed that the setup explained in the wiki page on java scripting will place the source files in the mission directory. If we can keep openness the default, it's easier to single out any anti-social code hoarders ;)

Anyway, the first release has a number of issues that make it rather useless at this stage.

- No signaling that the mission just ended; so we have no way of "cleaning up" after ourselves. Or do any final side effects - dumping final stats, flushing buffers, etc. This is made worse by...

- The JVM seems to retain its state between missions. This is bad for a lot of reasons, including bugs with dependencies on what mission ran before it. It may not load a new class with the same name as a previous one, even should it be a new version or even completely different. The JVM should be reset at the end of a mission, after some other cleanup opportunity.

- No support for eventhandlers. The only entry point into java code is the sqf jcall command. At best you can set up an sqf eventhandler doing jcalls. (An eventhandler should be made for mission end, both for java and sqf, imo.)

- Java threads cannot interact with the game. (Thus we have no equivalent for sqf spawn) You can create a java thread to run in the background, but if it calls any function from RVEngine, it's going to crash sooner or later. It can, in theory, be synchronized to when something is jcalling and the game is waiting for it... Or one can currently do spawn { while (true) do { jcall } } but that demotes java into a sqf tack-on rather than a first-class scripting language. And severely complicate multi-stage scripts.

- RVEngine.GameObject and family does not have methods. For example,

RVEngine.GameObject player = RVEngine.player();

RVEngine.sideChat(player, "ABC");

should really be replaced by

RVEngine.GameObject player = RVEngine.player();

player.sideChat("ABC");

The current reasons to use java:

- Heavy calculations that are non-viable in sqf - and that cannot be outsourced to the game engine. These are relatively few and far between in common usage.

... and that's basically it. If we assume RVEngine.X() calls don't arbitrarily yield, like their equivalents do in sqf, you can also use java to get an atomic block - where all the code or none of the code gets run before any other code gets its turn.

Oh and, as for JNI being expensive, I hear JNA isn't.

[nuxil 2]

after going thought the post in this thread. i can see no real reason i would use|learn java or use other languages "jython|jruby etc".

at the current state it is in, i can see no practical usage of java in the game. sure you could use it to do heavy calulation.

but what would that be? its not like you need to calulate the gravity pull the moon has on the earth and so on :p

also that you have to use sqf for your java was a bit turnoff. i thought i would be on pair with how sqf|sqs do it. example. you putted a init.jar or whatever. and it would use that to start up your javacode in the mission. but nop.

[.kju 3245]

How about some comments and a discussion by the developer (BI) for the points raised

and a blog post about their plans on how to move forward from here? :)

[Synide 0]

How about some comments and a discussion by the developer (BI) for the points raised

and a blog post about their plans on how to move forward from here? :)

That would be nice... preferably with pictures, :j:. But, at least some high level overview of the mechanics, other things that would of interest are the aspects of what the replacement VM had to cover in order for it to be accepted as a candidate. What other VM's were potentials and why they were not adequate.

I'll not bore you with my preferences regarding this topic but it would be nice to get some feedback regarding the broad brush strokes of the implementation/system architecture. And, will this influence the other product down the road?

[Deadfast 43]

RVEngine.getDammage(RVEngine.GameObject) - oh no, it's back :D

[Przemek_kondor 13]

RVEngine.getDammage(RVEngine.GameObject) - oh no, it's back :D

wut?

Is it really like that? I was hoping for real OOP, not set of static functions.

It should be like:

object.getDammage();

Is it final?

[noubernou 77]

I hope its not final or even close. :P TBH though if they leave the static functions thats fine, someone/group can always write a better OO interface for things using them.

[Slapstick 10]

WOOHOO So far I've achieved two of my main goals:

1. Use Groovy instead of Java.
   
2. Use Maven to build the code.
   

So far so good and I'm liking what I see. I share many of the concerns others have expressed (i.e. the lack of real OO), but this IS just a wrapper around functionality provided by the RV engine. Since the JNI layer likely calls exactly the same code the SQF interpreter calls I am not terribly surprised that the two APIs look similar. Hopefully this will evolve over time.

I've noticed that the setup explained in the wiki page on java scripting will place the source files in the mission directory.

This is NOT the best/proper way to set up a Java project. The example on the wiki simply shows how to get Eclipse, Java and TOH working together. Mashing code, class files, Eclipse project files and the TOH mission files all into the same directory is likely a Bad Idea. It will likely take a while for some "Best Practices" to emerge, but keeping the sources separate from the binaries is always a Good Idea, simply so people can choose to take one or the other and are not forced to take both.

And while Open Source is nice, if someone just wants to distribute the binary (.class/.jar) files without the source does it really matter? Do you read the Eclipse source code when using Eclipse?. Of course, the binary still needs to be distributed under a "free to use" license, but I would rather have a free to use closed source binary than open source code with a GPL license. In fact, I would prefer to have a well documented Jar file in a Maven repository than either of the above.

Anyway, the first release has a number of issues that make it rather useless at this stage.

Of course it is useless at this stage, but hopefully most of the issues raised will be addressed in later patches (they better be...).

Java threads cannot interact with the game.

My threads can... although my testing with threads has simply been to start one thread that calls RVEngine.hint every second, and another thread that kills the first thread after a few minutes. It is not exactly a stress test, but I haven't run into any problems starting threads or having them interact with RVEngine. The RVEngine functions seem to "yield" just fine, just don't do anything that blocks.

How about some comments and a discussion by the developer (BI) for the points raised

and a blog post about their plans on how to move forward from here?

+1.

I would also like to see some sort of road map just so I don't waste time asking for things that are in the pipeline.

I'd want to instantiate a ScriptEngineManager to run my ruby script from (the same?) directory where java files are

I am not familiar with JRuby, do you need to instantiate a ScriptEngineManager to run Ruby scripts? Can't you compile the Ruby scripts into .class files? Using SQF to load a Java class that instantiates a scripting engine to run a Ruby script does seem a bit excessive. You need something that can compile directly into real JVM .class files... I'm not sure JRuby is it...

However, to get Groovy code to work I needed to extract the Groovy runtime classes from the Groovy .jar file and copy them all into the mission directory. Then my Groovy code worked (sort of). You may need to do something similar with JRuby/JPython etc. Hopefully later patches will be able to load classes from .jar files on the class path and not just .class files.

RVEngine.getDammage(RVEngine.GameObject) - oh no, it's back

LMAO. Hopefully that will be removed next patch. It is one thing to maintain the function in SQF for backwards compatibility, but since there is no Java code to be backward compatible with this should go ASAP! Has anyone filed a bug report on Dev Heaven yet?

Edited February 27, 2012 by Slapstick
Spelling.

[.kju 3245]

Slapstick experience with: Take on Groovy

[rfc 10]

I am not familiar with JRuby, do you need to instantiate a ScriptEngineManager to run Ruby scripts? Can't you compile the Ruby scripts into .class files? Using SQF to load a Java class that instantiates a scripting engine to run a Ruby script does seem a bit excessive. You need something that can compile directly into real JVM .class files... I'm not sure JRuby is it...

It depends on the goal, yes. My idea was, for rapid prototyping, having the bare .rb scripts being directly executed seemed like the "fasted way" (but as we gave an overfew of the call chain, probably not something you would want to do in "production" ;-) ). JRuby can compile to pure .class files fine, I just haven't explored this yet.

[batto 17]

Hi guys. For those in the middle of learning: Treat anybody who's recommending Maven to you as your enemy. Seriously get away from this piece of crap as far as you can. I know what I'm talking about. It's just another big hype in Java world, something like XML, ... or Java. But this one is worst. If you really need to manage dependencies (you don't) look at Gradle. Ant will do fine (though it's crap too). I'm outta here.

[Serclaes 0]

Right. He's not the messiah, I'm the messiah? :rolleyes:

Would you care to elaborate why exactly Gradle is so much better than Maven? Since you obviously have vast experience with both...

[batto 17]

Hello. This would result in flame war and it doesn't fit here. So look at comments here please http://tapestryjava.blogspot.com/2007/11/maven-wont-get-fooled-again.html (I actually got to this page after googling "mave piece of shit", I do it quite frequently). I laugh at all of you maven-piece-of-crap lovers. I love the motto of your ultimate-xml-driven-tool: "convention over configuration" ... which is totally wrong because there is no option for configuration. I love when asking on forum/ml about how to do something that would be easily done with 1 line in some script and they reply you-re-doing-it-wrong-way-do-it-maven-way®. Unfortunately I had to use it at my job. No security (man in the middle on LAN is very easy), no parallel executions, full of bugs, XML programming, ... I'm outta here (now for real!).

[mahuja 12]

This is NOT the best/proper way to set up a Java project. The example on the wiki simply shows how to get Eclipse, Java and TOH working together. Mashing code, class files, Eclipse project files and the TOH mission files all into the same directory is likely a Bad Idea. It will likely take a while for some "Best Practices" to emerge, but keeping the sources separate from the binaries is always a Good Idea, simply so people can choose to take one or the other and are not forced to take both.

All the files mentioned in the mission directory is how the result looks. The class files and toh mission file(s) have to go together, since it will only read them from that directory*; when you pbo it all up, it'll have to be part of the mission.

* It may be that jload will accept paths, so you could have a separate classes subdir in the mission dir. I haven't tested this possibility.

"keeping the sources separate from the binaries is always a Good Idea, simply so people can choose to take one or the other"

Sort by file type, select the approximate half that is .class or .java depending on what you want, press delete. Though I acknowledge that is 1 to 2 clicks more than if they're in a separate directory. It's even simpler from a command line.

And while Open Source is nice, if someone just wants to distribute the binary (.class/.jar) files without the source does it really matter? Do you read the Eclipse source code when using Eclipse?. Of course, the binary still needs to be distributed under a "free to use" license, but I would rather have a free to use closed source binary than open source code with a GPL license. In fact, I would prefer to have a well documented Jar file in a Maven repository than either of the above.

1) Pre-built binaries are fine - as long as they're suitable for whatever ones needs are. But every so often you just need a slight change for it to be good for your uses. If you don't have the sources, you have to discard it completely; it may as well be useless junk.

In SQF, there's practically no scripts that don't need modification to work outside of the narrow use case the writer had for it. If your use case is a good enough match, good for you. If not, sqf allows you to modify it.

Another effect we have from sqf being source-only is that people can look at your code, and tell you exactly what line needs to be changed to fix a bug.

2) Learners - those learning java, or just how to use RVE from java, will be looking at code. Especially if they want a similar effect, but still different.

If you have hidden that code, you won't be getting what missions and mods they would have produced.

If, back during cold war crisis, sqs had been a pre-compiled language without sources provided, arma1 probably wouldn't have happened.

FWIW, there are arma2 missions under GPL. Like the one most played, ever. Especially if you include its arma1 versions. A lot of mission makers started their "careers" by modifying domination.

So yes, it matters a lot. As long as you're in it for the long term.

My threads can... although my testing with threads has simply been to start one thread that calls RVEngine.hint every second, and another thread that kills the first thread after a few minutes. It is not exactly a stress test, but I haven't run into any problems starting threads or having them interact with RVEngine.

My threads have all crashed after anywhere from 1 to 450000 RVEngine calls. This is a race condition problem, which means it will fail sooner or later, even if it's always worked for you while you were testing it. You're free to call RVEngine functions when the game is stopped for a jcall - at least as long as no other thread is calling one of them. Outside of that window, we basically have no guarantees, and we're observing crashes. If all a thread does is call hint once and then exit, then that too seems to fall into "incorrect" behavior that may cause a crash; It may not start running until the jcalled function returns, and at that point the game engine can be all over the relevant stuff. Some functions will be lower risk then others by nature of what they do, but all must be considered risky at this time.

The RVEngine functions seem to "yield" just fine, just don't do anything that blocks.

By yield, I mean pausing the calling java code to do other stuff like sqf code; such that when a function returns, the game state can be radically different from before it was called. That's definitely an issue with sqf today, the question was if java was immune to it. If it's not, you need to make sure all jcall-able functions are reentrant too. I can tell you that RVEngine.Sleep() is effectively a no-op, and yielding is its purpose in life, so I think the "does not yield" assumption is safe for the time being. Not that I'd rely too much on it even so.

Edited February 28, 2012 by MaHuJa
Spelling error bothered me

[Serclaes 0]

O.k. I see where he is getting at. To give some perspective on what he's saying: you can't expect a hammer to work well for screws. Every ill used tool will fuck you up.

[batto 17]

you can't expect a hammer to work well for screws

in case of maven: "you can't expect dildo to work well for screws", for anything other than compiling java source files and packaging them into jar it's worst possible tool ever, yet somehow people like themselves into pain, just look how easy it is to do something like file rename:

<plugin>

<artifactId>maven-antrun-plugin</artifactId>

<version>1.7</version>

<executions>

<execution>

<phase>generate-resources</phase>

<goals>

<goal>run</goal>

</goals>

<configuration>

<tasks>

<copy file="something" tofile="other"/>

</tasks>

</configuration>

</execution>

</executions>

</plugin>

in gradle you can actually write your build AS A PROGRAM (if you like), i don't need some unknown loosers (maven developers) to dictate me how should i build my code and wait 5 years to fix a bug with one line patch, maven is a bad joke, period

[Slapstick 10]

I love the motto of your ultimate-xml-driven-tool: "convention over configuration" ... which is totally wrong because there is no option for configuration.

Are you using the same Maven I am? Maven is totally configurable, it is just that you do not need to do any configuration if you follow the conventions.

If you find yourself jumping through hoops to do something the "Maven Way" when it could be done in a one line script then do it in a one line script. Maven is for dependency management, if Maven doesn't do what you want to do then don't use Maven to do it. At work I still use bash scripts and makefiles to coordinate my Maven builds.

Of course, my preference is Gradle; the power of Ant, the dependency management of Maven all in a nice concise Groovy syntax.

All the files mentioned in the mission directory is how the result looks. The class files and toh mission file(s) have to go together, since it will only read them from that directory*; when you pbo it all up, it'll have to be part of the mission.

The .class files and .sqm file have to be in the mission directory, but the Java source code files and Eclipse project files do not. The Eclipse project files include machine specific settings that can actually make it more difficult for others to use, and are worthless if the person is using a different IDE. Eclipse will create these files when you create/import a project so there is no need to include them with the mission. The source code should be kept separate simply so people are free to chose to take the bits they are interested in and don't get bloat they don't want.

I can confirm this works because I am currently using Maven to build my Java/Groovy code in a separate directory and only copying the generated .class files to the TOH mission directory.

But every so often you just need a slight change for it to be good for your uses. If you don't have the sources, you have to discard it completely; it may as well be useless junk.

Ah, but that is SQF-think. In Java it is possible to modify the behaviour of other classes (within limits) without having the source code. Well, you don't actually modify the class you create a new class that "extends" the class you want to modify. For example, suppose someone released a must have package, but it was closed source and their Vehicle.getVelocity() method contained a bug that caused it to be off by one all the time. I could do something like:

public class MyVehicle extends Vehicle {
...
public int getVelocity() {
	return super.getVelocity() + 1;
}
}

Now I can use instances of the MyVehicle class anywhere a Vehicle is expected and the "off by one" bug has been fixed.

2) Learners - those learning java, or just how to use RVE from java, will be looking at code.

Don't get me wrong, I am just playing Devil's Advocate. I suspect the Donators will outnumber the Code hoarders by a large margin. I am just saying closed source is not as "evil" in Java as it is in SQF. A well designed Java API will have abstract classes that can be extended or interfaces that can be implemented to allow others to change the behaviour of the classes with out modifying the source.

My threads have all crashed after anywhere from 1 to 450000 RVEngine calls. This is a race condition problem, which means it will fail sooner or later, even if it's always worked for you while you were testing it.

Agreed, RVEngine et al needs to be thread safe or we are doomed. Ok, maybe not doomed, but it will certainly be alot more work to write thread safe wrappers around them if they are not.

It may not start running until the jcalled function returns,

But that is the nature of concurrent programming. In fact I would think this to be the expected behaviour. Once a thread is started we have absolutely no control over the order the threads will be executed, or that the thread will even be started before the jCalled function returns. The more cores a CPU has, and therefore the more threads it can run, the more random this will seem.

---------- Post added at 07:09 PM ---------- Previous post was at 06:54 PM ----------

in gradle you can actually write your build AS A PROGRAM (if you like), i don't need some unknown loosers (maven developers) to dictate me how should i build my code and wait 5 years to fix a bug with one line patch, maven is a bad joke, period

You do realize that Gradle is just a Groovy wrapper around Maven right... If you are using Gradle then you are using Maven, albeit without all the XML. I agree that XML tends to get used where it shouldn't be (don't even get me started on Ant), but don't confuse XML with Maven.

Having said that, I thought I would be the only Gradle advocate here! Now I just need more recruits for the Groovy bandwagon :)

Edited February 29, 2012 by Slapstick
Fixed spelling.

[batto 17]

Maven is totally configurable, it is just that you do not need to do any configuration if you follow the conventions.

Ye, Maven is totally configurable, that's true. It takes 10 XML lines to change Java source level. Also conventional != required. Maven requires you do it Maven way like Maven devs knew every possible problem on the world.

Maven is for dependency management, if Maven doesn't do what you want to do then don't use Maven to do it.

Wrong, that's just the part of it. Are you sure you use Maven?!

At work I still use bash scripts and makefiles to coordinate my Maven builds.

Oh my...

You do realize that Gradle is just a Groovy wrapper around Maven right... If you are using Gradle then you are using Maven, albeit without all the XML.

Totally wrong. Gradle has nothing to do with Maven. It uses Ivy to fetch deps. Groovy wrapper around Maven would be exactly same piece of crap with slightly less verbose syntax.

I agree that XML tends to get used where it shouldn't be (don't even get me started on Ant), but don't confuse XML with Maven.

No confusion here. You program your build in shitty XML.

Edited February 29, 2012 by batto

[Slapstick 10]

Totally wrong. Gradle has nothing to do with Maven.

From the Gradle web site:

Gradle combines the power and flexibility of Ant with the dependency management and conventions of Maven into a more effective way to build. Powered by a Groovy DSL and packed with innovation, Gradle provides a declarative way to describe all kinds of builds through sensible defaults.

Their words, not mine.

No confusion here. You program your build in shitty XML.

You do realize that Ivy uses XML configuration files right? I'm not understanding your hating on Maven/XML when, for all intents and purposes, Ivy/XML is exactly the same thing.

[batto 17]

Their words, not mine.

Still it doesn't use Maven and it's completely different from Maven. If you really used both you should know.

[Slapstick 10]

Maven/Ivy/XML aside, there are some class loading items I wanted to mention.

1. The Wiki states that classes will be loaded from the mission, campaign, and/or user directories. However, I've only been able to get classes in the mission directory to load. I haven't created a campaign, but classes placed in the user directory (as returned by RVDirectories.getUserDirectory()) are ignored.

2. At the moment the game only loads .class files and can't find classes in jar files. We really need to be able to deploy jars and I'm hoping this is something on the "Todo, but not done yet" list.

3. End users need to be able to deploy jar files to "trusted directories". I suspect the problems I've had with AccessControlExceptions and Groovy are due to Java security permissions. I also suspect that any non-Java JVM language is going to require runtime classes that need the same kind of permissions that Groovy does. In fact, since most JVM languages are distributed with the Apache license (or at least a license as liberal as the JVM license), maybe TOH/AA3 could include the runtimes for these languages preinstalled.

[.kju 3245]

Does a project space at DH make sense to report issues and make feature requests?

It might make sense to have it separate to TKOH (and later A3) and move away from the forum mess. Thoughts?

[DnA 5154]

Without getting into specifics now, I'll just say that the full integration of Java as a scripting language into the RV engine will be a long process. We aim to make improvements in TKOH until the release of A3 and beyond. Even in A3 it will still undergo development and definitely not have replaced the SQF VM. Some of this work includes bug fixes (crashes, no access to missionNamespace variables, etc.) and other work targets changes in the overall implementation. Of course sample code for things like crashes can only help. We shall outline our full plans for Java in a development blog.

There will always be debate about specific languages or IDEs; some of it comes down to personal preferences, some to technological limitations, some to development philosophy. In any case, please do realize that even with its current limitations; the simple ability of doing real-time debugging with breakpoints is a massive aid to scripters who grew tired of using hints and such to trace variables.