Incorporate JRuby bits into pg gem

[headius]

Copying @ged, @jvshahid.

I think we're at or close to a point where we could release this as a -java version of the pg gem. There are still many libraries and applications that depend on functions the pg library provides that JDBC does not.

@ged Are you interested in working with us to get a -java version of the pg gem made? As I see it, the only requirements are the following:

• Incorporate the Java sources into your repository, so they can be built and tested in place.
• Release a -java gem whenever there's a new pg gem release.
• Keep features/bugs in sync.

We would obviously continue to support the Java version of the gem, and we do not expect you to take that over.

@jvshahid What remains before you would be comfortable releasing this? I know you had been looking into ActiveRecord tests when we paused a few months ago.

[jvshahid]

The active record tests look good. Last time i ran it i had 6 failures and 2 errors (out of 3787 tests). Ideally I'd wait until I fix those failures, but I'm swamped and I also don't think they're blockers. The other thing I'd like to take a look at is performance. Running the ActiveRecord test suite on JRuby is many times slower than running it on MRI. I think I'll focus on that one as soon as I have time. Again, I don't feel either one of these problems is a blocker.

[ged]

Hi!

When @headius mailed me back in November about this, I replied with some concerns about merging the two, and I still have some of the same concerns. I'll repost my reply here with some edits to reflect the changes in the jruby-pg codebase since then:

I agree that whatever we come up with should make it as easy as possible for the user who wants to install a gem to talk to Postgres, so with that as our guide, I'm sure we can come up with some arrangement.

A couple of questions/issues to think about:

• Since 'pg' is in Mercurial and tracked (primarily) on Bitbucket, does that mean the JRuby version will be as well? Or would we be expected to switch to git/Github? This may be a non-issue, as @larskanis uses the Github mirror for his development and so far merging has been pretty easy.
• Since they're effectively different codebases, how does error-reporting get to the right people if it's all hosted together? We could probably do quite a bit of it via components and/or versions in the issue tracker, but there will be the inevitable people that don't know which version they're using, and will require some guidance.
• How would versioning work? If we push a bugfix for the C ext, does the JRuby ext bump its version to match and re-release, even if no change was required? And vice-versa?
• I haven't looked closely yet at the API of the JRuby ext; is it API-compatible with the C ext? Is intended to be? If so, how are changes to the API coordinated? If we make a change to the C ext, do we wait for you to catch the Java part up to it before releasing? And vice-versa?

While we have some significant things to figure out, I don't think any of it is insurmountable. I'm excited for JRuby users! @jvshahid's contribution is an impressive body of work, and I'm happy to help in whatever way I can to get it out there so folks can use it.

I'm looking forward to working with you both.

[jvshahid]

Things has been quiet for some time. So let me add my input on some of the open questions:

• Regarding source control, I don't have any strong opinion about the source control software we can use mercurial and fallback to the github mirror if someone doesn't like bitbucket/mercurial work flow.
• I am a core commiter on the nokogiri team, working on the JRuby implementation. It was never the case that the reporter of the problem didn't know which ruby they are using. It is always clear whether the bug happens in MRI, JRuby or both. At this point the issue is labeled accordingly and either a person is assigned or pinged in the comments to take a look at the bug. The workflow is pretty smooth in my opinion.
• Regarding versioning, again using nokogiri as a good example, the entire code base is tagged and packaged. There were cases when users on mri or windows (one incident with JRuby) had problems with the released gem and a minor patch had to be pushed out for all three implementations although only one or two were changed. In short, it's fine to bump the version even if only one implementation was changed.
• Regarding the api. Yes, definitely. The entire build scripts, tests were copied from the ruby-pg repo. When the api wasn't clear about parameters meanings or return values, i always went back to the ruby-pg and libpq docs. The whole point from this gem is to be a drop-in replacement for ruby-pg on JRuby.

I hope I provided satisfactory answers to your questions.

Looking forward to work with you as well.

[jvshahid]

See ged/ruby-pg#1