The biggest thing Java is missing is full hot swap. Its been implemented via the dcevm but, inexplicably, has been ignored by both sun and oracle.
This one, existing technology would make Java DX on par with the dynamic languages
This one, existing technology would make Java DX on par with the dynamic languages
Regardless, it’s ridiculous that at this point Java doesn’t have full hotswap. All the hooks are there (as is apparent from the error messages when a hotswap fails) and the dcevm is being maintained by jetbrains employees. It needs an internal champion at oracle/sun.
Clojure (and other lisps) can do it well because their scope of changes can be really small. Nonetheless, method hot-swap is well-defined and is implemented by OpenJDK.
The biggest thing missing in Java is an answer for the billion-dollar mistake. Real world Java is plagued by NPEs because a lot of Java is written by low caliber programmers. Java + functional error handling would be a monumental improvement.
Can't really blame Java for that, though - if everybody standardized on, say, Haskell (or whatever we might agree is the "gold standard" for programming), the low caliber programmers would find a way to do something stupid in it, too. The only way to get around low caliber programmers is to raise the standard, but any suggestion of raising (or even setting) a standard for programming invites accusations of "gatekeeping" (a gate that really, really, really ought to be kept).
Hmm. Can't I? I know why Sun made Java. They wanted a platform to develop applications that didn't require the skill of a competent C++ programmer. They were targeting lower caliber coders.
I'm a pragmatist; yes, Java programmers would still find escapes, but they'd do it less and so the net number of flaws would be smaller. As jayd16 points out, there is a pragmatic way to deal with this; provide a compiler mode that eliminates null dereferences and rework the standard library to accommodate this. Simple and obvious. Afterwards you can throw the switch on whatever code your facing and you'll know if you're dealing with crap or not.
Which @NonNull? There's javax.validation.constraints.NotNull, org.springframework.lang.NonNull, org.checkerframework.checker.nullness.qual.NonNull, org.jetbrains.annotations.NotNull, android.support.annotation.NonNull and a bunch of others[1]. The proliferation of Not|NonNull is evidence that I'm right, no matter how hard I get downed on HN.
[1] https://stackoverflow.com/questions/35892063/which-nonnull-j...
Realistically, null is so fundamental to the Java language that removing it would arguably result in a different language entirely. Certainly all existing java codebases would have to be refactored. The same goes for exceptions. That's obviously not an option when one of your primary selling points is backwards compatibility, so I'm not really sure what kind of solution you're looking for here.
The answer to your SO link notwithstanding, I would argue the @lombok.NonNull is at least one of the best options, as it actually generates a null check that is executed at runtime. This makes it more powerful than most of the other solutions.
Again, as jayd16 pointed out a solution has been retrofitted to C#, Java's great nemesis. I don't accept the argument that this is somehow infeasible. Just make null assignments (including potential ones coming from libraries) an error and allow this feature to be scoped to your source files. Eventually the practice becomes ubiquitous. It's been done again and again in many languages and their various 'strict' modes.
The only actual problem here is that Java language developers aren't feeling sufficient pressure to address it. They should, but they're not, and that's sad. That sort of sadness is a common theme with Java.