Live data from Hacker News

What's new in Java 12, 13 and 14

java.christmas

101–110 of 136 posts

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

#101
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?

WASM won't kill JavaScript because there is a whole generation of programmers that actually prefers it to Python etc. and goes out of their way to use it (nodejs).

There are also more technical reasons like WASM not being able to access DOM.

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

#102
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?

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

#103
post #91
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…

> Updating from 11 to 17 without doing that is taking a huge risk. You will see features disappear without deprecation warnings. If upgrading from one stable release to the next stable release removes features without a deprecation period, something's wrong with the release model.

Versions 12 to 16 are/will be stable releases.

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

#104
post #51
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…

What do you really get out of a Java or Python REPL? If it’s the simple kind like python in bash, it’s really primitive compared to an IDE where you can inspect things. Why doesn’t a simple project suffice?

REPL-driven development is quite common in the LISP communities, and one of the main reasons I love Clojure. Stuart Halloway did a talk on this topic: https://vimeo.com/223309989

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

#105
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…

I find it to be the opposite. In recent years C# has had modest language changes while Java has introduced streams, optionals, lambdas, function pointers...a whole lot of catch up and IMO arguably in an uglier but ultimately quite similar way to C#. Now I get to relive another couple years of devs learning, unlearned, and then properly learning when to use Linq/streams.

Optionals and the new IO libraries are causing far more churn in my Java code and the libs I use than any recent C# changes.

The Java language doesn't feel conservative to me. It just feels slow. What was worth the wait? What does Java do better than C#? The only thing I miss while in C# is Java's take on enums.

All that said, I don't begrudge Java as a whole. The JVM and other priorities add a lot of value and I'm glad their adherence to bytecode compatibility remains strong. The language is the trade off but that doesn't mean I need to pretend its better.

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

#106
post #94
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…

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 next March, EA available now).

> Improved memory layout control, including stack-allocated types and inlined objects inside of other objects.

Project Valhalla. The most complicated of the bunch. Just had a recent major breakthrough, and you can work with the EA release already.

> project loom for golang-style I/O programming.

Working on it :)

> full tail recursion. Why was this feature rejected from the VM?

Not at all rejected. It's still a goal for Loom. We'll just do lightweight concurrency first. Cost/benefit prioritization etc.

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

#107
post #98
post #73

Earlier quoted context omitted.

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

> I'd be extremely surprised if you could show that any feature or lack thereof actually costs you money, Bad language design and semantics definitely costs money in the long term. For example, Tony Hoare refers to Null References as his "billion dollar" mistake. The verbosity of Java before sophisticated IDEs would also have cost significant time and money. Java is improving significantly (and arguably was never as…

> and so improvement can only ever be small and incremental.

You seem to hint that some hypothetical non-small improvement can be made differently (in some other language). Perhaps it could, but it doesn't seem anyone has done it yet. We do not observe large differences between and in companies based on language choice. I think some of the reason is that developers overestimate the cost of coding in the entire software development process.

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

#108

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.

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

#109
post #74
post #71

Earlier quoted context omitted.

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 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 always be on the latest and greatest version, but in my experience, medium-to-large corporates are extremely risk averse and would rather invest time upfront to do testing/qualifying software releases before deploying, then keep that deployment running for as long as possible with the assurance that the configuration is stable (or at least has known & documented failure modes). They understand the new model just fine - they just don't want it. Mostly because it introduces a lot of risk and/or requires continuous qualification, which is not only expensive but completely changes the way they operate.

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

#110
That “instanceof” change looks strictly worse than Kotlin’s “smart casts” (after checking x is an instance of Y, x implicitly casts to Y as long as its value doesn’t change).

The new Java shorthand, by introducing a new variable name, also introduces some sneaky variable shadowing risks (as this blog post itself explains!)

Edit to add: maybe the difficulty is in formally specifying “smart casts”, or at least clearly documenting them? I don’t think Jetbrains has documented all the rules used by Kotlin. It doesn’t seem undoable, though.

Post reply on HN