In a recent thread I questioned whether it mattered if there was a roadmap to MRI Ruby 2.x compatibility and later I said "So it seems JRuby plans to remain subservient to MRI Ruby. Pity." Among the replies someone said "what other path could JRuby take?". And Charles Nutter said "I believe we have done more to advance Ruby than any other implementation". I have great respect for Charles and I don't disagree with his claim. But I firmly believe that JRuby can be much more than it is. I didn't pose my original question because I object to the changes being implemented in MRI Ruby 2.1 - I have no idea what they are (I have not out-grown JRuby 1.7 yet). But I was trying to get the JRuby community to question its own direction. It seems to me the focus for the JRuby community is on compatibility with MRI Ruby rather than on JRuby as a product in its own right - a product which should follow its own future development path (which may or may not include compatibility with MRI Ruby). It only needs to be a useful tool for programmers. What would be wrong with a future in which MRI Ruby strives to be compatible with JRuby. Even now that would be a much greater challenge considering the breadth of JRuby's capabilities. To my mind there are three great strengths of JRuby that are hardly ever mentioned. It is trivially easy to install on any PC that already has the JVM installed (though the standard installation is not nearly as simple as it could be). It can easily be used to produce GUI programs by drawing on the underlying JVM. And most apps written in JRuby will run unchanged on any other PC just by copying the project so they can easily be distributed to non-expert users. The only external dependency is the JVM which many PCs already have installed. By contrast, "Aunt Mary" would find it impossible to install an MRI Ruby application. These features should make it very attractive to beginners to programming and to anyone who wants to create a cross platform GUI app but no effort seems to be made to reach those markets. The underlying assumption seems to be that people (experienced programmers) find JRuby after they find MRI Ruby (probably by way of Rails). I understand that the developers of JRuby are much better and more knowledgeable programmers than I could ever hope to be. But sometimes experts are too focused on their expertise to see the wider world. ...R
on 2014-02-25 17:42
on 2014-02-25 21:37
Bonjour Robin (sorry for my bad english: you'll have to guess what I mean ;-) Another strength of JRuby you didn't mention is that JRuby **is** a Ruby interpreter. So if I write a native (MRI) ruby script, it can easily be ported on the Java plateform. In fact, several years ago, I switched from Groovy to JRuby only because Sun decided to support the JRuby project. So I could count on one same language either on the Java plateform or some native plateform. If Groovy had a native version like MRI, I'd probably never go for (J?)Ruby. And if JRuby is no longer compatible with Ruby, it loses its main interest because there are already exists numerous other nice languages for the JVM. Regard, -- Maurice Le 25 fvr. 2014 17:42, Robin McKay <firstname.lastname@example.org> a crit :
on 2014-02-25 23:54
I think this is a matter of priorities. The Jruby team is and should be concentrating on making a viable ruby interpreter and are doing an excellent job of it. The rest of the stuff you are talking about are an ecosystem that grows around the language. There are already frameworks built around SWT and Swing, there is shoes which is being ported to jruby, etc. The people who work on jruby should work on making the most awesome, fastest, leanest, meanest ruby interpreter possible. It's up to the rest of the community to build on that base.
on 2014-02-26 09:24
Let's chime in as someone who spends most of the time with Ruby community gardening. I think this is misguided on many levels. First of all: MRI isn't bad per se, widely used and - despite its problems with concurrency - still a very usable piece of software. I question the triviality of installing JRuby somewhat. Ruby installs using a standard "./configure && make && make install" process and I see "Aunt Marys" (what is that, in any case?) doing that all day. It fits on UNIX systems very nicely, as good as JRuby fits in JVM environments. The easy distribution is a fun thing, I know that the Shoes team is struggling with that for month now. I know far more successful projects vendoring MRI than a JRuby. (e.g. Vagrant) Details aside, what would be wrong with a future where MRI strives for JRuby compatibility? Everything. JRuby is finally making a effort for being fully compatible with Ruby 2.1. So we finally, after years, reach a point where both implementations are on the same level, language-wise. Then deciding to take over the language development would be a disservice to the community that I don't think will be very welcome. JRuby, in my opinion, is more successful than similar projects like Jython because the team is humble, very constructive, cares about compatibility a lot and has a long breath. Also, they are not shy of any discussions with the MRI team, see the long discussions about Refinements that ultimately led to something usable. I am also under the impression that JRuby serves users first and then plays politics. The ability to get Ruby code working on and off the JVM without many assumptions about JRuby and MRI is one of the big strengths of the Ruby environment. Another project going mental and deciding to build their own Ruby interpretation doesn't sound like a good future, community- wise. We don't need a JRuby X and I would never touch it. I'd prefer a future where the MRI and JRuby team plan new things together better. Also, as final note: I like the direction where Ruby is going language-wise, so I don't see a need for someone taking over in any case. Best, Florian : I am running a beginners board and training beginners. : Except some runtime features, e.g. C exts.
on 2014-02-26 10:42
I should add that stackoverflow is filled with questions about why some gem that depends on native libs isn't installing. On the Mac there is a series of hoops you have to go through installing xcode or the xcode tools and then a bunch of brew installs before you can install a database gem or nokogiri or anything else. On windows it's even worse. This is where jruby makes a big difference because there is no compilation step and it "just works".
on 2014-02-26 10:48
Hi Tim, the "just works" part is relative: If you want to use gems that use native extensions on jruby, those will require the same series of hoops to jump through. However, you can distribute prebuilt binaries for all gems that require native extensions if you're so inclined. Tokaido (Rails Installer) and Vagrant both manage to do that just fine. No brew, no compiler, it "just works", even when using MRI. So if you want to distribute pre-built applications that require only a single "install me that" step, you can do so. Installing a development build or a development environment is much more involved, but that's a different thing. Regards Felix
on 2014-02-26 14:02
I second this post, especially the final note. Well nailed. One should consider the difference between the "wider world" and the practical world (ie the reality vs wild imagination or dreams). I for one started with ruby when rails was not even baking. At that time we did not even have the ruby gems system. Gems and rails changed the ruby ecosystem. From a community of specialized developers, it grew and grew. Maintainability and sustainability became important, especially with gems containing extensions. Hence ruby gems has to have a better dependency management (bundler). We saw other ruby implementations appear. Many... Each single one of them is a follower of MRI. Jruby is one of many, and even though it has many java advantages (wide java library, 1st class garbage collector, superior threading capabilities, etc...), it suffers from lack of publicity (success stories), it lags sometimes on compatibility with MRI and has unfortunately still a small audience. Many devs discover jruby by mistake or by chance. Many are trying the latest version of rails with jruby, and though rails is just the tip of the iceberg, any jruby lag with MRI or any jruby incompatibility will be a bad publicity. I do not see how MRI could be so influenced by any of its offsprings. Again jruby is just one offspring out of many. Making jruby a reference development platform for rails might give us more weight or publicity. I really mean reference, not just rails X supports jruby Y. We should not change the plans decided by the main developers team. Keeping up the compatibility with MRI and its lead products/gems is the sanest way forward.
on 2014-02-27 00:23
Vagrant is good for development but I don't think people will want to run each app in it's own virtual machine. Docker is more suitable for that kind of thing. In my case the devs use Macs (mostly) but the deployment is on linux so the gems have to be compiled for both Mac and Linux. If one dev adds a gem another dev has to install the external dependencies to install that gem via brew. If we were using jruby it would be a jar and it would work on both linux and mac. I haven't found too many gems that won't work on jruby. Jazz Hands is the only one that comes to mind immediately
on 2014-02-27 15:32
One thing I havent gotten to work with JRuby iscurses! I dont imagine anyone else in the world needs this to work, but Im writing software to test network servers that are headless machines we ssh into for terminals. I have a long running program, and wanted the users to see lots of pieces of status information as the program does its thing. curses was the best thing I could think of. Its really clunky and I tremble at the thought of being asked to add more information to the screen, since everything is absolute positioning. Anyone know of a better text mode windowing library? I used to use Vermont Views about 20 years ago, but that was a C library and Id rather not deal with writing a wrapper for it (if I could find it at all at this point in time). In my code I check to see if Im running under JRuby, and do not provide the full screen interface if so. - Keith
on 2014-02-27 15:38
Keith, Someone recommended this library to me recently and it is still being actively maintained: https://code.google.com/p/lanterna/ FFI bindings to libcurses also seems like it could be worth the effort. I have not used curses from C in decades but I don't remember it being a huge API. -Tom
on 2014-05-27 05:52
I've been using jruby for two years, and I want to add my two cents that it's more than a Java version of MRI. I've led two teams building big production applications with it: 1. www.mlife.com -- built in jruby with Rails, tying into a very fast java-based ESB. It handles millions of requests a day and doesn't break a sweat, with amazing uptime. 2. A new project that I'm working on for a large scale multi-user real-time system that fuses together jruby with Akka and scala. We've built first class Akka actors in jruby, some of which include components of Rails (such as ActiveRecord). jruby, for us, isn't just ruby built in java -- it's a fusion of ruby onto the jvm that lets us open/extend any java class and build incredibly powerful multi-threaded apps that scale. I've been building high volume distributed systems for over two decades. I laugh when I hear statements like "ruby doesn't scale." Anyone that says that doesn't understand two things: Firstly, languages don't scale, architectures do, and secondly : jruby. jruby rocks. - Russell
on 2014-08-31 15:42
on 2014-08-31 17:30
Fred - I'm sure the JRuby team understands the benefits of compatibility with the latest versions of Ruby. As I see it, their efforts to bring Ruby to the JVM, even without full 2.1 compatibility yet, are already heroic. JRuby is an open source project with limited resources; and the authors are individuals with limited amounts of time. As for me, I write mostly gems, and I choose *not* to use new language features, not only so that I can run JRuby, but also so that the users of my gems can run them even if they are using older (yes, unsupported, I know) versions of Ruby. (I currently draw the line at 1.9, using 1.9+ features.) You might want to consider this if you want your code to be runnable inside other Ruby code (that is, if you want your Ruby code to be callable in Ruby as opposed to only running on its own.) To me, the newer features are not that compelling as to justify my losing those benefits. Of course you're right that it would be better to have that 2.1 compatibility now, but please understand that resources are limited and acknowledge the effort that has already been made by the JRuby team. - Keith Keith R. Bennett http://about.me/keithrbennett