undefined | Better HN

0 pointsvips7L6mo ago0 comments

The new features make the code easier to read. For example var:

    List<Account> accounts = List.of(new Account(1), new Account(2));
    var accounts = List.of(new Account(1), new Account(2));

It just reduces visual noise and boilerplate that you already know.

Java 8 is also a slow and old runtime. It performs terribly in 2025. Here’s a quote from 2020 and the gap has only gotten wider [0]:

> JDK 8 is an antiquated runtime. The default Parallel collector enters huge Full GC pauses and the G1, although having less frequent Full GCs, is stuck in an old version that uses just one thread to perform it, resulting in even longer pauses. Even on a moderate heap of 12 GB, the pauses were exceeding 20 seconds for Parallel and a full minute for G1. The ConcurrentMarkSweep collector is strictly worse than G1 in all scenarios, and its failure mode are multi-minute Full GC pauses.

You’re doing a disservice to everyone by continuing to use and glorify it.

[0] https://hazelcast.com/blog/performance-of-modern-java-on-dat...

0 comments

Twirrim6mo ago

Using Java 8 doesn't mean using the java 8 JDK. It just means not using the newer features. I don't see anything in the parents post about restricting which JDK they use.

vips7LOP6mo ago

> Java 8 was the peak of development age for the JDK.

Still glorifying it.

watwut6mo ago

There is about zero difference in readability of your two statements, rending var not useful.

And 'var accounts = calculateAccounts(something)' is literally less readable, because now you dont see what exactly accounts is.

Var statement speed up writing, then are either irrelevant or gets rewritten to types for better readability.

leetcrew6mo ago

the advantage of var is not clear in toy examples. in real life, people write stuff like

  Map<String, MyExtremelySpecificAndVeryLongTypeName> myExtremelySpecificAndVeryLongTypeNameMap = myExtremelySpecificAndVeryLongTypeNameMapProvider.provide();

literally anything to reduce the number of line breaks needed for a single statement is welcome.

matt20006mo ago

I agree, and I'm not sure how something like 'var accounts = calculateAccounts(something)' can be thought of as better in a code review setting. I suspect using "var" or equivalent will be considered a problem by most companies within the next few years.

tombert6mo ago

This experiment has already been run with pretty much every language that isn’t Java or C, and I think most people have been ok.

Yes, code review is arguably worse, but most people who write Java do so with an IDE and the type is never unknown at that point.

Also, if your function is big enough to where the type of var is not very clear, it likely shouldn’t be passing code review regardless.

1 more reply

vips7LOP6mo ago

There’s nuance in programming. Both of these statements can be true. Var reduces boiler plate when you’re duplicating information in both the lvalue and rvalue.

I’m in agreement that when the information isn’t in the rvalue that you shouldn’t use var.

jfengel6mo ago

Var can help in maintenance. Change the return type of calculateAccounts and you don't have to modify this code (assuming that it duck-types out equivalently).

That isn't necessarily a huge win: it does force a compile change that isn't obvious from the source. And a refactoring tool could have performed the code change automatically so it's not as big a deal as it might have been.

matt20006mo ago

I would argue that it helps me when performing maintenance to see and correct where types may have changed. Not always, and sometimes it is busy work I agree, but overall I prefer it.

1 more reply

watwut6mo ago

Modify it when? If the interface renames? IDE does that. If the actual return type changes? They you do have to check that place whether it is still valid.

Maintenance involves a lot of reading of unknown code. That is literally the situation where you are rewiting var to specific types to figure out what is going on.

jauntywundrkind6mo ago

I tend to agree here, I prefer explicitness. Even though yes it does mean some pain when refactoring, it also creates very clear diffs showing impact, which I consider a positive.

Ideally this could all be dealt with via tools. An IDE that shows whatever the user prefers, but is actually saving into a format defined for the repo.

Larrikin6mo ago

It is less readable because either accounts is named incorrectly or calculateAccounts is.

If it should be createAccounts, nothing is lost unless you have multiple account types in which case you would call it createUserAccounts, create adminAccounts etc.

jghn6mo ago

> is literally less readable

Please point me to an objective measure of "readability" that holds for all people. And then demonstrate that your example is "literally" lower on that scale.

