What's new in Java 12, 13 and 14
java.christmas
What's new in Java 12, 13 and 14
1–10 of 136 posts
Re: What's new in Java 12, 13 and 14
#2The new style of switch statements is very nice. I've found myself using if else blocks to replace switch statements because they're simply more legible, and they take up less vertical space. Now the new style switch statements will be an improvement over that.
Re: What's new in Java 12, 13 and 14
#3off-topic: What a cool TLD!
Re: What's new in Java 12, 13 and 14
#4The new style of switch statements is very nice. I've found myself using if else blocks to replace switch statements because they're simply more legible, and they take up less vertical space. Now the new style switch statements will be an improvement over that.
Its copied from Scala pattern matching, and still isn't as good as it.
Re: What's new in Java 12, 13 and 14
#5Pattern matching in switch statements (calling them match statements would then be more fitting), a nice way to deal with nulls, and proper sum types (aka tagged unions, like enums in Rust) and Java would be pretty up-to-date.
Re: What's new in Java 12, 13 and 14
#6Now we have got 4 vanity TLD post on the FP. This smells.
Re: What's new in Java 12, 13 and 14
#7Java is actually getting quite a few nice features these days. I am especially excited about these improvements to the `switch` statement – I have always felt that the `switch` statement is more or less useless in its current form. Now, if it only had exhaustiveness..
Re: What's new in Java 12, 13 and 14
#8The new style of switch statements is very nice. I've found myself using if else blocks to replace switch statements because they're simply more legible, and they take up less vertical space. Now the new style switch statements will be an improvement over that.
Its copied from Scala pattern matching, and still isn't as good as it.
Almost all features in the Java language are guaranteed to be copied from other languages because it is in Java's "charter" not to introduce features that haven't been tried in other languages first, and then copy only those that have shown a good cost/benefit. The question you should ask is not which features are copied, but which ones aren't.
Re: What's new in Java 12, 13 and 14
#9One thing I find a bit disappointing is the focus on language features. Most of the effort in Java goes into the VM and libraries, while keeping the language conservative. This is because VM/library features have a much bigger impact on application quality, and more directly impact the application's users; moreover, it's a strategy that's proven quite successful -- HN notwithstanding, most developers don't like too much change in the language. Still, many developers focus on language changes that affect them, rather than major changes than can affect their customers and their business. Recent versions have seen major improvements to the GCs, startup time, and there's an exciting new Java Flight Recorder (low-overhead, deep in-production profiling) feature in 14 that allows streaming flight recorder events.
Also, the bit about LTS is problematic. While the multiple LTS update paths have their place (although the widely in their offerings and intended audiences), they are not less risky than the default path. The default path is designed to be the cheapest and easiest, but requires a little bit more agility. The effort required to update to a new feature release is not much bigger than the effort required to update to a patch release, especially as some of the LTS programs have major new features in their "patches." An LTS program should be chosen only once it's been established that the default, recommended update path is not right for your organization, and even then you'll need to compare the different LTS programs, as they differ from one another in about as much as LTS differs from the regular update path. LTS should not be the default choice.
Re: What's new in Java 12, 13 and 14
#10If I'm not mistaking, there is no JEP for making throw statements expressions. Is there an obvious thing that I'm missing here?
It would make sense for concise method bodies [1] and throwing in switch expression branches more consistent (over making exceptions for throw statements).
Also, C# did the same thing.