Initial work on native user API #5610

stuartwdouglas · 2019-11-20T02:55:24Z

First part of #5601

mkouba · 2019-11-20T07:20:36Z

Do you plan on adding a test for @RegisterResourceBundle? Otherwise looks very good!

gsmet

Definitely a very nice user experience improvement.

I added a few comments. Only the typo is a must fix, the rest is really to be discussed.

gsmet · 2019-11-20T09:05:58Z

core/runtime/src/main/java/io/quarkus/runtime/annotations/RuntimeInitialized.java

+ */
+@Retention(RetentionPolicy.RUNTIME)
+@Target(ElementType.TYPE)
+public @interface RuntimeInitialized {


It might be a silly question and I'm not totally convinced myself but should we stick to the Register prefix?

I don't know, I did think about it but I think it reads better this way. 'RegisterAsRuntimeInitialized' could be ok as well.

Actually I wonder if all of these should go in a 'native' package, although it would cause problems with the existing RegisterForReflection.

gsmet · 2019-11-20T09:07:07Z

docs/src/main/asciidoc/writing-native-applications-tips.adoc

+This guide covers some of the annotations that Quarkus supports to help generate native images. In some cases these
+annotations are applied directly to a relevant class, but in others the class that they are placed on does not actually
+matter (e.g. if you are referencing a class in a 3rd party jar). In this case we recommend creating an empty `NativeConfig`
+class somewhere in your application and placing all annotation that control native image generation on it, so they are all


Suggested change

class somewhere in your application and placing all annotation that control native image generation on it, so they are all

class somewhere in your application and placing all annotations that control native image generation on it, so they are all

gsmet · 2019-11-20T09:10:11Z

docs/src/main/asciidoc/writing-native-applications-tips.adoc

+annotations are applied directly to a relevant class, but in others the class that they are placed on does not actually
+matter (e.g. if you are referencing a class in a 3rd party jar). In this case we recommend creating an empty `NativeConfig`
+class somewhere in your application and placing all annotation that control native image generation on it, so they are all
+in the same place.


I wonder if we should have a table here summarizing the annotations so that the user has a global overview of what's possible.

emmanuelbernard · 2019-11-20T09:37:59Z

docs/src/main/asciidoc/writing-native-applications-tips.adoc

+}
+----
+
+In this example only the `ThirdPartyClass` and `ThirdPartyClass` other class are registered, `EmptyClass` is ignored.


I find that a bit counter intuitive. To be fair the whole annotation approach feels counter intuitive. I wonder if we could allow the class enlistment via an API and annotated toe block of code to be called.

@QuarkusBuild public void buildOperations(QuarkusBuildOperations ops) { ops.enlistClassForReflecton(ThirdPartyClass.clas); ops.otherOperations(...); }

Grouping those operations into a single interface looks like a nice idea.

This is actually pretty common in Jakarta EE (annotations that are not directly applicable to the class they are placed on). Some examples:

CDI response producer fields:

@Produces @EntityManager EntityManager entityManger;

This enables EntityManager injection in you application, but it can be literally anywhere and the class it is on makes no difference. Same with things like @DataSourceDefinition.

I do agree that it is a bit weird but your solution does not solve the problem of code affecting the whole app that could be anywhere.

Also we would need both, as for the cases where the class is in your application then an annotation is the easiest to understand.

emmanuelbernard · 2019-11-20T09:38:41Z

docs/src/main/asciidoc/writing-native-applications-tips.adoc

@@ -20,6 +20,14 @@ Please refer to the appropriate section depending on your context.

 GraalVM imposes a number of constraints and making your application a native executable might require a few tweaks.

+=== Quarkus Annotations


Let's mark new features as Preview in both docs and APIs/Annotations until we are happy we will support them for the while 1.x series.

Once we have decided on the API I don't think there is any issue supporting these, they are just a new facade on functionality we already have.

emmanuelbernard · 2019-11-20T09:39:52Z

docs/src/main/asciidoc/writing-native-applications-tips.adoc

@@ -278,9 +302,14 @@ method com.amazonaws.services.s3.model.CryptoConfiguration.<init>(CryptoMode)
 Call path from entry point to com.amazonaws.services.s3.model.CryptoConfiguration.<init>(CryptoMode):
 ----

