Idea JVM MFD

[sfpilot]

Hello

i have an idea/if possible request.

First let me just declare one thing. I suck at C++!

Now that we've gotten that out of the way let me say that i am a Java programmer and NOT a C++ programmer. But i do know that it is possible for Java and C++ to work together. So here is my idea:
A JVM Interface MFD.
Basically you would need to Define the screen of the MFD as the Java console. This would either require another method of printing in Java or a direct interface to the Java console in C++. Either of these methods would work but i don't know which would work better. So what would be the advantage of this addon?
Java is a simple language. And i would like to be able to make MFD addon's without having to go through C++.

And before you use the way overused excuse that "Java is slow". I will just say this: "Java was slow", Java is still slightly slower than C++ but not noticeably slower. If you need proof that it is fast enough i suggust you look at the Jmonkey Engine.
Yes that is a fully three dimensional gaming engine written in pure java with a high FPS.

If anyone knows how to make such an MFD, please let me know. I can develop the Java side if someone else can develop the C++ side.

 

[agentgonzo]

Java is a simple language.

C++ is a simple language.

Both java and C++ are turing complete, and the syntax of java was based on C++ (which was in turn based on C). I would consider java and C++ to be as complicated as eachother.

C++ isn't that hard to learn if you know java. I'd wager a shiny new pot of jam that it would be easier to learn C++ than to create this java-C++ hybrid MFD.

 

[Urwumpe]

The main problem would be interfacing Java and Orbiter. You would need a new Java SDK. It is just a bit poor to run Java without access to Orbiter data. And the whole mess of AWT and JavaX is not needed in Orbiter.

 

[Face]

You may be interested in the .NET wrapper here. It is not finished, but you can develope simple vessels with it. Not Java, but still OOP and VM.

You can see the complexity of VM-wrappers for Orbiter interfacing there, too.

regards,
Face

 

[yagni01]

The main problem would be interfacing Java and Orbiter. You would need a new Java SDK. It is just a bit poor to run Java without access to Orbiter data. And the whole mess of AWT and JavaX is not needed in Orbiter.

Essentially correct; you would have to write a Java Native Interface (JNI) adapter for the OrbiterSDK. I considered that in the beginning, as Java is also my primary language du jour, but I bit the bullet and took on the challenge of refreshing my C++. Continue making the transition - its always good to have more tools in the toolbox.

 

[Urwumpe]

Essentially correct; you would have to write a Java Native Interface (JNI) adapter for the OrbiterSDK. I considered that in the beginning, as Java is also my primary language du jour, but I bit the bullet and took on the challenge of refreshing my C++. Continue making the transition - its always good to have more tools in the toolbox.

I would prefer a special VM for running HAL/S or ADA programs, since Java is internally a bit bloated for aerospace applications. But don't ask me on how to develop it. I am already getting my head past temperature limits by writing a C++ implementation of the FCOS of the Space Shuttle.

 

[sfpilot]

i suppose it would be kind of useless, but it would still be neat. and Thank You so much for NOT using the Java is slow excuse!. i think that Java would be simpler to interface with than .net because there are already some Java/C++ wrappers out there.

i guess your right. its probably possible but not worth it. i just wish i could program an MFD in a language i understand better. i don't know why, i just can't figure out C++. i have learned VB, Python, C, Java, even a little LISP, but i just can't understand the one language i really wan't to learn: C++.

oh yes and i forgot to mention bit of INTERCAL .

 

[Hielor]

i suppose it would be kind of useless, but it would still be neat. and Thank You so much for NOT using the Java is slow excuse!. i think that Java would be simpler to interface with than .net because there are already some Java/C++ wrappers out there.

.NET has interopability with native code as a primary language feature.

i guess your right. its probably possible but not worth it. i just wish i could program an MFD in a language i understand better. i don't know why, i just can't figure out C++. i have learned VB, Python, C, Java, even a little LISP, but i just can't understand the one language i really wan't to learn: C++.

C++ is just C with objects. If you really know C and Java, then you already know 95% of C++.

 

[eveningsky339]

Isn't Java an OOP like the C languages?

 

[Urwumpe]

Isn't Java an OOP like the C languages?

Java is even more OOP than C++ because it has no functional language in the background and has a more logical system for polymorphism.

 

[sfpilot]

C++ is just C with objects. If you really know C and Java, then you already know 95% of C++.

thats the odd part. i completely understand Java and i no a lot of C, but even though i understand some C++, it still does not seem like a natural language like java.

i understand stuff like Cout << "Hello world",but i think what confuses me is the classes being two files and then the pointers and references. there just seems to be so much more syntax in C++.

Java is even more OOP than C++ because it has no functional language in the background and has a more logical system for polymorphism.

That is what i love about Java! it is all OOP. there is no such thing as a variable outside a class. and
the best part is that every single variable is a reference variable by default. i don't know if C++ does this.

 

[eveningsky339]

thats the odd part. i completely understand Java and i no a lot of C, but even though i understand some C++, it still does not seem like a natural language like java.

i understand stuff like Cout << "Hello world",but i think what confuses me is the classes being two files and then the pointers and references. there just seems to be so much more syntax in C++.

Some criticize C++ as being bloated. It is, after all, C with "extra stuff" added on. It just takes time to set it, that's all.

 

[Hielor]

thats the odd part. i completely understand Java and i no a lot of C, but even though i understand some C++, it still does not seem like a natural language like java.

i understand stuff like Cout << "Hello world",but i think what confuses me is the classes being two files and then the pointers and references. there just seems to be so much more syntax in C++.

The header file for a class just says "There is this thing, and here's everything you can do to it. You don't need to know exactly how it works internally, but this is the interface." Other files can now #include that header to access the stuff defined in the header, without needing to care about the details.

 

[Urwumpe]

And the best part is that every single variable is a reference variable by default. i don't know if C++ does this.

Luckily not. That behavior is one of the things I hate in Java, because I sometimes don't want references. Also Java does not create references to elemental data types, like int.

In C++, I have many options to define "references":

As pointer, if I want also the option to NOT point at an object (*x), this is similar to the references in Java.
As reference, if I want to be sure that the reference is always pointing to an object (&x).
As smart pointer class using templates or proxy patterns...but this is also possible in Java now.

---------- Post added at 11:01 PM ---------- Previous post was at 10:58 PM ----------

The header file for a class just says "There is this thing, and here's everything you can do to it. You don't need to know exactly how it works internally, but this is the interface." Other files can now #include that header to access the stuff defined in the header, without needing to care about the details.

The dogma is called "Forward declaration". You define the existence and the interface of a class, module, function, etc, before you implement it. This is also a good tool for ensuring that the interfaces are properly used, since you can make the compiler check these for changes.

In Java, you don't have such a option yet, which means the only serious way to get something similar is being excessive with interfaces.