5 ms·

First, it's not a "crusade" but the steps necessary to deliver the features Java's users demand. Second, the prevalence of the use of JDK internals has dropped

by pron 2y ago

First, it's not a "crusade" but the steps necessary to deliver the features Java's users demand. Second, the prevalence of the use of JDK internals has dropped drastically, and demonstrably so. For example, many programs broke before internals were encapsulated during the upgrade from 8 to 9; 99% of the causes were libraries relying on internals, which had changed. Access to internals was closed off in JDK 16, although, as you say, it can be selectively allowed. And yet, between JDK 17 and JDK 23, changes of similar magnitude to the JDK internals caused nearly no upgrade problems. Upgrading the JDK now is smoother and easier than it's been in the last two decades. Why? Because there's been a large reduction in libraries' access to internals. I think Java's handling of this transition compares very favourably to how other languages have handled similar transitions from some old model to a new one (or evolution in general) in terms of balancing the needs of both old and new projects.

cogman10 2y ago
I can attest to how easy it's become to update jdks for our org. 8->11 was really a pain in the neck. 11->17 had some pain, but mostly was nothing serious. 17->21 has been painless. And I have some projects running on 24 already with no problems. The feature delivery has been great and we are getting pretty close to not needing to do anything but update the jdk to move forward. Now, if only I could get devs to stop using lombok....
- sgammon 2y ago
  > Now, if only I could get devs to stop using lombok One of the only remaining reasons I discard libraries without a further thought
- pandemic_region 2y ago
  Why the Lombok hate? It's just an innocent preprocessor allowing a bit of syntactic sugar right?
  - pests 2y ago
    It feels weird to me that functions exist without being in the source code.
    - pandemic_region 2y ago
      I never looked at it that way, but I get now where you're coming from. To me, the Lombok annotations are more like @Transactional, providing some useful boilerplate that I don't need to care about, it just works.
      - pests 2y ago
        I agree its extremely useful. I am just used to languages/frameworks that at least autogenerate the code. Maybe some inheritance to give you a place to make changes that wont be wiped.
  - dingi 2y ago
    It’s not an innocent preprocessor. It’s a hack which breaks on almost every JDK upgrade.
    - mschuster91 2y ago
      Now, given that a looot of projects use Lombok, it might be worth a try to actually standardize (or at least upstream) the feature given there seems to be an obvious demand of people to not having to pollute their codebase with tons of pointless getter and setter boilerplate.
      - cogman10 2y ago
        AutoValue, Immutables, MapStruct. All libraries that do what Lombok does without using JVM internals. Records also literally do a huge portion of what Lombok does. There are a lot of fairly popular alternatives to Lombok out there that don't need a constant eye on maintenance. Lombok is probably the most popular but that's really mostly because it's got the first mover advantage.
- pests 2y ago
  Been a long time since I used Java. I checked out lombok since you mentioned it. Does it really just internally create all those methods without there being actual source code? It seems nice but really spooky-action-at-a-distance feeling. Sounds like a nightmare.
  - DevelopingElk 2y ago
    Yes, from a language design it's ugly and the implementation is convoluted. From a user perspective it's awesome and enables better interfaces.
    - pests 2y ago
      I don't even agree with their demo video. It shows the "hard" way of autogenerating settings/getters, toString, hash, etc. The end result was like an additional ~80 boilerplate lines. I have no problem keeping those lines around.. opposed to adding the lombak.jar and changing my build config. I do understand the user perspective of it "just working" and of course the getters/setters will grow as you add fields... it just seems like such a low amount of code to keep around it shouldnt be too much hassle.
      - vbezhenar 2y ago
        It's not 80 lines. It's many thousands of lines in any real project. Lines that you should keep synchronised with "source of truth". People love Lombok for a reason. And most developers don't really care about implementation details, they believe that Lombok is "big enough" to work in the foreseeable future. It worked for them for years, it's supported well in Idea. I, personally, avoid Lombok, specifically because I care about implementation details. Because if I would have wanted better Java, I'd go with Kotlin rather than this hacky way of using another Java-like language. But other people hold different opinions.
        cogman10 2y ago
        There are alternatives that don't rely on jvm internals to accomplish their goals. They do like 90% of what lombok does. Immutables and AutoValue are two examples I've used that work fine. The 10% lombok can do because it's peaking at internals isn't valuable. I don't, for example, need an annotation to create a static logger. That's dumb.
