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

151–160 of 243 posts

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

#151

Post by int_19h »

DaiPlusPlus wrote: post #113
ragnese wrote: post #93

Earlier quoted context omitted.

The hype around Rust is largely justified. There. I said it. Rust is nowhere near perfect. It's also supposed to be a systems language- it was probably not originally intended to replace languages like Java for general "app" development. But it's so much better of a language than most of the higher level languages you see in popular use: Java, PHP, JavaScript, Python, etc, that people are actually willing to deal wit…

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…

The situation is changing in the CLR land, now that they can just say that legacy codebases can stay on .NET 4.x, and .NET Core is where all the fancy development is happening. There are already some C# language features that are Core-only because they require the corresponding runtime changes.

The other thing is - people always forget that, unlike JVM, CLR has more than just the object layer. By design, it has enough low-level constructs to compile a language like C++, complete with multiple inheritance, unions, varargs etc. Obviously, you can do pretty much anything on top of that - the only problem is that you won't be able to interop with other .NET code, except through C-style FFI. But, hypothetically, it would be possible to establish a higher-level ABI without baking it into the VM as an object model, thus allowing a reboot without throwing everything away.

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

#152

Post by The_rationalist »

pcl wrote: post #145
dbsmith83 wrote: post #142

Earlier quoted context omitted.

Kotlin types and Java types are much more compatible than Scala types. No need to use converters. Also, Scala leans very FP, while Kotlin and Java don't, so they are also more similar in that regard, though I don't know if that's what "JVM-aligned" means here. Overall, Kotlin and Java just have better interoperability than Scala and Java

Yeah, that's exactly what I meant. The JVM is designed to execute the constructs of the Java language. Scala compiles to JVM bytecodes, but it does a lot of (very cool!) things that are not natively supported by the JVM, and thus tend to be pretty expensive. Scala's pattern matching, for example, goes beyond what can be efficiently expressed in the JVM. As a rule, Kotlin does not take this approach. Instead, almost a…

It's not clear that bytecode changes are needed for efficient pattern matching support. Java is getting pattern matching support. The related JEPs mention that: The implementation will likely make use of dynamic constants https://openjdk.java.net/jeps/309 I strongly suspect that Scala could be more efficient if it used it too. However I have no idea if this could improve compile time. (kotlin has until now procrastinated implementing pattern matching support because they say it increase compile time, but maybe that doesn't hold with constant dynamics)

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

#153

Post by kaba0 »

nesarkvechnep wrote: post #131
kaba0 wrote: post #97

Earlier quoted context omitted.

With checker framework, you can basically have it (and much much more, I believe no other language comes close to that level of static analysis). It is annotation-based and not a fancy keyword, but it is there.

Haskell, OCaml?

Higher kinded types do make some features obsolete, but checker has MapKey checker, Lock and Index checker, and while locks may not be needed that often with everything is immutable by default mode, concurrency is hard and that alone is not always enough. While index errors are not as frequent in Haskell, due to (Head:Tail), but if you do use Array, you can’t express indexing safely without dependent types.

I’m not saying that it is better in every aspect than haskell (not too familiar with ocaml), but java is an easy and extremely popular language. And thus it has really really great tooling, and with annotations it is really extensible.

And if static analysis is not enough, there is also JML.

Also, checker taps more into intersection types, which is not really expressible in Haskell, but I’m yet again not knowledgeable enough on this latter, correct me if I’m wrong.

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

#154

Post by The_rationalist »

twh270 wrote: post #78
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…

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.

Kotlin property access solves this. You access to the property but behind the hood it will call the getter/setter if it exists.

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

#155

Post by ta988 »

jacques_chester wrote: post #65
The_rationalist wrote: post #58

Earlier quoted context omitted.

What you're waiting for is already available with Kotlin coroutines (which has a very clean API btw) And no reactive streams still are useful for processing collection streams asynchronously and here again kotlin solve it all https://kotlinlang.org/docs/flow.html

