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

Java 22 Released

mail.openjdk.org

Post reply on HN
Print view View original

161–170 of 178 posts

Re: Java 22 Released

#161

Post by owlstuffing »

DarkNova6 wrote: post #148
owlstuffing wrote: post #64

Earlier quoted context omitted.

As a modern language Java is still quite feature deficient. But you can use compiler plugins like the manifold project[1] to level up. 1. https://github.com/manifold-systems/manifold

I'm not 100% sold. I like some of it's features (e.g. the mentioned typed SQL safety) but adding all of it seems super heavy-weight. Lombok took a good time to become widely accepted and I don't think this will ever appeal to more than just a niche audience. At the very least, I prefer not to have any surprises in my codebase because it looks like Java but isn't quite so really.

> I'm not 100% sold.

The vast majority of people that use it aren't, but that's a feature :)

Manifold isn't an all-or-nothing proposition. It's architecture is modularized so that you can select the parts you want à la carte as separate dependencies in your build.

> At the very least, I prefer not to have any surprises in my codebase

But manifold surprises are pleasant ones :) As with any library or framework, it's a design decision: does it provide enough productivity and opportunities to offset its presence in your project? It's not a panacea.

Re: Java 22 Released

#162

Post by jsnelgro »

pjmlp wrote: post #159
jsnelgro wrote: post #158

Earlier quoted context omitted.

Android?

Android OS layer has zero Kotlin, and Google had to backtrack on their decision to let Java languish, as the Android ecosystem started to lose out on Java ecosystem, thus ART is now updatable via Play Store since Android 12, and Java 17 LTS is the latest supported version. Kotlin is only used on Jetpack Compose and a couple of AndroidX libraries, that you have to ship alongside the application. And as alternative to…

Interesting, I don't develop for Android so I don't know the details in this space. Surprising to learn that the Android OS layer is 100% Java. In terms of a platform, I was more referring to the mass adoption of Kotlin for Android app development. 95% of the top 1,000 Android apps are written in Kotlin and adoption overall is > 50% according to their overview page https://kotlinlang.org/docs/android-overview.html

IMO those numbers create a lot of staying power for the language.

Re: Java 22 Released

#163

Post by fuzztester »

eddd-ddde wrote: post #112
coldpie wrote: post #39

Earlier quoted context omitted.

I 1000% agree. Though, a favorite early programming memory of mine was when static methods finally clicked and I went back and looked at all that boilerplate that meant nothing to me and it all became crystal clear what it meant and why it had to be like that.

This reminds me of when I finally understood why returning 0 from a function named main made sense.

And why array indices start at 0 instead of 1, in many, though not all, programming languages.

Re: Java 22 Released

#164

Post by fuzztester »

jimbokun wrote: post #33

Maybe my favorite feature in this release: https://openjdk.org/jeps/463 Finally solves the inscrutable Hello World program! Yes, it's just ergonomics for early beginners. But could be the difference in whether or not someone new to programming sticks with Java or not.

Well, they reduced a few lines of boilerplate for hello world Java program, while adding many many paragraphs of text to explain it. ;)

Re: Java 22 Released

#165

Post by fuzztester »

aidos wrote: post #57
bheadmaster wrote: post #48

Earlier quoted context omitted.

Good that they got rid of the class/public static void/string[] Args boilerplate, but if they just went one step forward and declared implicit main function as top-level scope of a file, we could've got to a Python level of tersity. Just imagine! System.out.println("Hello world!");

To be that guy, not quite a python level of tersity!

# Python 3

p = print # the print() function

# Now we can do:

p("Hello world")

# endlessly, in this file.

Shorter by 17-odd characters than the above Java version.

Re: Java 22 Released

#166

Post by DarkNova6 »

owlstuffing wrote: post #161
DarkNova6 wrote: post #148

Earlier quoted context omitted.

I'm not 100% sold. I like some of it's features (e.g. the mentioned typed SQL safety) but adding all of it seems super heavy-weight. Lombok took a good time to become widely accepted and I don't think this will ever appeal to more than just a niche audience. At the very least, I prefer not to have any surprises in my codebase because it looks like Java but isn't quite so really.

> I'm not 100% sold. The vast majority of people that use it aren't, but that's a feature :) Manifold isn't an all-or-nothing proposition. It's architecture is modularized so that you can select the parts you want à la carte as separate dependencies in your build. > At the very least, I prefer not to have any surprises in my codebase But manifold surprises are pleasant ones :) As with any library or framework, it's a…

> Manifold isn't an all-or-nothing proposition. It's architecture is modularized so that you can select the parts you want à la carte as separate dependencies in your build.

Oh that's neat! Didn't sound like it when I was skimming over it. I'll keep it in head next time a pet project comes along :-)

