Add tip on common Java API overrides

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-reference.adoc#native-reports,native build time reports>>.
+
 [[native-in-extension]]
 == Supporting native in a Quarkus extension