From 639ff441a505fc588b73a81139be845984b90ab4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Galder=20Zamarren=CC=83o?= Date: Tue, 12 Jul 2022 08:28:11 +0200 Subject: [PATCH] Add tip on common Java API overrides --- .../writing-native-applications-tips.adoc | 26 +++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/docs/src/main/asciidoc/writing-native-applications-tips.adoc b/docs/src/main/asciidoc/writing-native-applications-tips.adoc index 569c26f06d07f..103fdff6382e3 100644 --- a/docs/src/main/asciidoc/writing-native-applications-tips.adoc +++ b/docs/src/main/asciidoc/writing-native-applications-tips.adoc @@ -543,6 +543,32 @@ The nice advantage of CDI-based singletons is that your class initialization is so you can freely decide whether it should be build-time or run-time initialized, depending on your use case. +=== Beware of common Java API overrides + +Certain commonly used Java methods are overriden by user classes, +e.g. `toString`, `equals`, `hashCode`...etc. +From a GraalVM points-to analysis perspective, +what happens in these method overrides matters, +even if the application does not explicitly call them. +This is because these methods are used throughout the JDK, +and all it takes it's for one of those calls to be done on an unconstrained type, +e.g. `java.lang.Object`, +for the analysis to have to pull all implementations of that particular method. + +So, what can you if the implementation one of these methods is giving trouble during native executable build time? +The best thing would be to come up with parallel methods that don't override super class methods. +E.g. instead of defining `String toString() { ... }` method, +create a `String show() { ... }` method. +If you can't modify the source code to apply this suggestion, +you might be able to use GraalVM substitutions, +but these are quite brittle and can break easily. +So if you end up having to use these, +you should try use them only temporarily, +until you have the chance to rework/rewrite the code to avoid the original issue. + +The best way to find out what parts of the source code get included in the analysis +is by looking at the <>. + [[native-in-extension]] == Supporting native in a Quarkus extension