Is there a roadmap / timeline for ruby 2.x compatibility? I didn’t see
it
on the main website.
I haven’t seen any 2.x dependencies showing up, and I’m not sure how
major
the differences are.
Thanks,
Chris
Does it matter?
…R
While I don’t care about this issue in particular. I think it is very
important for an open source project to communicate with it’s user
community. It gives people confidence the maintainers have a plan and
are
still working on the project. The users of a project like JRuby are
themselves developers who need to plan their own projects and
understanding
the trajectory of the technologies they are building on is critical.
-Justin
Thanks Charlie for the clarification!
We are fully prepared that plans change, but it is comforting to know
the general intention.
I expect this will be picked up by Ruby Weekly 
On 2014-02-21, at 19:08, Charles Oliver N. [email protected]
wrote:
- JIT support for keyword arguments
I haven’t seen any 2.x dependencies showing up, and I’m not sure how major
–
Uwe K.
[email protected]
2.0 support is available in an experimental state in 1.7.x. We
generally aren’t working on it there, but we have fixed some small
bugs and missing features during 1.7 maintenance.
JRuby master, which will becoming JRuby 9000, supports only
2.1-compatibility. Most 2.0/2.1 features have been implemented, with a
few exceptions:
- Refinements
- Module#prepend
- JIT support for keyword arguments
- String#scrub
It is our intention to release 9k roughly Summer 2014 with full 2.1
support.
- Charlie
Although this has not been published on our lists of wikis we have been
giving talks for over a year where we iterate over the plan and the
status. I guess it looks obvious in retrospect it could be put
somewhere
as well 
-Tom
Great to hear.
Why, pray tell, is the next version called “9000” instead of, say, oh, I
don’t know, “2”?
On Fri, Feb 21, 2014 at 1:08 PM, Charles Oliver N.
We could think of no typical next-major-version number that wouldn’t
lead to confusion with MRI version numbers. 1.8, 2.0 both would
“conflict” with MRI version numbers…and be even more confusing since
“JRuby 2.0 supports Ruby 2.1”. Wat?
We considered pulling a Java and going from 1.7 to 8, but…meh.
The 9000 version number became a working title, and at present it
actually is the next major version of JRuby.
system ~/projects/jruby $ jruby -v
jruby 9000.dev (2.1.0.dev) 2014-02-21 b725465 on Java HotSpot™
64-Bit Server VM 1.7.0_45-b18 [darwin-x86_64]
Of course, 9000 is a pretty cool number too.
- Charlie
On Fri, Feb 21, 2014 at 11:04 PM, John Joseph B.
On Sat, Feb 22, 2014 at 4:20 PM, Rohit N.
[email protected] wrote:
“The 9000 series is the most reliable computer ever made. No 9000 computer
has ever made a mistake or distorted information. We are all, by any
practical definition of the words, foolproof and incapable of error.”
HAL
And of course JRuby 9000 will be perfect in every way 
- Charlie
Of course, 9000 is a pretty cool number too.
“The 9000 series is the most reliable computer ever made. No 9000
computer
has ever made a mistake or distorted information. We are all, by any
practical definition of the words, foolproof and incapable of error.”
HAL
On Fri, Feb 21, 2014 at 11:33 PM, Charles Oliver N.
<[email protected]
So it seems JRuby plans to remain subservient to MRI Ruby. Pity.
…R
Why do you say that? I believe we have done more to advance Ruby than
any
other implementation. We work with MRI because we wish to remain
cooperative members of the Ruby community.
- Charlie (mobile)
<< Ground control to Major Troll… Ground control to Major Troll… >>
Your past posts have been more than negative: I still recall your answer
“if you insist on doing things the hard way” when on the list we were
trying to help out a user on his bundler issues with jruby-complete. The
purpose of this mailing list is to help users and share experience, not
bash against the very same tool at the origin of this mailing list.
Quoting you again: “So it seems JRuby plans to remain subservient to MRI
Ruby. Pity.”
I’d say the exact opposite, and pity here to me becomes an offensive
word.
Jruby has saved the day many times over at my day work, where MRI would
not
offer me (for example) the SQL drivers to connect to some of our
internal
databases. This is where Jruby leads.
<< Ground control to Major Troll… Now it’s time to leave the capsule
if
you dare…>>
On Sun, Feb 23, 2014 at 8:12 PM, John Joseph B. <
Robin, what other path could JRuby take?
On Sun, Feb 23, 2014 at 3:55 AM, Charles Oliver N.
“Jruby has saved the day many times over at my day work, where MRI would
not
offer me (for example) the SQL drivers to connect to some of our
internal
databases. This is where Jruby leads.”
This is exactly my point. I can’t see why JRuby can’t stand on its own
feet as a much better product than MRI Ruby.
And JRuby makes it easy to develop applications that run on any PC just
by copying the application files. MRI Ruby can’t do that, and neither
can many other languages.
But from what I can see these unique strengths of JRuby are rarely
publicized. The emphasis always seems to be restricted to “is it
compatible with MRI Ruby xx.x?”
…R
But from what I can see these unique strengths of JRuby are rarely
publicized. The emphasis always seems to be restricted to “is it
compatible with MRI Ruby xx.x?”
I don’t think the two are mutually exclusive.
It’s called Jruby so of course it has to be compatible with ruby and
people
expect their ruby code to run un altered. If you want to hype jruby on
it’s own merits you have to look at creating gems or frameworks which
leverage all the jruby goodness. Torquebox is a great example of this.
There are opportunities out there to fill in the gaps in the ruby
ecosystem
with jurby, for example SOAP libraries. It might be cool to have a
jruby
specific framework too but frankly I don’t know what that would look
like.
If you want to eschew ruby look to Mirah I guess.
Hi there,
there are “Five notable incompatibilities” to 1.9.3 known of as of the
release of 2.0:
https://www.ruby-lang.org/en/news/2013/02/24/ruby-2-0-0-p0-is-released/
- and these are fairly minor (different default encoding for ruby
scripts being one of them). And "We have also taken care with the 2.0.0
design to make it compatible with 1.9. ".
E.g. 2.0 and also 2.1.0 are super compatible as far as I am aware of.
For my projects I run them with 1.9.3/2.0 and 2.1 without any issues.
2.x adds new features but in a backwards compatible way
Long story short, I love JRuby’s approach to this and am eagerly
waiting for 9k
Thanks to the JRuby dev team for their amazing work.
Cheers,
Tobi
Tom, Charlie -
Do you mean only 2.1, do you mean not 2.0, not 1.9, or both? Ruby 2.x
has been very slow to be adopted. In my informal surveys at user group
meetings, Ive found that < 10% of Ruby developers are using 2.x. I
havent looked very much into 2.x myself yet. Is it totally backward
compatible with 1.9?
When 1.8 was still in use in some places, I found JRuby a really
convenient tool for checking 1.8 compatibility. It would be handy to do
the same with 1.9. But I do realize that focusing on a single version
can simplify implementation, and that thats really important.
Thanks for all your hard work, guys.
- Keith
JRuby master, which will becoming JRuby 9000, supports only
2.1-compatibility.
Keith R. Bennett
On Mon, Feb 24, 2014 at 9:00 AM, Keith B.
[email protected]wrote:
Tom, Charlie -
Do you mean “only 2.1”, do you mean “not 2.0”, “not 1.9”, or both? Ruby
2.x has been very slow to be adopted. In my informal surveys at user group
meetings, I’ve found that < 10% of Ruby developers are using 2.x. I
haven’t looked very much into 2.x myself yet. Is it totally backward
compatible with 1.9?
We mean only 2.1 and no other version. From people I have talked to the
transition from 1.9.x to 2.x has been very smooth. I think the lessons
learned from MRI’s 1.9.1 release has made this transition easier. They
have worried quite a bit about migration from one version of Ruby to the
next.
We have been trying much harder to apply all 1.9+ fixes to both 1.7
branch
and master. I feel like maintaining these two branches for an extended
period of time will not be very difficult. We used to hate dual branch
maintenance but the frequent merging has simplified the job a lot. The
only downside is training PR submitters to consider which branch to PR
to.
Expect 1.7.x to last a long time if you cannot get off the 1.8/1.9
train.
Note that we will never support 2.0.x beyond experimental feature but
the
differences between 2.0 and 2.1 are really not large barring
refinements.
Even then that is a new feature and not one which would hurt someone
only
wanting a 2.0 feature set.
When 1.8 was still in use in some places, I found JRuby a really
convenient tool for checking 1.8 compatibility. It would be handy to do
the same with 1.9. But I do realize that focusing on a single version can
simplify implementation, and that that’s really important.
As I said above you can do that with an install of both JRuby 1.7.x and
JRuby 9000. It won’t be quite a convenient but it will still be
available
for those who need it (at least until most people do not use 1.8/1.9 and
then we will consider when to EOL 1.7).
-Tom
On Mon, Feb 24, 2014 at 10:13 AM, Thomas E Enebo
[email protected]wrote:
haven’t looked very much into 2.x myself yet. Is it totally backward
compatible with 1.9?
We have been trying much harder to apply all 1.9+ fixes to both 1.7 branch
and master.
Just want to make sure it is obvious that I mean 1.9+ fixes which still
apply to 2.1 since master will only support 2.1
-Tom