6 ms·

Question from a novice-ish developer: What is the purpose of porting things to the JVM? I had this idea before that porting things like Ruby or Rails to the JVM

Question from a novice-ish developer: What is the purpose of porting things to the JVM? I had this idea before that porting things like Ruby or Rails to the JVM was meant to offer ruby the advantages of having a java core (better threading, garbage collection, faster). But, as I understand it, Node is faster than JVM languages? What are the other advantages gleaned from porting? e: Thank you guys for the answers, definitely makes a lot more sense now.

jamesbritt 13y ago
Jruby lets your ruby code use any Java library and gui toolkit. This is quite useful. Also, if you work at a Java shop having stuff run on the JVM affords a way to sneak in new tech. :)
- moondowner 13y ago
  In my opinion (I'm a Java dev), the main benefits are being able to run RoR apps on TorqueBox[1] or some other JRuby server[2] and benefit the clustering, HA and other stuff that go with it; and 'the use of "true" native threads'[3]. [1] http://torquebox.org/ http://torquebox.org/ [2] https://github.com/jruby/jruby/wiki/Servers https://github.com/jruby/jruby/wiki/Servers [3] http://www.restlessprogrammer.com/2013/02/multi-threading-in-jruby.html http://www.restlessprogrammer.com/2013/02/multi-threading-in...
jmgrosen 13y ago
It seems like a major motivation for this project is to be able to use Java libraries from Javascript (a la Jython). There are a non-negligible number of libraries that only exist for Java, and being able to harness those from JS sounds nice to me, even if it means taking a performance hit.
- mmanfrin 13y ago
  Ohhhh, so one would just make like a node interface for some Java library, and it would be available for use in any JVMNode app? This makes a lot of sense.
dragonwriter 13y ago
> Question from a novice-ish developer: What is the purpose of porting things to the JVM? Interop with the things that already exist in the Java ecosystem. > I had this idea before that porting things like Ruby or Rails to the JVM was meant to offer ruby the advantages of having a java core (better threading, garbage collection, faster). To the extent that those were effects of porting Ruby to the JVM they were mostly secondary, Java interop was the key feature (Rails, BTW, wasn't ported to the JVM, it just runs anywhere you have a functional Ruby implementation -- heck, before Ruby had executable specs, the test for a functional implementation was pretty much "does it run Rails".)
deleted 13y ago
[deleted]
justinsb 13y ago
The JVM gives you very good JIT, GC, threading, manageability (profiling, debugging, memory inspection etc), scalability to huge machines, a huge ecosystem of software and has basically solved every real-world deployment problem. (Maybe apart from memory utilization!) It is definitely possible to beat the JVM on any one of these facets, but to consistently beat it on all of them is a _lot_ of work. (I'm not sure which benchmark you're referring to where Node beats the JVM, but I suspect it's relatively 'focused'.) To my mind, the idea of porting is that you face a choice: you can recreate the JVM functionality in your own runtime, or you can port to the JVM. Porting to the JVM is certainly non-trivial, but you then get thousands of man-years of work in return. It's certainly worth doing a project to see whether the porting effort pays off; especially if this done concurrently with working on the language's 'native' runtime.
- mmanfrin 13y ago
  Very thorough answer, thank you :]
- dmpk2k 13y ago
  but to consistently beat it on all of them is a _lot_ of work. As long as you aren't native, that is. Although that's unrelated to the discussion at large.
  - pcwalton 13y ago
    Even then it's not that easy. A non-optimizing C compiler will have a hard time beating the JVM's slew of optimizations.
    - erichocean 13y ago
      A non-optimizing C compiler Is there a C programmer on the planet that does production builds with a non-optimizing compiler? How is your comparison even remotely relevant to the GP?
      - bruceboughton 13y ago
jonny_eh 13y ago
Imagine that you just started a new job at a big company. It's a "Java shop". You're allowed to use any technology stack you want for your apps, and all the other apps have APIs, but there's hundreds of useful Java libraries that already exist for talking to these APIs. This would allow you to use NodeJS but still leverage the existing Java libraries, not requiring you to rewrite them.
pron 13y ago
Node is actually much slower than Java. True, the JavaScript implementation on the JVM is slower than V8 (even Nashorn, the new JavaScript engine included in Java 8). Of course, the main motivation is, as others have said, integration with the huge Java ecosystem, but being able to drop down to Java for performance (when you need it) is a lot easier than writing native V8 modules.
- dmpk2k 13y ago
  but being able to drop down to Java for performance (when you need it) is a lot easier than writing native V8 modules. There's a node-ffi package, although it has some overhead from the call itself. https://github.com/rbranson/node-ffi https://github.com/rbranson/node-ffi
ww520 13y ago
> But, as I understand it, Node is faster than JVM languages? What is the source for that?
Edmond 13y ago
Naive (and mostly ignorant) programmers make a habit of sh*tting on the JVM and the Java platform in general. My usual response regarding the merit of the JVM is this: there is a reason there's jvm on the server, desktop, on your phone, on the rovers on mars and god knows on how many mission critical systems. And no it isn't because of great marketing, which is another common and lame response from JVM detractors. The JVM is an impressive engineering effort and the eco-system spawned by it is currently unrivaled. With the new trend of porting other languages (ruby,python,js..etc) to it, the I see the JVM as the middleware over which most future software would be built.
peterashford 13y ago
Are you really claiming that Node is faster than Java? Source?
tootie 13y ago
Node is more adept at handling many concurrent requests due to its architecture but it's runtime is far slower than the JVM. The vert.x framework that is the basis for this project is based on a similar paradigm to node and is far faster.
MichaelMoser123 13y ago
to run it 'in the cloud'; most hosting places will allow you to run java only, this restriction is in place so that everything will seem secure and divided into neat compartments.

jamesbritt 13y ago

Jruby lets your ruby code use any Java library and gui toolkit. This is quite useful. Also, if you work at a Java shop having stuff run on the JVM affords a way to sneak in new tech. :)

moondowner 13y ago
In my opinion (I'm a Java dev), the main benefits are being able to run RoR apps on TorqueBox[1] or some other JRuby server[2] and benefit the clustering, HA and other stuff that go with it; and 'the use of "true" native threads'[3]. [1] http://torquebox.org/ http://torquebox.org/ [2] https://github.com/jruby/jruby/wiki/Servers https://github.com/jruby/jruby/wiki/Servers [3] http://www.restlessprogrammer.com/2013/02/multi-threading-in-jruby.html http://www.restlessprogrammer.com/2013/02/multi-threading-in...

jmgrosen 13y ago

It seems like a major motivation for this project is to be able to use Java libraries from Javascript (a la Jython). There are a non-negligible number of libraries that only exist for Java, and being able to harness those from JS sounds nice to me, even if it means taking a performance hit.

mmanfrin 13y ago
Ohhhh, so one would just make like a node interface for some Java library, and it would be available for use in any JVMNode app? This makes a lot of sense.

dragonwriter 13y ago

> Question from a novice-ish developer: What is the purpose of porting things to the JVM? Interop with the things that already exist in the Java ecosystem. > I had this idea before that porting things like Ruby or Rails to the JVM was meant to offer ruby the advantages of having a java core (better threading, garbage collection, faster). To the extent that those were effects of porting Ruby to the JVM they were mostly secondary, Java interop was the key feature (Rails, BTW, wasn't ported to the JVM, it just runs anywhere you have a functional Ruby implementation -- heck, before Ruby had executable specs, the test for a functional implementation was pretty much "does it run Rails".)

deleted 13y ago

[deleted]

justinsb 13y ago

The JVM gives you very good JIT, GC, threading, manageability (profiling, debugging, memory inspection etc), scalability to huge machines, a huge ecosystem of software and has basically solved every real-world deployment problem. (Maybe apart from memory utilization!) It is definitely possible to beat the JVM on any one of these facets, but to consistently beat it on all of them is a _lot_ of work. (I'm not sure which benchmark you're referring to where Node beats the JVM, but I suspect it's relatively 'focused'.) To my mind, the idea of porting is that you face a choice: you can recreate the JVM functionality in your own runtime, or you can port to the JVM. Porting to the JVM is certainly non-trivial, but you then get thousands of man-years of work in return. It's certainly worth doing a project to see whether the porting effort pays off; especially if this done concurrently with working on the language's 'native' runtime.

mmanfrin 13y ago
Very thorough answer, thank you :]
dmpk2k 13y ago
but to consistently beat it on all of them is a _lot_ of work. As long as you aren't native, that is. Although that's unrelated to the discussion at large.
- pcwalton 13y ago
  Even then it's not that easy. A non-optimizing C compiler will have a hard time beating the JVM's slew of optimizations.
  - erichocean 13y ago
    A non-optimizing C compiler Is there a C programmer on the planet that does production builds with a non-optimizing compiler? How is your comparison even remotely relevant to the GP?
    - bruceboughton 13y ago

jonny_eh 13y ago

Imagine that you just started a new job at a big company. It's a "Java shop". You're allowed to use any technology stack you want for your apps, and all the other apps have APIs, but there's hundreds of useful Java libraries that already exist for talking to these APIs. This would allow you to use NodeJS but still leverage the existing Java libraries, not requiring you to rewrite them.

pron 13y ago

Node is actually much slower than Java. True, the JavaScript implementation on the JVM is slower than V8 (even Nashorn, the new JavaScript engine included in Java 8). Of course, the main motivation is, as others have said, integration with the huge Java ecosystem, but being able to drop down to Java for performance (when you need it) is a lot easier than writing native V8 modules.

dmpk2k 13y ago
but being able to drop down to Java for performance (when you need it) is a lot easier than writing native V8 modules. There's a node-ffi package, although it has some overhead from the call itself. https://github.com/rbranson/node-ffi https://github.com/rbranson/node-ffi

ww520 13y ago

> But, as I understand it, Node is faster than JVM languages? What is the source for that?

Edmond 13y ago

Naive (and mostly ignorant) programmers make a habit of sh*tting on the JVM and the Java platform in general. My usual response regarding the merit of the JVM is this: there is a reason there's jvm on the server, desktop, on your phone, on the rovers on mars and god knows on how many mission critical systems. And no it isn't because of great marketing, which is another common and lame response from JVM detractors. The JVM is an impressive engineering effort and the eco-system spawned by it is currently unrivaled. With the new trend of porting other languages (ruby,python,js..etc) to it, the I see the JVM as the middleware over which most future software would be built.

peterashford 13y ago

Are you really claiming that Node is faster than Java? Source?

tootie 13y ago

Node is more adept at handling many concurrent requests due to its architecture but it's runtime is far slower than the JVM. The vert.x framework that is the basis for this project is based on a similar paradigm to node and is far faster.

MichaelMoser123 13y ago

to run it 'in the cloud'; most hosting places will allow you to run java only, this restriction is in place so that everything will seem secure and divided into neat compartments.