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)
> for not embracing religion of OOP and FactoryFactory
Not the case today. Of course, crappy code (or questionable patterns) can be found in all languages, and java community had made some innovations in the area early on, but today we have a different picture.
FactoryFactory has gone mostly extinct, the most likely place to see it is “dailywtf.com”.
We now know that we prefer composition over inheritance, we have stream api - language and community evolved, old patterns are not neccessary anymore to solve same/similar problems.
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.
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).
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.
Enterprise space architecture is not picky, all programming languages get a place when they manage to hit big at corporate life.
It can be Yourdon with C and Pascal, Booch with Smalltalk and C++, Patterns with Smalltalk and C++, UML with Ada, C++, Smalltalk and Java, Rational RUP , Java and .NET application servers, Kubernetes with WebAssembly microservices,....
Ever looked into Typescript with effects, pretending to be Haskell?
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).
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).
Ya, that seems to be a misunderstanding. "Industry purposes" covers a huge range of stuff. Go is pretty good for systems programming where Java isn't really an option due to the fundamental limits imposed by garbage collection and lack of pointers. Java is pretty good for higher-level application development where occasional GC pauses are tolerable (the GC pauses are rare and fast now, but they still rule out using Java for certain purposes).
Front page, 82 comments, comment 2 hours ago…why is this the top comment? “People who write Typescript could just be writing Java except they’re scared of being outcasts for not using design patterns” is bait, not a serious technical opinion.
I would love to have a Java compiler with the capabilities of the .net compiler. To make incremental builds to aid code completion including type information, looking past simple syntactical errors, fixing them, and continuing compilation.
Currently, this is “magic” embedded in eclipse, IntelliJ, and maybe a bit in the vscode plugin. Imagine having a Java LSP running that can provide all this information while typing.
.net has had this for ages. From a language design I think that is wonderful.
Bright future for it just means it is not planning to become 40th or 400th.
(My prediction - in next ten years java will always be among top 6; new language might come to the very top and some leapfrogging game between c# and java)
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".
There are more Java devs than people in my home country. Like how could you even give a single description for all of them? They all work on vastly different stuff, from low-latency trading to robotics, to regular old CRUD. Not even the CRUD part is as monotonic though as you make it out to be.
Spring Boot isn‘t bad. It‘s opinionated about configurations and dependencies. Its main advantage is that you can start shipping production-quality code very quickly, focusing on business problems rather than anything else. Vibe coding on it is more or less stable, entire apps can be built solo in a few months. And it‘s easy to do fullstack with SSR based on Thymeleaf and Htmx. It is absolutely superior to anything that exists for node stack.
And then there‘s also Micronaut, if you prefer compile-time setup to Spring.
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.
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.
I have been using Java since version 1.4. Both the language and its ecosystem have come a long way since then. I endured the height of the EJB phase. I adopted Spring when version 1.2 was released. I spent hours fighting with IDEs to run OSGi bundles. I hated building UIs with Swing/AWT, many of which are still in use today and are gradually being replaced by lovely JavaFX. When I look at code I wrote around 12 years ago, I'm amazed at how much I've matured too.
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.
Glad to see this being removed. Java plugins especially on Linux were awful and required by tons of corporate stuff. Anyone remeber IcedTea Web? A functional and opensource Java plugin and Java Webstart implementation?
Note that the the Java plugin and webstart was removed a long time ago.
I personally regret that the API was removed as it's a few classes and they are still used. Just search JApplet on Github. It's also possible to run applets in the modern browsers with WASM or in Java IDE's as plugin.
I made several Webstart corporate apps back in the day! The infrastructure was pretty neat, when it worked. And it was a whole lot better than JS back then, still in the IE6 times.
I was pretty surprised when I learned recently that the Java alternative for green threads doesn't use colored functions. It put Java in a higher place in my perception.
It doesn't completely solve function coloring though. Causing carrier threads to get pinned is still not good, similarly as calling blocking function from async function is not good in colored systems.
Any time you have a barrier between one function being able to call another. The original article on this called them red functions and green functions. A green function can call a red function but a red function can't call a green function.
In terms of async, it's when you have to have a function with "async" attached to it and making it so that only other async functions can call async functions.
It ends up creating a weird circumstance where you can end up with a lot of duplicated APIs, particularly in libraries, because you are providing both async and non-async versions of functions.
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.
The terminology is used to talk about languages that have async and sync functions where you declare (or color) the function as either async or sync.
In these languages it's pretty common for the language to enforce a constraint that async functions can only call other async functions. Javascript / Typescript, Python are popular examples of languages with colored functions.
"green threads" is generally how I see these systems identify as "non-colored but with async-like performance" fwiw. or "fibers". otherwise it's "async" or "coroutines".
There are different types of coroutines. The C++ type are sometimes called "stackless coroutines". With stackless coroutines you can't yield from a nested function call. Stackless coroutines are basically generators where you can pass arguments through resume, and async/await is effectively a form of stackless coroutines with yield/resume semantics that aren't fully generalized as coroutines, but oriented toward some bespoke notion of concurrency rather than as an abstract control flow operator.
"Stackful coroutines" allow yielding from any arbitrary point. They're basically fibers, except with the explicit control transfer and value passing yield and resume operators; there's no hidden or implicit control transfer like with green threads. Though, some people would argue allowing any function to yield without announcing this in their type signature is tantamount to hidden control transfer. Personally, I don't see how that's different than allowing any function to call other functions, or to loop, but in any event languages are free to layer on additional typing constraints--constraints that can be tailored to the desired typing semantics, rather than dictated by implementation details.
Stackless coroutines are typically implemented as a special kind of function whose state is allocated and instantiated by the caller. In contrast, stackful coroutines are typically implemented by reifying the stack, similar to threads. The "stack" may or not be the same as the system's ABI stack.
In stackful coroutines, unless there are additional typing constraints imposed by the language for hygiene reasons, any function can typically be called as a coroutine or use yield and resume. There's no need to compile functions into special alternative forms as call frame management works the same whether invoked from a coroutine context or not.
What alternative would they be referring to? Green threads were only (re-)introduced to Java in version 21 in 2023.
I think what they're trying to say is that Java's green thread implementation has special support for async I/O. Threads that block on I/O aren't polled for completion by the runtime, instead they use OS async features under the hood.
This allows Java's green threads to compete performance-wise with async/await solutions, but with cleaner code that doesn't need colored functions.
In older green thread implementations in other languages, I/O can actually cause significant CPU overhead due to polling threads that are blocked by I/O requests.
As someone who has been out of the Java world for many years, but recently forced back into it due to Android dev requirements, Post lawsuit, what is the relationship between Android (Google) and Java now? When can we expect 26 on Android? On that note, why is Android always so far behind? Is it because Kotlin is primary or is it deeper? Did the lawsuit play a role?
Android has their own runtime (creatively named as Android runtime), which does not run java byte code, but their own binary format. JVM class files can be compiled to that format, but the support for that always lags behind OpenJDK java versions.
Part of the reason kotlin became the de facto language on the platform was that they supported only terribly old Java at the time, that didn't even have lambdas even though it was already out.
The problem is that most of the Java libraries want to follow the desktop/server, aka the OpenJDK scene, but that would make them incompatible with Android so there was/is some incentives to bump up the version they support.
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.
'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.
I haven't read a Java manual since the time of Java 8. Do you have any books or other resources you could recommend to catch up with all that has changed in these years?
Some of the standard library stuff could be usable from Clojure and other languages. The jvm level optimizations (garbage collection) should benefit all jvm languages. The language changes are mostly not that relevant unless you program directly in Java.
I use Kotlin myself (after doing Java since 1995). Most of the overview here reads like they are adding a lot of stuff that Kotlin has had for many years. Structured concurrency, lazy stuff, etc. You can argue about which language does it better/nicer/etc. but that debate is a bit boring to me. But good for Java developers that they are getting some obviously useful things that so far they never had. Progress is nice. Better late than never.
When it was about the 7th incubator iteration, I got curious so I read the actual JEP history, and it had this informative tidbit, also included in the latest release:
"The Vector API will incubate until necessary features of Project Valhalla become available as preview features. At that time, we will adapt the Vector API and its implementation to use them and then promote the Vector API from incubation to preview."
Project Valhalla has been "in progress" for at least a decade now (Wikipedia say 2014). So who knows when we'll actually see a Vector API in preview.
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.
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.
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.
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.
It isn't, check Gerrit commit history, they only take bits and pieces, plus ART doesn't do all bytecode equivalents. Some JVM bytecode don't have counterparts in Dex, rather get desugared into multiple instructions.
No, 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.
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.
Oracle's Java Mobile Edition could've crushed Android. No one stopped them.
> Google was the geek darling of do not evil, thus they got a pass from fanboys.
Oracle's case against Google went all the way up to Supreme Court of US. Oracle did not win anything substantial in courts against Google is not fanboys' doing.
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.
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)
> for not embracing religion of OOP and FactoryFactory
Not the case today. Of course, crappy code (or questionable patterns) can be found in all languages, and java community had made some innovations in the area early on, but today we have a different picture.
FactoryFactory has gone mostly extinct, the most likely place to see it is “dailywtf.com”.
We now know that we prefer composition over inheritance, we have stream api - language and community evolved, old patterns are not neccessary anymore to solve same/similar problems.
Sample of one - junit (testing lib) source code, from quick glance it seems more procedural than dogmatic OOP: https://github.com/junit-team/junit-framework/blob/main/juni...
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.
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).
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.
> As for build systems, Maven is old and cranky but if something else replaces it, it will probably be quite similar anyway.
Bazel is the most obvious contender and very different from Maven in almost every possible way.
Enterprise space architecture is not picky, all programming languages get a place when they manage to hit big at corporate life.
It can be Yourdon with C and Pascal, Booch with Smalltalk and C++, Patterns with Smalltalk and C++, UML with Ada, C++, Smalltalk and Java, Rational RUP , Java and .NET application servers, Kubernetes with WebAssembly microservices,....
Ever looked into Typescript with effects, pretending to be Haskell?
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).
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).
Ya, that seems to be a misunderstanding. "Industry purposes" covers a huge range of stuff. Go is pretty good for systems programming where Java isn't really an option due to the fundamental limits imposed by garbage collection and lack of pointers. Java is pretty good for higher-level application development where occasional GC pauses are tolerable (the GC pauses are rare and fast now, but they still rule out using Java for certain purposes).
Go has gc too and arguably worse one than Java
Front page, 82 comments, comment 2 hours ago…why is this the top comment? “People who write Typescript could just be writing Java except they’re scared of being outcasts for not using design patterns” is bait, not a serious technical opinion.
Oh. That’s why it’s the top comment.
"a solid foundation for the future" is faint praise for a language that has been around for over thirty years.
> It has become a best of breed language
To me it lags significantly behind .net (runtime) and C#/F# (language). I don't see Java catching-up.
They trade blows, and have different philosophies (complex runtime, simpler language vs the reverse).
E.g. on the GC side Java is ahead of any other platform, especially with the low-latency ZGC garbage collector.
I would love to have a Java compiler with the capabilities of the .net compiler. To make incremental builds to aid code completion including type information, looking past simple syntactical errors, fixing them, and continuing compilation.
Currently, this is “magic” embedded in eclipse, IntelliJ, and maybe a bit in the vscode plugin. Imagine having a Java LSP running that can provide all this information while typing.
.net has had this for ages. From a language design I think that is wonderful.
Java LSP backends are basically headless Eclipse and NetBeans, they definitely go beyond syntactical errors.
There's also the upcoming Metals v2 that's using another compiler frontend optimized for performance, Google Turbine: https://metals-lsp.org
Actionable diagnostics for Java aren't implemented yet though.
Java is 4th on tiobe.
Bright future for it just means it is not planning to become 40th or 400th.
(My prediction - in next ten years java will always be among top 6; new language might come to the very top and some leapfrogging game between c# and java)
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.
There are more Java devs than people in my home country. Like how could you even give a single description for all of them? They all work on vastly different stuff, from low-latency trading to robotics, to regular old CRUD. Not even the CRUD part is as monotonic though as you make it out to be.
Spring Boot isn‘t bad. It‘s opinionated about configurations and dependencies. Its main advantage is that you can start shipping production-quality code very quickly, focusing on business problems rather than anything else. Vibe coding on it is more or less stable, entire apps can be built solo in a few months. And it‘s easy to do fullstack with SSR based on Thymeleaf and Htmx. It is absolutely superior to anything that exists for node stack.
And then there‘s also Micronaut, if you prefer compile-time setup to Spring.
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.
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.
I am captivated by your thought process.
Once i heard a manager explain "we must get rid of anything Oracle, including Java, because of license reasons". I see this attitude everywhere since.
JavaScript people are too afraid to use Java, that is why something like TypeScript exists.
And for personal projects, C# has become a better and more fun "just works" platform.
I have been using Java since version 1.4. Both the language and its ecosystem have come a long way since then. I endured the height of the EJB phase. I adopted Spring when version 1.2 was released. I spent hours fighting with IDEs to run OSGi bundles. I hated building UIs with Swing/AWT, many of which are still in use today and are gradually being replaced by lovely JavaFX. When I look at code I wrote around 12 years ago, I'm amazed at how much I've matured too.
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.
JEP 504: Remove the Applet API
Glad to see this being removed. Java plugins especially on Linux were awful and required by tons of corporate stuff. Anyone remeber IcedTea Web? A functional and opensource Java plugin and Java Webstart implementation?
Note that the the Java plugin and webstart was removed a long time ago.
I personally regret that the API was removed as it's a few classes and they are still used. Just search JApplet on Github. It's also possible to run applets in the modern browsers with WASM or in Java IDE's as plugin.
Remember IcedTea Web? Oh boy, I still have environments that use it.
I made several Webstart corporate apps back in the day! The infrastructure was pretty neat, when it worked. And it was a whole lot better than JS back then, still in the IE6 times.
Yeah XMLHttpRequest and activex thing IE6 had. That was Javascript style that days.
I was pretty surprised when I learned recently that the Java alternative for green threads doesn't use colored functions. It put Java in a higher place in my perception.
It doesn't completely solve function coloring though. Causing carrier threads to get pinned is still not good, similarly as calling blocking function from async function is not good in colored systems.
No need of colored functions because that Java green thread returns a Future<Value> not Value like colored functions
What are colored functions?
Any time you have a barrier between one function being able to call another. The original article on this called them red functions and green functions. A green function can call a red function but a red function can't call a green function.
In terms of async, it's when you have to have a function with "async" attached to it and making it so that only other async functions can call async functions.
It ends up creating a weird circumstance where you can end up with a lot of duplicated APIs, particularly in libraries, because you are providing both async and non-async versions of functions.
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-...
https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
The terminology is used to talk about languages that have async and sync functions where you declare (or color) the function as either async or sync.
In these languages it's pretty common for the language to enforce a constraint that async functions can only call other async functions. Javascript / Typescript, Python are popular examples of languages with colored functions.
https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
In this context: functions anotated with async
"green threads" is generally how I see these systems identify as "non-colored but with async-like performance" fwiw. or "fibers". otherwise it's "async" or "coroutines".
There are different types of coroutines. The C++ type are sometimes called "stackless coroutines". With stackless coroutines you can't yield from a nested function call. Stackless coroutines are basically generators where you can pass arguments through resume, and async/await is effectively a form of stackless coroutines with yield/resume semantics that aren't fully generalized as coroutines, but oriented toward some bespoke notion of concurrency rather than as an abstract control flow operator.
"Stackful coroutines" allow yielding from any arbitrary point. They're basically fibers, except with the explicit control transfer and value passing yield and resume operators; there's no hidden or implicit control transfer like with green threads. Though, some people would argue allowing any function to yield without announcing this in their type signature is tantamount to hidden control transfer. Personally, I don't see how that's different than allowing any function to call other functions, or to loop, but in any event languages are free to layer on additional typing constraints--constraints that can be tailored to the desired typing semantics, rather than dictated by implementation details.
Stackless coroutines are typically implemented as a special kind of function whose state is allocated and instantiated by the caller. In contrast, stackful coroutines are typically implemented by reifying the stack, similar to threads. The "stack" may or not be the same as the system's ABI stack.
In stackful coroutines, unless there are additional typing constraints imposed by the language for hygiene reasons, any function can typically be called as a coroutine or use yield and resume. There's no need to compile functions into special alternative forms as call frame management works the same whether invoked from a coroutine context or not.
Are you perhaps confusing green threads with stackless async models, like async/await? Green threads don't imply colored functions.
They said "Java alternative for green threads" so they're talking about not green threads.
What alternative would they be referring to? Green threads were only (re-)introduced to Java in version 21 in 2023.
I think what they're trying to say is that Java's green thread implementation has special support for async I/O. Threads that block on I/O aren't polled for completion by the runtime, instead they use OS async features under the hood.
This allows Java's green threads to compete performance-wise with async/await solutions, but with cleaner code that doesn't need colored functions.
In older green thread implementations in other languages, I/O can actually cause significant CPU overhead due to polling threads that are blocked by I/O requests.
As someone who has been out of the Java world for many years, but recently forced back into it due to Android dev requirements, Post lawsuit, what is the relationship between Android (Google) and Java now? When can we expect 26 on Android? On that note, why is Android always so far behind? Is it because Kotlin is primary or is it deeper? Did the lawsuit play a role?
Java's primary development happens on OpenJDK.
Android has their own runtime (creatively named as Android runtime), which does not run java byte code, but their own binary format. JVM class files can be compiled to that format, but the support for that always lags behind OpenJDK java versions.
Part of the reason kotlin became the de facto language on the platform was that they supported only terribly old Java at the time, that didn't even have lambdas even though it was already out.
The problem is that most of the Java libraries want to follow the desktop/server, aka the OpenJDK scene, but that would make them incompatible with Android so there was/is some incentives to bump up the version they support.
I've used Java decades ago (anyone remember servlet?) and I'm glad that I can use flutter for Android development.
Man I still have scars learning Java in college. Took the entire fun out of coding until I ended up learning C.
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.
'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.
I haven't read a Java manual since the time of Java 8. Do you have any books or other resources you could recommend to catch up with all that has changed in these years?
Really glad to see we're getting a native PEM API.
Pleasantly surprised.
But it is a preview though.
Cool. I feel as though I'll never be able to escape 8, or ignore Ellison's legacy, unfortunately.
> or ignore Ellison's legacy, unfortunately.
Can you elaborate?
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.
Some of the standard library stuff could be usable from Clojure and other languages. The jvm level optimizations (garbage collection) should benefit all jvm languages. The language changes are mostly not that relevant unless you program directly in Java.
I use Kotlin myself (after doing Java since 1995). Most of the overview here reads like they are adding a lot of stuff that Kotlin has had for many years. Structured concurrency, lazy stuff, etc. You can argue about which language does it better/nicer/etc. but that debate is a bit boring to me. But good for Java developers that they are getting some obviously useful things that so far they never had. Progress is nice. Better late than never.
In general, some java language changes do involve JVM changes.
So yes, it impacts other jvm languages like Closure.
Here most obvious would be GC improvements.
Ah , Java, a language I pray I never have to ever touch again.
Vector API (Eleventh Incubator) - maybe 11th time’s the charm.
When it was about the 7th incubator iteration, I got curious so I read the actual JEP history, and it had this informative tidbit, also included in the latest release:
"The Vector API will incubate until necessary features of Project Valhalla become available as preview features. At that time, we will adapt the Vector API and its implementation to use them and then promote the Vector API from incubation to preview."
Project Valhalla has been "in progress" for at least a decade now (Wikipedia say 2014). So who knows when we'll actually see a Vector API in preview.
On the other hand, there is a bunch of movement on Valhalla side nowadays. You can download a build and try out value types yourself!
Does the Java team use AI? If not, they should use it to give us more features and better performance in a release.
Dont you have parents to tell them that? Open a pr in the codebase
Android as always in shambles. Shame that neither Google, nor ecosystem cares about Java because they’ve bought JetBrains kopium.
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.
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
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.
J++ predates C#. It was Microsoft's version of Java that wasn't quite compatible.
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.
J++ already had those extensions, hence the lawsuit.
Do you think it's legal reasons, technical reasons, NIH syndrome, or some other reason why Android doesn't use OpenJDK?
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
It isn't, check Gerrit commit history, they only take bits and pieces, plus ART doesn't do all bytecode equivalents. Some JVM bytecode don't have counterparts in Dex, rather get desugared into multiple instructions.
That's a proper late 90s reference, props!
> Google basically played a J++ with Android Java
No, 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.
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.
Oracle's Java Mobile Edition could've crushed Android. No one stopped them.
> Google was the geek darling of do not evil, thus they got a pass from fanboys.
Oracle's case against Google went all the way up to Supreme Court of US. Oracle did not win anything substantial in courts against Google is not fanboys' doing.
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.
My dear I am programming since 1986, and a Nokia alumni.
I wouldn’t blame Google for Oracle being a lawnmower.