It's would be nice to have Groovy supported. It has smooth Java integration, relatively short learning curve and support for unit testing.
Version 3 is being worked on to support the new features that have emerged since Java 9, with support for lambda expressions and JPMS, for instance.
Also, Vert.x has Groovy support and it would be consistent that Quarkus also supports it. Groovy has an average of 12 million downloads per month, so it is considered a popular and growing language.
Given the fact that everything that Quarkus supports works OOTB on GraalVM native images, I think that it would be very difficult (perhaps impossible?) to make Groovy work properly
With current Groovy 2.x I agree that it is very difficult (https://speakerdeck.com/wololock/groovy-and-graalvm). I believe in a better horizon with version 3. I suggest leaving this issue open as we follow the evolution of Groovy in the coming months.
Please, check this article - it might be helpful for this task: https://e.printstacktrace.blog/graalvm-and-groovy-how-to-start/
This probably isn't as hard as it seems. Just a matter of appending the things needed to get groovy working properly on GraalVM.
This issue/pullrequest has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This is definitely something we want to keep around as a "really like to have". marking as pinned.
I have seen Groovy being used extensively in production Camel applications. Groovy makes mapping objects super easy and efficient. It is the XSLT of the JSON world for a lot of people. This is not a nice to have this is a requirement to be taken seriously as a contender for Springboot/Karaf etc.
IMHO JBang (https://www.jbang.dev/) is much nicer than Groovy and already runs Quarkus applications
@gastaldi it might be nicer but converting an entire system where the mapping have been done in Groovy from scratch is not going to fly. These services are currently working as is if it was a simple shift and lift to Quarkus no worries but redeveloping those mappings over into JBang is money. Note that this is particular to Camel.
@Namphibian thanks for the feedback!
Yes, I agree with you, I was talking about greenfield applications.
It's a good thing we have https://github.com/apache/camel-quarkus/issues/1746 (as part of Camel Quarkus), since we're talking Camel use cases here.
I don't think jbang would help here. Jbang is about bootstrapping the app from simpler means.
Here the ask is that one can use groovy classes similar to how we support kotlin, Scala etc.
Since groovy is quite compatible with Java and can compile to a .class I'm wondering if not at least something like using it for mapping or other auxiliary work would "just" work at least in Java mode ?
Native mode might be more challenging.
Groovy should definitely just work with Quarkus apps in JVM mode. Not sure about how compatible the latest Groovy versions are with native mode though...
Yeah look I love the Qaurkus project. And I am dying to push it into production just several key features are not there quiet yet.
What key features do you have in mind @Namphibian ?
Most helpful comment
This is definitely something we want to keep around as a "really like to have". marking as pinned.