5 ms·

Programming language is a tool. Java developers value stability and ease of understanding for the code. I've seen the nice features you complain that don't get

Programming language is a tool. Java developers value stability and ease of understanding for the code. I've seen the nice features you complain that don't get used, reality is that nobody wants to waste time knowing them unless they are intuitive to use. Especially when are forcing to use newer JDKs. There is no value in solving a challenge in a way that only you understand or make others lose time trying to understand the logic. Java 8 was the peak of development age for the JDK. Everything that came after isn't really memorable nor helpful, especially lambdas. You mention "var", why would we ever want in Java to hold a variable that you can't read immediately what is the type? That is a source of bugs and time waste to track down what object is being used. I don't mind you are happy with all these changes, just remember that we absolutely don't care about them nor will make much of an effort because in the end of the day we don't want to follow the same route of other programming languages unable to handle gigantic and complex platform systems. This isn't a competition to showoff who can apply new tricks, we absolutely don't care about functional programming. Java code must be simple and easy for anyone to read, that's it.

frje1400 1y ago
> You mention "var", why would we ever want in Java to hold a variable that you can't read immediately what is the type? var items = new HashMap(); Instead of HashMap items = new HashMap(); That's the point of var. It reduces noise a lot in some situations.
- jsnsndn 1y ago
  While I do use `var` when appropriate, your example is in general not appropriate You would like to use Map<Key, Value> items = new HashMap<>() since in general you do not want implementation detail leaking into contracts
  - vips7L 1y ago
    Using var there doesn’t leak any implementation details into any contracts. Var is for local variables inside of functions. There are no details or contracts there.
- vbezhenar 1y ago
  You should write Map<String, Integer> items = new HashMap<>(); It allows you to limit `items` usage to `Map` supertype and allows you to swap implementation easily, if necessary. `var` is weird feature, because it allows people to use implementation-specific methods methods and tie code to a single implementation, essentially making it less agile. There are valid use-cases for `var`, but IMO this feature should not have been added to the language, as it's too dangerous and most people won't use it responsibly.
  - tombert 1y ago
    Your example isn’t good though; var is only for local variables, which should be perfectly allowed to use implementation-specific methods. For argument types you don’t have var, so methods that take in a map can stay abstract and you can still pass in the implementation-specific version into those without casting it to the interface. ETA: I guess I am trying to say that if you want to be abstract, they should be at the argument or properties level. Local variables should be used locally. I agree that generally speaking you should try and prefer using Map for anything shared across different parts of code but I am not convinced it’s bad to have var be implementation-specific; if your method is big enough to where swapping out implementations like this will take a lot of time, your method is probably too big anyway.
  - pico303 1y ago
    No, you shouldn't write that. Your variable should represent the complete implementation. Where you use it should be as generic as possible, for example, the parameter in a function call.
    - jfengel 1y ago
      Why would you want that? The whole point of an interface or superclass is to let you swap implementations without changing everything. I also like the nudge it gives you to use only the higher level methods, rather than the ones specific to the subclass unless they're needed. That also improves flexibility.
      - 1y ago
