com.oracle.svm.core.annotate.* annotations in separate artifact

[Jurrie]

My project needs to include com.oracle.substratevm:svm:1.0.0-rc12, because I need to use the com.oracle.svm.core.annotate.* annotations. However, this transitively includes a whole lot of other dependencies. I don't need those. I can exclude them of course, but it would be cleaner if the annotations were in a different package with no transitive dependencies. Something like com.oracle.substratevm:svm-annotations.

[cstancu]

I think #1003 (comment) applies here as well.

[Jurrie]

Hi @cstancu, I don't think I agree, as the 'provided' scope still gives a whole lot of extra dependencies in the project. If you only want to use the annotations to make your application work with GraalVM native-image, those other dependencies are not needed (and only introduce the risk of actually using them). What's your take on this?

[olpaw]

@Jurrie having com.oracle.svm.core.annotate.* in a separate artifact with no other dependencies makes sense. We will implement that change in a future release.

[Jurrie]

@olpaw as my applictation progressed to be compatible with GraalVM's native-image, I also needed an @AutomaticFeature. For this annotation, I needed the org.graalvm.nativeimage.Feature interface as well. That's in a different package. So, I guess we would need a separate package with all stuff needed (classes, interfaces, annotations, ...) to make a random Java application compatible with native-image.

[christianwimmer]

I don't like to separate the annotations in a separate artifact because in an ideal world, it should not be necessary to use them to get an application running as a native image. Substitutions are a workaround until the substituted method itself is changed, which can be a lengthy process when it is in a third-party library.

Note that you also should not use @AutomaticFeature, but instead list the feature class explicitly using the --features=... option. You can do that in a native-image.properties file that you include in your application or library .jar file.

[Jurrie]

Hi @christianwimmer. I agree: in an ideal world, those annotations should not be necessary. But why is that an argument against splitting them out in a separate artifact? On top of that: this is not an ideal world. You can not argue with the fact that those artifacts are necessary now. They are meant to be used as a workaround, so why not ease the use by reducing the transitive dependencies?

You also say that @AutomaticFeature should not be used. Where is this documented? And what is the reason behind it? And why is @AutomaticFeature still available?
I actually like the fact that @AutomaticFeature is automatically picked up! Having that stuff in a resource (native-image.properties) instead of in the source is far more fragile. For the same reason, I keep away from placing reflection information in a JSON file, and favor org.graalvm.nativeimage.RuntimeReflection.