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

What's new in Java 12, 13 and 14

java.christmas

Post reply on HN
Print view View original

71–80 of 136 posts

Re: What's new in Java 12, 13 and 14

#71

Post by heelix »

pron wrote: post #21
kjeetgill wrote: post #16

Earlier quoted context omitted.

I agree. I find the VM stuff the most facinating too, but I think you're underestimating the incredible impact language changes have had and continue to. Language changes don't aren't just bells and whistles. Lambdas changed how nearly every API works and record types have the opportunity to make a huge difference. Sure var was smaller, but it's been refreshing. I also think you're underselling how conservative the o…

6 months is not hectic, because the new feature releases are not major releases. In fact, major releases are gone, the last one ever being 9. Up until JDK 9, there used to be patch releases every couple of months, and big feature releases (which used to be called "limited updates") every six months. In addition to bug and security fixes, those included large, potentially disruptive features — like JavaFX and support…

Man, I disagree. For large enterprises, six months is a ridiculous pace to package/distribute a new major version. The fact that it is just enhancements does not matter. It may seem simple, but most implementations have that integer as part of the deployment path. The aggressive deprecation/removal in the 'major' six month cycle has been rough. If this is my local workstation, no worries. It creates chaos on work systems, however.

(Did a decade+ at Oracle, and now at a shop three times its size. You should understand inflexibility and moving at the speed of business. :P )

There still are quarterly patches to the LTS releases (7u241, 8u231, 11.0.5), with the next batch due the second week of January for all the LTS versions - 7/8/11 on the Oracle side, 8/11 on the Adopt OpenJDK, and other OpenJDK implementations possibly supporting all three. Almost every other organization I've talked with is sticking to the LTS, with plans to jump from JDK 11 to JDK 17 when it comes around. (and hearing the woes of all the folks still trying to get past JDK 8)

Re: What's new in Java 12, 13 and 14

#72

Post by mumblemumble »

pron wrote: post #31
EnderMB wrote: post #22

As someone that used to write a lot of C#, I find that the language is changing so often that it's hard to know what's new and what's been around for years. In contrast, Java hasn't changed all that much over the years, and I wonder if an approach of taking the more useful features from C# and ignoring some of the others would be a good approach. I often wonder how Java developers feel when they look over at C#, and…

It's not taking some features and ignoring others. It's taking features than have shown good cost/benefit, and not taking those that haven't. The choice here is about which features not to adopt, just as much as it is about which features to adopt. Java's philosophy is still innovation in the VM while keeping the language conservative. It's just that conservative is a relative term, here. If some language feature see…

> It's taking features than have shown good cost/benefit, and not taking those that haven't.

I actually wonder if it's more taking features that have proven sexy, and ignoring the rest. I still think that the single biggest source of verbosity - and design damage in some of the newer APIs such as streams - is that Java hasn't implemented extension methods. That costs me time and money on a regular basis. By comparison, the cost of fall through by default in switch statements is that I have to use a linter. Which I already have to do for a fistful of other reasons, anyway, so, while this -> operator certainly scratches an itch I've had, it doesn't move the needle much in terms of productivity or code quality.

edit: Should add, in C#'s defense - .NET's lightweight concurrency was initially implemented as a library. C#'s async/await came later, and is just syntactic sugar as far as I've ever been able to tell.

Re: What's new in Java 12, 13 and 14

#73

Post by pron »

mumblemumble wrote: post #72
pron wrote: post #31

Earlier quoted context omitted.

It's not taking some features and ignoring others. It's taking features than have shown good cost/benefit, and not taking those that haven't. The choice here is about which features not to adopt, just as much as it is about which features to adopt. Java's philosophy is still innovation in the VM while keeping the language conservative. It's just that conservative is a relative term, here. If some language feature see…

> It's taking features than have shown good cost/benefit, and not taking those that haven't. I actually wonder if it's more taking features that have proven sexy, and ignoring the rest. I still think that the single biggest source of verbosity - and design damage in some of the newer APIs such as streams - is that Java hasn't implemented extension methods. That costs me time and money on a regular basis. By compariso…

First, no language feature has been shown to move the needle much in terms of productivity or code quality. We are unable to detect differences between (reasonable) language choices, let alone individual features, so it's mostly about ergonomics. I'd be extremely surprised if you could show that any feature or lack thereof actually costs you money, but if you could, that would be quite a discovery. As to extension methods, they're not ignored. The language team is just unconvinced it's a good feature, which doesn't mean there aren't people who like it. As to switch statements, the language team had actually analyzed many hundreds of millions of lines of code before committing to the feature.

Re: What's new in Java 12, 13 and 14

#74

Post by pron »

heelix wrote: post #71
pron wrote: post #21

Earlier quoted context omitted.

6 months is not hectic, because the new feature releases are not major releases. In fact, major releases are gone, the last one ever being 9. Up until JDK 9, there used to be patch releases every couple of months, and big feature releases (which used to be called "limited updates") every six months. In addition to bug and security fixes, those included large, potentially disruptive features — like JavaFX and support…

