Thoughts on migrating back to the JVM

[Benjamin Conlan]

Thanks to innovations in the upcoming Java 8 (nashorn & javafx-webkit) release do you think that there might be a possibility to migrate the Light Table platform back to the JVM?

I'm mostly thinking in regards to supporting plugins etc? I'm guessing things can be patched in via the node/jvm bridge that is currently used in the compilation process, but from your Conj talk, it sounds like moving away from the JVM is on the cards (which I'm a huge advocate for with regards to clojurescript).

Does this mean that ideally plugins should be implemented in some v8/nodejs supported language and call remote services to perform a particular operation when requiring JVM/non-nodejs dependent features (As suggested when using the closure compiler in your talk)?

[Chris Granger]

I'm not sure that we would really gain that much from moving back toward the JVM, and given my experiences with JS-JVM bridges I suspect we'd actually take a pretty serious performance hit. (Not to mention all the recent JVM zero-days ...)

> Does this mean that ideally plugins should be implemented in some v8/nodejs supported language and call remote services to perform a particular operation when requiring JVM/non-nodejs dependent features (As suggested when using the closure compiler in your talk)?

Yep. Basically you use anything that can compile down to JS for UI-ish/workflow stuff and then delegate the language processing and eval to a service (ideally in the language itself) that handles it. Swank/Slime are a good example of this in practice. These services just talk over TCP and JSON, so virtually any language can be supported that way :)

Cheers,
Chris.