Not without changing everything in significant ways. There are two distinct kinds of types in Java: objects, including arrays, and primitives. Objects are represented as pointers, and those can be null — that's their default value. And multiple pointers can point to the same object. Primitives (int, long, boolean, char, byte, short, float, double) are "value types", they can't be null, are copied on assignment, and have meaningful default values (0 for numbers, false for booleans). Adding non-primitive value types would mean having to solve many new problems that C++ had and still has. That said, they are exploring this idea, iirc they call it "project valhalla".
Who said anything about non-primitive value types? Java just needs a second kind of reference type: non-nullable reference types that are always initialized, where a direct assignment from a nullable-reference-typed value to a non-nullable-reference-typed slot fails to compile (but the opposite succeeds.) You’d instead have to go through Optional.ofNullable or somesuch, where that proxy type would then be modified to have variants of .get et al that return a non-nullable-reference return type.
Java could adopt swift-like `Object!` typing for non-nullable variables and spread that guarantee through the compiler and JVM runtime.
I don't think it's a technical impossibility, but it's more likely to be solved by a JVM-based language like Kotlin than it is to get it adopted into the Java mothership.
Compile-time checks definitely can't guarantee anything. You could still end up with null pointers from, for example, a library like gson using reflection to set fields. If you add "non-null" to the type descriptors inside class files (something like Kjava/lang/Object; instead of the usual Ljava/lang/Object;) and have the JVM enforce non-null-ness at runtime, you'll still have crashes caused by null pointers but earlier. Oh and you'll have to make an exception to allow these to be null during a constructor or static initializer invocation so it could actually initialize everything. It gets messy.
IIRC that proposition for value types makes them more akin to structs, without inheritance and dynamic methods. And I don't remember whether the fields are final, but given the current trend towards making everything as immutable as possible, they probably are.
