@AutomaticFeature annotation deprecation warning from GraalVM native-image build

[lread]

Just noticed the following warning from a rewrite-clj native-image test build:

Warning: Feature class InitAtBuildTimeFeature is annotated with the deprecated annotation @AutomaticFeature. Support for this annotation will be removed in a future version of GraalVM. Applications should register a feature using the option --features=InitAtBuildTimeFeature

Thought it would be good to record here as we might have to actually act on it someday.

[borkdude]

Yeah, probably just documentation that users should add that flag to their build?

[borkdude]

I think it might be better to add an explicit package to that class as well.

[lread]

Yup and yes.

This is technically a breaking change.

So might as well go to a v1.x release.

[borkdude]

I don't think this is a breaking change since users didn't have to reference the class name before, it was automatic.

[lread]

But the build interface will have changed, no?

After users bump graal-build-time, builds will break if they don't take action of adding --features=.....
(assuming that we also remove the @AutomaticFeature annotation which is slated for removal by Graal team).

The break is imposed by changes to Graal, but still breaking from a user perspective, I think.

[borkdude]

Right, but that's not a breaking change in our library

[borkdude]

Anyway, I'm fine with a 1.0.0 release :)

[borkdude]

Also, I think it might be good to move to io.github instead of com.github

[lread]

@borkdude, for the io.github scheme I see your old question on Slack:

For a library coordinate, do you prefer com.github.foo/lib or io.github.foo/lib or don't care? Tag with ⬅️ for the first, ➡️ for the second or 🤷 with don't care.

And Alex Miller responded with:

I prefer the latter because it maps to the web page you can publish from the project (which maybe is the seed of an ownership verification scheme)

Is that still the primary benefit?

(Totally fine with this btw, just trying to understand what problem we are solving)

[borkdude]

The problem is that everyone seems to have shifted to that, but it doesn't really matter that much

[lread]

I'm making a sweep update to graal-docs, clj-easy/graal-docs#58.

I may as well tackle this one so I can use something not-deprecated in examples.

[lread]

I think I'll stick with com.github for the artifact so that tools like antq can discover the new version.

The new version won't work for folks without any changes, but at least they'll be more likely to learn about it. And the CHANGELOG/README will explain.

Does that make sense to you too?

[borkdude]

Yeah, let's stay with com.github.

[lread]

Implementation note: now that we aren't using a java annotation, thought it might be nicer to switch our java source to clojure source and use :gen-class. It did not work out (something to do with default interface methods).
Sticking with java source.

[lread]

Currently our fully qualified Feature class is InitAtBuildTimeFeature (it is package-less).

New name candidates:

1. clj_easy.graal_build_time.InitAtBuildTimeFeature - keeps old name but adds package
2. clj_easy.graal_build_time.InitAtBuildTime - it will be obvious it is a feature, we can drop the suffix
3. clj_easy.graal_build_time.InitClojureClasses - describes specific goal
4. clj_easy.graal_build_time.InitClojurePackages - describes actual work
5. clj_easy.graal_build.time.ClojureTweaks - generic name, allows Feature to take on additional work in some later version if need be.

Because this name will be now specified on the native-image command line it deserves a bit of thought.

I seem to like the package name (as I haven't shown any alternatives!).
My wip is currently using option 3 but am very open to ideas/feeback/suggestions.

[ericdallo]

I like both 3 and 4 as make clear to users what will do as it's what they care that the feature will do

[borkdude]

4 would be the best I think

[borkdude]

or 3, also fine, agreed :)