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

81–90 of 143 posts

Re: JEP draft: Prepare to make final mean final

#81

Post by pandemic_region »

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…

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

Re: JEP draft: Prepare to make final mean final

#82

Post by pests »

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…

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.

Re: JEP draft: Prepare to make final mean final

#83

Post by pests »

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 feels weird to me that functions exist without being in the source code.

Re: JEP draft: Prepare to make final mean final

#85

Post by nirvdrum »

stickfigure wrote: post #3

Great! Now can we make `final` the default for all fields, variables, and parameters? (yes yes, I know, that would break syntax... but please come up with something to discourage mutability)

I'd be happy with a `val` keyword. I thought that was a seriously missed opportunity when they introduced `var`.

Re: JEP draft: Prepare to make final mean final

#86

Post by pandemic_region »

pests wrote: post #83
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 feels weird to me that functions exist without being in the source code.

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.

Re: JEP draft: Prepare to make final mean final

#87

Post by DevelopingElk »

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.

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

Re: JEP draft: Prepare to make final mean final

#88

Post by n_plus_1_acc »

eastbound wrote: post #16
PathOfEclipse wrote: post #12

Earlier quoted context omitted.

setAccessible is also used to be able to access private fields, and not just to be able to write to final fields. Most libraries shouldn't need to set final fields, and I say this as someone who was very against when they deprecated java.lang.misc.Unsafe. I've only had to set a final field once in my career and it was related to some obscure MySql/JDBC driver bug/workaround. This particular deprecation seems very sen…

So how should GSON initialize an object? The theory is, go through the constructor. However, some objects are designed to go through several steps before reaching the desired state. If GSON must deserialize {…, state:”CONFIRMED”}, it needs to call new Transaction(account1, account2, amount), then .setState(STARTED) then .setState(PENDING) then .setState(PAID) then .setState(CONFIRMED) ? That’s the theory of the const…

Just do it like Rust

Re: JEP draft: Prepare to make final mean final

#89

Post by pests »

pandemic_region wrote: post #86
pests wrote: post #83

Earlier quoted context omitted.

It feels weird to me that functions exist without being in the source code.

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.

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.

Re: JEP draft: Prepare to make final mean final

#90

Post by pests »

DevelopingElk wrote: post #87
pests wrote: post #82

Earlier quoted context omitted.

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.

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 just seems like such a low amount of code to keep around it shouldnt be too much hassle.
Post reply on HN