Maven Wrapper VS Codename One

Maven also has the maven wrapper: https://github.com/takari/maven-wrapper which accomplishes the same thing.

When creating a new Maven project, Micronaut also configures the Maven wrapper.

IDE's can be fiddly, and anyway I don't think it's good to depend on an IDE for building.

The project could have been set up instead with the "Maven wrapper"(1) which provides "mvn.cmd/sh" scripts at the top level of the project to fetch and run the proper Maven. So after cloning the project, all you have to do is set a proper JAVA_HOME and then do "./mvn clean package". The IDE's will then set themselves up properly if you import the project as a Maven project, and will sync with changes to the Maven pom.xml whenever it changes (Intellij does at least). That's really hard to beat.

(1) https://github.com/takari/maven-wrapper (Being integrated into Maven itself soon).

I got it from here: https://github.com/takari/maven-wrapper

> Now “obviously” the answer is that we should have pegged the version of gradle required to use the script

My first step with either gradle or maven is to install the wrapper generator, which has this effect. After adding the wrapper you invoke it via ./gradlew or ./mvnw in the project doirectory.

It’s not perfect - especially in terms of IDE support - but it’s crucial to at least keeping your CLI builds consistent across team members and in automation.

gradle wrapper: https://docs.gradle.org/current/userguide/gradle_wrapper.htm...

maven wrapper: https://github.com/takari/maven-wrapper

codenameone.com — Open source, cross-platform, mobile app development toolchain for Java/Kotlin developers. Free for commercial use with an unlimited number of projects

This was resolved in this issue: https://github.com/codenameone/CodenameOne/issues/3706

Naturally depends on the use case, yet they work good enough to be in business for 20 years.

https://www.ptc.com/en/products/developer-tools/perc

https://www.aicas.com/wp/products-services/jamaicavm-tools/

https://www.codenameone.com/

Android 5 & 6 (only changed back into JIT/AOT due to long compile times), https://www.infoq.com/news/2014/07/art-runtime/

Unfortunely the best well known, Excelsior JET, is no longer in business, most likely due to GraalVM and OpenJ9 being available as free beer, while PTC, Aicas Codename One are safe in their domains.

There is also RoboVM (https://github.com/MobiVM/robovm) as free beer, however it actually started as a commercial product, and the acquisition from Xamarin kind of stagnated it (naturally).

At Codename One, we were using App Engine when our daily billing suddenly skyrocketed from a few dollars to hundreds. The potential cost was so high it threatened to bankrupt us within a month. Despite our best efforts, including educated guesses and fixing everything we could, we were never able to pinpoint the specific bug. Instead, we had to solve the problem through brute force.

We don't use GraalVM since our project was developed prior to its existence and we aimed for deeper native integration than it can offer: https://github.com/codenameone/CodenameOne

XMLVM, Codename One and iSpectrum (cross compile Java code from an Android app or creating one from scratch

I suggest filing an RFE in the issue tracker.

Thanks. It's always good to get another reminder. Yes, it was reported. u/shannah78 is working on this but we have time until November.

please check this issue https://github.com/codenameone/CodenameOne/issues/3686

We use ParparVM which we wrote. It compiles a subset of Java 8 (sort of) to native by translating the bytecode to C and passing that through XCode. The reason we took this path and not the path of "direct to native", is that it allows for future compatibility.