I like Kotlin coroutines and I've used them, but they (this argument is controversial) have a function colouring problem. As the JVM adds virtual threads I expect that a rebasing of Kotlin's coroutines will remove that objection. Plus, sometimes, I want to use Java.

Also debugging with them can be quite painful. It is getting better, but I still pull my hair frequently.

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

#156

Post by The_rationalist »

ragnese wrote: post #86
voidfunc wrote: post #13

Java gets a bad rap from people that used it late 90's through early 2000's and got burned out by XML and design pattern heavy frameworks but its a lovely language that with a little discipline can be used to create very lean looking code. Go is one of the HN darling languages and I work in Go everyday for work (and generally like it), but I really wish I could reach for Java most days.

I disagree that it's a lovely language. I think, as developers, we very quickly develop Stockholm syndrome. Once you "learn" a language, it's really easy to churn out code and apply idioms without even realizing that you're constantly writing workarounds and kludges for your language's deficiencies. As a polyglot dev, the following are my gripes with Java: * null - we all know, so I'm not going to bother expanding ex…

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 function signature is frustrating. This is why everyone says they're "incompatible" with Java's closure APIs.

No unsigned ints.

No concept of `const` or immutability.

Kotlin allow to specify either variance or contravariance so I guess it fixe this point too? * The fact that arrays got type variance wrong*

* interfaces are extremely lacking compared to type classes and lead to verbose and cumbersome patterns such as "Adapter".* Interesting, can you link to an example? Kotlin has first class support for delegation as an alternative.

* Type-erased generics. Why shouldn't I be able to implement a generic interface for multiple types? E.g., class MyNumber implements Comparable, Comparable, Comparable {}* Kotlin has support for reified generics to some extent. The JVM is currently getting state of the art support for it too and for specialization.

* Dates and timezones are still insane, even in Java 8+.* I always hear that Java has got the best Time library, what is the complaint about?

* JDBC sucks. JPA also kind of sucks.* Do yourself a favor and use the JDBI or so many other sexy alternatives.

Of all your points the only unaddressed are: * interfaces are extremely lacking compared to type classes and lead to verbose and cumbersome patterns such as "Adapter".

And Silent integer overflow/wrap-around*

Strong agree about stockolmization and cargo cultism of language constructs.

Most programming languages are pretty awful Correct, hence why Kotlin stands out.

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

#157

Post by zmmmmm »

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…

It's so crazy - with all the huge and radical features they've added this would surely have been so simple by comparison and yet added more value than about 80% of the things they've done. It's about half the reason I still use Groovy now since Java has solved most of the rest over time. But I just cannot go back to writing getters and setters!

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

#158

Post by The_rationalist »

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 is the application language you're looking for (and Scala 3 to a lesser extent). Contrary to what you say it is the best language I've ever used for concurrency. It has it all, structured concurrency, cancelation, Flow, transparency (no await), etc. Regarding your second point the JVM is increasingly using the stack and with the soon complete generics you'll be able to avoid the boxed versions of the primitive types (though they remain useful when you want identity)

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

#159

Post by The_rationalist »

geodel wrote: post #109
Thaxll wrote: post #84

Earlier quoted context omitted.

"Go is one of the HN darling languages" It's def not the case, I spend too much time here and on Reddit and people are always complaining about Go ( generics, errors, type system etc ... ), if you want the godly language it would be Rust, anything about Rust will be upvoted. As for Java, it's a good language / runtime that is overly complicated behind layers of abstraction. Take Spring for examnple, magic everywhere,…

> if you want the godly language it would be Rust, anything about Rust will be upvoted. That is just better half part, sad part is anything negative about Rust will be heavily downvoted. Most of the time I disagree with Java/Go in their thread it would be just fine but not with Rust.

The same can be said about pro chromium or contra mozilla comments, it's a kind of cargo cultism/echo chamber

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

#160

Post by frant-hartm »

blntechie wrote: post #123
tonyarkles wrote: post #23

Earlier quoted context omitted.

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.

Try `npm install` then..
Post reply on HN