18 ms·

Why are you doing that? Jruby has been a complete ecosystem in itself and very few MRI specific gems need porting over. You could spend a whole bunch of time o

Why are you doing that? Jruby has been a complete ecosystem in itself and very few MRI specific gems need porting over. You could spend a whole bunch of time on this and actually not make an impact on people who actually use jruby in production EDIT: now that I think of it, there's one extension that would be very useful - libgit2 + Rugged.

AlphaSite 11y ago
The same system is used by Graal.js and the other languages for their native extensions.
nirvdrum 11y ago
The Truffle backend in JRuby+Truffle uses a different class hierarchy that makes supporting the Java extension API tricky. It's certainly doable and we haven't ruled it out, but the API parts of JRuby really need to be ironed out first. Right now it's essentially anything that's public in JRuby core, which is a bad situation to be in. Various attempts at rectifying that have predictably broken third party code, so it needs to be handled with care. Of course, rather than trying to fix the general problem, we could support the most common JRuby gems out there or the core subset of the API they use. These are just the sorts of things we need to look at a bit more.
- sandGorgon 11y ago
  thanks for replying. What you are talking about is potentially a big issue. Like it or not, the biggest usage of jruby is in running Rails. Unlike jython, which not a lot of people use, jruby is extremely popular. one of the reasons for its popularity is the way it can be hosted using Tomcat or build a jar and drop it in a container ... a nice little trojan horse into the world of enterprisey software. I would be very excited for Truffle+Jruby if it outperforms in this usecase. Where do you envision Truffle/Jruby being used - as a dropin replacement for MRI or for JRuby ? Or are you thinking of a third ecosystem around this project ?
  - nirvdrum 11y ago
    One of our stated goals is to run code is to run code without modification, including extensions. We have no intention of creating a third ecosystem. However, with Truffle's polyglot interface, someone certainly could write a JRuby+Truffle specific extension -- that's just not our general plan for extensions. Early in its life, JRuby+Truffle was a separate project and its goal was to run everything MRI can. Thanks to efforts on both the JRuby and Oracle sides, the project was open-sourced and merged with JRuby. That brought along a ton of benefits for us, but did open the JRuby ext. can of worms. I'm trying hard to answer your question without committing to solve a problem we haven't looked at in depth. I suspect we'll wind up supporting some portion of the JRuby ext. API, but whether that ends up via an alternative implementation, a sandboxed JRuby runtime, a bytecode processor using something like a hypothetical TruffleJava, or something entirely different, I don't know. We've had enough pure Ruby code to try to get working that we've been able to defer the extension discussion for a bit. Having said all that, to really get the benefits of JRuby+Truffle you're going to want to use Graal. While JEP 243 [1] should make deployment scenarios much easier starting with Java 9, you'll probably still need to coordinate with your ops team since the JAR needs to be on the bootclasspath. That's really just to say that you won't be able to just drop the JRuby JAR in and get optimal performance -- there's still going to be a second step that you might not be able to "backdoor" into your stack. [1] -- http://openjdk.java.net/jeps/243 http://openjdk.java.net/jeps/243
    - sandGorgon 11y ago
      hi - thanks for taking the time to answer. Look, I appreciate the engineering, but I'm genuinely curious if you think taking the JVM + building a MRI-compatible stack with C-transpilation is the perfect first order goal. I'm not sure why you refer to Jruby ext api as a can of worms - perhaps there is some VM level dragons that I'm not aware of... but the Jruby ecosystem is brilliant. I built my first software services startup on top of Jruby - custom enterprise software that runs on Tomcat (the idea came from Mingle - a JRuby based enterprisey Basecamp from Thoughtworks) Even in a general usecase, Jruby is brilliant when used with Puma. This deployment is unbeatable by any other ruby server. However, startup times in the java world is definitely a pain.. which is why developers tend to use MRI. In fact I know lots of developers who develop in MRI and deploy in jruby. I think if you decide to take the direction of building a jruby compatible implementation with MRI beating startup times and with even one fourth of the performance you are talking about... tell me where to sign the cheque ;)

AlphaSite 11y ago

The same system is used by Graal.js and the other languages for their native extensions.

nirvdrum 11y ago

The Truffle backend in JRuby+Truffle uses a different class hierarchy that makes supporting the Java extension API tricky. It's certainly doable and we haven't ruled it out, but the API parts of JRuby really need to be ironed out first. Right now it's essentially anything that's public in JRuby core, which is a bad situation to be in. Various attempts at rectifying that have predictably broken third party code, so it needs to be handled with care. Of course, rather than trying to fix the general problem, we could support the most common JRuby gems out there or the core subset of the API they use. These are just the sorts of things we need to look at a bit more.

sandGorgon 11y ago
thanks for replying. What you are talking about is potentially a big issue. Like it or not, the biggest usage of jruby is in running Rails. Unlike jython, which not a lot of people use, jruby is extremely popular. one of the reasons for its popularity is the way it can be hosted using Tomcat or build a jar and drop it in a container ... a nice little trojan horse into the world of enterprisey software. I would be very excited for Truffle+Jruby if it outperforms in this usecase. Where do you envision Truffle/Jruby being used - as a dropin replacement for MRI or for JRuby ? Or are you thinking of a third ecosystem around this project ?
- nirvdrum 11y ago
  One of our stated goals is to run code is to run code without modification, including extensions. We have no intention of creating a third ecosystem. However, with Truffle's polyglot interface, someone certainly could write a JRuby+Truffle specific extension -- that's just not our general plan for extensions. Early in its life, JRuby+Truffle was a separate project and its goal was to run everything MRI can. Thanks to efforts on both the JRuby and Oracle sides, the project was open-sourced and merged with JRuby. That brought along a ton of benefits for us, but did open the JRuby ext. can of worms. I'm trying hard to answer your question without committing to solve a problem we haven't looked at in depth. I suspect we'll wind up supporting some portion of the JRuby ext. API, but whether that ends up via an alternative implementation, a sandboxed JRuby runtime, a bytecode processor using something like a hypothetical TruffleJava, or something entirely different, I don't know. We've had enough pure Ruby code to try to get working that we've been able to defer the extension discussion for a bit. Having said all that, to really get the benefits of JRuby+Truffle you're going to want to use Graal. While JEP 243 [1] should make deployment scenarios much easier starting with Java 9, you'll probably still need to coordinate with your ops team since the JAR needs to be on the bootclasspath. That's really just to say that you won't be able to just drop the JRuby JAR in and get optimal performance -- there's still going to be a second step that you might not be able to "backdoor" into your stack. [1] -- http://openjdk.java.net/jeps/243 http://openjdk.java.net/jeps/243
  - sandGorgon 11y ago
    hi - thanks for taking the time to answer. Look, I appreciate the engineering, but I'm genuinely curious if you think taking the JVM + building a MRI-compatible stack with C-transpilation is the perfect first order goal. I'm not sure why you refer to Jruby ext api as a can of worms - perhaps there is some VM level dragons that I'm not aware of... but the Jruby ecosystem is brilliant. I built my first software services startup on top of Jruby - custom enterprise software that runs on Tomcat (the idea came from Mingle - a JRuby based enterprisey Basecamp from Thoughtworks) Even in a general usecase, Jruby is brilliant when used with Puma. This deployment is unbeatable by any other ruby server. However, startup times in the java world is definitely a pain.. which is why developers tend to use MRI. In fact I know lots of developers who develop in MRI and deploy in jruby. I think if you decide to take the direction of building a jruby compatible implementation with MRI beating startup times and with even one fourth of the performance you are talking about... tell me where to sign the cheque ;)