Discussion

Java 26 Is Here, And With It a Solid Foundation for the Future

wiseowise: Android as always in shambles. Shame that neither Google, nor ecosystem cares about Java because they’ve bought JetBrains kopium.

pjmlp: Google basically played a J++ with Android Java, with Kotlin as their .NET/C#.At least they are forced to partially update Android Java, now Java 17 subset, so that Kotlin can keep up with was is mostly deployed at Maven Central.

xxs: That's a proper late 90s reference, props!

haolez: I was pretty surprised when I learned recently that the Java alternative for green threads doesn't used colored functions. It put Java in a higher place in my perception.

dmos62: What are colored functions?

AlotOfReading: The term comes from an old blog post [0] about different kinds of effect systems. Every function has a color, and every colored function can only call functions that are compatible with it, usually of the same color. The net result is that you end up either duplicating a lot of your common code so you have compatible interfaces for all the different colors (let's call that "separate but equal" if we're feeling spicy), or you end up shoving round pegs into the square holes of your dominant function color.[0] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

cogman10: Pretty sure they did a J# ;). But I agree that Kotlin is their C#.The JDK and JVM has advanced so fast while android has been lagging. It's pretty frustrating, especially because google has been so slow to pull in changes from later java versions.A part of me wishes that android would just dump their hokey dalvik, ART, and other BS and just use the OpenJDK or a fork of the OpenJDK with whatever special sauce they need. A lot of the project Leyden stuff lends itself nicely to maybe someday being able to run real java on android.Edit: Apparently android is forking OpenJDK, since Android 7.https://en.wikipedia.org/wiki/Android_Nougat

freedomben: Do you think it's legal reasons, technical reasons, NIH syndrome, or some other reason why Android doesn't use OpenJDK?

cogman10: A little bit of all of the above.Android's usage of Java started right as Sun was being acquired by oracle and right before the jdk was GPLed.... And I'll be. Apparently Android is using the OpenJDK since Android 7. [1][1] https://en.wikipedia.org/wiki/Android_Nougat

hencq: J++ predates C#. It was Microsoft's version of Java that wasn't quite compatible.

cogman10: Correct, and J# was a brief transition language to help migrate Visual J++ applications onto the .Net SDK. J++ -> J# -> C# was the evolution.I say J# is a more apt comparison because like Microsoft's Java, android has a substantial set of APIs that aren't part of the JDK standard. Working on Java vs Anrdoid is practically like working with the JDK vs .Net.

pjmlp: J++ already had those extensions, hence the lawsuit.

pjmlp: J# was the transition product to port J++ into .NET, I am quite sure.Not only I was there on those years, my employer was a MSFT partner that got to test .NET before it was announced to the world, so that we could have our products as part of the announcement event in Portugal.OpenJDK is cherry picked, Google only picks pieces of it, rather than full compatibility.

saltyoldman: Jesus Fing Christ we renamed master to main but we still allow someone to say colored functions!?!?!Stack Exchange comment> "I've heard people say "colored" functions (eg async functions, or functions marked with throws ) are bad because they pollute your code base"

Starlevel004: Smug guy term for "you can't call a function without passing an argument"

izacus: No.

xeubie: I think astronomers could measure the age of the universe in nano-Valhallas. Every year, it feels 50% closer to completion...In all seriousness I'm happy with what Mr. Goetz and the team have done. Sealed interfaces (java 17) + exhaustive switch statements (java 21) means we now have union types in java! And instead of jumping on the async/await bandwagon we now have a more general solution that doesn't lead to API duplication (virtual threads). But Valhalla has been a veeery long time coming.

noelwelsh: 'Tis true. At the same time, Project Valhalla will be the most significant change to the JVM in a very long time, and probably its best chance to stay relevant in the future.

cyberax: > Google basically played a J++ with Android JavaNo, they didn't. Google happily used regular Java until Oracle played Oracle. Then Google stopped updating the supported Java language version and started diversifying away from Java.

pjmlp: They definitely did not, it was Android Java from day one, and Oracle should have crushed them like Sun did to Microsoft, unfortunately Google was the geek darling of do not evil, thus they got a pass from fanboys.

