Virtual Threads for a scripting language in Java 8 without Loom

Virtual Threads for a scripting language in Java 8 without Loom(jactl.io)

53 points by jaccomo 3 days ago | 8 comments

jaccomo 3 days ago |

Author here: Jactl is a secure embeddable scripting language that compiles to bytecode and supports Java 8 and later versions. The article describes how Continuations were used to provide Virtual Thread-like behaviour for scripts. Blocking operations suspend a script which is then resumed from where it left off once the operation completes.

arunix 3 hours ago | |

On the front page, there is an example about optional typing, but it's not very clear how the typing is coming in:

  def fib(x) { x <= 2 ? 1 : fib(x - 1) + fib(x - 2) }
  
  println "40th fibonacci number is ${fib(40)}"

marcolinux 9 hours ago | |

TIL about jactl! Just reading the site right now. Many thanks for: no colored function (no async/wait) !

Any tips on using with gui/swing? rendering images/simple html, that would be awesome!

And what about (gasp) JSP? Or any other templating? It is old school, yeah but I like jsp include (with params) and jsp 'web components' (tags).

Anyway, thanks for writing jactl!

sriram_malhar 4 hours ago |

Ah, I had virtual threads in Java 8 back in the day. I believe it still works.

Check Kilim: https://github.com/kilim/kilim

BenoitP 3 hours ago | |

Another project worth checking would be Quasar (and had virtual threads in 2013):

https://docs.paralleluniverse.co/quasar/

But I believe the author moved to a Big Corp which sells databases, working on some big project which took all his time...

geodel 2 hours ago | | |

LOL, the person you are talking about is Project lead for Loom in OpenJDK.

arvyy 5 hours ago |

As a related work regarding continuations, there was also a thesis by Andrea Bernardini (https://andrebask.github.io/thesis), with similar principal idea

_old_dude_ 10 hours ago |

Nice article.

I think this is similar to the way Kotlin implements coroutine.

I believe Kotlin goes to the extra miles to also capture parts of the stack frames when creating the Continuation object so even when the runtime resume the continuation, the exceptions thrown later get the "correct" stack trace (not the one that shows that you come from a call through a MethodHandle).