Live data from Hacker News

New language features since Java 8 to 17

advancedweb.hu

281–290 of 358 posts

Re: New language features since Java 8 to 17

#281
post #24

Earlier quoted context omitted.

By multiline strings are you referring to text blocks? Those have been added to the language in Java 15: https://docs.oracle.com/en/java/javase/15/text-blocks/index.... .

Tbh I still crave Kotlins inline string interpolation.

A “superior” implementation is in the works with templated strings.

It will look something like this:

STR.”text with \\{variable}”, but anything implementing the TemplatedString interface can change the behavior of interpolation. There is not even a requirement to produce strings only!

Re: New language features since Java 8 to 17

#282

Earlier quoted context omitted.

I don’t follow why this is unfortunate?

What I don't want to see happen is innovation stop in JVM languages and then Java, no longer under threat, also stops innovating.

Java has basically no threat from Kotlin and the like. The reason it innovates now is simply Oracle’s increased pouring of money into the platform, which is especially visible now compared to the stagnation of the end of the Sun era.

Re: New language features since Java 8 to 17

#283
post #62
post #2

Unfortunately it looks like Java is going to evolve enough to take the wind out of the sails of Kotlin and Scala for most dev shops. I guess the positive take is that those improvements might not have happened without the efforts to develop better JVM languages.

Scala still has a better design at its base, which is missing from Java and I don’t see how Java can retro-fit it into the language, Immutability is a big part of being functional and doing safe multi-threading stuff, java is doing all the good syntactic stuff (case class, switches with guards etc) but without immutability it’s a far cry from the same facility in Scala land. Having said that, this trend is welcome fo…

With records, Java does try to embrace immutability to a certain degree, but of course it will never be completely immutable.

Re: New language features since Java 8 to 17

#284

Earlier quoted context omitted.

What would do notation add to Java?

Not the parent, but presumably it would allow for fancy monad stuff like Scala's Cats Effects[0] and Zio[1] which can make async programming easier to follow without having to introduce async/await [0]: https://typelevel.org/cats-effect/ [1]: https://zio.dev

For the async use-case, “native do notation” will be superior in the form of Loom, that will transform virtual thread calls to non-blocking concurrency.

As for others, without proper Monads, I doubt they would have much use.

Re: New language features since Java 8 to 17

#285
post #191

Earlier quoted context omitted.

Not yet. You can track Project Valhalla [0], the incubator for value/inline types in OpenJDK. But I don't get the sense it's landing particularly soon. https://openjdk.java.net/projects/valhalla/

Really? They’ve already written the JEPs. It seems to me that they just have a few more details to iron out. Wouldn’t be surprised to see something land for Java 19.

Not likely in 19 unfortunately. It is still lots of work with many many interactions with the whole of the language.

Re: New language features since Java 8 to 17

#286
post #220

Earlier quoted context omitted.

Java annotations are type safe. And dynamic types is precisely what turns me off of Clojure

Java annotations aren't executable on their own, so they're trivially type safe. The systems that do things depending on those annotations are typically reflection-based, which does an end-run around the static type system and usually requires a lot of casts. I like static typing myself, but having experienced languages with better type systems, Java's feels like a straitjacket. It's unsurprising that so much of the…

I think what op meant is that dependency injection is type safe, in that in case of going through a constructor, they have to indeed type check with the dynamically provided instances.

Re: New language features since Java 8 to 17

#287
post #152

Earlier quoted context omitted.

Dominant outside Android? Keep dreaming, where is the KVM implementation by JetBrains? Yeah right they had to reboot it.

Kotlin is in frequent use on the backend in many places, including Amazon and Google.

Just like any JVM guest language since Beanshell, and all lumped together are a tiny dot on JVM deployment world wide.

Google is Kotlin's godfather, naturally they are using it, just like Amazon with their own Android flavour.

Re: New language features since Java 8 to 17

#288
post #286
post #220

Earlier quoted context omitted.

Java annotations aren't executable on their own, so they're trivially type safe. The systems that do things depending on those annotations are typically reflection-based, which does an end-run around the static type system and usually requires a lot of casts. I like static typing myself, but having experienced languages with better type systems, Java's feels like a straitjacket. It's unsurprising that so much of the…

I think what op meant is that dependency injection is type safe, in that in case of going through a constructor, they have to indeed type check with the dynamically provided instances.

(I got lucky and spotted this reply instantly; I promise I wasn't lurking waiting for a reply.)

Don't dynamic DI frameworks like Spring use runtime reflection to invoke such constructors? If a bug existed in Spring causing a value of the wrong type to be provided, I expect it would go undetected until runtime, at which point Java will throw an exception.

My understanding of "type safe" is that the code is statically known not to have such defects. It's likely that we're just getting hung up on definitions.

Re: New language features since Java 8 to 17

#290
post #191

Earlier quoted context omitted.

Not yet. You can track Project Valhalla [0], the incubator for value/inline types in OpenJDK. But I don't get the sense it's landing particularly soon. https://openjdk.java.net/projects/valhalla/

Really? They’ve already written the JEPs. It seems to me that they just have a few more details to iron out. Wouldn’t be surprised to see something land for Java 19.

I'd definitely be curious about which signals you're drawing on. From what I've seen, the Valhalla OpenJDK wiki has gone without update for quite some time, and even that wiki refers to JEP 169 ("Value Objects") as old.

I do get the feeling that there's activity, given that JEP 416 is targeted for Java 18 and specifically refers to Valhalla (and Loom) as benefactors of the proposal, and seeing as the mailing list is reasonably active. But since there's little official word and not much buzz on my radar (even Loom has significant buzz), I'm not expecting anything soon.

Post reply on HN