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

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

advancedweb.hu

Post reply on HN
Print view View original

191–200 of 243 posts

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

#191

Post by thu2111 »

aardvark179 wrote: post #130
kaba0 wrote: post #92

Earlier quoted context omitted.

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…

Specifically, the JVM knows there are no pointers into the stack because Java and bytecode cannot express:

    int a = 1;
    int *b = &a;
Or rather, this construct can occur, but it's always the decision of the JIT compiler to emit such code and it is cooperating with the rest of the runtime.

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

#192

Post by kaba0 »

DaiPlusPlus wrote: post #98
twh270 wrote: post #78

Earlier quoted context omitted.

Much of the verbosity came from the false presumption that every field in every class needs a public getter and setter. (I cannot express in words how terrible this is.) Some can come from the framework, mostly poorly-designed ones. I think Java 11 and higher are reasonably terse/expressive without being overly dense.

Remind me, why doesn’t Java have object-properties yet? So far the only reason I’ve concluded is Java’s language designers’ egos were so damaged by C#, Swift, Kotlin, TypeScript, etc that after dogmatically denying the developer-productivity benefits of properties for the past 20 years that to concede now would mark the end of Java as a language entirely. ...I kid, but seriously I haven’t heard any compelling argumen…

I believe the Java lang team simply dislikes the Java Beans convention, and if they see a better future, they rather not maintain properties forever.