-If you need to delay the initialization of a class, you can use the `--initialize-at-run-time=<package or class>` configuration knob.
+If you need to delay the initialization of a class, you can use the `@io.quarkus.runtime.annotations.RuntimeInitialized` annotation


Same here for API vs annotation.
Also we should explain why a user would want to do that.

emmanuelbernard · 2019-11-20T09:40:25Z

docs/src/main/asciidoc/writing-native-applications-tips.adoc


-It should be added to the `native-image` configuration using an `<additionalBuildArg>` as shown in the examples above.
+Native mode also supports the notion of 'runtime reinitialization' where static init is run at image generation time, and
+then re-run at startup. This can be done via the `@io.quarkus.runtime.annotations.RuntimeReinitialized` annotation in a


Explain why you would want to do that. It's dry otherwise.

FroMage · 2019-11-20T13:19:53Z

docs/src/main/asciidoc/writing-native-applications-tips.adoc

+[source,java]
+----
+@RegisterForReflection(targets={ThirdPartyClass.class, OtherClass.class})
+public class EmptyClass {


Shouldn't it be NativeConfig then?

emmanuelbernard · 2019-11-22T16:15:30Z

When I looked at the list of subjects, I think while there is value in this extension. It might actually be moot or less important if we really manage to improve #2277

stuartwdouglas · 2020-01-14T00:02:36Z

@emmanuelbernard do we still want this? If not we should close the PR.

emmanuelbernard · 2020-01-14T17:24:54Z

We want it in some form at some point. Whether I would spend our energy on in in the next 2/3 releases, I don't think so.

stuartwdouglas added 3 commits November 20, 2019 13:33

Add ability to discover the hierachy for @RegisterForReflection

9771661

Add @RuntimeReinitialized and @RuntimeInitialized

f57872d

Add the ability to register proxy classes via annotation

a94abc6

stuartwdouglas requested a review from gsmet November 20, 2019 02:55

gsmet requested changes Nov 20, 2019

View reviewed changes

gsmet added the release/noteworthy-feature label Nov 20, 2019

emmanuelbernard requested changes Nov 20, 2019

View reviewed changes

FroMage reviewed Nov 20, 2019

View reviewed changes

Add support for resource bundles

b7ce582

stuartwdouglas force-pushed the native-user-api branch from 2641c9a to b7ce582 Compare November 20, 2019 23:24

stuartwdouglas closed this Jan 14, 2020

gsmet added the triage/invalid This doesn't seem right label Jan 20, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Initial work on native user API #5610

Initial work on native user API #5610

stuartwdouglas commented Nov 20, 2019

mkouba commented Nov 20, 2019

gsmet left a comment

gsmet Nov 20, 2019

stuartwdouglas Nov 20, 2019

stuartwdouglas Nov 20, 2019

gsmet Nov 20, 2019

gsmet Nov 20, 2019

emmanuelbernard Nov 20, 2019

FroMage Nov 20, 2019

stuartwdouglas Nov 20, 2019

stuartwdouglas Nov 20, 2019

emmanuelbernard Nov 20, 2019

stuartwdouglas Nov 20, 2019

emmanuelbernard Nov 20, 2019

emmanuelbernard Nov 20, 2019

FroMage Nov 20, 2019

emmanuelbernard commented Nov 22, 2019

stuartwdouglas commented Jan 14, 2020

emmanuelbernard commented Jan 14, 2020

	class somewhere in your application and placing all annotation that control native image generation on it, so they are all
	class somewhere in your application and placing all annotations that control native image generation on it, so they are all

		@@ -20,6 +20,14 @@ Please refer to the appropriate section depending on your context.

		GraalVM imposes a number of constraints and making your application a native executable might require a few tweaks.

		=== Quarkus Annotations

Initial work on native user API #5610

Initial work on native user API #5610

Conversation

stuartwdouglas commented Nov 20, 2019

mkouba commented Nov 20, 2019

gsmet left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

emmanuelbernard commented Nov 22, 2019

stuartwdouglas commented Jan 14, 2020

emmanuelbernard commented Jan 14, 2020