Support Desktop OSs Also

Feature
1

Hello,

Is it possible to extend the functionality to the desktop also. You have one code base which runs on Mobile and Desktop alike regardless of OS.

Suminda

2

Dear Suminda,

adding support for desktop OSes is technically possible, please let me provide you with a short summary of the challenges:

  1. Supporting Mac OSX as a target OS is the easiest, it only needs the generation of the Objective-C bindings for OSX and adding support for the OSX target in the build tools and IDE integrations.

  2. Linux support is technically also feasible, since ART runs on Linux/Android already. The bigger question (and required effort) is: which GUI framework should we use: GTK or Qt or both?

    • GTK is C-based so the Nat/J Generator handles it out of the box. It is however based on GObject, so the Nat/J Generator would need a special mode to generate nice bindings for it.
    • Qt is C++, so bindings could be created for it using Nat/J’s C++ support. However, the Nat/J Generator does not yet support C++, and also Qt uses a special flavor of C++ with its own meta object system, which would require explicit support from Nat/J.

  3. Windows support will be feasible after the new LLVM backend is ready, this will be the MOE 2.x release series. We already got ART compiling on Windows and get to Hello World stage (including calling .NET functionality using jni4net) at one point. We would need to update this support to the latest ART that we are now using. It still needs a lot of work, especially in the runtime library and standard class library to use the Windows version of OpenJDK. The question here is (again) how to access the platform:

    • Use jni4net and integrate with the .NET runtime
    • Create a Java binding (“Language Projection”) for the Windows Runtime (which is essentially using the COM ABI)

As you can see, we already thought a lot about this topic, and we will consider adding support for it, if sufficient interest and/or funding is available.

We would be also very interested in your specific use cases (e.g. type of apps) that you would like to develop with the Multi-OS Engine and which desktop OSes are the most interesting to you.

Best Regards,
Gergely

2 Likes
3

One area we are looking at MOE is trying to get better performance and jitter less memory access from our Java / JVM Language code base than possible in the JDK while being portable to other OS and also being usable on the JVM.

As for libraries I think best is borrow Harmony or RoboVM port of Harmony. This way you can keep the license ASL 2.0.

4

Thanks for your input.

In my opinion, Harmony is a dead end: It was abandoned in Apache 5 years ago, and now its last major user (Android) is migrating off to OpenJDK. It would take a huge effort to bring Harmony up to JDK 8 or better JDK 9 level, and it is not really worth it (again, my opinion). Staying in the pre-JDK8 era with stopgaps like Retrolambda is not a good solution either.

Our current plan is to follow the Android development closely, and migrate to OpenJDK in MOE 2.x, when we upgrade to the Android N platform and to the new MOE LLVM backend.

In MOE 2.x we will compile the class library code into a separate shared library (Framework), and the methods will be accessed with dlopen / dlsym only at runtime, very similar to what happens in a regular JVM when the runtime library classes are loaded. This way code derived from OpenJDK will be kept separate, and not mixed with application code.

5

This sounds OK.

Coming back to desktop. Can it be a goal generate code which can outperform (in terms of speed, memory, predictable GC) the Oracle JDK?

6

will it be possible to invoke an another LLVM-visible functions directly (extern “C” like openGL, openAL, e,t,c) form Java code directly without JNI stubs ?

7

Dear Kirill,

It could be possible, but in this case the necessary VM bookkeeping will have to be emitted at each call site. It has to be checked whether this leads to measureable performance increase compared to Fast JNI.

Best Regards,
Gergely

8

Well, assume i have 2500 gl draw calls each frame (about 1000 objects) + 250 calls for ui

2500 * (~10 gl setup calls) + 250 * (5 setup calls)

This is about 26k calls per fame * 2 (VR) * 75 FPS = 4M calls per second.

Do you really think “VM bookkeeping” will not matter on a phone chip ?

9

No, what I meant that we should have measurements to see where are the bottlenecks exactly, and optimize based on that.

Also, for the general case, you can’t just call into a native method, you need the VM to know about it. For special use cases, like calling only OpenGL functions, without ever calling back to the VM from native code, such direct calls may be feasible, but the limitations have to be documented very carefully.

10

Exactly, we are talking about “special use cases, like calling only OpenGL functions, without ever calling back to the VM”
This is what RoboVM has and what was performing very well. Special kind of functions declarations.

Isn`t “@CFunction” kind of this case ?

11

Hi Gergely,

Having Mac OS X support would be fantastic! I also noted in another thread that you are planning on renaming the packages from ios.* to apple.*. Is there a timeline for this? Also when are you expecting the Mac OS X functionality to be available?

I am planning to release my game in the Mac OS X store for a while, but I wasn’t able find bindings for GKLocalPlayer andStoreKit. I assume that should all be possible with MOE. If you need someone to help test the Mac OS X version, I would be glad to help out.

Great work!

Thanks,
Chris

EDIT: just realized this is thread is from 2016 (not 2019). :roll_eyes: Is there support for Mac OS X yet? I couldn’t find any documentation, so I assume it’s not ready or somewhere hidden?