Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JEP draft: Prepare to make final mean final

openjdk.org

Post reply on HN
Print view View original

91–100 of 143 posts

Re: JEP draft: Prepare to make final mean final

#91

Post by throwaway92422 »

cogman10 wrote: post #75
pron wrote: post #71

Earlier quoted context omitted.

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, althou…

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 u…

I like Lombok. The best annotation is @Builder. It makes working with records much more convenient.

Re: JEP draft: Prepare to make final mean final

#92

Post by Phelinofist »

sgammon wrote: post #77
owlstuffing wrote: post #67

Earlier quoted context omitted.

The issue is that many essential libraries and tools rely on setting internal final fields. I assume that's why the options around this have remained open-ended. The problem with these various "integrity by default" options is that, in most cases, granting access to one effectively grants access to all. For instance, JNI, agent libraries, and JPMS options can each be used to bypass restrictions, making the separation…

It's 2025 and Guava supports JPMS now

Android doesn't :(

Re: JEP draft: Prepare to make final mean final

#93

Post by dingi »

pandemic_region wrote: post #81
cogman10 wrote: post #75

Earlier quoted context omitted.

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 u…

Why the Lombok hate? It's just an innocent preprocessor allowing a bit of syntactic sugar right?

It’s not an innocent preprocessor. It’s a hack which breaks on almost every JDK upgrade.

Re: JEP draft: Prepare to make final mean final

#94

Post by JanecekPetr »

throwaway92422 wrote: post #91
cogman10 wrote: post #75

Earlier quoted context omitted.

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 u…

I like Lombok. The best annotation is @Builder. It makes working with records much more convenient.

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!

Re: JEP draft: Prepare to make final mean final

#95

Post by JanecekPetr »

pandemic_region wrote: post #81
cogman10 wrote: post #75

Earlier quoted context omitted.

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 u…

Why the Lombok hate? It's just an innocent preprocessor allowing a bit of syntactic sugar right?

- It doesn't work with ErrorProne (https://github.com/google/error-prone/issues?q=sort%3Aupdate...) - you need a special plugin in your IDE for the generated classes to be visible and/or the code to be parsable - it does not work with many other tools, usually there is a bridge to fix that, e.g. with MapStruct: https://mapstruct.org/faq/#Can-I-use-MapStruct-together-with...

Other tools and libraries generally do not interact in such an errorprone manner.

That said, when you know how it works, what it needs, and you know how to iron all of those tiny wrinkles, it works fine and saves you some code and/or sanity. It's not the devil, it's a powerful tool with some downsides.

Re: JEP draft: Prepare to make final mean final

#96

Post by dwattttt »

pandemic_region wrote: post #81
cogman10 wrote: post #75

Earlier quoted context omitted.

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 u…

Why the Lombok hate? It's just an innocent preprocessor allowing a bit of syntactic sugar right?

http://thecodelesscode.com/case/97

There's one of these for just about every occasion

Re: JEP draft: Prepare to make final mean final

#97

Post by pandemic_region »

JanecekPetr wrote: post #95
pandemic_region wrote: post #81

Earlier quoted context omitted.

Why the Lombok hate? It's just an innocent preprocessor allowing a bit of syntactic sugar right?

- It doesn't work with ErrorProne ( https://github.com/google/error-prone/issues?q=sort%3Aupdate... ) - you need a special plugin in your IDE for the generated classes to be visible and/or the code to be parsable - it does not work with many other tools, usually there is a bridge to fix that, e.g. with MapStruct: https://mapstruct.org/faq/#Can-I-use-MapStruct-together-with... Other tools and libraries generally do no…

I did not know about ErrorProne thanks, I can see this is useful indeed and then Lombok would be the odd one out breaking that tool. About the special IDE plugin, IntelliJ has native support but yeah it needs a bit of attention that's true. Overall the minor extra hassle is still worth it in my world. We're not using all of the annotations, but (in order of utility) @AllArgsConstructor, @Data, @Getter, @Setter and the occasional @Synchronized.

Re: JEP draft: Prepare to make final mean final

#98

Post by saghm »

pests wrote: post #82
cogman10 wrote: post #75

Earlier quoted context omitted.

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 u…

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.

I mean, we're talking about how the best way to externally modify things that are ostensibly supposed to be internal and immutable, right? I feel like pretty much any way of doing it is going to be spooky action at a distance by definition. Modifying private internals from the outside isn't something you can do with mundane-action-at-close-range or whatever the alternative would otherwise be called.

Re: JEP draft: Prepare to make final mean final

#99

Post by vbezhenar »

pests wrote: post #90
DevelopingElk wrote: post #87

Earlier quoted context omitted.

Yes, from a language design it's ugly and the implementation is convoluted. From a user perspective it's awesome and enables better interfaces.

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…

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.

Re: JEP draft: Prepare to make final mean final

#100

Post by gf000 »

pandemic_region wrote: post #81
cogman10 wrote: post #75

Earlier quoted context omitted.

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 u…

Why the Lombok hate? It's just an innocent preprocessor allowing a bit of syntactic sugar right?

The biggest gripe is that it is not a preprocessor. Java has standard interfaces to properly preprocess code, and they have a very thoughtful limitation of no code modification, it is strictly additive.

There are very cool libraries making use of it, e.g. mapstruct.

Now, lombok in its current approach can't make use of it, as it explicitly wants to modify the given class with its annotations. This is forbidden, so they literally hack into the java compiler classes themselves, modifying the AST in-flight. As you can imagine, this might break at a new Java update any time.

Post reply on HN