Live data from Hacker News

A categorized list of all Java and JVM features since JDK 8 to 16

advancedweb.hu

121–130 of 243 posts

Re: A categorized list of all Java and JVM features since JDK 8 to 16

#121
post #99
post #76

Earlier quoted context omitted.

I write a lot of Kotlin code but still tend to use Java a lot. All of the features you mention are not really an advantage for Kotlin anymore. Java has had tools to deal with nulls for a long time, we tend to assume everything is non-null unless annotated with `@Nullable` and let tools check correct usage at compile time... data classes are very similar to Java 16's records. Type-inference since Java introduced `var`…

If I remember correctly, it's fairly easy to use @Nullable and still end up with nulls there, even without an IDE warning. I'll have to double check to see if I can still reproduce that. But, to be fair, it's actually fairly easy to break Kotlin's null safety, too: https://blog.haroldadmin.com/circular-refs-kotlin/ But I basically agree with what you've said. Kotlin is certainly still a much more ergonomic language,…

Value classes cannot provide the performance/memory flatness that Valhalla will bring though. So I'm not really sure what benefit does "values classes" bring. Just to make sure, you are talking about the inline class which is just a wrapper around single property?

   inline class Password(val value: String)

Re: A categorized list of all Java and JVM features since JDK 8 to 16

#122

Earlier quoted context omitted.

Ah right - that's not really what we're talking about here, even though they have the same name.

“Codes like a class, works like an int!” - Taken from the top of the page. This is exactly what Value Classes are in Scala. You supply an underlying value which is then interpreted as the value itself, not a reference.

> must have exactly one parameter,

Huge limitation. Not anywhere near the same thing.

Re: A categorized list of all Java and JVM features since JDK 8 to 16

#123

Earlier quoted context omitted.

“Java is a big DSL to transform XML into stacktraces” — so was the joke at the time when domain-specific languages were the hype. This, and the FizzBuzz, Enterprise Edition: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... More seriously, what are you missing in Go that is well-done in Java? I assume verbosity of the code is still the defining characteristic of Java?

Now we've got Spring, which in my, admittedly limited, experience does a great job of transforming what could have been compile-time errors into run-time errors.

Running ‘mvn install’ on even a simple Spring project with default dependencies is scary to watch on the console. So many things happen and it’s not even the verbose mode.

Running ‘dotnet build’ is much more saner and one can reasonably understand what happens.

Re: A categorized list of all Java and JVM features since JDK 8 to 16

#124

I’ve always admired Java for managing to slowly but surely move the language forward while maintaining backwards compatibility and keeping the community together. When you look at how many other languages have faltered and lost momentum due to transition issues (Perl 6, Python 2/3), it really shows have difficult of a task it is. Progress can seem glacially slow at times - it’s always disappointing to see your favori…

I would add C# to the list of languages with good backward compatibility and progression with every new version. Very similar to Java, and has a lot more feature set with somewhat decent documentation.

Re: A categorized list of all Java and JVM features since JDK 8 to 16

#125

I’ve always admired Java for managing to slowly but surely move the language forward while maintaining backwards compatibility and keeping the community together. When you look at how many other languages have faltered and lost momentum due to transition issues (Perl 6, Python 2/3), it really shows have difficult of a task it is. Progress can seem glacially slow at times - it’s always disappointing to see your favori…

A big benefit of the 6-month release cadence (since Java 10) is that if your favorite feature gets pushed, the next release is just around the corner.

Re: A categorized list of all Java and JVM features since JDK 8 to 16

#126
post #80

Earlier quoted context omitted.

There are JEPs out for parts of it now - Primitive Objects (which is the new name for value types) https://openjdk.java.net/jeps/401 and Unify the basic primitives with objects https://openjdk.java.net/jeps/402

I haven't read up on the details of these but this is a huge step in the right direction if pulled off properly. The dichotomy between primitive and non-primitive types in Java is a real rough spot. I'd have to see how they deal with null values though because the introduction of auto-boxing certainly introduced a new area for NullPointerExceptions to catch the unwary off-guard.

There is extensive discussion of that topic in the valhalla-dev and valhalla-spec-experts mailing lists, but I think the details are still being worked out.

Re: A categorized list of all Java and JVM features since JDK 8 to 16

#127

Earlier quoted context omitted.

Ah right - that's not really what we're talking about here, even though they have the same name.

“Codes like a class, works like an int!” - Taken from the top of the page. This is exactly what Value Classes are in Scala. You supply an underlying value which is then interpreted as the value itself, not a reference.

