Java

[Harrumph 10]

Myself and several others would like to ask for a 'formal' statement from BIS on the status of Java integration within ArmA 3.

If it has been abandoned, or is 'no longer the focus' as some posts (without citations) seem to indicate, then why is this the case?

It is my opinion that a well integrated scripting solution would be, by far, the most significant enhancement that could be made to ArmA 3. - The reasoning is quite straight forward: it's vastly acknowledged that one of the largest features of ArmA II is the community and addons, so imagine what could be produced with a feature complete general purpose programming language such as Java.

I've done my best to list and describe a few of them on the CIT, but there's been little feedback on that:

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

Object orientation, debugging and compile-time checking are sorely needed tools, please could you tell us if we can expect them. If not, why not?

[eddieck 10]

+1 - I would love to have an answer to this!

[kylania 568]

Considering that the Java implementation in TKOH was apparently severely limited and isn't being developed anymore and that Java is basically a gun to your head I wouldn't be disappointed if it wasn't included at all.

[Harrumph 10]

Considering that the Java implementation in TKOH was apparently severely limited

Yes... That's precisely why the thread is being made? If just a handful of issues (as that thread outlines) are fixed, it'll be in a workable state.

and isn't being developed anymore

I don't see that as an official statement from BIS, and even if they do 'confirm' it, I'd like to know the reason behind it.

and that Java is basically a gun to your head I wouldn't be disappointed if it wasn't included at all.

"Malicious code can break your computer!" Java isn't really different to harmful code in any language in this regard. What the article seems to outline is web based Java attacks, what's to say this would apply to ArmA?

Edit:

I'm not trying to motivate that "WE MUST HAVE JAVA!", only that a proper general purpose programming language is vastly preferable to what we currently have with SQF. Using the JVM allows a huge amount of languages, based on the author's preference, to be used.

Edited September 28, 2012 by Harrumph

[james2464 177]

+1 I would like to hear about this.

[Sealife 22]

+ 1 just some clarification on what to expect ,no java or limited TOH style entry level would do.

[Foxtrop 10]

+1 i want to know! java would be a powerful tool

[AAD10 Pete 10]

Myself and several others would like to ask for a 'formal' statement from BIS on the status of Java integration within ArmA 3.

If it has been abandoned, or is 'no longer the focus' as some posts (without citations) seem to indicate, then why is this the case?

It is my opinion that a well integrated scripting solution would be, by far, the most significant enhancement that could be made to ArmA 3. - The reasoning is quite straight forward: it's vastly acknowledged that one of the largest features of ArmA II is the community and addons, so imagine what could be produced with a feature complete general purpose programming language such as Java.

I've done my best to list and describe a few of them on the CIT, but there's been little feedback on that:

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

Object orientation, debugging and compile-time checking are sorely needed tools, please could you tell us if we can expect them. If not, why not?

I would appreciate an official statement from BIS to this topic too. thx.

[astutavian 3]

Any kind of language runtime that would allow "real" programming languages to be used to create missions etc would be welcome - but I'd rather see something like the Mono VM implemented. Mono and C# grow and progress faster than Java and the JVM, which are somewhat stagnant lately. Plus, C# has language features built in that would be highly advantageous in an asynchronous environment. Consider this piece of SQF script:

[] spawn
{
   While{true} do{
       //Free up thread until player dies...
       WaitUntil{not alive player};

       //...then execute some script...
       _priWeapon = primaryWeapon player;
       _secWeapon = secondaryWeapon player;

       //...then free up thread again until player respawns...
       WaitUntil{alive player};

       //...and execute some more script
       removeAllWeapons player;
       player addWeapon _priWeapon;
       player addWeapon _secWeapon;
       player addAction["Support...","x_scripts\dialog_support.sqf",[],0,false,true,"","_this == _target"];
   };
};

As you can see, it runs an infinite loop that waits for something to happen (in this case, conditions to become true) without tying up the thread. When the condition becomes true, a thread executes the code and then is freed up again until the next time.