Re: Java 22 Released

#167

Post by fuzztester »

fuzztester wrote: post #163
eddd-ddde wrote: post #112

Earlier quoted context omitted.

This reminds me of when I finally understood why returning 0 from a function named main made sense.

And why array indices start at 0 instead of 1, in many, though not all, programming languages.

https://en.m.wikipedia.org/wiki/Zero-based_numbering

Re: Java 22 Released

#168

Post by int_19h »

soulbadguy wrote: post #92
int_19h wrote: post #55

Earlier quoted context omitted.

Not just value types, but also: 1. Pointers to the same (and not just references to objects). 2. Unions (via explicit-layout structs) 3. Function pointers. 4. C-style varargs. To be fair, not all of these have been exposed in C# historically even though CLR had them all along. Most notably, unmanaged function pointers took over 20 years. And since most people look at CLR through the prism of C#, they aren't necessari…

Indeed. The CLR from its inception implemented a lot of features for helping native inter-op. I would guess that msft did make the effort simply because of their large legacy c/c++/win32 code base. It's a shame really that msft stewardship of the .net/clr was so lacking. Of all the modern virtual machine clr us pretty much up there

The goal wasn't so much native interop as being the universal VM for different languages. Specifically, they had an explicit requirement that pure CLR bytecode should be a valid compilation target for C++ (among other things - such as what would eventually become F#, hence why CLR also has explicit tailcalls, for example). But, of course, when you have all the necessary abstractions, that also allows for easy interop with the world outside the VM.

It's too bad that this vision was never fully realized - in part, because .NET was not open enough originally, but also because of internal divisions in Microsoft itself. If it did, we could have had the equivalent of both LLVM and WebAssembly much, much earlier.

Re: Java 22 Released

#169

Post by pjmlp »

jsnelgro wrote: post #162
pjmlp wrote: post #159

Earlier quoted context omitted.

Android OS layer has zero Kotlin, and Google had to backtrack on their decision to let Java languish, as the Android ecosystem started to lose out on Java ecosystem, thus ART is now updatable via Play Store since Android 12, and Java 17 LTS is the latest supported version. Kotlin is only used on Jetpack Compose and a couple of AndroidX libraries, that you have to ship alongside the application. And as alternative to…

Interesting, I don't develop for Android so I don't know the details in this space. Surprising to learn that the Android OS layer is 100% Java. In terms of a platform, I was more referring to the mass adoption of Kotlin for Android app development. 95% of the top 1,000 Android apps are written in Kotlin and adoption overall is > 50% according to their overview page https://kotlinlang.org/docs/android-overview.html IM…

> Android OS layer is 100% Java

More like 70%, the remaining 30% are split between Linux kernel (C), Treble drivers written in C++ (Java is also supported), SQLlite (C), and naturally Skia, ART are written in C++. With a couple of newer drivers like the Bluetooth stack, adopting Rust.

However zero Kotlin.

Naturally Kotlin has such an adoption on userspace, Jetpack Compose the new UI framework is written in Kotlin, so already adopting that jumps up the adotption numbers.

It is like measuring Swift adoption by the use of SwiftUI, even if the business logic is still written in Objective-C.

I do agree that Google being Kotlin's godfather, pushing it for new projects, does create a lot of staying power.

However it is also the reason why on JVM, it is only yet another guest language, as there is no one telling Java developers they should not write Java to use framework XYZ.

All those that tried, Grails, Spark, Akka,... eventually lose adoption speed, and got replaced by Java alternatives.

Which Google had to accept, Kotlin's value without the breath of Java written libraries isn't that great any longer, and they aren't going to rewrite the whole Maven Central into Kotlin, as the Java community moves beyond Java 8.

Re: Java 22 Released

#170

Post by pjmlp »

int_19h wrote: post #168
soulbadguy wrote: post #92

Earlier quoted context omitted.

Indeed. The CLR from its inception implemented a lot of features for helping native inter-op. I would guess that msft did make the effort simply because of their large legacy c/c++/win32 code base. It's a shame really that msft stewardship of the .net/clr was so lacking. Of all the modern virtual machine clr us pretty much up there

The goal wasn't so much native interop as being the universal VM for different languages. Specifically, they had an explicit requirement that pure CLR bytecode should be a valid compilation target for C++ (among other things - such as what would eventually become F#, hence why CLR also has explicit tailcalls, for example). But, of course, when you have all the necessary abstractions, that also allows for easy interop…

The internal divisions had more a play into this than anything else, Windows could have evolved into something like Android or Inferno, but that isn't something that those on Sinofsky's team would accept.

Also why we got WinRT being like .NET, but with COM and C++, with .NET Native being a complete difference compiler toolchain, as he got hold of the Windows reigns.

Post reply on HN