Nick Sieger: JRuby 1.0.3: No Java-based extension library backward compatibility

"JRuby 1.0.3: No Java-based extension library backward compatibility" by Nick

Wed, 02 Jan 2008 17:36:49 +0000

Shahfazliz, Kaj: looks like your problem has been tracked here too: JRUBY-1861. Please follow the updates there.

Christian: no, not really :). Despite the lack of mention of 1.4 on the jruby-extras page, the latest should be 1.4. Check and see the name of the goldspike jar file that gets installed when you create the war.

"JRuby 1.0.3: No Java-based extension library backward compatibility" by Kaj Hejer

Mon, 31 Dec 2007 23:57:21 +0000

Hi!

Did you solve your “private method...” error?

I have this issue too and filed a report about this, see http://tinyurl.com/285ph4

-Kaj :)

"JRuby 1.0.3: No Java-based extension library backward compatibility" by Shahfazliz Shahron

Fri, 28 Dec 2007 09:17:38 +0000

when i ran “jruby -S rake war:standalone:create” i get this error.. rake aborted! private method `makedirs’ called for File:Class is it because i’m using Goldspike 1.3? i’m using jruby 1.0.3 and i used the following command to install goldspike “jruby script/plugin install http://jruby-extras.rubyforge.org/svn/trunk/rails-integration/plugins/goldspike”

"JRuby 1.0.3: No Java-based extension library backward compatibility" by Christian Seiler

Fri, 21 Dec 2007 11:31:45 +0000

Is there an official homepage of Goldspike? The latest version on http://rubyforge.org/projects/jruby-extras is still 1.3

JRuby 1.0.3: No Java-based extension library backward compatibility

Nick Sieger — Wed, 19 Dec 2007 04:14:00 +0000

JRuby 1.0.3 just came out a couple of days ago. It was a decent point release; a handful of good bugs fixed. Normally a 1.0.3 release would not be all that exciting, but during this cycle, trunk’s internal API (upon which several JRuby extensions depend) started to diverge. Unfortunately, this forced us to face a decision: either fork and maintain two versions of every extension (one for 1.0.x and one for 1.1 and beyond), or break backwards compatibility.

We ended up choosing the latter, prefering a single schism to parallel version hell. It’s probably going to cause some pain for us (in number of support inquiries), and especially for those who might be looking casually at JRuby and trying it for the first time, for example via NetBeans. NetBeans 6.0 recently shipped with JRuby 1.0.2, which is now incompatible with the latest versions of several high-demand gems. Look for the 6.1 nightly builds to be fixed soon, and hopefully the 6.0.1 update can include the new release as well. (If you’re using NetBeans 6 and have run into this problem, you can download and unpack JRuby 1.0.3 and show NetBeans where it is.)

So when in doubt, grab the most recent JRuby release possible to minimize compatibility issues. To attempt to be as clear as possible about which versions work with what, I’ve included a table below. I’ll fill in with updates as I receive them, and let me know if a piece of software you use isn’t mentioned, but should be.

	JRuby Version
	1.0 - 1.0.2, 1.1b1	1.0.3, 1.1b2
Library
rubygems	<= 0.9.4	<= 0.9.4, = 1.0 *
rails	<= 1.2.6, >= 2.0.x †	any
activerecord-jdbc	<= 0.6	>= 0.7
jruby-openssl	<= 0.0.5	>= 0.1
goldspike	1.3	1.4
mongrel	any ‡	1.1.2

* Rubygems 0.9.5 may not be compatible with any JRuby version; we won’t ship it with a release
† requires jruby-openssl (0.0.5 or earlier) to be installed
‡ combination needs testing with JRuby 1.0.2 and Mongrel 1.1.2

Other libraries not mentioned here, such as javasand (JRuby version of freaky freaky sandbox) or jparsetree (JRuby version of ParseTree) will also likely need updating for 1.0.3 and 1.1. For library authors needing a hint for which way to go, here are some pointers to our temporary bridge API.

Lessons learned? An extension API and migration strategy might be normally be a good thing to nail down before a 1.0 release. Hopefully, you’ll forgive us that blunder this one time, and we’ll make sure to get this mess cleaned up in a future 1.x release, and any pains you had to go through with version incompatibilities will be soothed by the continual high-quality releases we’ve been able to craft.