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

111–120 of 136 posts

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

#111

Post by pron »

sangnoir wrote: post #109
pron wrote: post #74

Earlier quoted context omitted.

> 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 patc…

> 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. I think this the italicized portion is the disconnect between what Oracle wants Java users to do, and what they'd rather not do. I know the pain of wanting your users to a…

I understand that, I'm just saying that if your risk calculation concludes that LTS is less risky by default, then it's based on false assumptions, based on misunderstanding. The new feature releases are not major releases. If companies were fine upgrading to feature ("limited update") releases while there were still major releases around, I don't see why they would be more risky now that major releases are gone. I think that people can perceive them to be more risky because they confuse the change to the way those releases are named with the old major releases. For some companies, getting an LTS service is less risky, but not because of some intrinsic quality of LTS but because of their particular internal processes. For a great many companies, sticking to the default, gradual update process is the cheapest, least risky option.

Moreover, there are also special risks to LTS programs, particularly the free ones. A much smaller number of people work on them (about 1/50 of the total number of people working on OpenJDK), and they completely rely on backports from the mainline. So, for example, once the CMS collector is removed from the mainline, it becomes unsupported in some LTS programs (certainly the free ones) because there are no longer fixes to backport, and they don't have the resources to fix bugs without backports.

Finally, you can't talk about risk and treat LTS as a single thing, as the different LTS programs vary greatly in their risk vs. conservativeness. The Oracle LTS service contains almost only true patches: bug and security fixes, like the first two patches for each feature release. Red Hat's LTS/OpenJDK Updates and Azul's Zulu backport huge new features in their "patches." Amazon considers (or considered) taking the current VM and backporting it as a whole to an old JDK version in a "patch."

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

#112

Post by pron »

kllrnohj wrote: post #102
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…

The thing I find disappointing is the lack of bytecode changes. The language changes are all just trivial tweaks to javac. Appreciated niceties, sure, but nothing meaty. The VM changes are then likewise focused mostly on the GC. Again, appreciated, but it's entirely disconnected from the language. Where's the long-overdue improvements to the bytecode? Where's value types? Where's runtime generics?

It's not true that the VM changes focus mostly on the GCs. There have been significant changes to startup time and low-overhead profiling. And there are constant improvements in the JIT compilers. Project Loom's lightweight concurrency also involves big VM changes, but without any bytecode changes.

Reified runtime generics for reference types is a bad idea; it destroys language interop for very little gain. Value types and specialized generics for value types, on the other hand, are in the works. You can download and play with them here: http://jdk.java.net/valhalla/

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

#113

Post by tempguy9999 »

pron wrote: post #106
sreque wrote: post #94

Earlier quoted context omitted.

Language changes are super important when they enable you to program in a new way, or in that way with significantly less boilerplate. For instance, Java 8 enabled new ways of programming via Lambdas and structural typing. You could code in that way before, but anonymous class boilerplate was so high that few bothered, and those that did were hard-pressed to convince their colleagues of its value. The problem with la…

> Other future changes I am excited for, but don't expect to get implemented any time soon, if ever, frankly, are: Most if not all of them will land in the next few years. In fact, working on those precise features is what most of the OpenJDK team does. > Improved native code interop. I consider this to be both a language and VM change. That would be Project Panama, making its initial, partial delivery in JDK 14 (GA…

Utterly dumb question but why is tail recursion necessary in the JVM given that the compiler is better placed simply to turn recursion into a loop. TR removal should be done best at the highest level I'd think.

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

#114

Post by pron »

tempguy9999 wrote: post #113
pron wrote: post #106

Earlier quoted context omitted.

> Other future changes I am excited for, but don't expect to get implemented any time soon, if ever, frankly, are: Most if not all of them will land in the next few years. In fact, working on those precise features is what most of the OpenJDK team does. > Improved native code interop. I consider this to be both a language and VM change. That would be Project Panama, making its initial, partial delivery in JDK 14 (GA…

Utterly dumb question but why is tail recursion necessary in the JVM given that the compiler is better placed simply to turn recursion into a loop. TR removal should be done best at the highest level I'd think.

