In this context: functions anotated with async
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.
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.
[0] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
(Technically, that's the symptom - the underlying cause is that it's a function that involves some effect, like asynchronicity, or, in some functional languages, IO.)
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"
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?
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.
"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.
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.
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)
I don't know if it's true though.
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.
> 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.
wiseowise•1h ago
pjmlp•1h ago
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•1h ago
cogman10•58m ago
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•56m ago
cogman10•51m ago
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
pjmlp•36m ago
hencq•48m ago
cogman10•43m ago
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•40m ago
pjmlp•42m ago
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.
cyberax•47m ago
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.
pjmlp•34m ago
cyberax•23m ago
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.
sulam•36m ago