Regarding the deprecation and ultimately removal of --initialize-at-build-time=

[zakkak]

Hello,

I would like to ask about the justification behind the deprecation and ultimately removal of --initialize-at-build-time= in 22.0 (see 5013ca7)

Is this to prohibit the use of the flag (in that specific way) in order to prevent issues like #3417?
Or is it based on something new coming in like an improved analysis that will result in more aggressive, yet reliable, compile-time initialization?

Thanks

cc @vjovanov

[borkdude]

I also would like to know more about this. Clojure projects rely on this feature. As far as a I know, it is impossible to build a Clojure project without this option. I asked about this to @shelajev and he told me to ping @vjovanov about this. Should we be concerned that 21 is the last version that will support Clojure projects (like babashka and clj-kondo, which have grown quite popular over time), or does the warning just mean that there will be another way to accomplish the same behavior that we got with this flag in 21, etc?

I'm willing to "sit down" with one of the GraalVM devs and walk through what is needed to compile a very simple Clojure project and what errors you see when not using the --initialize-at-build-time option.

[borkdude]

Ah, that's interesting, thanks, I'll have a closer look when I have time.

[luontola]

For example, I'm currently writing an AWS Lambda function. clojure-native-image-agent reports about 5000 classes. After ignoring all Clojure functions etc. it's about 1000 classes. The code uses AWS Java SDK, but the tool reports only these 10 classes. If it would actually report all the classes that the application uses at runtime, there would be hundreds of com.amazonaws classes.

com.amazonaws.AmazonWebServiceRequest
com.amazonaws.HandlerContextAware
com.amazonaws.ReadLimitInfo
com.amazonaws.client.builder.AwsClientBuilder
com.amazonaws.client.builder.AwsSyncClientBuilder
com.amazonaws.services.kms.AWSKMSClientBuilder
com.amazonaws.services.kms.model.DecryptRequest
com.amazonaws.services.lambda.runtime.Context
com.amazonaws.services.lambda.runtime.RequestStreamHandler
com.amazonaws.services.lambda.runtime.api.client.AWSLambda

[borkdude]

I made an issue here to investigate if we can combine both approaches:

• Configure during native image build (clj-easy/graal-build-time)
• Use Java agent (or another way) to detect transitively instantiated classes (luontola's approach)

One question that arises from this for @thomaswue: could GraalVM have an option to automatically include transitively instantiated classes at build time, in addition to the trace option? That would save us from building this tool in the first place. I guess the reason not to would be that it would be too easy to do this?

[vjovanov]

It would be convenient, however, this would lead to accidental errors as unknown classes get initialized. Also, this is not trivial to do as it is hard to know exactly what are the transitively instantiated classes.

[borkdude]

I agree the tool should emit warnings about classes that are being pulled in unexpectedly.

[fcurts]

How are those libraries referenced, is it via maven artefacts?

Yes.

Is there a way for those libraries to declare themselves as "build time initialization required"?

These are OSS libraries. It may make sense for these libraries to declare whether they want to be initialized at build time, but for our Truffle language I wouldn't want to rely on this. If there's no general wildcard, we'll probably have our build generate the list of packages.

Does it also work with the automatic detection when nothing is specified

We've used --initialize-at-build-time from day one and haven't tried anything else. The most critical build time initialization is certainly for our own code (e.g., parse/initialize our Truffle language's standard library).