The compiler can only make this transformation in special cases, in particular, when it doesn't break any of the JVM's semantics (also, not all recursion is self-recursion, i.e. a tail call to the subroutine you're in). You can't just discard a frame of a call in a tail position, because some security mechanisms require knowing the full call-stack (plus, developers might hate you when their stack traces start missing crucial frames). So we're talking about explicit tail calls, in places that can be checked for the safety of the optimization.

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

#115

Post by sangnoir »

pron wrote: post #111
sangnoir wrote: post #109

Earlier quoted context omitted.

> 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. I think this the italicized portion is the disconnect between what Oracle wants Java users to do, and what they'd rather not do. I know the pain of wanting your users to a…

I understand that, I'm just saying that if your risk calculation concludes that LTS is less risky by default , then it's based on false assumptions, based on misunderstanding. The new feature releases are not major releases. If companies were fine upgrading to feature ("limited update") releases while there were still major releases around, I don't see why they would be more risky now that major releases are gone. I…

> I understand that, I'm just saying that if your risk calculation concludes that LTS is less risky by default, then it's based on false assumptions, based on misunderstanding.

I agree with you - and I don't think LTS have less inherent risk. The distinguishing feature of LTS releases is the length of support - you can still release minor versions weekly, but still bless every 25th minor release as the LTS versions and it would work out the same because the users will know that version will get support for X years without full requalification.

You could very well be right about the 3rd-party patches/back-porting (I'll take your word for it, I'm now at the periphery of the JDK world), but their existence could be a sign of how Java users are desperately unprepared to support evergreen releases.

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

#116

Post by pron »

sangnoir wrote: post #115
pron wrote: post #111

Earlier quoted context omitted.

I understand that, I'm just saying that if your risk calculation concludes that LTS is less risky by default , then it's based on false assumptions, based on misunderstanding. The new feature releases are not major releases. If companies were fine upgrading to feature ("limited update") releases while there were still major releases around, I don't see why they would be more risky now that major releases are gone. I…

> I understand that, I'm just saying that if your risk calculation concludes that LTS is less risky by default, then it's based on false assumptions, based on misunderstanding. I agree with you - and I don't think LTS have less inherent risk. The distinguishing feature of LTS releases is the length of support - you can still release minor versions weekly, but still bless every 25th minor release as the LTS versions a…

They're not evergreen. The last major Java release was 9, two years ago. Since then, Java has had a perpetual stream of free support.

The very notion of a "support period" becomes less relevant because what is the version that is being supported? It used to be a major release but that is now gone. The old six-monthly feature releases were also "supported" by patches for only six months. There were no more patches for 8u20 once 8u40 came out, and people were fine with that and not desperate at all. So now that we name a version 12 instead of 9u60 it's not fine? If you like, you can think about it as if we're on Java 9 forever, with an eternal support period. It's just that how the versions are named has changed.

People still don't understand the meaning of the new versions and the change to the version naming scheme. With time, they will. In the meantime, some of them still apply old terminology to new concepts and reach wrong conclusions.

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

#117

Post by volkk »

oauea wrote: post #108
maximente wrote: post #93

what's up with all these .christmas domains appearing high on HN listings? there appear to be accounts dedicated to posting from javascript.christmas, java.christmas, and functional.christmas , all of the same style/format/etc. the only posts they submit are from those domains. is this a coordinated boosting effort? functional.christmas => https://news.ycombinator.com/submitted?id=bendiksolheim javascript.christmas =…

Looks like spam. I've flagged the most recent posts, hopefully the mods see this.

how is it spam if it's just shared various blog posts from a single website?

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

#118

Post by lemagedurage »

xixixao wrote: post #96
maximente wrote: post #93

what's up with all these .christmas domains appearing high on HN listings? there appear to be accounts dedicated to posting from javascript.christmas, java.christmas, and functional.christmas , all of the same style/format/etc. the only posts they submit are from those domains. is this a coordinated boosting effort? functional.christmas => https://news.ycombinator.com/submitted?id=bendiksolheim javascript.christmas =…

Scroll down to the bottom of the page, it’s essentially a single website.

"Bekk is all about craftmanship and the people crafting it. This year, we're creating 12 calendars, each with daily content, articles and podcasts."

Seems like they are trying to attract developers, shame their main site is Norwegian.

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

#119

Post by MattConfluence »

maximente wrote: post #93

what's up with all these .christmas domains appearing high on HN listings? there appear to be accounts dedicated to posting from javascript.christmas, java.christmas, and functional.christmas , all of the same style/format/etc. the only posts they submit are from those domains. is this a coordinated boosting effort? functional.christmas => https://news.ycombinator.com/submitted?id=bendiksolheim javascript.christmas =…

https://blogg.bekk.no/introducing-bekk-christmas-ad01660ccad...

Is there a rule against authors posting their own content? It's not some grand conspiracy, it's just an christmas campaign by a company that has asked their employees to write about topics that interest them, and those articles are shared during advent. On the 25th it'll presumably go quiet again until December 1st 2020.

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

#120

Post by skybrian »

vogr wrote: post #89
skybrian wrote: post #66

Earlier quoted context omitted.

I'm curious if there is an elegant way to deal with backward compatibility when adding another case to a widely used sum type? Is it just a matter of fixing all the compile errors immediately?

I think the limitation you are describing is one of the two aspects of the expression problem[0]: - with objects you can easily add new types, but it's difficult to add functions (methods) dealing with these types - with sum types you can easily add new functions, but it's hard to add new variants in the sum type Is it possible to overcome these limitations? I first read about the expression problem in the excellent…

Thanks, this is interesting discussion.

It seems like these treatments tend not to get to the heart of the expression problem as seen in actual language tools, which is migration between language versions. Let's say you're on version 5 of a language and you want to migrate all your tools to support version 6 where there is a new expression type. Can your codebase clearly represent a situation where some tools have been migrated to support version 6 and others aren't done yet? Can you easily figure out what remains to be done? And once the migration is done, can we remove any traces of the previous version that we don't want anymore?

And how do we approach this if the AST is published as a library and each tool is a package written by a different team?

There might be other usages of sum types that are simpler, though.

Post reply on HN