2 ms·

Oh I remember about 10 years ago doing the migration from Oracle JVM to OpenJDK. I think it would have been around the Java 6 period, but there were all sorts o

Oh I remember about 10 years ago doing the migration from Oracle JVM to OpenJDK. I think it would have been around the Java 6 period, but there were all sorts of small things that I didn't think would be an issue that ended up cutting us. The two main ones were a font, which I don't remember exactly which or why but I think it was to generate PDFs and it came bundled with the Oracle JVM so the PDF library defaulted to it. For Open JDK there was an extra setup step to install a RedHat font, but it was confusing when a pdf comes out garbled because you switched your JVM. But I could be mixing up my issues. I think the other was built in certificates, but it was too long ago now. Having a fun time at the moment with Java 11 to 17. The application has extensive Lombok, so nothing quite works the same. I've had less pain migrating from Python 2 to 3.

winrid 3y ago
Yeah, Lombok doesn't use standard, supported APIs. They even say in their docs, what they're doing could become incompatible for future java versions at any time. Not java's fault really. It is for this reason I don't use it (also I don't like too much magic, but that's me).
- jarym 3y ago
  > I don't like too much magic Not just you. 'Magic' seems great until newer members of the team have no idea how it works and just use it - then things get painful.
  - happymellon 3y ago
    I dislike Spring JPA for the same reason. It just magically understands your query based upon the name of the function. There is far too much "magic" going on these days which has a massive learning curve for the newbies, and a headache for everyone else when something stops working because they've changed how the incantation works.
- happymellon 3y ago
  Yeah, I didn't pick it and this is an inherited codebase that I'm trying to bring up to date while I still have overlapping Java 11 support. I haven't picked it in the past except for a toy project, to experiment with Lombok. It has some interesting ideas which would be nice if they folded it into Java, but while it's fringe it ends up being a liability.
  - winrid 3y ago
    Yes! Then we could call it "kotlin" :)
    - happymellon 3y ago
      Hopefully not. > val a: Int = 1 I wouldn't want to inflict that on anyone.
      - winrid 3y ago
        You don't need to have the "int" there, though, right? You can just do "val a = 1" [0] Don't get me wrong, I still pick Java over Kotlin, but I thought ktl had type inference. Even Java has "var a = 1" now. I just wish we had optional named parameters in Java, that's like, my biggest issue with the language. [0] https://www.oreilly.com/library/view/kotlin-programming-the/9780135165188/ch02s05.html https://www.oreilly.com/library/view/kotlin-programming-the/...
        happymellon 3y ago
        I took that example from the Kotlin homepage. I've not used Kotlin, but since Scala recommends that you include the type declaration if you know what it is, I assumed that Kotlin did as well. If their example is bad, then apologies! Optional named parameters and also default values would be great. The stuff that gets used by the most in this codebase is the `allParameterConstructor` for enums and the `slf4j` annotation. Without those two I could probably remove the Lombok dependency.

winrid 3y ago

Yeah, Lombok doesn't use standard, supported APIs. They even say in their docs, what they're doing could become incompatible for future java versions at any time. Not java's fault really. It is for this reason I don't use it (also I don't like too much magic, but that's me).

jarym 3y ago
> I don't like too much magic Not just you. 'Magic' seems great until newer members of the team have no idea how it works and just use it - then things get painful.
- happymellon 3y ago
  I dislike Spring JPA for the same reason. It just magically understands your query based upon the name of the function. There is far too much "magic" going on these days which has a massive learning curve for the newbies, and a headache for everyone else when something stops working because they've changed how the incantation works.
happymellon 3y ago
Yeah, I didn't pick it and this is an inherited codebase that I'm trying to bring up to date while I still have overlapping Java 11 support. I haven't picked it in the past except for a toy project, to experiment with Lombok. It has some interesting ideas which would be nice if they folded it into Java, but while it's fringe it ends up being a liability.
- winrid 3y ago
  Yes! Then we could call it "kotlin" :)
  - happymellon 3y ago
    Hopefully not. > val a: Int = 1 I wouldn't want to inflict that on anyone.
    - winrid 3y ago
      You don't need to have the "int" there, though, right? You can just do "val a = 1" [0] Don't get me wrong, I still pick Java over Kotlin, but I thought ktl had type inference. Even Java has "var a = 1" now. I just wish we had optional named parameters in Java, that's like, my biggest issue with the language. [0] https://www.oreilly.com/library/view/kotlin-programming-the/9780135165188/ch02s05.html https://www.oreilly.com/library/view/kotlin-programming-the/...
      - happymellon 3y ago
        I took that example from the Kotlin homepage. I've not used Kotlin, but since Scala recommends that you include the type declaration if you know what it is, I assumed that Kotlin did as well. If their example is bad, then apologies! Optional named parameters and also default values would be great. The stuff that gets used by the most in this codebase is the `allParameterConstructor` for enums and the `slf4j` annotation. Without those two I could probably remove the Lombok dependency.