This is something that Java is ill suited to do without resorting to callbacks, (which can't even be in the form of true closures because it only has inner classes). With C#, however, you could implement it so that you can write code that looks quite similar to the SQF:

Spawn(delegate
{
   while(true) {
       //Free up thread until player dies...
       await Until(()=> !Player.Alive);

       //...then execute some script...
       var priWeapon = Player.PrimaryWeapon;
       var secWeapon = Player.SecondaryWeapon;

       //...then free up thread again until player respawns...
       await Until(()=> Player.Alive);

       //...and execute some more script
       Player.RemoveAllWeapons();
       Player.AddWeapon(priWeapon);
       Player.AddWeapon(secWeapon);
       Player.AddAction("Support...", ShowSupportDialog, condition: (p, t) =>  p == t );
   }
});

...thus having the best of both worlds.

[Harrumph 10]

...but I'd rather see something like the Mono VM implemented. Mono and C# grow and progress faster than Java and the JVM, which are somewhat stagnant lately.

I appreciate the constructive comments, AstutAvian. However, it would be preferable if we can keep language wars out of this as it's a surefire way to derail the thread.

The fact that there's almost certainly going to be argument about which language to use is a strong indicator of how similar they are. The core idea which is being motivated here is the importance of any general purpose programming language instead of SQF. Java is only mentioned for two reasons:

1. The developers have already promised it
   
2. There has already been work done on integrating it to the engine.
   

If BIS would rather use an alternative that has a similar feature set to java, I'm sure most of us would be happy to just escape SQF.

Edited September 29, 2012 by Harrumph
clarity

[astutavian 3]

If BIS would rather use an alternative that has a similar feature set to java, I'm sure most of us would be happy to just escape SQF.

Definitely - anything that allows us the power of a true programming language and allows us to use existing code libraries will be welcomed by everyone, whether or not it's their favorite choice. Did not mean to derail your thread.

[wolffy.au 9]

+1 for hearing an official statement.

I've done my best to move to OO programming on SQF, while I wait for JVM. See here:

http://www.ausarma.org/blog/4/entry-31-object-oriented-sqf-part-1/

When BIS annouced the inclusion of a Java engine in Arma 3, I was excited. I had developed in Java back in the mid-90's and its where I learnt about the usefullness of object orientation (OO) and interfaces (polymorphism).

Unfortunately, there have been rumours that Java in A3 may be delayed. This posed a real problem for us with MSO, as we were looking to re-architecture the project, take advantage of more readable code, more reusable code, testing harnesses which should create overall better quality game mode.

So, I came up with a methodology to allow us to start creating OO classes and common interfaces in SQF. This would allow us to get the benefits of OO and depending on the outcome of Java in A3, either easily convert to Java OR continue to use OO-SQF in the meantime.

[lev 21]

Any kind of language runtime that would allow "real" programming languages to be used to create missions etc would be welcome - but I'd rather see something like the Mono VM implemented. Mono and C# grow and progress faster than Java and the JVM, which are somewhat stagnant lately. Plus, C# has language features built in that would be highly advantageous in an asynchronous environment. Consider this piece of SQF script:

[] spawn
{
   While{true} do{
       //Free up thread until player dies...
       WaitUntil{not alive player};

       //...then execute some script...
       _priWeapon = primaryWeapon player;
       _secWeapon = secondaryWeapon player;

       //...then free up thread again until player respawns...
       WaitUntil{alive player};

       //...and execute some more script
       removeAllWeapons player;
       player addWeapon _priWeapon;
       player addWeapon _secWeapon;
       player addAction["Support...","x_scripts\dialog_support.sqf",[],0,false,true,"","_this == _target"];
   };
};

As you can see, it runs an infinite loop that waits for something to happen (in this case, conditions to become true) without tying up the thread. When the condition becomes true, a thread executes the code and then is freed up again until the next time.

This is something that Java is ill suited to do without resorting to callbacks, (which can't even be in the form of true closures because it only has inner classes). With C#, however, you could implement it so that you can write code that looks quite similar to the SQF:

Spawn(delegate
{
   while(true) {
       //Free up thread until player dies...
       await Until(()=> !Player.Alive);

       //...then execute some script...
       var priWeapon = Player.PrimaryWeapon;
       var secWeapon = Player.SecondaryWeapon;

       //...then free up thread again until player respawns...
       await Until(()=> Player.Alive);

       //...and execute some more script
       Player.RemoveAllWeapons();
       Player.AddWeapon(priWeapon);
       Player.AddWeapon(secWeapon);
       Player.AddAction("Support...", ShowSupportDialog, condition: (p, t) =>  p == t );
   }
});

...thus having the best of both worlds.

Wouldn't conditions satisfy what you are looking for? This exists in Java as well:

http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/locks/Condition.html

Semaphores also do the trick if you prefer those:

http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/Semaphore.html

[Slapstick 10]

Myself and several others would like to ask for a 'formal' statement from BIS on the status of Java integration within ArmA 3.

If it has been abandoned, or is 'no longer the focus' as some posts (without citations) seem to indicate, then why is this the case?

+1

It would be nice to hear some sort of formal statement, or an informal statement from a knowledgable source (I.E. a BIS employee), about the future of the Java API. It seems a shame to invest so much effort, tout Java as the "next great thing", and then just let it languish with no further comment...

[astutavian 3]

Wouldn't conditions satisfy what you are looking for? This exists in Java as well:

http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/locks/Condition.html

Semaphores also do the trick if you prefer those:

http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/Semaphore.html

The OP has asked us to avoid derailing his thread so I'll keep it brief: those constructs exist in most languages but they are blocking, rather than non-blocking operations - they tie up the thread for the duration of the wait.

[ruhtraeel 1]

I appreciate the constructive comments, AstutAvian. However, it would be preferable if we can keep language wars out of this as it's a surefire way to derail the thread.

The fact that there's almost certainly going to be argument about which language to use is a strong indicator of how similar they are. The core idea which is being motivated here is the importance of any general purpose programming language instead of SQF. Java is only mentioned for two reasons:

1. The developers have already promised it
   
2. There has already been work done on integrating it to the engine.
   

If BIS would rather use an alternative that has a similar feature set to java, I'm sure most of us would be happy to just escape SQF.

I too would like the scripting to be done in Java, or C#. They're both reasonably similar to each other, but at least it's one of those 2 and or other similar alternatives.

[Alwarren 2767]

I don't really care what language is used, but I'd like to see one that is:

1. Reasonably reliable to parse out-of-runtime to prevent syntax errors during editing already.

2. Can be externally debugged with an IDE like Eclipse or NetBeans, or at least a good internal debugger.

With SQF right now, some errors are hard to track down since the language itself is weird (no offense intended). I think the above two points are pretty important for a more streamlines development.

[RichardStallman 1]

This is yet another clear example of the evils of proprietary software oppressing the users by restricting their freedoms.

I too, would be in favor of a wholly free scripting solution such as openJDK or the mono VM, and urge BIS to respond on this issue.

[eddieck 10]

I asked Dwarden on Skype about this. The answer was: no comment currently, and not for some time. Hopefully the "not for some time" means it's still planned.

[Alwarren 2767]

This is yet another clear example of the evils of proprietary software oppressing the users by restricting their freedoms.

I too, would be in favor of a wholly free scripting solution such as openJDK or the mono VM, and urge BIS to respond on this issue.

Richard Stallman, eh?

I don't think this is a question of free vs. proprietary. It's more of a question of the language itself. I don't really care whether the scripting language is free or not as long as it gets the job done, I just would like the possibility of better pre-runtime error discovery and better runtime debugging support, that's all.

[Harrumph 10]

I asked Dwarden on Skype about this. The answer was: no comment currently, and not for some time. Hopefully the "not for some time" means it's still planned.

This is a woefully inadequate response. It's been over a week since the creation of this thread with no answer from BIS. This is both worrying and frustrating. If the original question could be answered instead of this pointless evasiveness, I for one, would certainly be happier.

Edited October 5, 2012 by Harrumph
grammar

[dmarkwick 261]

This is a woefully inadequate response. It's been over a week since the creation of this thread with no answer from BIS. This is both worrying and frustrating. If the original question could be answered instead of this pointless evasiveness, I for one, would certainly be happier.

Well, pragmatically I don't see how it could affect you either way: either it will or it won't, and having *some* information now will do what exactly? All anyone can do is post what they've seen or heard, no more :)

[eddieck 10]

This is a woefully inadequate response. It's been over a week since the creation of this thread with no answer from BIS. This is both worrying and frustrating. If the original question could be answered instead of this pointless evasiveness, I for one, would certainly be happier.

Agreed. Even a "we would like to work on it, but at this time can't make any guarantees" would be nice. (I have a feeling that's what's behind the "no comment.")

[paecmaker 23]

This is a woefully inadequate response. It's been over a week since the creation of this thread with no answer from BIS. This is both worrying and frustrating. If the original question could be answered instead of this pointless evasiveness, I for one, would certainly be happier.

Well, they are not forced to answer to the threads, look around there are many threads which it took a long time before we got an official statement. They give us more facts when they feel ready to, not when we demand them.

[Sealife 22]

Myself and several others would like to ask for a 'formal' statement from BIS on the status of Java integration within ArmA 3.

A reminder about the Thread reason : no point in he said : i said , even arma2 AI could give us an answer like that if it was desired.

Lets await official and formal , anything else just isnt helping.