Man, I disagree. For large enterprises, six months is a ridiculous pace to package/distribute a new major version. The fact that it is just enhancements does not matter. It may seem simple, but most implementations have that integer as part of the deployment path. The aggressive deprecation/removal in the 'major' six month cycle has been rough. If this is my local workstation, no worries. It creates chaos on work sys…

> six months is a ridiculous pace to package/distribute a new major version

I agree, which is why we've done away with major releases altogether. There have been feature releases every six months with major new features for over ten years now. All that's changed is that we've changed how they're named and removed the major releases. And if you've found it acceptable that the 8u20 feature releases stopped getting patches after six months, and upgraded to 8u40, it shouldn't matter much that we now give those versions an integer number. Not only do you not need to package a new major release every six months, but you don't need to package a new major release ever again!

Your assumption that it's significantly harder to switch from 11.0.2 to 12 than it is to switch from 11.0.2 to 11.0.3 does not seem to be based on any data we've seen. Most organizations that can do the latter can do the former. Not only the result will be cheaper and easier overall, but you'd get to enjoy all the performance and serviceability features even if you don't want to use new language/library features.

> Almost every other organization I've talked with is sticking to the LTS, with plans to jump from JDK 11 to JDK 17 when it comes around.

That will change soon (it already is changing), as more people understand the new model and the change to the version names. However, even if you are certain that your choice of LTS is justified (and I must say that it doesn't seem like you fully understand the new model yet -- which is OK, many don't, and it will take time), you must test your code on the current JDK. Updating from 11 to 17 without doing that is taking a huge risk. You will see features disappear without deprecation warnings.

Re: What's new in Java 12, 13 and 14

#75

Post by n0rbwah »

smitty1e wrote: post #38
vturner wrote: post #32

Sigh, I know new language features are cool, but I highly doubt the growing dominance of Python and JS is a question primarily of language features. Python has a REPL and the outstanding tooling built on that along with an ecosystem of libraries where a default use case is the design choice. That all leads to "fast" development which what a lot of people care about. JS has the default use app deployment area: browser…

Right, but will We Assembly be a JS killer? If I can stay in Python and target the browser without the fuss and bother of JavaScript, why would I?

There's already a transpiler to compile python to Javascript. The question is: why would you want the hassle to add that tool to your pipeline and the added complexity of debugging your frontend code?

Re: What's new in Java 12, 13 and 14

#76

Post by ivolimmen »

vbezhenar wrote: post #43
qw wrote: post #25

Earlier quoted context omitted.

Java 8 was released March 18, 2014, so they had 5 years to upgrade. But I see your point about the new release schedule, where the LTS version is not supported after 6 months. I think the companies need to change their mindsets. New Java version are backwards compatible, as they introduce changes gradually. It is actually more dangerous to wait, because they risk that some features (like GC) are deprecated after 4-5…

I still need to pass weird flags for Tomcat to make it work under Java 9+, almost 6 years later. Modules were a mistake. If not for modules, a lot of people would have migrated to 9+.

Modules where not a mistake but we will likely benefit from it in say at least 5 years. Every artifact/library you use has to be a (real) module to be able to use it's full potential.

Re: What's new in Java 12, 13 and 14

#77

Post by [deleted] »

pron wrote: post #21
kjeetgill wrote: post #16

Earlier quoted context omitted.

I agree. I find the VM stuff the most facinating too, but I think you're underestimating the incredible impact language changes have had and continue to. Language changes don't aren't just bells and whistles. Lambdas changed how nearly every API works and record types have the opportunity to make a huge difference. Sure var was smaller, but it's been refreshing. I also think you're underselling how conservative the o…

6 months is not hectic, because the new feature releases are not major releases. In fact, major releases are gone, the last one ever being 9. Up until JDK 9, there used to be patch releases every couple of months, and big feature releases (which used to be called "limited updates") every six months. In addition to bug and security fixes, those included large, potentially disruptive features — like JavaFX and support…

[deleted]

Re: What's new in Java 12, 13 and 14

#79

Post by suyash »

smitty1e wrote: post #38
vturner wrote: post #32

Sigh, I know new language features are cool, but I highly doubt the growing dominance of Python and JS is a question primarily of language features. Python has a REPL and the outstanding tooling built on that along with an ecosystem of libraries where a default use case is the design choice. That all leads to "fast" development which what a lot of people care about. JS has the default use app deployment area: browser…

Right, but will We Assembly be a JS killer? If I can stay in Python and target the browser without the fuss and bother of JavaScript, why would I?

JavaScript and Python can't match performance, scalability, security, rich libraries for developing enterprise applications that comes with Java Ecosystem.

Re: What's new in Java 12, 13 and 14

#80

Post by dkersten »

pron wrote: post #9

One 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 m…

I agree because I use the JVM but I do not use Java. So I care about changes to the JVM and ecosystem but changes to the Java language itself don’t mean anything to me.
Post reply on HN