5 ms·

I suppose the reason is backwards compatibility of code, something that Java values a lot more than other languages. Still, I also suppose there's going to be

I suppose the reason is backwards compatibility of code, something that Java values a lot more than other languages. Still, I also suppose there's going to be a compiler flag that auto-assumes non-nullability unless specified otherwise.

jeroenhd 2y ago
On the one hand Java is very strict about backwards compatibility (still reserving keywords like const and goto even though they're not used (anymore)), but on the other hand Java 9's module system broke just about every Java <=8 project I've ever seen. Project Loom also breaks tons of code because of locking and other threaded side effects that weren't even a consideration before, a trade-off between coloured functions and risking old code breaking. It seems to me that Java is very conservative when it comes to the language itself, but actually compiling and running that language seems less of a concern. In this case, the "specify a flag to make all non-annotated variables non-null" approach would only add a single glyph to the language (the ? for denoting nullability), which I would've expected based on the way Java has evolved over time.
- Tainnor 2y ago
  Another problem with (especially older versions of) Java is that the language was so restrictive that many of the popular frameworks rely on reflection and/or bytecode manipulation and these things can and do break frequently across JDK or JRE updates.
- deely3 2y ago
  > Java 9's module system broke just about every Java <=8 project I've ever seen. As far as I understand, some IDE's and built automation tools did not rollout support for module system immediately, yes?
  - jeroenhd 2y ago
    It took a while for IDEs and tools to catch up, but I still encounter issues with old codebases to this day, using the latest and greatest tools. The problem isn't necessarily that the compiler isn't called right, but rather that a lot of existing library code suddenly didn't work anymore. By compartmentalising code (a welcome improvement!), projects that weren't designed for this compartmentalisation need a lot of "basically turn off Java module restrictions" command line flags to the JVM.
  - mschuster91 2y ago
    Mixing a Java >= 9 project with Maven libraries made for <= 8 is one hell of a headache.
- kaba0 2y ago
  > but on the other hand Java 9's module system broke just about every Java <=8 project I've ever seen That’s not true at all. Besides the package name change with jakarta, all it did is just expose a couple, popular libraries that were depending on runtime internals. Most of this could be fixed by bumping said libraries version. And the whole point of the module system is that it will never happen again, due to stricter encapsulation. > Project Loom How would it break any code? You have to explicitly use virtual threads, normal threads are not touched at all and will work as they have always did. And yeah, java has always been “conservative on the language front, state-of-the-art on the runtime”
  - cesarb 2y ago
    > How would it break any code? You have to explicitly use virtual threads, normal threads are not touched at all and will work as they have always did. You often have no control over what kind of thread the caller of your code is using. Code written for the old threading model can and will end up being called by these newfangled virtual threads. If it does something the virtual threads don't like (which, as far as I have heard, includes things like some uses of synchronized blocks), you can have unexpected breakage.
    - imtringued 2y ago
      You're confusing the thread pinning problem with "breakage". The problem with some synchronized blocks is that they lead to thread pinning for the duration of the lock. Why is thread pinning bad? Because it means that if one core is idle, but all the threads are pinned to a specific core, you won't get full CPU utilisation. This undermines the performance benefit of virtual threads, because they are supposed to be schedulable via work stealing.
    - kaba0 2y ago
      That’s not backwards compatibility, but forwards compatibility, though. And you would really have to go out of your way to introduce such an issue. Certain extreme (e.g. native calls) cases are handled by simply pinning a virtual thread to a real thread. So it would only cause an issue if it was already causing an issue at much smaller thread numbers. And many of these extreme cases are getting “solved” to not pin the thread.

jeroenhd 2y ago

On the one hand Java is very strict about backwards compatibility (still reserving keywords like const and goto even though they're not used (anymore)), but on the other hand Java 9's module system broke just about every Java <=8 project I've ever seen. Project Loom also breaks tons of code because of locking and other threaded side effects that weren't even a consideration before, a trade-off between coloured functions and risking old code breaking. It seems to me that Java is very conservative when it comes to the language itself, but actually compiling and running that language seems less of a concern. In this case, the "specify a flag to make all non-annotated variables non-null" approach would only add a single glyph to the language (the ? for denoting nullability), which I would've expected based on the way Java has evolved over time.

Tainnor 2y ago
Another problem with (especially older versions of) Java is that the language was so restrictive that many of the popular frameworks rely on reflection and/or bytecode manipulation and these things can and do break frequently across JDK or JRE updates.
deely3 2y ago
> Java 9's module system broke just about every Java <=8 project I've ever seen. As far as I understand, some IDE's and built automation tools did not rollout support for module system immediately, yes?
- jeroenhd 2y ago
  It took a while for IDEs and tools to catch up, but I still encounter issues with old codebases to this day, using the latest and greatest tools. The problem isn't necessarily that the compiler isn't called right, but rather that a lot of existing library code suddenly didn't work anymore. By compartmentalising code (a welcome improvement!), projects that weren't designed for this compartmentalisation need a lot of "basically turn off Java module restrictions" command line flags to the JVM.
- mschuster91 2y ago
  Mixing a Java >= 9 project with Maven libraries made for <= 8 is one hell of a headache.
kaba0 2y ago
> but on the other hand Java 9's module system broke just about every Java <=8 project I've ever seen That’s not true at all. Besides the package name change with jakarta, all it did is just expose a couple, popular libraries that were depending on runtime internals. Most of this could be fixed by bumping said libraries version. And the whole point of the module system is that it will never happen again, due to stricter encapsulation. > Project Loom How would it break any code? You have to explicitly use virtual threads, normal threads are not touched at all and will work as they have always did. And yeah, java has always been “conservative on the language front, state-of-the-art on the runtime”
- cesarb 2y ago
  > How would it break any code? You have to explicitly use virtual threads, normal threads are not touched at all and will work as they have always did. You often have no control over what kind of thread the caller of your code is using. Code written for the old threading model can and will end up being called by these newfangled virtual threads. If it does something the virtual threads don't like (which, as far as I have heard, includes things like some uses of synchronized blocks), you can have unexpected breakage.
  - imtringued 2y ago
    You're confusing the thread pinning problem with "breakage". The problem with some synchronized blocks is that they lead to thread pinning for the duration of the lock. Why is thread pinning bad? Because it means that if one core is idle, but all the threads are pinned to a specific core, you won't get full CPU utilisation. This undermines the performance benefit of virtual threads, because they are supposed to be schedulable via work stealing.
  - kaba0 2y ago
    That’s not backwards compatibility, but forwards compatibility, though. And you would really have to go out of your way to introduce such an issue. Certain extreme (e.g. native calls) cases are handled by simply pinning a virtual thread to a real thread. So it would only cause an issue if it was already causing an issue at much smaller thread numbers. And many of these extreme cases are getting “solved” to not pin the thread.