ea-async with Java 9

[HaloFour]

I'm testing using ea-async with a SpringBoot 5.x application I am working on. When I try to compile and run this on Java 9 I get the following error:

java.lang.IncompatibleClassChangeError: Method java.util.function.Function.identity()Ljava/util/function/Function; must be InterfaceMethodref constant

I am doing the instrumentation at compile-time via the maven plugin.

A quick Googlin' seems to indicate that the Java bytecode validator got a little better/stricter with Java 9 so what worked with Java 8 is no longer valid.

[JoeHegarty]

Going to ping @DanielSperry to see if he has any idea.

In general we're reducing our reliance on ea-async internally and pursuing a more reactive programming based model.
Orbit 2.x will support both futures and reactive streams at the boundaries and it's usually more natural to use streams as Monads than it would be to use ea-async.

There are other issues preventing Orbit running on Java 9 right now which we need to resolve before we'll get a chance to look at this in ea-async.

That's not to say we're abandoning this project, just that we're focused on supporting other models right now and getting our other projects on Java 9 so it isn't getting a lot of attention in the short term.

[HaloFour]

Ah that's a shame. I love reactive streams but to me they suffer from the same inside-out development model that futures do which can make it challenging to adopt, especially across a team used to traditional imperative programming.

Any chance that ea-async might evolve to support reactive in a similar vein to how C# is planning on implementing language support for asynchronous streams?

[JoeHegarty]

I hadn't seen that proposal for C# before but it's interesting for sure.
We don't have any firm plans around that kind of system for ea-async at present.

My main issue (if you want to call it that) with ea-async is that while it undoubtedly gives you a more natural programming model when working with futures you pay significant costs for that.

Debugging becomes a lot more difficult because there is no first class language support so ea-async does things the debugger can't interpret correctly. This is by far the most common complaint/request I get and there is really no easy way for us to support debugging.

I find I spend more time explaining and supporting this library internally than any other. Users will use await in methods that don't return a CompletionStage because they don't truly understand what the library is doing. Or they will get confused about how async interacts with the threading model of their application (all futures after the first are continued on the same thread) etc.

Ideally async/await should be implemented at the compiler level but as far as I know there has been no serious proposal which deals with coroutines/async/await style in the Java compiler itself.
I think Java is seriously behind the curve here and that we desperately need language support, both Scala and Kotlin (1.1+) have first class support for this style of programming and other JVM languages (Groovy?) may as well.

The original developer of this library is no longer maintaining it so it is now on my plate alongside Orbit, which is a much bigger and more critical project for us.
It's tricky to make changes and maintain this project so it has effectively been on life support for the past few months.

All that being said, ea-async is core to enabling the current Orbit 1.x experience and I strongly believe it adds value to the overall Java ecosystem to have this available.

As we move into development of Orbit 2.x it's important to me that we maintain the same ease of use we have today and ea-async is a big part of how we achieve that.

What that means for ea-async isn't entirely fleshed out at this point, but here are the possibilities I see:

• We'll dedicate resources to ea-async to get it up and running on JDK9 and potentially expand the featureset as needed
• We'll introduce something similar into Orbit itself (we already have plans for a stand-alone orbit-concurrent library)
  • Orbit 2.x is planned to be much more modular so you'd be able to take just the concurrency library
• We'll adopt another solution (though as far as I am aware, not much exists in this space).

Hopefully that gives you some insight into where my thinking is with this project moving forward.

[HaloFour]

Thanks for the update. It's a little disheartening but I can totally understand where you're coming from.

I completely agree about the state of asynchrony in Java. It's not just the language, it seems that the entire ecosystem doesn't "get it". There seems to be an incredibly pervasive idea that threads are really cheap, so spin 'em up and block 'em all day long. I've quite literally seen network I/O bound Java microservices spending 2-3 times as much memory on wasted thread stack space than on heap. The Future<T> interface is an abomination.

Here's hoping that something gives soon or else Java will find itself increasingly marginalized in it's own ecosystem.

[JoeHegarty]

My apologies for the insanely slow progress here.
I have ea-async up and running on JDK9 and 10 locally and I expect to push out a new version in the next few days.

[JoeHegarty]

Resolved in 1.1.0 which is now available.
https://github.com/electronicarts/ea-async/releases/tag/v1.1.0