Is GraalVM polygot feature important?

[Oleksiy Lukin]

Hi, Quarkus developers!

Polyglot is one of the most powerful features of GraalVM and seems that it is absolutely ignored by Quarkus. It does not work properly since the class loader changes in 1.3.0. and now it is broken totally in 1.12.0. Seems that situation is not going to be better because RedHat's variant of GraalVM does not have a Polyglot feature at all. It means that this feature is not important.

I think it IS important to allow support of JavaScript at least because JS support is removed from JDK and the only viable alternative is Graal's Polyglot.

Another thing that was broken by "modern" class loaders is JNI library loading. It is buggy and getting worse from release to release.

I like Qaurkus but I use polyglot features a lot in my projects. It is sad to say, but  I have to start looking for some alternative framework, e.g. MN, that has Polyglot and JNI working properly.

[Sanne Grinovero]

Hi Oleksiy,

thanks for the feedback.

The choice of Red Hat's build of GraalVM to not have the polyglot
features doesn't reflect the strategy of Quarkus, it merely implies
that that team isn't ready/staffed/willing to *support* such a feature
to customers at this point, which is understandable as they offer
amazing SLAs, so they necessarily have to be very cautious.
But that doesn't mean that Quarkus engineers (both from Red Hat and
beyond) aren't interested in making such support an option in the
future - and there should be no problem in using another GraalVM
build.

From my personal point of view, I haven't tested it and I had no idea
that we broke something, so I'd be interested to see more details: I
had no idea that our classloader optimisations would possibly break
the Polyglot feature; is there an issue? Same for JNI libraries - I
actually contributed a fix to GraalVM related to library linking
myself, and I know other colleagues did much more, so I wouldn't say
we disregard such aspects.

I would agree with you that it's an important feature to have and I
can help you champion this cause. May I suggest that if this is
important for you, to add integration tests for such features so to
not have further regressions: hopefully it's going to be a team
effort. If there's integration tests for any feature X, then no one
will intentionally break it, or at least not without extensive debate
here with all users. But first, please create issus and let's see if
we can fix them.

Thanks

> --
> You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/ae61e931-8f6b-417b-af03-2e53e5e8a709n%40googlegroups.com.

[Max Rydahl Andersen]

+1 on what Sanne highlights here.

If you can help add tests for these will go a long way.

and reference issues showing breakage would be great.

/max

> https://groups.google.com/d/msgid/quarkus-dev/CAFm4XO3FrOgxtdO%2Biqc60Ku%2B7Ced_DiGVUNUV4b7n_kPXZ%3DuHg%40mail.gmail.com.

/max
https://xam.dk/about

[Oleksiy Lukin]

Guys, I reported an issue about polyglot a year ago: https://github.com/quarkusio/quarkus/issues/8035
But! It is closed because "it works". It still does not actually. 

I commented and voted on related issues. I created a reproducer app on github and keeping it updated.
https://github.com/alukin/polyglot-test-quarkus

There are similar issues also (open and closed)

https://github.com/quarkusio/quarkus/issues?q=is%3Aissue+polyglot

I used an ugly workaround to make my code work by restoring the default classloader and then returning back one from quarkus.
But even this workaround does not work anymore in 1.12. 
Regarding JNI - simple adding of RocksDB jni jar dependency to the project's POM should work fine because it is absolutely simple and does not use any tricks. But! It works only if I do LD_PRELOAD in native mode. 

So... I do not want to argue.
The only thing I can think of now is to switch to some other framework, where such simple things "just work". Yes, it "just works" in MN.
 

[Max Rydahl Andersen]

i found https://github.com/quarkusio/quarkus/issues/9634 and
https://github.com/alukin/polyglot-test-quarkus

are that the issue you see or something in addition ?

/max

/max
https://xam.dk/about

[Stuart Douglas]

So a proper fix for the test/dev ClassLoader issue just missed the 1.12 release: https://github.com/quarkusio/quarkus/commit/c545fc2eb1e794ed60fbde73818ef3002fe8f910, so if you test with your reproducer against 999-SNAPSHOT the tests will pass.

No idea why this is not working in the fast-jar format, it's CL is much simpler and in theory should not have this problem, so I am going to investigate.

Stuart

--

[Stuart Douglas]

https://github.com/quarkusio/quarkus/pull/15592/files

should fix it, so everything should work properly in the next release.

Stuart

[Falko]

I propose we add a test in CI for this.

We'd probably need a new job since although we do have jobs with GraalVM already, those are about native images and this ployglottopic is not (AFAICS).

WDYT?

[Stuart Douglas]

On Thu, 11 Mar 2021 at 03:58, 'Falko' via Quarkus Development mailing list <quark...@googlegroups.com> wrote:

I propose we add a test in CI for this.

We'd probably need a new job since although we do have jobs with GraalVM already, those are about native images and this ployglottopic is not (AFAICS).

Yea, but like you say it will need to be its own job.

Stuart

 

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/ddcfc315-a07e-4c18-8b48-b9c6d407b9c0n%40googlegroups.com.

[Falko]

https://github.com/quarkusio/quarkus/issues/15615 to tracks the work needed for such a job.

Cheers,

Falko