ARMA 3 Alpha - Java Virtual Machine

[derdoe 10]

Main reason for choosing Java for TakOH and Arma 3 was cross-platform possibilities and the amount of community members familiar with Java. Thats why other possibilities e.g. Python, Mono etc. were discarded iirc.

[Alwarren 2767]

All this coding talk is very alien to me.

Could anyone explain or summarize what Java implementation will or could be used for in ArmA3?

Having Java has two major advantages for scripters/mission makers.

1) Java can be interfaces to a lot of third party components, like databases, network, other stuff, so it will give a considerable boost in functionality.

2) SQF, while being perfectly capable of dealing with most problems a mission maker or addon scripter faces, isn't a very intuitive language. Some aspects are a bit obscure, and the syntax cannot (as far as I can see) be parsed using traditional LL(1) or LR(1) parsers, which makes it difficult to have decent error checking within the editor you are using. Java,, OTOH, can be parsed and analyzed. If you have a Java IDE like Eclipse or Netbeans, you will immediately see syntax errors, but also semantic errors like uninitialized variables. Things that you do not get with SQF.

[Trracer 10]

SQF with the addition of CBA and jayarma2lib can be quite powerful. I for one predict that the java implementation in Arma3 will be very very sandboxed.

I also wonder if a headless client implementation will be included in arma3, now that gives some great AI possibilities.

[Alwarren 2767]

SQF with the addition of CBA and jayarma2lib can be quite powerful. I for one predict that the java implementation in Arma3 will be very very sandboxed.

I also wonder if a headless client implementation will be included in arma3, now that gives some great AI possibilities.

It should be very sandboxed or you will run into security vulnerabilities.

CBA and jayarma2lib are addons, if you want to run vanilla, you don't have them, which is where JVM support would be handy.

Plus, I don't think it can be stressed enough how important static analysis is for overall quality. Ever so often I see script errors pop up on released missions that would have been avoidable with the right tools.

[Harrumph 10]

So the first the thing that stands out to me is the complete lack of type safety. Sample doesn't extend any class or implement any particular interface.

This is irrelevant - The first thing the community is going to do is construct a sane wrapper API around this with concurrency protection, type safety and OO support.

I have been nagging about the status of Java for ages due to wanting to get started on this as early as possible.

The only thing that matters is that the functions are available in some form or another.

For actually relevant issues, you might want to check out the take on java tracker:

https://dev-heaven.net/projects/jvm/issues

[gossamersolid 155]

This is irrelevant - The first thing the community is going to do is construct a sane wrapper API around this with concurrency protection, type safety and OO support.

That's not our job! That's the job of BIS to be doing this properly.

If they're going to implement a new language, they shouldn't half ass it. They should do it properly.

[Harrumph 10]

That's not our job! That's the job of BIS to be doing this properly.

If they're going to implement a new language, they shouldn't half ass it. They should do it properly.

I agree that BIS should make every effort to get the language into as usable state as possible, but this will have a lot more to do with having pure java calls from the engine, such as triggers, init.sqf, waypoint conditions, etc. At present, BIS has provided a library of static, non-typesafe functions directly converted from their SQF equivalents. This is precisely the approach I'd advocate, as it greatly reduces the maintenance requirements on their side. By having a community-managed wrapper around BIS' primitive interface, we could construct it better to our own needs, rather than being obliged to use a potentially badly designed one from BIS.

Even if BIS could fully anticipate every use case, I'd be much more trusting of the community's collective expertise to maintain it and keep it up to date. Look at the Linux server for several reasons as to why community maintenance is the way to go.

[gallexme 1]

wrong thread sorry

[noubernou 77]

Tested JayLib with A3 Alpha yesterday. Works fine. Expect a release when I get ACRE ported (waiting on lazy evaluation to be ported from A2 betas, since a bunch of CBA code, and some ACRE code uses it).

[i_2_i 10]

sorry to repeat this post here in and heli game, but i am not sure if different projects / people.

hi with your java support did you have to write a lot of jni code to get back to your engine or sqf, other c/win32, ect.

if so you may want to take a look at Jenie something I created a long time ago for Java. it allows you to call native api and they call back and pass back and forth and manipulate complex data structures without having to write any JNI code!

check it out! if you like use it, just dont forget i'm the one that slaved to create all that java/c/c++ code :)

http://mjgoya.blogspot.com/p/servertec-software-projects.html

[pwnstar23 10]

Can we expect Alpha to be updated some time in the future with Java implementation or will it only be in the release version of Arma 3?

[noubernou 77]

There seems to be a lot of the Java stuff in the game right now, though I don't think its exposed to SQF to call into it.

[looter 10]

There seems to be a lot of the Java stuff in the game right now, though I don't think its exposed to SQF to call into it.