- throwaway92422 2y ago
  I like Lombok. The best annotation is @Builder. It makes working with records much more convenient.
  - JanecekPetr 2y ago
    https://github.com/Randgalt/record-builder https://github.com/Randgalt/record-builder The upsides are: - it generates code and does not do anything funky with internals, - it has a lot of knobs if you need something a little different. The downside is that it does not provide you with the other Lombok annotations. In practice that has been OK!
    - cogman10 2y ago
      Besides this I'd also point to Immutables and AutoValue which both can make builders without touching jvm internals.
- xxs 2y ago
  >Now, if only I could get devs to stop using lombok.... that's actually not too hard. It has happened to get them all converted to avid opponents of lombok.
Supermancho 2y ago
> First, it's not a "crusade" but the steps necessary to deliver the features Java's users demand Semantics. Nobody demanded anything, if we want to play word games. The java philosophy of final, makes software less extensible. This is the point; to have less overriding. Regardless of what the voting body decides (the meaning of users being subtly repurposed), the feature is anti-developer-agency past the point of healthy balance. I dont understand the enthusiasm.
- samus 2y ago
  Final making software less extensive is a red herring. The JEP is about final for fields, not final for classes. Nothing changes regarding the latter. It merely deprecates facilities that enable programmers to ignore the explicitly stated intentions of other developers.
  - Supermancho 2y ago
    > enable programmers to ignore the explicitly stated intentions of other developers You say ignore. This is unnecessarily pejorative. You mean "change". Software does not care about explicit intentions or who is leveraging it. Overriding is one of the essential methods of extending software.
    - pron 2y ago
      Java allows you to freely change any decision made by any author of any library you use. None of that ability has been taken away. However, changing other code (and potentially changing the assumptions on which it was built) shouldn't be as easy as using it in a way that preserves its assumptions. If it were just as easy, you could accidentally break other code's assumptions. In some situations, all that's required of you is merely to declare that you indeed intend to change some other code's assumptions; in more involved situations (e.g. a library method computes the sum of its argument and you want to change it to compute the product) the work is more involved, but you can still do it relatively easily. What we have blocked is the ability of a library to change the assumptions of another library or of the application's without the application knowing about it. A library absolutely must not be allowed to do that while hiding that from the application.

by pron 2y ago

cogman10 2y ago

I can attest to how easy it's become to update jdks for our org. 8->11 was really a pain in the neck. 11->17 had some pain, but mostly was nothing serious. 17->21 has been painless. And I have some projects running on 24 already with no problems. The feature delivery has been great and we are getting pretty close to not needing to do anything but update the jdk to move forward. Now, if only I could get devs to stop using lombok....

sgammon 2y ago
> Now, if only I could get devs to stop using lombok One of the only remaining reasons I discard libraries without a further thought
pandemic_region 2y ago
Why the Lombok hate? It's just an innocent preprocessor allowing a bit of syntactic sugar right?
- pests 2y ago
  It feels weird to me that functions exist without being in the source code.
  - pandemic_region 2y ago
    I never looked at it that way, but I get now where you're coming from. To me, the Lombok annotations are more like @Transactional, providing some useful boilerplate that I don't need to care about, it just works.
    - pests 2y ago
      I agree its extremely useful. I am just used to languages/frameworks that at least autogenerate the code. Maybe some inheritance to give you a place to make changes that wont be wiped.
- dingi 2y ago
  It’s not an innocent preprocessor. It’s a hack which breaks on almost every JDK upgrade.
  - mschuster91 2y ago
    Now, given that a looot of projects use Lombok, it might be worth a try to actually standardize (or at least upstream) the feature given there seems to be an obvious demand of people to not having to pollute their codebase with tons of pointless getter and setter boilerplate.
    - cogman10 2y ago
      AutoValue, Immutables, MapStruct. All libraries that do what Lombok does without using JVM internals. Records also literally do a huge portion of what Lombok does. There are a lot of fairly popular alternatives to Lombok out there that don't need a constant eye on maintenance. Lombok is probably the most popular but that's really mostly because it's got the first mover advantage.