I think the current future view is Withers ( https://github.com/openjdk/amber-docs/blob/master/eg-drafts/... ).

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

#193

Post by kaba0 »

kerblang wrote: post #89
voidfunc wrote: post #28

Earlier quoted context omitted.

> More seriously, what are you missing in Go that is well-done in Java? 1. Generics. And yea, I know Go is getting generics "Real Soon Now" (tm), but it is incredibly annoying to write the same collection code over and over and there's some third-party libs that would really benefit from generics (looking at you Azure Go SDK). 2. Error handling... with the big caveat that I actually like Go's error handling mechanism…

Sorry that I find it necessary for yet another answer to your verbosity question, but: The real verbosity is in the standard libraries. What would be a one-liner in any other language is usually at least 2, often 3, and sometimes enough that you end up writing your own wrapper function or library. Especially noticeable is the agony of Lists & Maps, which are first-class citizens in most languages (classic job intervi…

There is List.of() and Map.of() now. And I would say, Java has one of the better standard libs out there in my opinion.

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

#194

Post by kaba0 »

LgWoodenBadger wrote: post #171
geodel wrote: post #106

Earlier quoted context omitted.

Huh, one needs to see first party Java libraries from earlier times. It is pretty clear engineers at Sun also believed that AbstractFactoryFactory everything will be the way world need to be rebuilt. Of course one can show empathy and understand justifications for things they like and simply laugh out "LOL Go No Generics' when they don't.

I don’t find this to be true outside of the mostly awful, and now dead, JEE landscape. What first-party stuff are you referring to?

I’m not sure it is necessarily dead, Jakarta EE is alive, but definitely not as big as it was.

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

#195

Post by brabel »

sixbrx wrote: post #174
brabel wrote: 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`…

Well Checker framework to check nulls will limit you to Java 11 or earlier, at least until sometime after Java 17 lands. Also it is a constant pain having it guess wrongly about map value nullability based on key provenance which its not really smart enough to track, and it gets some Java api nullabilities wrong which need correcting here or there at annoying times. Better than nothing but nowhere near as good as pro…

We don't use Checker, we tried it and it was too buggy/complex. We use IntelliJ itself to do the checks (so they don't run on every compilation, but they do run every time you change something) - you can configure it to treat null issues as errors instad of warnings. This is of course not 100% but it doesn't need to be, tests and code-review tend to catch the remaining places where we forgot to check for null.

NullPointerException is really rare in our codebase which is a few million lines of code (something like 80% Java, 20% Kotlin), so I wouldn't call it a major issue or even a minor issue.

At work, everyone has the choice to write code in either Java or Kotlin and most people, most of the time, stick with Java, so the percentage of Kotlin code is not increasing, it's mostly stable lately.

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

#196

Post by tom_mellior »

ragnese wrote: post #166
MaxBarraclough wrote: post #137

Earlier quoted context omitted.

> No unsigned ints. I think that's a mixed blessing. I believe Java did this deliberately to avoid the trouble that C and C++ have with signed and unsigned integer types having to coexist. Personally I've never been inconvenienced by Java's lack of unsigned integer types, but I'm sure it can be annoying in some situations. I'm quite fond of Ada's approach to integer types, but I suspect I'm in a minority. > Silent in…

I don't know about Ada, but I enjoy Rust's strictness when it comes to numeric types. > Java-style wrapping integers should never be the default, this is arguably even worse than C and C++’s UB-on-overflow which at least permits an implementation to trap. EXACTLY. It's f-ing stupid. C's excuse was compilers doing magic on UB or whatever. Java has no such excuse. They just wanted it to behave the same as C/C++ to attr…

> EXACTLY. It's f-ing stupid. C's excuse was compilers doing magic on UB or whatever. Java has no such excuse. They just wanted it to behave the same as C/C++ to attract C++ devs.

But... as you yourself are saying, Java's behavior is not "the same as C/C++". Java wraps while in C and C++ signed overflow is undefined. (Interestingly, C++ is now moving away from UB for this, and defining wrapping semantics. While I'm not one for proof by authority, it looks like some very well-informed people disagree with you about the usefulness of this feature.)

Signed integer overflow checking can be almost free. Until it isn't, because it doesn't play nicely with SIMD code. So the code you want to run fastest will pay the biggest price. This article is from 2016 so take it with a grain of salt, but it looks like this can cause 20% to 40% slowdowns: https://blog.regehr.org/archives/1384

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

#197

Post by kaba0 »

ragnese wrote: post #140
DaiPlusPlus wrote: post #113

Earlier quoted context omitted.

It surprises me that we don’t yet have an applications language with an ultra-modern type-system. It’s so strange that the current leaders are a scripting-transpiler (TypeScript) and a systems language (Rust) - but not an apps language in-between. ...then again it’s understandable when you see how the traditional apps languages (C#, Java, etc) are severely hobbled by their VM/runtime, because that’s usually the sourc…

It surprises me as well. And to belabor my own point some more: there's a reason the #1 question about Rust from newbies seems to be "Is there a language like Rust, but with a garbage collector?" - sometimes reworded as "Is there a way to turn off the borrow checker?" To be fair, I think that a decent amount is possible on JVM and CLR. Scala, for as much hate as it gets, has a much stronger type system than Kotlin/Ja…

> Kotlin/Java are decent, but not good at concurrency

Since when JVM languages aren’t good at concurrency?

Also, primitives are usually not heap-allocated, so I don’t see what’s the problem with it. It makes the JVM a beast when it comes to number crunching.

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

#198

Post by MaxBarraclough »

ragnese wrote: post #164
int_19h wrote: post #150

Earlier quoted context omitted.

> I believe Java did this deliberately to avoid the trouble that C and C++ have with signed and unsigned integer types having to coexist. The problems really only come from mixing those types, and the simple solution is to disallow such mixing without explicit casts in cases where the result type is not wide enough to represent all possible values - this is exactly what C# does. I think Java designers just assumed th…

My opinion is that a high-level language like Java has no business making me guess how many bytes my numeric values will occupy. It's insane. Since when does Java give a crap about memory space? "Allocations are cheap!" they said. "Computers are fast!" they said about indirection costs. Then they stopped and asked me if I want my number to occupy 1, 2, 4 or 8 bytes? Are you kidding me? Yes, you should have those type…

> the default should basically be a smart version of BigInteger that maybe the JVM and/or compiler could guesstimate the size of or optimize while running.

I suspect this would be disastrous for performance. I believe Haskell uses a similar approach though.

Sometimes you want to store 20 million very small values in an array. Forcing use of bigint would preclude doing this efficiently (in the absence of very smart compiler optimisations that is).

As int_19h points out, the Ada approach lets us escape the low-level world of int8/int16/int32/int64 while retaining efficiency and portability and avoiding use of bigint.

> there should be a handful of numeric types that are strict in behavior and do not willy-nilly cast back and forth

I agree that reducing the number of implicit conversions allowed in a language is generally a good move. Preventing bugs is typically far more valuable than improving writeability. This is another thing Ada gets right.

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

#199

Post by kaba0 »

ragnese wrote: post #169
The_rationalist wrote: post #156

Earlier quoted context omitted.

Your analysis is interesting and far from exhaustive, It would be nice to have a collaborative feature matrix for languages, on github. Kotlin solve the following points: null - we all know, so I'm not going to bother expanding except to say that @NotNull is NOT a solution and it doesn't guarantee shit. I don't hate checked exceptions as a concept, but the fact that you can't be "generic" over the exceptions in a fun…

Kotlin does indeed (mostly) fix null. Kotlin does not fix the issues with checked exceptions. It gives up and gives us nothing for error handling. So, for all the beauty and magic of a strong static type system, I have absolutely no idea if `fun foo(i: Int): Int` is just going to crash my program when I give it -1. "Do you have a fatal error? Throw an exception." "Do you have a non-fatal error that's totally expected…

Just as an additional detail: Java has a new DateTime and related classes, that I believe solves every(?) problem with the old Date class.

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

#200

Post by ragnese »

kaba0 wrote: post #197
ragnese wrote: post #140

Earlier quoted context omitted.

It surprises me as well. And to belabor my own point some more: there's a reason the #1 question about Rust from newbies seems to be "Is there a language like Rust, but with a garbage collector?" - sometimes reworded as "Is there a way to turn off the borrow checker?" To be fair, I think that a decent amount is possible on JVM and CLR. Scala, for as much hate as it gets, has a much stronger type system than Kotlin/Ja…

> Kotlin/Java are decent, but not good at concurrency Since when JVM languages aren’t good at concurrency? Also, primitives are usually not heap-allocated, so I don’t see what’s the problem with it. It makes the JVM a beast when it comes to number crunching.

> Since when JVM languages aren’t good at concurrency?

Since it's trivially easy to accidentally mutate data across concurrent contexts (threads). You have to actively remember to reach for Mutexes. You also have do understand how `synchronized` works and remember to actually use it. If you use a class that someone else wrote, you have to dig into their code (if available) to make sure they made their class thread-safe.

> Also, primitives are usually not heap-allocated, so I don’t see what’s the problem with it. It makes the JVM a beast when it comes to number crunching.

You don't need a number crunching beast to write most application-level software. That's my point. It's great for number crunching that you have byte, short, int, long as separate primitives. You know what most applications actually want? A number that wont magically wrap around to negative-LARGE_NUMBER when you guess the maximum size wrong. Java has fixed-size arrays, too, for super-performance mode. But applications just use List that has no size limit that you have to guess. It should do that same for Integers.

Post reply on HN