I think this is can be handled with Lombok using @Getter and @Setter annotations (https://projectlombok.org/features/GetterSetter). It is not exactly the same because you call generated methods instead using assignment syntax but I guess it's close enough - if you need some custom logic in the getter/setter then you remove the annotation and write your own implementation (I think Lombok might be smart enough to ignore the annotation if an appropriately named getter/setter is present).

Non-nullable types sound great, I wonder if this could be introduced to Java in a backwards-compatible way (I suppose it would follow the same path with introducing explicitly nullable types first, though I guess it could be handled using Optionals?).

If you need a shortcut for accessors, you may aswell make your fields public and avoid get/set altogether...

This allows you to override the logic later. Public fields in a language where "x.y" means "directly access field y on value x" don't allow that; x.y forever means "directly access field x" and you can't later interpose code between attributes and the code accessing it.

This isn't the only way of doing it, depending on your language. Python has a completely different mechanism where a class can start with a directly-accessed "y", but in a later version make it a property. (More than one, actually.) Some languages route all property accesses through something you can hook. Some languages simply automatically do what C# is doing here.

Semantically and abstractly, there's no reason to every not be able to override a property access in later versions like that, because it is so darned useful. Unfortunately, performance wise, it's hard to beat a language that guarantees structure layout and guarantees that x.y can be compiled into a single constant memory load instruction, and unfortunately, you can't just wave "compiler optimization" at the problem and make it go away (considered in isolation this seems like an obvious solution but as usual as it starts interacting with all the other features it gets much harder than the simple cases). The higher performance languages have a strong reason to give people ways to get guaranteed direct struct member accesses.

Though please note that if you "upgrade" anything from a field to a property, you need to recompile any dependencies. Otherwise they will obviously try to invoke the field that no longer exists, instead of calling the property methods.

Not if you need to implement some setter logic though, or want to reserve the option to do so in the future. And not if you want those instance variables to be available as JavaBean properties.

I haven't developed in Java in a long time, but public instance variables were a no-no when I did for these reasons.