Again, by this standard, literally any language with FFI is "unsafe". This is not a useful definition in practice.
As far as translation of Java or Python to safe Rust, sure, if you avoid borrow checking through the usual tricks (using indices instead of pointers etc), you can certainly do so in safe Rust. In the same vein, you can translate any portable C code, no matter how unsafe, to Java or Python by mapping memory to a single large array and pointers to indices into that array (see also: wasm). But I don't think many people would accept this as a reasonable argument that Java and C are the same when it comes to memory safety.
So you can see that the fact you can invoke unsafe code is not a good distinguishing factor. It is the other, safe part. Rust, Java and Python all have huge memory safe subsets that are practical for general purpose programming - almost all of the features are available in those safe subsets. C and C++ do not - in order to make them memory safe you’d have to disallow most of the useful features eg everything related to pointers/references and dynamic memory.
As far as translation of Java or Python to safe Rust, sure, if you avoid borrow checking through the usual tricks (using indices instead of pointers etc), you can certainly do so in safe Rust. In the same vein, you can translate any portable C code, no matter how unsafe, to Java or Python by mapping memory to a single large array and pointers to indices into that array (see also: wasm). But I don't think many people would accept this as a reasonable argument that Java and C are the same when it comes to memory safety.