Coroutines on overlay types

[Chocohead]

I have an overlay type for a class in JavaScript which works as expected:

@JSClass
public class ForkJoinPool implements JSObject {
	public ForkJoinPool() {
	}

	public ForkJoinPool(int threads) {
	}

	public native <T> JSPromise<T> queueWork(Task<T> task);

Needing to break my Java logic up to await for queueWork is inconvenient however. Lots of nested callbacks and awkward chains to each promise.

I thought this would be a good place to use a coroutine:

@JSClass
public class ForkJoinPool implements JSObject {
	public ForkJoinPool() {
	}

	public ForkJoinPool(int threads) {
	}

	@Async
	public native <T> T queueWork(Task<T> task);

	private <T> void queueWork(Task<T> task, AsyncCallback<T> callback) {
		queueWorkAsync(task).then(result -> {
			callback.complete(result);
			return null;
		}, error -> {
			callback.error(new TaskException(error));
			return null;
		});
	}

	@JSMethod("queueWork")
	private native <T> JSPromise<T> queueWorkAsync(Task<T> task);

The @Async seems to be ignored however; there is no change to the compiled output and (the public) queueWork still returns a JSPromise<T>.

Is using @Async within an overlay type allowed/supported? I'm using 0.13.0-dev-5 in case that is significant.

[konsoletyper]

@Async is not supported in exported methods/classes. Moreover, it's not recommended to ever use @Async (directly or indirectly, say, by calling Thread.sleep) when you compile in "library" mode.

[Chocohead]

@Async is not supported in exported methods/classes.

It did seem as such, good to have it confirmed.

For my purposes, exposing the JSPromise returning methods directly and using a separate method to synchronously wait for them seems to work well as a substitute:

@Async
public static native <T> T await(JSPromise<T> future);

private static <T> void await(JSPromise<T> future, AsyncCallback<T> callback) {
	future.then(result -> {
		callback.complete(result);
		return null;
	}, error -> {
		callback.error(new TaskException(error));
		return null;
	});
}

Moreover, it's not recommended to ever use @Async (directly or indirectly, say, by calling Thread.sleep) when you compile in "library" mode.

Is this because of the way it gets compiled/optimised? Just curious, I'm not making a library (this time at least).

[konsoletyper]

Is this because of the way it gets compiled/optimised? Just curious, I'm not making a library (this time at least).

No, it's because of highly undeterministic async infection. When your method uses await, it should be async itself. Unlike async/await in languages like Python or JS, TeaVM's coroutines were made to be compatible with existing Java code, which does not know anything about async/await. So when you write, say, in TS, you care about asyncs from the very beginning and you can control the async infection, however it's not the case with Java/TeaVM. You can think that you are 100% sure that some particular method is not async, but it is. The only way to figure out why, one has to traverse the entire call graph, which can consist of thousands nodes (currently, TeaVM does not provide a switch to dump call graph, but I'm not sure that anyone would really use it). Or to consider that if they are using @Async somewhere, than in theory any method can be @Async.