Hi Kevin,
these are all good and valid questions. The primary scope of Jemo is to be a runtime for Java development on public / private / hybrid cloud environments, of late we have coalesced the infrastructure for Jemo around Kubernetes so OpenShift / Kubernetes is the preferred infrastructure model on which to run Jemo nodes (containers).
Jemo was originally a platform targeted at delivery hyperscale enterprise integrations (so more a competitor to Dell Boomi or MuleSoft Anypoint), it did so by providing an SPI interface layer to public cloud providers such as AWS, Azure and GCP and incorporating a distributed computing paradigm allowing for high speed asynchronous programming and distributed work models.
So the reason Jemo has its own programming model is simply to accommodate for it's HPC origins (these are not expressed by runtimes like Microprofile and JakartaEE). This being said we realise that few will adopt the native Jemo programming model as will instead opt to use Microprofile or JakartaEE so it is our desire to allow applications written with both models to run unaltered on the Jemo runtime. So we will neither extend nor complete with these models but aim to embrace both and we would encourage any extensions to be contributed directly through the core projects and then implemented in Jemo.
With regard to Quarkus and Micronaut, Jemo aims at using a different model based on intelligent class loading and unloading and deploy time forensics to achieve fast startup times and low memory consumption. We are not using AOT in Jemo but are instead introspecting applications at the time they are deployed and loading the necessary code to service events when necessary and unloading that code when Jemo no longer sees the need to retain it in memory, we store all of the code base in S3 or similar so that all containers are stateless and equal. (i.e. in Jemo any container can run any Jemo application, we do this because one of our targets is increasing application density in the cloud). We don't think that Jemo is the right answer to all problems which we believe the AOT engines solve better. So we see Jemo as complementary to these two platforms and being able to deliver better compatibility for those applications which cannot be compiled through AOT but still want to run within a stateless container environment.
Our view with Jemo is to build a homogeneous computational cluster for Java applications that provides unparalleled application density a containerised deployment model and eliminates the vendor lock-in to public cloud services. We plan to leverage the work of the CNCF on Kubernetes as well as other Eclipse Foundation projects like Microprofile, JakartaEE, Jetty and others where possible to obtain this goal.
I hope this helps to clarify and hopefully motivates you to help us on our journey.
Chris.
