3 ms·
I see it more as an niche opportunity to integrate bits of Java code in Go applications. The start-up costs can be "paid" when the app starts. Performance will
by tgv 3y ago
I see it more as an niche opportunity to integrate bits of Java code in Go applications. The start-up costs can be "paid" when the app starts. Performance will be bad, but it might save some rewrites (provided they can get things like db connections going).
- tombert 3y agoYeah that makes some sense; there's probably millions of lines of Java code out there where performance doesn't really matter, and so aren't worth rewriting. Being able to embed a JVM just to run those from Go projects isn't a bad idea. Tangential, but a long time ago, I wanted to reuse a node.js slug library in .NET. I thought about trying to port it at first, but then I realized that this actual job didn't need to be terribly fast, so I instead embedded the Jurassic JS library into my code, and was able to load in the slug library that way directly). It wasn't especially fast (but actually faster than I thought it would be!), but it was certainly fast enough, and I didn't have to worry about not having feature parity.
- kaba0 3y agoWhy not just do traditional IPC, or even a batch process starting up a JVM from time to time when needed?
- tgv 3y agoThere are always other solutions. This one might just work in some cases. As I wrote: it's (probably) niche.
- int_19h 3y agoAnother good example was IKVM, which basically transpiled Java bytecode into .NET IL. Saxon XSLT used to build on top of that to provide .NET libraries from the same codebase as the original Java version. (Saxon had since moved to transpiling the source code instead - the languages are close enough that this is fairly straightforward.)
- paulddraper 3y agoExactly. The cool thing is that since this uses the Go garbage collector, you can create a very nice Go-native interface to that JVM code.