Hacker News new | ask | show | jobs
by randallsquared 4361 days ago
> You seem to be assuming that the only way to do JVM stuff is considering all the difficulties that enterprise Java shops with legacy projects put up with.

Ah, that's because that was the only place I've had much experience with Java and Scala. We wanted to use Elasticsearch (Java) from our CMS (Java), and the recommended way to do that (at the time: embedding ES in your application as a search-only node) turned out to be infeasible, due to ES and the CMS (which was started in 2006ish) being unwilling to share any specific JDK without a lot of code changes to the CMS. We ended up building a system involving RabbitMQ and a thousand lines of PHP, as the easiest solution. :(

So, yeah, I recognize that a lot of my bad feelings about JVM languages are not particularly relevant to green-field development, whether in Java or Scala. I just got ranty. Sorry.
1 comments
saryant 4361 days ago
Why wouldn't you just run ES as a standalone server and use its REST API? ES is a core part of the stack at the startup I work at and it never would've occurred to us to run it as an embedded service.
link
randallsquared 4361 days ago
You'd run the data nodes as standalone servers, but the recommended way to talk to ES from your Java app was, at the time, to embed ES as a non-data node in your app, which means that you could talk to ES in-process, and the local ES would be part of the cluster, just pass on queries and data to the data nodes. This was 2011 (0.18.x or 0.19.x, I think), so maybe that's not the recommended way any longer. The REST interface was also available, and recommended for anything that wasn't Java, and that's what we ended up using (but given the opportunity not to write the code that interfaced between database and ES in Java, we took it, and wrote that in PHP, with just a tiny bit in Java to push a job on the queue).

It looks like that's still what's happening in the Java API: http://www.elasticsearch.org/guide/en/elasticsearch/client/j... I'd like to reiterate that moving our app to a more recent JDK would have also been a good solution, except that we didn't have the dev and qa resources at the time to devote to that.

link