Quarkus is described as a Kubernetes Native Java stack, which I think is unfair marketting hype given that there is no code specific in it for Kubernetes, to my knowledge (ignoring deployment scripts and Maven plugins, etc).
Anyone tried launching it in a different Docker orchestrator? Specifically, Hashicorp Nomad? How about Marathon? Bonus points for Swarm, of course.
If this is possible, should the documentation be updated to remove such marketing words as "Kubernetes native"?
I expect you may be a little bit right about the marketing hype as you call it, although I do not understand why Quarkus would need to tie itself to Kubernetes in order to call itself a Kubernetes Native Java Stack. As you seem well aware:
Kubernetes has become the de-facto standard container orchestration solution with its many certified implementations, like the ones mentioned in your link from the comments. According to many opinions, it has won the war on container orchestration.
The original group starting the Quarkus project (i.e. Red Hat) stated:
The goal of Quarkus is to make Java a leading platform in Kubernetes and serverless environments while offering developers a unified reactive and imperative programming model to optimally address a wider range of distributed application architectures.
Red Hat has a invested/sponsored the related technologies like (in random order):
And Quarkus is just one of the ways they are trying (quite successfully) to apply new technological advancements in Java (like the module system, ahead-of-time-compilation) as implemented in both OpenJDK and GraalVM to improve the integration with modern hosting and deployment solutions, like Kubernetes. For more see e.g.: these blogs
Some of the more simple, lower level changes necessary to improve the behaviour of the Java Virtual machines are related to certain Linux features (like cgroups) and have already been fixed in the past.
However, one of the greatest challenges to get existing Java applications to run on GraalVM's Substrate VM for native images is that it does not (yet) support all of the features that popular Java frameworks (e.g. Spring and Hibernate) rely on, as documented in this long list
So, as I understand, in order to fix that quoting from here they developed Quarkus:
[to work] equally well on any JVM and as GraalVM native image executables. And you can build native images with no hassle, on your side.
Is this all about marketing? No, I don't buy that. I think it is about having a clear vision and goal by the projects leadership.
I'll give you that it would be a great addition to more clearly describe which platforms are considered a compatible target, have had some kind of formal testing, and are thus "supported;" but for that kind of information you are probably looking at formal support contracts on Quarkus and more importantly: GraalVM (probably from Red Hat, Oracle, IBM and friends).