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

Java.evolved: Java has evolved. Your code can too

javaevolved.github.io

Post reply on HN
Print view View original

31–40 of 40 posts

Re: Java.evolved: Java has evolved. Your code can too

#31

Post by jghn »

stuaxo wrote: post #18
gzread wrote: post #9

Not many people know this, but you can also write public int x, y; instead of private int x, y; public int getX() {return x;} public void setX(int x) {this.x = x;} public int getY() {return y;} public void setY(int y) {this.y = y;} this is compatible with any language version

I'm from the ancient years of Java, surely this must have started at some point ? Do you get getters and setters ? I left Java around version 5.

The more modern take is to not bother with getters & setters for most things. People were cargo-cutting getters/setters on every variable without thinking about the implications.

First off, there's the question of if most things should even *allow* updates or just be immutable.

Second, what's the discernable difference between `public final int foo` and `private final foo` w/ `public int getFoo()`. Nothing really. The claim was always "but what if you want to update `foo` to be something more complex? The pain that these advocates always suggested never really wound up being much of a real world problem.

Re: Java.evolved: Java has evolved. Your code can too

#32

Post by jghn »

happymellon wrote: post #10
gzread wrote: post #9

Not many people know this, but you can also write public int x, y; instead of private int x, y; public int getX() {return x;} public void setX(int x) {this.x = x;} public int getY() {return y;} public void setY(int y) {this.y = y;} this is compatible with any language version

And the second you have anything other than a toy application you'll find out why getters, setters, and validation were invented, and why we them just moved everything to have consistent interfaces.

Have worked on many a non-toy java application. Have never used things like Lombok hiding getters/setters behind the covers. Never found this to be a real world problem.

Re: Java.evolved: Java has evolved. Your code can too

#33

Post by brunoborges »

javaUIevolved wrote: post #17
brunoborges wrote: post #3

Earlier quoted context omitted.

Hey mate, what UX would you suggest? Happy to explore ideas! For a better visualization to compare old/new, just click on the card and it will open that particular pattern in a new page.

Can you add a page where its just a list of all of them in a format like that? https://imgur.com/a/iO42lrs I would love to just scroll through a page without having to click on individual cards to see both side by side. Love the overall idea of what you did!

Done, updated!

Re: Java.evolved: Java has evolved. Your code can too

#34

Post by jaen »

brunoborges wrote: post #27
gzread wrote: post #9

Not many people know this, but you can also write public int x, y; instead of private int x, y; public int getX() {return x;} public void setX(int x) {this.x = x;} public int getY() {return y;} public void setY(int y) {this.y = y;} this is compatible with any language version

In many cases, yes, public fields are fine. But there are limitations: - Can't synchronize access. `synchronized` keyword is not applicable to fields, only to methods and code blocks. - Can't proxy. Not possible in public fields, therefore can't intercept calls before state is changed. This is useful for example in mocking frameworks, and telemetry libraries. - Can't evolve. Methods allow encapsulation, which allows…

but...

1. Synchronizing on trivial properties (otherwise you couldn't use `public` anyway!) is an anti-pattern, as it's a too fine-grained unit of concurrency and invites race conditions.

2. Can't proxy without rewriting byte code, you mean.

3. Of course you can evolve, it's just a breaking ABI change so it requires a trivial code migration on the side of the callee. If the cost of that migration is too high, something else is wrong.

Re: Java.evolved: Java has evolved. Your code can too

#35

Post by leapingdog »

jghn wrote: post #31
stuaxo wrote: post #18

Earlier quoted context omitted.

I'm from the ancient years of Java, surely this must have started at some point ? Do you get getters and setters ? I left Java around version 5.

The more modern take is to not bother with getters & setters for most things. People were cargo-cutting getters/setters on every variable without thinking about the implications. First off, there's the question of if most things should even *allow* updates or just be immutable. Second, what's the discernable difference between `public final int foo` and `private final foo` w/ `public int getFoo()`. Nothing really. Th…

Anything relying on beans for (de)serialization via reflection (XML; JSON) were the big incentive in the J2EE space if I recall correctly.

Re: Java.evolved: Java has evolved. Your code can too

#36

Post by jghn »

leapingdog wrote: post #35
jghn wrote: post #31

Earlier quoted context omitted.

The more modern take is to not bother with getters & setters for most things. People were cargo-cutting getters/setters on every variable without thinking about the implications. First off, there's the question of if most things should even *allow* updates or just be immutable. Second, what's the discernable difference between `public final int foo` and `private final foo` w/ `public int getFoo()`. Nothing really. Th…

Anything relying on beans for (de)serialization via reflection (XML; JSON) were the big incentive in the J2EE space if I recall correctly.

Yes. And I believe it kept going with Spring.

But those were mistakes imposed by frameworks. Not a necessity for good language usage.

Re: Java.evolved: Java has evolved. Your code can too

#37

Post by uniq7 »

jaen wrote: post #34
brunoborges wrote: post #27

Earlier quoted context omitted.

In many cases, yes, public fields are fine. But there are limitations: - Can't synchronize access. `synchronized` keyword is not applicable to fields, only to methods and code blocks. - Can't proxy. Not possible in public fields, therefore can't intercept calls before state is changed. This is useful for example in mocking frameworks, and telemetry libraries. - Can't evolve. Methods allow encapsulation, which allows…

but... 1. Synchronizing on trivial properties (otherwise you couldn't use `public` anyway!) is an anti-pattern, as it's a too fine-grained unit of concurrency and invites race conditions. 2. Can't proxy without rewriting byte code, you mean. 3. Of course you can evolve, it's just a breaking ABI change so it requires a trivial code migration on the side of the callee. If the cost of that migration is too high, somethi…

> a trivial code migration on the side of the callee

If your library is used by multiple consumers, forcing all them to migrate is not trivial, no matter how simple the change is.

If your income comes from these customers, it is not a good idea to put every one of them in the situation of having to choose between updating their code or stoping being your customer.

Re: Java.evolved: Java has evolved. Your code can too

#38

Post by happymellon »

brunoborges wrote: post #26
happymellon wrote: post #20

Earlier quoted context omitted.

Except records are immutable and have getters and setters as builtins to replicate what we've been doing with Lombok. So enforces what I was saying.

To be clear, Records don't have setters. They are immutable.

Yeah, sorry, typo.

Still they institutionalise getters, which is the opposite of what their argument was.

Re: Java.evolved: Java has evolved. Your code can too

#39

Post by tadfisher »

happymellon wrote: post #38
brunoborges wrote: post #26

Earlier quoted context omitted.

To be clear, Records don't have setters. They are immutable.

Yeah, sorry, typo. Still they institutionalise getters, which is the opposite of what their argument was.

Well, they don't have "getters" either, they have accessors; x() instead of getX(). It's still bad, but at least it doesn't enforce JavaBeans conventions, which is where getters and setters actually originate [0].

0: https://en.wikipedia.org/wiki/JavaBeans

Re: Java.evolved: Java has evolved. Your code can too

#40

Post by joe_mwangi »

pshirshov wrote: post #16

What's still missing: - typeclasses/implicits - HKTs - for comprehension - macros/quasiquotes powerful enough to implement my custom reflection

Typeclasses are coming. And they will use them for growing the language such as operator overloading, collection literals, narrowing & widening types, etc.
Post reply on HN