Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Feature: Compatability with Quarkus. #5665
Yes, we'd love to work with Quarkus! I actually have been hoping to try compiling a trimmed version of JRuby that uses less (or zero) reflection and no invokedynamic. JRuby 1.7 could also fully AOT compile Ruby code to JVM bytecode (9k does not do that yet) so it might be possible to precompile JRuby and your Ruby code.
Are you interested in helping us identify issues and getting JRuby working on Quarkus?
@headius In an attempt to help progress the project forward I'll ask a question. About strategy. The question is a difficult one that involves a non-trivial amount of work. That I can't commit to solving.
The adoption of Quarkus depends on predictable reflection. It is always possible for us to mark up code or configure the build to know about the (relatively few) invasive reflections we have to do. More interesting will be to see how closely the class library followed OpenJDK...for AOT there must be some internal classes they had to rework.
My general thoughts for supporting Quarkus:
This will allow us to have most call sites be direct, possibly inlined and specialized by the GraalVM AOT compiler, while avoiding most reflection.
This will allow us to do many of the Java integration features we depend on, since the reflective parts will already have been handled.
This eliminates the need for invokedynamic, which is unlikely to ever be supported on GraalVM.