Yes, we are planning direct Swift support with Nat/J v3. I will write more on this in the next update, but just to manage your expectations, I think it will be ready only end of Q2 2020. It requires a complete overhaul of how Nat/J works, and how the different languages are plugged into it. We plan to do the development in the open, so contributions will be very welcome.
@kisg are you planning to improve on the source code mapping back to exception stack traces?
I have several kinds of mysterious crashes in MOE internals that only happen at the user’s devices, so I only have crash reports pushed to Fabric and they aren’t that helpful.
Any plan on porting the latest android vm that brings full Java8 support?
No direct plans, but I know what you mean, If there is a crash in native code generated from Java, there is no meaningful stacktrace currently.
If it is not yet up on GH, could you please create a feature request here: https://github.com/multi-os-engine/multi-os-engine/issues
Yes, it would be nice. Of course it is also a lot of work, so contributions will be very welcome.
The VM landscape has also changed a lot with the arrival of SubstrateVM from the Graal project.
One of the strengths of MOE is its modularity. When we started its development, it was an important design decision, that the VM can be replaced if something better than Dalvik (at the time) comes along. So we switched to ART when it became open source almost right away.
I am interested in taking MOE into a direction, where multiple Java runtimes are supported (ART, MobiVM, SubstrateVM, … etc.) and the developer can choose the best fit for her project.
I will write more on this in an upcoming MOE Update post. I am also very interested in your take on this, so I hope that there will be a lively discussion in the comments.
Thank you @kisg . There is an old report at https://github.com/multi-os-engine/multi-os-engine/issues/11
Not sure if anything had changed since then and in any case, I’d be interested to learn how to interpret the current stack traces down to the root cause of issue. Some crashes may seem as issues in the generated code or some MOE runtime, but I can’t say for sure.
Hi @kisg , I would like to know if the september update will be available soon? I am actually locked on my app and I really rely on this update…
Hi! If you only blocked because of latest IDE and SDK updates, you can use this
Sorry for the delay, we should be ready with the release by the end of this week.
Thanks for your reply. We have successfully unlocked the situation with the gradle plugin of the community
The aim of my question was also to know the progress of the official release and thanks to @kisg’s reply, I know it will be there soon.
Quick update: we are progressing with the release, just needs a couple days more time, please stay tuned, I will keep you posted.
Any news regarding the new release?
Hi Gergely, is there a new planing available for September/October release?
Hi Michael (and Kees),
the plan is to finally finish this first update. I am sorry that it takes longer than I expected. The Build VM is finally up, so we are getting there.
Just one quick update: we received the official consent (and CLA) from @Noisyfox to integrate his changes into the official release of MOE. I also invited him to become a committer in the MOE project.
Thank you @Noisyfox for all your work on MOE so far, and we are looking forward to many more from you in the future.
wow! that great!! can’t wait for the up coming release
Then I will look into publishing really useful code I wrote for my apps on github
Glad to hear moe is reviving! Hopefully moe will support watchOS in his future update. There are true potential in this area
Quick update: I am debugging an issue with the Nat/J config file editor plugin, hope to resolve it soon and can continue with the release.