Live data from Hacker News

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

advancedweb.hu

171–180 of 243 posts

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

#171
post #106

Earlier quoted context omitted.

I somewhat agree, but Java grew up in a different era when communication about these things wasn't as easy. It's hard to change the direction of something as large and widely deployed as Java. It's happening but it will take time and its always going to dealing with its legacy as there just so much of it out there.

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?

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

#172
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`…

> 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... Oh yeah, nothing like creating Frankenstein's monster instead of using a tool that was designed for the purpose. And no, it's not the same. You'll never beat Kotlin compiler , no matter how many annotation you use - you will always mis…

[deleted]

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

#173
post #77

Earlier quoted context omitted.

Say you have: public void doSomething(Optional foo) { ... } You want `foo` to be `Optional.empty()` or `Optional.of("some string")`. The way things currently work, `foo` could also be `null`.

How does making Optionals allocated on the stack (value types) prevent this? Or rather why do you need value types to accomplish this?

> How does making Optionals allocated on the stack (value types) prevent this?

Let's not confuse language specification issues with implementation issues. Both value and object types can be allocated on the stack. Both can be allocated on the heap. Both can not be allocated at all and can be scalar replaced. So this isn't the meaningful difference!

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

#174
post #76
post #29

All the backend projects I work on were originally written in Java. I'll admit that Streams and Lombok make it a somewhat pleasant experience to work with, at least compared to when I used it in college (I think Java 8 was newest?). But that said, I once tried writing a new feature in Kotlin, and now all our code is Kotlin. I don't really see how Java can compete with the non-nullable types, data classes, and type-in…

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 proper language support IMO.

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

#175
Oracle has added lots of nice things to Java. For Java to become even better, they can start deprecating and later removing the not-nice things.

EDIT: I got to the "Deprecation and removal" section at the bottom of the article. They have deprecated a few of the many crufty APIs. Nice!

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

#176

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.

“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?

Logging.

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

#177
post #9

One of the primary features I'm holding out hope for eventually making it into the language is ValueTypes: http://cr.openjdk.java.net/~jrose/values/values-0.html and the current Valhalla Project: https://wiki.openjdk.java.net/display/valhalla/Main The simplest example of why this would be valuable (edit: this was not an intentional pun), the Optional type could become stack based, such that you could ensure that the…

You don't really need to hold out hope for this... it is coming and soon. It's been in active progress for years now (its a huge undertaking).

>It's been in active progress for years now

And it might be in "active progress" for years more, seeing that we were promised it would come a decade ago.

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

#178
post #2

nice to see everything in one place with short example code. Specially helpful for those still using Java 8 and looking to upgrade, Java 17 will be a LTS so that will be a good opportunity to upgrade.

using java 8 and not looking to upgrade unless the license situation is altered

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

#179

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…

OP mentioned "Ada's approach to types", as well. Ada lets you write stuff like "T is range 1 .. 20" or "T is range -1.0 .. 1.0 digits 18". This then gets mapped to the appropriate hardware integer or floating-point type.

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

#180

Earlier quoted context omitted.

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…

> 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. I disagree. Have you ever tried to actually implement something non-trivial that takes advantage of structured concurrency with cancellation? It's pretty hard to do correctly. Can you really tell me off the top of your head what the difference is be…

> Coroutines use unchecked exceptions for control flow

That's... horrible.

Why can't Kotlin do it the way C# does with heap-allocated state-machines?

Post reply on HN