pyrale6mo ago

Readability was a term coined by people writing languages that are litterally unusable without an IDE to hide stuff when they render the source file to explain why refusing to learn languages with curly braces is sane.

1 more reply

vips7LOP6mo ago

> var accounts = calculateAccounts(something)'

Where did I write this? It’s almost as if there’s nuance in programming.

Var helps when you’re duplicating information that is already known. Your example is clearly not that.

j / k navigate · click thread line to collapse

0 pointsvips7L6mo ago0 comments

The new features make the code easier to read. For example var:

    List<Account> accounts = List.of(new Account(1), new Account(2));
    var accounts = List.of(new Account(1), new Account(2));

It just reduces visual noise and boilerplate that you already know.

Java 8 is also a slow and old runtime. It performs terribly in 2025. Here’s a quote from 2020 and the gap has only gotten wider [0]:

You’re doing a disservice to everyone by continuing to use and glorify it.

[0] https://hazelcast.com/blog/performance-of-modern-java-on-dat...

0 comments

Twirrim6mo ago

Using Java 8 doesn't mean using the java 8 JDK. It just means not using the newer features. I don't see anything in the parents post about restricting which JDK they use.

vips7LOP6mo ago

> Java 8 was the peak of development age for the JDK.

Still glorifying it.

watwut6mo ago

There is about zero difference in readability of your two statements, rending var not useful.

And 'var accounts = calculateAccounts(something)' is literally less readable, because now you dont see what exactly accounts is.

Var statement speed up writing, then are either irrelevant or gets rewritten to types for better readability.

leetcrew6mo ago

the advantage of var is not clear in toy examples. in real life, people write stuff like

  Map<String, MyExtremelySpecificAndVeryLongTypeName> myExtremelySpecificAndVeryLongTypeNameMap = myExtremelySpecificAndVeryLongTypeNameMapProvider.provide();

literally anything to reduce the number of line breaks needed for a single statement is welcome.

matt20006mo ago

tombert6mo ago

This experiment has already been run with pretty much every language that isn’t Java or C, and I think most people have been ok.

Yes, code review is arguably worse, but most people who write Java do so with an IDE and the type is never unknown at that point.

Also, if your function is big enough to where the type of var is not very clear, it likely shouldn’t be passing code review regardless.

1 more reply

vips7LOP6mo ago

There’s nuance in programming. Both of these statements can be true. Var reduces boiler plate when you’re duplicating information in both the lvalue and rvalue.

I’m in agreement that when the information isn’t in the rvalue that you shouldn’t use var.

jfengel6mo ago

Var can help in maintenance. Change the return type of calculateAccounts and you don't have to modify this code (assuming that it duck-types out equivalently).

matt20006mo ago

I would argue that it helps me when performing maintenance to see and correct where types may have changed. Not always, and sometimes it is busy work I agree, but overall I prefer it.

1 more reply

watwut6mo ago

Modify it when? If the interface renames? IDE does that. If the actual return type changes? They you do have to check that place whether it is still valid.

Maintenance involves a lot of reading of unknown code. That is literally the situation where you are rewiting var to specific types to figure out what is going on.

jauntywundrkind6mo ago

I tend to agree here, I prefer explicitness. Even though yes it does mean some pain when refactoring, it also creates very clear diffs showing impact, which I consider a positive.

Ideally this could all be dealt with via tools. An IDE that shows whatever the user prefers, but is actually saving into a format defined for the repo.

Larrikin6mo ago

It is less readable because either accounts is named incorrectly or calculateAccounts is.

If it should be createAccounts, nothing is lost unless you have multiple account types in which case you would call it createUserAccounts, create adminAccounts etc.

jghn6mo ago

> is literally less readable

Please point me to an objective measure of "readability" that holds for all people. And then demonstrate that your example is "literally" lower on that scale.

pyrale6mo ago

1 more reply

vips7LOP6mo ago

> var accounts = calculateAccounts(something)'

Where did I write this? It’s almost as if there’s nuance in programming.

Var helps when you’re duplicating information that is already known. Your example is clearly not that.

j / k navigate · click thread line to collapse