Safe Rust is actually safer than Java because Java still has data races (that happen when you don't use correct synchronization when doing multithreaded code). In Java data races aren't as catastrophic as C (that is, it's not UB), but they are still a very severe kind of bug.

In Safe Rust, data races can't happen because you can only share stuff between threads if they are either synchronized or read only - attempting to share data that can't be accessed by many threads results in a compile time error.

Also: Java depends heavily on the GC to have memory safety. There are probably some kernels that manage memory with GCs, but for most of them it's not appropriate.

And even for projects that are written in a language that uses a GC (like written in Python, or Java, or C#), having two GCs in the same project, sharing data between each other, is kind of catastrophic. Because of this, a project in a high level language either uses libraries written in the same language (or at least the same runtime), or languages written in C or C++. So Python programs use Python libraries or C libraries, C# programs use C#/.NET libraries or C libraries. But it's uncommon to use a Python library in a C# project, or a C# library in a Python project.

Just like C, Rust fills the niche of writing libraries that can be used in many ecosystems. Right now some Rust libraries are used in Javascript projects (either on node or on the web, with wasm), for example.

- Java's use of GC and a large runtime makes it inappropriate for many use cases

- Java had a pretty slow startup time, which makes it a poor fit for many CLI applications and similar

- Java has historically had pretty poor support for interoperating with c libraries (although this is improving with project panama)

- Rust has a richer, more powerful type system than Java (although scala's is more comparable)

- Rust's affine types (lifetimes) actually prevent certain types of bugs that occur in languages like Java as well. Things like using a connection or file handle after it is closed, forgetting to release a lock, not properly synchronizing access to memory between multiple threads, etc.

Because adopting a language that utilizes a garbage collector for memory management in the Linux kernel is even less likely than adopting Rust.

One reason I can think of is its memory management model gives programmers more control than a garbage collector. With the borrow checker, you know when your variables will get dropped/deallocated, but a garbage collector is not necessarily as controllable.

Java does not provide performance comparable to C/C++.

It depends on what you call "performance". IO throughput can be the same. So can be CPU utilization. Memory consumption will always be larger though, and the kind of code you need to write in Java to achieve parity might not look like any Java most people are familiar with.