4 ms·
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.o
by vips7L 1y ago
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-data-heavy-workloads-part-1/ https://hazelcast.com/blog/performance-of-modern-java-on-dat...
- Twirrim 1y agoUsing 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.
- vips7L 1y ago> Java 8 was the peak of development age for the JDK. Still glorifying it.
- watwut 1y agoThere 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.
- jfengel 1y agoVar 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.
- matt2000 1y agoI 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.
- cokely 1y agoYeah I generally avoid using 'var' to elide method return types for that reason. In my early phase of var enthusiasm I even had it result in a bug that would have been caught if the type had been made explicit. I do still really like it in the `var list = new ArrayList<String>()` case though.
- watwut 1y agoModify 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.
- leetcrew 1y agothe 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.
- jghn 1y ago