What you're talking about is just wrapping a single value. It's a type-system thing.

What we're talking about are wrapping compound values. It's a VM implementation thing.

They're not really comparable.

Re: A categorized list of all Java and JVM features since JDK 8 to 16

#129
I've been using Java and the JVM since about 1995 when Sun released the early betas (pre 1.0). It's more or less a convenience marriage. Right place and right time I guess. I happened to specialize in it for a while. A long story short: I pivoted to Kotlin a while ago and stopped caring about what Oracle is doing to keep up. Too little, too late; and it seems to perpetually not matter at all unless you are still doing Java, which I'm not.

Kotlin works great on the JVM and about the same across Jdk 8-16 (probably from v6 even). A lot of stuff happened in between but the Kotlin compiler and library ecosystem seems to cover up and smooth out the differences. Most of the Java compiler or standard library changes stopped mattering to me. There's not a single thing from v15 to v16 that I can name that matters to me, at all. All my code works fine with v11 (the first and only post v8 LTS release) and the delta with getting it to work with v8 is trivial. There's just nothing since about 2014 that actually matters to me. Not even a little bit. All of my Kotlin code bases trivially work with any release since then.

I use Spring and Spring Boot in their latest versions and there's no question about Kotlin being the preferred language for that at this point. You get basically everything they did to make it work with Java 8 plus everything that Kotlin adds on top, which is a lot. Some of that even works with recent Java versions.

At this point that includes stuff like co-routines and Flows that makes the whole abomination that is Spring Flux usable (as opposed to a minefield of complexity you have to deal with via 2014 era Java), data classes instead of last century style Java Beans (just, no!), etc. Java 9 and on-wards is kind of half getting there with things like Loom and records landing only very recently and not havig had any impace yet whatsoever. You want something modern, fresh, and nice with Spring that is not experimental and well supported: Kotlin is it. Everything else is stuck at being experimental until way after Oracle labels latest & greatest Java version as LTS, which might happen in the next two years or so. Java 11 technically happened but never really registered in the same way that Java 8 did. For a lot of conservative places, 8 was the last stable release. That was in 2014! Everything after that is optional, nice to have, and yet to impact major frameworks. Except of course if you use Kotlin, which fast forwards you about seven years plus whatever Java has left to catch up.

There really is no functional difference between JDKs other than slight changes in Java APIs you probably should not be using with Kotlin anyway. All the important stuff is tested with and works fine with v8. I'm talking libraries, tools, and frameworks. Most of my code works exactly the same with Java 8 as it does with Java 16. I get very little value out of using something more recent than jdk 8. But I still upgrade. Kotlin uses some of that transparently but mostly it does not matter, at all.

We are basically talking purely non functional things that are mostly about things like performance being slightly better, new garbage collectors, or the whole modules thing that is largely irrelevant to any kind of server side usage having happened or not. I've never been on project where that actually mattered even the slightest. Complete waste of time that pre-dates the acquisition by Oracle even. But nice that they cleared some technical debt there and got rid of some circular dependencies in a standard library that I largely don't depend on with Kotlin.

Which is a different way of saying that I get very little out of Java updates in the last seven years. My mode is mostly that, well if you are going to pick a JVM, you might as well pick a recent one because it probably has a few fixes that may or may not matter to you. But it's going to work fine either way.

The next big thing with Kotlin is multi-platform and cutting loose from Oracle. I'm already utilizing kotlin-js for some front end stuff and am keeping an eye on their WASM efforts and native stuff as well. A lot of what I care about already works fine across all of those.

Re: A categorized list of all Java and JVM features since JDK 8 to 16

#130
post #92

Earlier quoted context omitted.

Worth keeping in mind that the implementation they have chosen of stack copying from the heap has a larger performance overhead than something like Go which was designed around green threads/fibers/virtual threads/ etc. from the start. If you can keep your stack size very low in each task then this probably won’t be noticeable if you are doing lots of IO which can trigger wakeups. More of a replacement for an async/a…

The technical details are way out of my league, but I remember reading that stack copying can be made really cheap somehow? Perhaps due to the JVM having more abstraction below a virtual thread than Go?

Many virtual threads won’t have large stacks, and many others will not substantially grow or shrink their stacks between yields. You only need to copy stack frames from the heap as they are needed (so as the stack unwinds) and you only need to copy new stack frames to the heap when a thread yields. With a few other clever tricks this can really reduce the data that has to be copied.

We can do these tricks because we know lots of properties of the Java stack, and they give a different set of trade offs to Go’s approach.

Post reply on HN