delusional 1y ago
> You mention "var", why would we ever want in Java to hold a variable that you can't read immediately what is the type? I've been a full time java developer for the past 7 years. Let me start by agreeing that I have very little interests in the functional "innovations" they added. They're fine, but most of my colleagues agree that code using streams or lambdas very quickly becomes harder to debug then if you just wrote the code with loops and. That's far from true for every java feature though. Switch statements have been super cool, Green threads are a promising road out of the CompletionStage hell the children are dreaming of these days. "var" is a very nice way to reduce double typing ("Thing x = new Thing()" -> "var x = new Thing()") and also a nice way to avoid changes to unrelated files ("Thing x = getFoo(); f(x);" -> "var x = getFoo(); f(x)" means changing the name of class Thing doesn't require any change to the code) that's been helpful in a lot of cases.
- nunobrito 1y ago
  Yes, please don't get me wrong. There are always a few good things, but like you mention with streams: the person writing it can have an idea of what he was doing but the others afterwards will struggle to make changes and will likely revert the code base to simpler code. Switch statements got better. I'm also getting used to Paths albeit don't yet understand why File wasn't already good enough. It is difficult to find compelling reasons for upgrading the JDK since I know it will be hassle for everyone that later down the line has to install/run the product.
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 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.
  - vips7L 1y ago
    > Java 8 was the peak of development age for the JDK. Still glorifying it.
- watwut 1y 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.
  - jfengel 1y 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.
tombert 1y ago
I do not want to be rude but I am going to be: this entire comment illustrates my point very well. Instead of trying to actually learn new stuff, you say that the language peaked thirteen years ago. > Everything that came after isn't really memorable nor helpful, especially lambdas. Lambdas came out in Java 8, along with the streams API, and the fact that you don’t think they’re useful more demonstrates to me that you don’t actually understand it, since nearly every language before and after Java has lambdas and nearly everyone agrees that they’re useful. Reifying a bunch of temporary interfaces is not “more readable” than a lambda. A bunch of terrible nested for-loop logic is not “more readable” than the streams API. > You mention "var", why would we ever want in Java to hold a variable that you can't read immediately what is the type? Your IDE can show the type, but even disregarding that there are lots of cases where you have to write the type twice in Java and it just makes noise. It doesn’t make the code more readable. > we don't want to follow the same route of other programming languages unable to handle gigantic and complex platform systems. Burying your head in the sand and Ignoring improvements in the language doesn’t make you more able to handle complex problems. It actually does the opposite and that’s so plainly obvious that I don’t think you actually thought through the sentence before you wrote it. Take something like virtual threads. Most Java programmers don’t use them and instead keep using an executor service incorrectly because they also never learned the difference between blocking and non blocking IO. For them, virtual threads would be strictly better because it properly parks blocking IO. Ultimately, I guess I disrespectfully disagree that Java “peaked” in 2012.
deknos 1y ago
You know what's quite more important? * Performant and safe standard library. * batteries included * a good way to actually care about managing dependencies, during build and runtime. Okay, you got your stuff, please everyone now let's care about the standard library and that it really good.
pyrale 1y ago
> Especially when are forcing to use newer JDKs. Dude, java 8's eol was 8 6 years ago, now. I have nothing gainst waiting a bit for "newer JDKs", but way too often the pattern is that teams use the oldest possible JDK and only migrate several months/years after the last possible vendor has sunset their support. > Java 8 was the peak of development age for the JDK. To me it looks it was merely the point where your stopped caring.
Sharlin 1y ago
If I had to guess, I'd say that a vastly bigger problem in the world is legacy code written in decades-old obsolete and inconvenient language dialects than code that's "too new".
javanonymous 1y ago
> why would we ever want in Java to hold a variable that you can't read immediately what is the type I can use my IDE to see the type if necessary. > Everything that came after isn't really memorable nor helpful, There are several improvements that are very helpful One example is how multi line strings help me to read more clearly without the unnecessary string concatenations: var sql = """ SELECT foo FROM bar WHERE last_updated > :lastUpdated """; Another example is how switch statements have improved code readability, at least from my personal subjective viewpoint. String dayName = switch (day) { case 1 -> "Monday"; case 2 -> "Tuesday"; case 3, 4, 5 -> "Other day"; default -> "Weekend"; };
- nunobrito 1y ago
  You could have as easily used String instead of var and there would be no ambiguity. This gets worse for numbers where it is important to know if you are dealing with an integer, long or something even bigger. I agree with you on switches and do like the """ feature, thought. It was a real pain in the rear to include the multiple + "\n" back in the old days. This is a very clean and intuitive improvement.

frje1400 1y ago

> You mention "var", why would we ever want in Java to hold a variable that you can't read immediately what is the type? var items = new HashMap(); Instead of HashMap items = new HashMap(); That's the point of var. It reduces noise a lot in some situations.

jsnsndn 1y ago
While I do use `var` when appropriate, your example is in general not appropriate You would like to use Map<Key, Value> items = new HashMap<>() since in general you do not want implementation detail leaking into contracts
- vips7L 1y ago
  Using var there doesn’t leak any implementation details into any contracts. Var is for local variables inside of functions. There are no details or contracts there.
vbezhenar 1y ago
You should write Map<String, Integer> items = new HashMap<>(); It allows you to limit `items` usage to `Map` supertype and allows you to swap implementation easily, if necessary. `var` is weird feature, because it allows people to use implementation-specific methods methods and tie code to a single implementation, essentially making it less agile. There are valid use-cases for `var`, but IMO this feature should not have been added to the language, as it's too dangerous and most people won't use it responsibly.
- tombert 1y ago
  Your example isn’t good though; var is only for local variables, which should be perfectly allowed to use implementation-specific methods. For argument types you don’t have var, so methods that take in a map can stay abstract and you can still pass in the implementation-specific version into those without casting it to the interface. ETA: I guess I am trying to say that if you want to be abstract, they should be at the argument or properties level. Local variables should be used locally. I agree that generally speaking you should try and prefer using Map for anything shared across different parts of code but I am not convinced it’s bad to have var be implementation-specific; if your method is big enough to where swapping out implementations like this will take a lot of time, your method is probably too big anyway.
- pico303 1y ago
  No, you shouldn't write that. Your variable should represent the complete implementation. Where you use it should be as generic as possible, for example, the parameter in a function call.
  - jfengel 1y ago
    Why would you want that? The whole point of an interface or superclass is to let you swap implementations without changing everything. I also like the nudge it gives you to use only the higher level methods, rather than the ones specific to the subclass unless they're needed. That also improves flexibility.
    - 1y ago

delusional 1y ago

> You mention "var", why would we ever want in Java to hold a variable that you can't read immediately what is the type? I've been a full time java developer for the past 7 years. Let me start by agreeing that I have very little interests in the functional "innovations" they added. They're fine, but most of my colleagues agree that code using streams or lambdas very quickly becomes harder to debug then if you just wrote the code with loops and. That's far from true for every java feature though. Switch statements have been super cool, Green threads are a promising road out of the CompletionStage hell the children are dreaming of these days. "var" is a very nice way to reduce double typing ("Thing x = new Thing()" -> "var x = new Thing()") and also a nice way to avoid changes to unrelated files ("Thing x = getFoo(); f(x);" -> "var x = getFoo(); f(x)" means changing the name of class Thing doesn't require any change to the code) that's been helpful in a lot of cases.

nunobrito 1y ago
Yes, please don't get me wrong. There are always a few good things, but like you mention with streams: the person writing it can have an idea of what he was doing but the others afterwards will struggle to make changes and will likely revert the code base to simpler code. Switch statements got better. I'm also getting used to Paths albeit don't yet understand why File wasn't already good enough. It is difficult to find compelling reasons for upgrading the JDK since I know it will be hassle for everyone that later down the line has to install/run the product.

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 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.
- vips7L 1y ago
  > Java 8 was the peak of development age for the JDK. Still glorifying it.
watwut 1y 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.
- jfengel 1y 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.

tombert 1y ago

I do not want to be rude but I am going to be: this entire comment illustrates my point very well. Instead of trying to actually learn new stuff, you say that the language peaked thirteen years ago. > Everything that came after isn't really memorable nor helpful, especially lambdas. Lambdas came out in Java 8, along with the streams API, and the fact that you don’t think they’re useful more demonstrates to me that you don’t actually understand it, since nearly every language before and after Java has lambdas and nearly everyone agrees that they’re useful. Reifying a bunch of temporary interfaces is not “more readable” than a lambda. A bunch of terrible nested for-loop logic is not “more readable” than the streams API. > You mention "var", why would we ever want in Java to hold a variable that you can't read immediately what is the type? Your IDE can show the type, but even disregarding that there are lots of cases where you have to write the type twice in Java and it just makes noise. It doesn’t make the code more readable. > we don't want to follow the same route of other programming languages unable to handle gigantic and complex platform systems. Burying your head in the sand and Ignoring improvements in the language doesn’t make you more able to handle complex problems. It actually does the opposite and that’s so plainly obvious that I don’t think you actually thought through the sentence before you wrote it. Take something like virtual threads. Most Java programmers don’t use them and instead keep using an executor service incorrectly because they also never learned the difference between blocking and non blocking IO. For them, virtual threads would be strictly better because it properly parks blocking IO. Ultimately, I guess I disrespectfully disagree that Java “peaked” in 2012.

deknos 1y ago

You know what's quite more important? * Performant and safe standard library. * batteries included * a good way to actually care about managing dependencies, during build and runtime. Okay, you got your stuff, please everyone now let's care about the standard library and that it really good.

pyrale 1y ago

> Especially when are forcing to use newer JDKs. Dude, java 8's eol was 8 6 years ago, now. I have nothing gainst waiting a bit for "newer JDKs", but way too often the pattern is that teams use the oldest possible JDK and only migrate several months/years after the last possible vendor has sunset their support. > Java 8 was the peak of development age for the JDK. To me it looks it was merely the point where your stopped caring.

Sharlin 1y ago

If I had to guess, I'd say that a vastly bigger problem in the world is legacy code written in decades-old obsolete and inconvenient language dialects than code that's "too new".

javanonymous 1y ago

> why would we ever want in Java to hold a variable that you can't read immediately what is the type I can use my IDE to see the type if necessary. > Everything that came after isn't really memorable nor helpful, There are several improvements that are very helpful One example is how multi line strings help me to read more clearly without the unnecessary string concatenations: var sql = """ SELECT foo FROM bar WHERE last_updated > :lastUpdated """; Another example is how switch statements have improved code readability, at least from my personal subjective viewpoint. String dayName = switch (day) { case 1 -> "Monday"; case 2 -> "Tuesday"; case 3, 4, 5 -> "Other day"; default -> "Weekend"; };

nunobrito 1y ago
You could have as easily used String instead of var and there would be no ambiguity. This gets worse for numbers where it is important to know if you are dealing with an integer, long or something even bigger. I agree with you on switches and do like the """ feature, thought. It was a real pain in the rear to include the multiple + "\n" back in the old days. This is a very clean and intuitive improvement.