It seems the CRuby and JRuby versions are released with separate version numbering schemes. When looking for a gem to install, bundler will look for the latest version number, and if no matching -java version is found will try to install the CRuby version, which will fail due to the dependency on Oj and Msgpack.
An application author who is aware of this can lock to a working version, but for someone building gems that in turn depend on transit-ruby, this is problematic. I don't know which platform my users will be using, and so can't lock the version for them. This creates the impression that things are simply incompatible with JRuby, even though that's not strictly true.
The solution would be to always release a CRuby and a -java version at the same time with matching version numbers.
I just released transit-ruby-0.8.567-java, which aligns with the most recent CRuby release. Leaving this open until we automate releasing CRuby and JRuby gems together.
It seems the CRuby and JRuby versions are released with separate version numbering schemes. When looking for a gem to install, bundler will look for the latest version number, and if no matching -java version is found will try to install the CRuby version, which will fail due to the dependency on Oj and Msgpack.
An application author who is aware of this can lock to a working version, but for someone building gems that in turn depend on transit-ruby, this is problematic. I don't know which platform my users will be using, and so can't lock the version for them. This creates the impression that things are simply incompatible with JRuby, even though that's not strictly true.
The solution would be to always release a CRuby and a -java version at the same time with matching version numbers.