Does multi-os-engine have a roadmap?

Feature
1

Hello, Multi_OS-Engine is great! Does mutli-os-engin have a roadmap?
Now Google releases android 7.0, Will Multi-OS-engine build on android 7.0’s new runtime?
After 1.1 release, If MOE will build on android 7.0, I will be very good.

Thanks!

2

Dear Radxe,

there are currently 2 branches of MOE in development:

  • The main branch (from where 1.1 and the future 1.x releases are made) is based on Android M.

  • We also have a second branch named moe-windows-bitcode, which will become the MOE 2.x version. This one is already based on Android N, and it will include a new LLVM based backend for ART to support bitcode. The “windows” in the branch name refers to the fact that this branch has some preliminary support for Windows, but currently we are concentrating on getting it ready for iOS, and the Windows work will be picked up afterwards, when there is demand for it.

Regarding roadmap: We are planning the releases in the GitHub issue tracker: https://github.com/multi-os-engine/multi-os-engine/issues

We plan to do a release every 4-6 weeks: 1.2 will arrive in September, 1.3 in October and so on. We will release 2.0 “when it is ready”, but once we have the basics running, we will publish the code on the development branch, so others can join the effort as well.

We welcome every contribution to the project. We are now working on setting up the Gerrit Code Review system for the project, and we will accept the contributions through Gerrit.

Best Regards,
Gergely

1 Like
3

Dear Gergely,
Wow, then we can use it to develop AOT windows native exe, MOE 2.x will be great!
About Bitcode support, robovm can convert class to bit code, can MOE use it to support bitcode ?
RoboVM use soot as a optimization framework, can MOE use it to optimize? I feel the robovm app runs more fastly, maybe because of soot.
if we use some RoboVM features, maybe we can get MOE 2.x more quickly.
Thanks, I like MOE!
Best Regards.
Radxe

4

Dear Radxe,

About Bitcode support, robovm can convert class to bit code, can MOE use it to support bitcode ?

Such direct code sharing with RoboVM is not possible. While RoboVM uses LLVM, its runtime is quite different from Android ART, that is used in MOE.

RoboVM use soot as a optimization framework, can MOE use it to optimize?

It should be straightforward to add Soot to the moe-gradle plugin as an additional optimization phase. I opened an issue and we will see when we can implement it.

I feel the robovm app runs more fastly, maybe because of soot.

Do you have a concrete place / test case where the MOE version seems slower to you? In our earlier benchmarks performance was on average on par with RoboVM,

Best Regards,
Gergely

1 Like
5

Dear Gergely,
You are kindly, thanks.
I have some simple examples, when I use robovm to test it on iPhone 4s, it runs OK, but MOE version need near 4 ~ 5 seconds to startup, I just feel, no benchmarks.
Another idea, for runtime library, there are MOE, robovm, openjdk9 mobile, can we combine android 7 (gpl and class path exception) with these library (special openjdk9 mobile for iOS, it’s GPL and ClassPath Exception license, it has complete implements, but it is based on jdk9 which support modular)?
I use MOE 1.0, when MOE 2.x, do I need to do some migration?

MOE is now the only true useful tool to develop iOS app using JAVA, I really hope MOE will be better and better!

Thanks!

6

Great job! nice if we can have a look the benchmarks. Love MOE

7

Dear Radxe,

could you please share this example with us (e.g. in a private message)?

About the runtime library: MOE is using the runtime library from Android, which for Android M (MOE 1.x) is based on Apache Harmony, and for Android N (MOE 2.x) is based on a heavily customized OpenJDK 8. We are trying to keep the MOE code as close to Android as possible to minimize the differences between the 2 platforms. We hope, that Android will move to JDK9 soon, so we can use that going forward.

Migration paths: we will try to keep the migration as easy as possible. The MOE 1.x and 2.x branches will be set up, that they will work as mostly drop-in replacements: you just change the Gradle plugin dependency version and things should work as expected.

However, you should prepare for a breaking change in MOE 1.2: We are going to rename the class names from ios.* to apple.* in preparation for supporting other Apple platforms like macOS or tvOS later. We know that this kind of migration is always painful, but that’s also the reason why we want to do it as early as possible.

Best Regards,
Gergely

1 Like
8

Dear Gergely,
I create an iOS app using MOE wizard, and then run it on my iPhone 4s, the startup time is near 4s, maybe my iPhone4s is too old.
Gergely, in fact, breaking change is not problem, we like MOE, I can accept breaking change in MOE1.2 and MOE 2.x.
MOE is only full feature tool, it is best, I think MOE2.x will be great.
I will alway support MOE!
Best Regards
Radxe