4 ms·
You're right, you could separate them into two containers and build a networked API between them, and in many cases that may be the right approach. But I wouldn
by irbull 10y ago
You're right, you could separate them into two containers and build a networked API between them, and in many cases that may be the right approach. But I wouldn't completely throw this solution away yet (I'm the author of this solution, so I guess I'm biased).
For example, if you want to call an NPM module (say Grunt) from and Java / Maven build, it may be easier to bundle this in the same process rather than trying to provision node in the middle of the task. Also, if you have existing Java libraries and want to make use of them as you migrate to Node, it might be easier with the shared memory approach (through ByteBuffers and TypedArrays) that J2V8 offers, than to try and pass the Data between services.
This isn't meant to replace services, it's just another technology choice on the spectrum.
And finally, I thought the problem of integrating Node and Java sounded challenging and cool, and I enjoy challenging problems :).
- pfooti 10y agoTrue enough - something like "because it's there" is certainly a pretty good reason to climb a (metaphorical) mountain.
- irbull 10y agoAlso (for a bit more history), I had already implemented the V8 / Java integration. I did this because we needed a performant JavaScript engine on Android, and Rhino just didn't cut it. Adding the Node integration was (theoretically) pretty easy, although because of how Node.js is linked on Windows, it gave me some headaches. Part of why I did the Node / Java integration was to see if there are any use cases. We'll see, I hope someone finds it useful, and if not, I learned a tone.