Add tip on common Java API overrides

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

@@ -545,6 +545,25 @@ 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.
+The majority of overrides do not cause problems,
+but if they use third party libraries (e.g. for additional formatting),
+or use dynamic language features (e.g. reflection or proxies),
+they can cause native image build to fail.
+Some of those failures might be solvable via configuration,
+but others can be more tricky to handle.
+
+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 is 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.
+
 [[native-in-extension]]
 == Supporting native in a Quarkus extension