4 ms·

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, ex

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

lenkite 4y ago
Enhanced hot swap using GraalVM has mostly caught up with capabilities https://www.graalvm.org/22.1/reference-manual/java-on-truffle/hotswap/ https://www.graalvm.org/22.1/reference-manual/java-on-truffl...
- e67f70028a46fba 4y ago
  I’ve tried that and it didn’t work reliably for me. The jet brains runtime release works but it’s a bear to figure out which download to use. 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.
  - kaba0 4y ago
    What should happen when you remove an existing field, remove a method already used, change its initial value, etc? You will quickly get some incorrect state by blind hot swapping, and it is not trivial to do in a mutable object graph. 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.
    - e67f70028a46fba 4y ago
      Dcevm handles all those reasonably well. The current version doesn’t support changing super classes but the old version did. This is in dev mode so it doesn’t need to be perfect, just right enough most of the time.
deleted 4y ago
[deleted]
topspin 4y ago
> The biggest thing Java is missing is full hot swap 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.
- bhuber 4y ago
  It doesn't fully solve the problem, but @lombok.NonNull helps a lot. It makes it clear which properties shouldn't be null, and catches NPEs closer to the source. Incidentally, lombok in general does wonders for boilerplate reduction. https://projectlombok.org/ https://projectlombok.org/
  - topspin 4y ago
    > but @lombok.NonNull helps a lot 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-java-annotation-to-use https://stackoverflow.com/questions/35892063/which-nonnull-j...
    - bhuber 4y ago
      I didn't say it wasn't a problem - if I could wave a magic wand and get rid of the concept of null in Java I would. That isn't what we're discussing though - you said, "The biggest thing missing in Java is an answer for the billion-dollar mistake [- NPEs]". I've provided what I consider to be at least a partial answer. If you care about avoiding NPEs in Java, it's a pretty good solution. 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.

lenkite 4y ago

Enhanced hot swap using GraalVM has mostly caught up with capabilities https://www.graalvm.org/22.1/reference-manual/java-on-truffle/hotswap/ https://www.graalvm.org/22.1/reference-manual/java-on-truffl...

e67f70028a46fba 4y ago
I’ve tried that and it didn’t work reliably for me. The jet brains runtime release works but it’s a bear to figure out which download to use. 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.
- kaba0 4y ago
  What should happen when you remove an existing field, remove a method already used, change its initial value, etc? You will quickly get some incorrect state by blind hot swapping, and it is not trivial to do in a mutable object graph. 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.
  - e67f70028a46fba 4y ago
    Dcevm handles all those reasonably well. The current version doesn’t support changing super classes but the old version did. This is in dev mode so it doesn’t need to be perfect, just right enough most of the time.

deleted 4y ago

[deleted]

topspin 4y ago

> The biggest thing Java is missing is full hot swap 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.

bhuber 4y ago
It doesn't fully solve the problem, but @lombok.NonNull helps a lot. It makes it clear which properties shouldn't be null, and catches NPEs closer to the source. Incidentally, lombok in general does wonders for boilerplate reduction. https://projectlombok.org/ https://projectlombok.org/
- topspin 4y ago
  > but @lombok.NonNull helps a lot 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-java-annotation-to-use https://stackoverflow.com/questions/35892063/which-nonnull-j...
  - bhuber 4y ago
    I didn't say it wasn't a problem - if I could wave a magic wand and get rid of the concept of null in Java I would. That isn't what we're discussing though - you said, "The biggest thing missing in Java is an answer for the billion-dollar mistake [- NPEs]". I've provided what I consider to be at least a partial answer. If you care about avoiding NPEs in Java, it's a pretty good solution. 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.