pests 2y ago
Been a long time since I used Java. I checked out lombok since you mentioned it. Does it really just internally create all those methods without there being actual source code? It seems nice but really spooky-action-at-a-distance feeling. Sounds like a nightmare.
- DevelopingElk 2y ago
  Yes, from a language design it's ugly and the implementation is convoluted. From a user perspective it's awesome and enables better interfaces.
  - pests 2y ago
    I don't even agree with their demo video. It shows the "hard" way of autogenerating settings/getters, toString, hash, etc. The end result was like an additional ~80 boilerplate lines. I have no problem keeping those lines around.. opposed to adding the lombak.jar and changing my build config. I do understand the user perspective of it "just working" and of course the getters/setters will grow as you add fields... it just seems like such a low amount of code to keep around it shouldnt be too much hassle.
    - vbezhenar 2y ago
      It's not 80 lines. It's many thousands of lines in any real project. Lines that you should keep synchronised with "source of truth". People love Lombok for a reason. And most developers don't really care about implementation details, they believe that Lombok is "big enough" to work in the foreseeable future. It worked for them for years, it's supported well in Idea. I, personally, avoid Lombok, specifically because I care about implementation details. Because if I would have wanted better Java, I'd go with Kotlin rather than this hacky way of using another Java-like language. But other people hold different opinions.
      - cogman10 2y ago
        There are alternatives that don't rely on jvm internals to accomplish their goals. They do like 90% of what lombok does. Immutables and AutoValue are two examples I've used that work fine. The 10% lombok can do because it's peaking at internals isn't valuable. I don't, for example, need an annotation to create a static logger. That's dumb.
throwaway92422 2y ago
I like Lombok. The best annotation is @Builder. It makes working with records much more convenient.
- JanecekPetr 2y ago
  https://github.com/Randgalt/record-builder https://github.com/Randgalt/record-builder The upsides are: - it generates code and does not do anything funky with internals, - it has a lot of knobs if you need something a little different. The downside is that it does not provide you with the other Lombok annotations. In practice that has been OK!
  - cogman10 2y ago
    Besides this I'd also point to Immutables and AutoValue which both can make builders without touching jvm internals.
xxs 2y ago
>Now, if only I could get devs to stop using lombok.... that's actually not too hard. It has happened to get them all converted to avid opponents of lombok.

Supermancho 2y ago

> First, it's not a "crusade" but the steps necessary to deliver the features Java's users demand Semantics. Nobody demanded anything, if we want to play word games. The java philosophy of final, makes software less extensible. This is the point; to have less overriding. Regardless of what the voting body decides (the meaning of users being subtly repurposed), the feature is anti-developer-agency past the point of healthy balance. I dont understand the enthusiasm.

samus 2y ago
Final making software less extensive is a red herring. The JEP is about final for fields, not final for classes. Nothing changes regarding the latter. It merely deprecates facilities that enable programmers to ignore the explicitly stated intentions of other developers.
- Supermancho 2y ago
  > enable programmers to ignore the explicitly stated intentions of other developers You say ignore. This is unnecessarily pejorative. You mean "change". Software does not care about explicit intentions or who is leveraging it. Overriding is one of the essential methods of extending software.
  - pron 2y ago
    Java allows you to freely change any decision made by any author of any library you use. None of that ability has been taken away. However, changing other code (and potentially changing the assumptions on which it was built) shouldn't be as easy as using it in a way that preserves its assumptions. If it were just as easy, you could accidentally break other code's assumptions. In some situations, all that's required of you is merely to declare that you indeed intend to change some other code's assumptions; in more involved situations (e.g. a library method computes the sum of its argument and you want to change it to compute the product) the work is more involved, but you can still do it relatively easily. What we have blocked is the ability of a library to change the assumptions of another library or of the application's without the application knowing about it. A library absolutely must not be allowed to do that while hiding that from the application.