Add Java sections to best practices (ossf#40)

Signed-off-by: Thomas Leplus <thomasleplus@users.noreply.github.com>
Signed-off-by: balteravishay <avishay.balter@gmail.com>

Author: thomasleplus

docs/best-practice-interfacing.md

@@ -25,3 +25,9 @@ It is and will continue to be necessary for software written in memory safe by d
 ## JavaScript
 
 ## Java
+
+* Avoid using the legacy Java Native Interface (JNI) APIs. If needed, prefer the newer Foreign Function & Memory (FFM) APIs introduced in Java 22.
+* Monitor or prevent JNI API occurrences (e.g. uses of the `native` keyword or calls to `System.load()` or `System.loadLibrary()`) in your code using [static code analysis tools](https://www.baeldung.com/tag/static-analysis).
+* If using JNI is your only option, follow all the same best practices as you would with a [non memory-safe language](best-practice-non-memory-safe-by-default-languages.md).
+* Always enable the [-Xcheck:jni JVM option](https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/clopts002.html#CHDHCBBG) to activate additional validation of JNI functions' arguments. Even if your code does not use JNI, your third-party dependencies might (JDBC drivers are a common example).
+* The [-verbose:jni JVM option](https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/clopts002.html#CHDCHGEE) can also be useful to detect or troubleshoot JNI issues but beware of the potential performance as it could cause a lot of extra log messages if JNI is heavily used in your application.

docs/best-practice-memory-safe-by-default-languages.md

@@ -28,4 +28,7 @@ TO DO
 
 ## Java
 
-TO DO
+* Avoid using `sun.misc.Unsafe` or `jdk.internal.misc.Unsafe`. If needed, prefer the newer [Foreign Function & Memory (FFM) APIs](https://docs.oracle.com/en/java/javase/22/core/foreign-function-and-memory-api.html) (Java 22 or above) which implement boundary checks when accessing off-heap memory and errors results in exceptions (e.g. IndexOutOfBoundsException) instead of crashes (e.g. SIGSEGV).
+* If `sun.misc.Unsafe` or `jdk.internal.misc.Unsafe` is your only option, follow all the same best practices as you would with a [non memory-safe language](best-practice-non-memory-safe-by-default-languages.md).
+* Monitor occurrences of `sun.misc.Unsafe` or `jdk.internal.misc.Unsafe` in your code (or prevent them) using for example [checkstyle's IllegalImport rule](https://checkstyle.org/checks/imports/illegalimport.html) configured to detect both `sun.*` and `jdk.internal.*`.
+* If FFM APIs are used, enable the compilation option `-Xlint:restricted` to detect risky usages at compile time (the option enables warnings in the `[restricted]` log category). Similar warnings are produced by default by the JVM at runtime. These warnings should be monitored and investigated as well since they could come from third-party libraries and not just from own code.