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.

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).

E.g. on the GC side Java is ahead of any other platform, especially with the low-latency ZGC garbage collector.

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)

And then there‘s also Micronaut, if you prefer compile-time setup to Spring.

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.

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-...

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 this context: functions anotated with async

"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.

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

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.