Which PBOs? I'd like to take a look at it.

[noubernou 77]

Which PBOs? I'd like to take a look at it.

Not in any of the PBOs.

[John_McClane12341 1]

I really think that Java would be more useful then C or C++. And Java would be easier for the devs to integrate within the game.

[noubernou 77]

How would a JVM be more simple than writing hooks in the native language that the game is coded in for the devs?

[pwnstar23 10]

I wish we could get an answer here, this is important.

[NeZz_DK 1]

I wish they made it so that we could write java plugins and include them in the mission packages, that way we would be able to write our scripts in java or in SQF, and it wouldn't need any kind of special setup to run java enhanced missions.

[lee1hy 1]

Every game require .net framework, so why not JDK?

[Gorbachev 1]

I really don't understand why Java is so great. Java apps run slow. Average PC users don't even know what Java is or why they don't have the latest version. It seems like another barrier for average joe to overcome just to join a multiplayer game.

[lee1hy 1]

i dont know why people worry about JVM? there are many malicious programs and may it is yours.

java is easy and a lot of people use. that you can create easily your content and it is great advantage to commuity. slow jvm is old story rather than worry about the jvm, please check for malicious programs on your computer

[Harrumph 10]

How would a JVM be more simple than writing hooks in the native language that the game is coded in for the devs?

Integrating the JVM means that mission scripting could also be done in many languages other than SQF. This is an important feature that I highly doubt C++ can do in any practical way. Even if it was possible to script a mission in C++, there are three significant reasons as to why this is a terrible idea:

1. C++ executes natively without a sandboxed environment.

I'd be very hesitant to run randomly compiled native C++ code locally, while the JVM provides a more secure approach through SecurityManagers, etc.

2. C++ is a very complex language.

For hobbyist programmers and mission makers simply looking to get something to work in a basic format, C++ is a horrible, horrible solution.

Using the JVM allows access to much more suitable languages, such as Lua, Python, Ruby and Groovy, all of which have guaranteed interoperability with existing Java libraries and code.

3. C++ is platform dependent.

I realise that C++ itself is a portable language, but this would mean recompiling the code for both windows clients and a Linux server - an awkward solution at best.

I still hope that one day we might get a Linux based server that isn't neglected. Using C++ as a scripting language would be a step backwards here.

[noubernou 77]

Integrating the JVM means that mission scripting could also be done in many languages other than SQF. This is an important feature that I highly doubt C++ can do in any practical way. Even if it was possible to script a mission in C++, there are three significant reasons as to why this is a terrible idea:

1. C++ executes natively without a sandboxed environment.

I'd be very hesitant to run randomly compiled native C++ code locally, while the JVM provides a more secure approach through SecurityManagers, etc.

2. C++ is a very complex language.

For hobbyist programmers and mission makers simply looking to get something to work in a basic format, C++ is a horrible, horrible solution.

Using the JVM allows access to much more suitable languages, such as Lua, Python, Ruby and Groovy, all of which have guaranteed interoperability with existing Java libraries and code.

3. C++ is platform dependent.

I realise that C++ itself is a portable language, but this would mean recompiling the code for both windows clients and a Linux server - an awkward solution at best.

I still hope that one day we might get a Linux based server that isn't neglected. Using C++ as a scripting language would be a step backwards here.

Cool, but all I asked was how is implementing the JVM simpler. It is not.

[pwnstar23 10]

I really don't understand why Java is so great. Java apps run slow. Average PC users don't even know what Java is or why they don't have the latest version. It seems like another barrier for average joe to overcome just to join a multiplayer game.

Java is not slow. Compared to native language like c++ it is slower, but it isn't slow. Compared to sqf it is VERY FAST. Since sqf must be parsed often and at run time. ( you can precompile some stuff ).

Cool, but all I asked was how is implementing the JVM simpler. It is not.

Who cares? That's the developers job not ours. They get paid to implement things even if they are hard. It was their idea to begin with anyway.

[noubernou 77]

Java is not slow. Compared to native language like c++ it is slower, but it isn't slow. Compared to sqf it is VERY FAST. Since sqf must be parsed often and at run time. ( you can precompile some stuff ).

Who cares? That's the developers job not ours. They get paid to implement things even if they are hard. It was their idea to begin with anyway.

SQF is not really that slow. It is slower obviously than native code, but it is very very fast otherwise. ACRE executes thousands of commands per-frame in SQF with very little performance impact. Most people just do not understand how to leverage SQF correctly in the engine.

Second, I care, because it means something more stable and useful if its easier to work into the engine. There are already enough little quirks to make programming on the RV engine a pain in the rear sometimes, throwing a heavy VM on top of it and having to deal with all the crap that goes on between the engine and VM is even more of a burden, both for content developers and the developers at Bohemia.