In fact, Java is the descendant of this old design...
# coroutines
e
In fact, Java is the descendant of this old design approach where “concurrent objects” are supported as a language construct, where you encapsulate the “actor” into a class and mark public methods by a special annotation (
synchronized
!) to make sure that the state inside the “actor” is safe. @uli’s Counter (https://github.com/uluckas/s2s-KActorAnnotations/blob/master/KActorTest/src/main/kotlin/de/musoft/annotationProcessor/test/Counter.kt) example is easy to represent in Java-style just by marking all public funs with
@Synchronized
. The obvious big problem in Java is that it was implemented on top of (heavy-weight!) threads, so it does not scale. Easy to fix with coroutines. Another problem (in Java) is that it is easy to forget this annotation on some method. It is easy to fix, too, with a better design where classes are marked, not methods (Swift is also aware of this trap). However, there is a more serious, conceptual problem, to this approach to programming in general, even if you implement it on top of light-weight coroutines — it is easy to get into deadlocks with a code like that when you start having a lot of those “actors” in your code. Keep this in mind.