cyberax: Android was not 100% compatible with Java, but mostly because it had a specialized environment. It did not support things like dynamic bytecode generation, but it faithfully reproduced pretty much everything else that made sense.And yeah, it would have been so much better with Oracle(tm)(r)(c)(fuckyou) running Android with Pure Java(tm)(r)(c)(screwyou) instead. Now with EJB5 and more XML!You might be too young to remember, but SunOracle essentially abandoned the Java language development for more than a decade, until Kotlin provided a very much needed magic kick.Oh, and if you think _Google_ is bad for splitting the Java ecosystem, let me introduce you to J2ME and JavaCard.

dzonga: the people that work on Java & the JVM are very smart.it has become a best of breed language - hell its better than Go for industry purposes.the drawback with Java will always be the CULTURE - (maybe someone can insert a quote of how in physics progress is only made, when old physicist die - I don't wanna be morbid ) but with Java same that's when the culture will change.All those people using typescript (could be using Java - but the culture doesn't want them and consider them heretics for not embracing religion of OOP and FactoryFactory)

antonvs: Are you perhaps confusing green threads with stackless async models, like async/await? Green threads don't imply colored functions.

karel-3d: I didn't use Java since 7, but from people that do - nowadays you basically don't code Java, you code Spring Boot. And that has all the bad things you think when people say "Java".I don't know if it's true though.

ezfe: There's a lot of programming that has nothing to do with SpringBoot - and I say this as someone who works in a backend team that uses SpringBoot for all our apps.

shermantanktop: You're talking to specific people.A completely different culture of Java usage can and does exist a lot of places. It is absolutely true that success creates a certain ossification of practice. But SpringBoot is not necessary, any more than Guice or any other framework-y thing.

stanac: After ~13 years of working with C#, I moved to Kotlin. It's such a beautiful language. When I have to read docs for a Java lib I realize why I like Kotlin.I want to say culture around Java doesn't have to change, new culture is growing around succinctness (if not simplicity) of Kotlin, and it gets most of the benefits of Java ecosystem.

dxxvi: Does the Java team use AI? If not, they should use it to give us more features and better performance in a release.

HendrikHensen: What do you mean by "better than Go for industry purposes"?I don't understand what "industry purposes" means and in what aspects Java is better than Go in your opinion (I can think of some myself, but I'm interested in your perspective).

kyrra: Not the GP, but for really large code bases, Go is missing a few features that I've noticed:1) No immutable types. My work team is a huge user of immutable data stuctures in Java to make sure data passed around to other teams isn't changed. Go doesn't really have a good way to do this.2) Refactoring can be really annoying (or at least really noisy) because of public/private being defined by capitalization of method/field names.3) Error handling isn't great. I love Go's errors being just normal values, but the `error` interface is awkward when trying to figure out what kind of errors can be thrown without having in-depth knowledge of the kinds of errors that can be returned. We regularly need to make different decisions depending on the kind of error returned. Knowing which errors can be returned in Go is not defined by the method being called (only in comments).

ludovicianul: I program in Java for more than 15 years now. I can resonate with people hating the language from it's early days due to the experience with all the enterprisy features and over abstractions. Or confunding Java with the Spring ecosystem. But Java came a long way over the years. It's now what many would call a "modern" language. It's less verbose, has many of the features people find appealing in Scala and Kotlin and it can even compile to native binaries using GraalVM. This made building CLIs in Java feasible. Or lambdas.

mands: It's getting better, it doesn't all have to be Spring Boot and JBoss.There is quarkus, helidon and micronaut for slimmer more modern backend frameworks. jbang for scripting (think uvx, bunx), Tambo UI (https://tamboui.dev/) for terminal UIs, and more.Along with all the new Java features that help you write much simpler code - eg. virtual threads, structured concurrency, stream gatherers, and performance / resource improvements.It's not all there yet, but I think the next few years things will come together nicely (however a better build system is sorely needed - one of the things that Go / Rust did right).

cess11: If someone reads this and wonders what JBoss is, the contemporary variety is called WildFly and it is actually rather easy to install and play around with.https://www.wildfly.org/I think this is an often overlooked solution to some of the problems we nowadays tend to approach the clown for.As for build systems, Maven is old and cranky but if something else replaces it, it will probably be quite similar anyway.

oystersareyum: Do changes to Java itself impact e.g. Clojure? I think it uses many java primitives instead of emitting jvm byte code but I can be wrong.

olivia-banks: Really glad to see we're getting a native PEM API.

lucketone: Pleasantly surprised.But it is a preview though.