GraalVM is going to allow incomplete classpaths by default

303 views
Skip to first unread message

Foivos Zakkak

unread,
Mar 2, 2022, 9:33:56 AM3/2/22
to Quarkus Development mailing list
Hello all,

Please see https://github.com/oracle/graal/pull/4305 and provide
feedback to the GraalVM team.

The aforementioned PR removes the --allow-incomplete-classpath option
and allows the classpath to be incomplete by default. The same PR
introduces a new --link-at-build-time option which however may not be
used to request all classes on the classpath to be "linked" at build
time (i.e. to make it work like it does now). Instead Quarkus will
need to explicitly define all the classes/packages it wants to "link"
at build time.

Regards,
--
Foivos Zakkak
Senior Software Engineer, R&D Product Middleware
Red Hat
7B4069D929BAAE91C0B3220A0846BFD103F04EA1

Foivos Zakkak

unread,
Mar 2, 2022, 11:50:01 AM3/2/22
to Quarkus Development mailing list
On Wed, Mar 2, 2022 at 4:33 PM Foivos Zakkak <fza...@redhat.com> wrote:
>
> Hello all,
>
> Please see https://github.com/oracle/graal/pull/4305 and provide
> feedback to the GraalVM team.
>
> The aforementioned PR removes the --allow-incomplete-classpath option
> and allows the classpath to be incomplete by default. The same PR
> introduces a new --link-at-build-time option which however may not be
> used to request all classes on the classpath to be "linked" at build
> time (i.e. to make it work like it does now). Instead Quarkus will
> need to explicitly define all the classes/packages it wants to "link"
> at build time.

Apparently I was wrong about that last part.
--link-at-build-time without arguments will be able to be used by
quarkus to bring back the old behavior.
It's only prohibited in native-image.properties that reside in a jar file.

Sorry for any possible inconvenience.

Max Rydahl Andersen

unread,
Mar 3, 2022, 5:49:17 AM3/3/22
to Foivos Zakkak, Quarkus Development mailing list
On 2 Mar 2022, at 17:49, Foivos Zakkak wrote:

> On Wed, Mar 2, 2022 at 4:33 PM Foivos Zakkak <fza...@redhat.com> wrote:
>>
>> Hello all,
>>
>> Please see https://github.com/oracle/graal/pull/4305 and provide
>> feedback to the GraalVM team.
>>
>> The aforementioned PR removes the --allow-incomplete-classpath option
>> and allows the classpath to be incomplete by default. The same PR
>> introduces a new --link-at-build-time option which however may not be
>> used to request all classes on the classpath to be "linked" at build
>> time (i.e. to make it work like it does now). Instead Quarkus will
>> need to explicitly define all the classes/packages it wants to "link"
>> at build time.
>
> Apparently I was wrong about that last part.
> --link-at-build-time without arguments will be able to be used by
> quarkus to bring back the old behavior.
> It's only prohibited in native-image.properties that reside in a jar file.
>
> Sorry for any possible inconvenience.

Thanks for noticing that there could be a issue. Good to see graalvm remove the issue of jars being able to
affect global flags.


/max

>
>> Regards,
>> --
>> Foivos Zakkak
>> Senior Software Engineer, R&D Product Middleware
>> Red Hat
>> 7B4069D929BAAE91C0B3220A0846BFD103F04EA1
>
>
>
> --
> Foivos Zakkak
> Senior Software Engineer, R&D Product Middleware
> Red Hat
> 7B4069D929BAAE91C0B3220A0846BFD103F04EA1
>
> --
> 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/CA%2BXL9jG7fRJvoXUp5%3DAcLFG9Es%3D7WbOVSJoN0rM6EgF4BOOEyQ%40mail.gmail.com.

Sanne Grinovero

unread,
Mar 3, 2022, 6:32:04 AM3/3/22
to Foivos Zakkak, Quarkus Development mailing list
Unfortunately this doesn't implement what I had asked for, and actually seems to make things even a bit more inconvenient.

Expressed my concerns on the PR:

I also don't think it's a good idea to "flip the default" but I understand other frameworks are otherwise struggling to make things work. That's unfortunate, as I believe in the long run it will harm the perception of the optimisations that GraalVM can provide - even if Quarkus can still make the most of it.

Thanks,
Sanne

--

Sanne Grinovero

Architect, Hibernate team

Sr. Principal Software Engineer

Red Hat UK Ltd

Reply all
Reply to author
Forward
0 new messages