One Rick Bradley reports on a J2EE-turned-Rails project which is experiencing an amazing 1:25 ratio between trivial LOC counts between the two platforms.
That in itself isn't that interesting, however. I've already seen plenty of similar reports and my own experiments have hinted at something around that ballpark as well. What's interesting is that Rick needs nested transactions to implement certain regulatory requirements.
This gets us to the topic of Ruby on Rails and enterprise features.
We don't have nested transactions in the current J2EE spec but there are some workarounds available for implementing some kind of nested transactions in J2EE by hand. (Then again, how many times you've seen someone actually doing that?) As far as I know, there's no known workaround yet for implementing nested transactions with Ruby on Rails. That's a small advantage for J2EE. (Then again, I wouldn't be surprised if someone was already working on adding nested transaction support by now)
Another "enterprise feature" Rails is lacking is distributed transactions, i.e. two-phase commit. J2EE obviously has this but Rails is currently limited to simple transactions even though it is possible to split your domain objects to be persisted in multiple databases.
Authentication is another feature that people seem to have "extra" requirements for in enterprise environments. Again, Rails doesn't support Single Sign-On (SSO) out of the box but adding support for, say, perimeter authentication with SiteMinder and Apache should be as trivial as it is in J2EE.
I'd be interested to hear what other features you'd consider belonging to this "enterprise" category that Rails doesn't have (or you're not sure if it has).
I realize that you don't have similar trust to the Rails core team and the community in general as you might have in Oracle Corporation itself. Having said that, by not logging a ticket for those issues you're aware of you're not increasing the chance that those issues will be solved.
What's this "Oracle connector", by the way? Are you talking about ruby/OCI8? (Can you tell I'm not too familiar with the native driver stuff...) If I've understood correctly, both ruby-oci8 and Python's cx_Oracle are simply bridges for the OCI client provided by Oracle, right?
Oh, and in the Burton Group telebriefing with Richard Monson-Haefel, David Heinemeier Hanssen, David Geary, and Dave Thomas, David mentioned that they've been in talks with Oracle about them picking up the Oracle driver. Obviously that's just talk right now, but at least there's hope ;)
I thought about that JMS/JMX thing for a while. Here's what I figured out.
There's rjni which is a binding from Ruby to JNI. With that, you could do something like the following:
reflector = RJNI::Reflect.new sclass = reflector["com.foo.MyJmsClient"] client = sclass.new client.send(:message => "Hello", :topic => "CHAT")
That would require you implementing the JMS client itself in Java but you could then use the Java client from Ruby.
Getting away completely without any Java code between your Ruby code and the JMS provider would mean reimplementing a JNDI client which knows how to deserialize Java objects which would mean reading .class files from the JDK's tools.jar and converting those to Ruby classes, and doing the same the other way around, i.e. writing Ruby objects to a stream as serialized Java objects with all the class versioning intact and all.
Sounds like a lot of work to me, so maybe it would be worth it to try the rjni way first (or just implement a server-side XML-RPC or SOAP service that bridges to the JMS and poll that service with Ruby).
As for JMX, you'd again have to go through JNI or implement Java's RMI protocol in Ruby, or (if your JMX server supports it) the (optional) JMXMP protocol which is built on top of TCP using TLS and SASL for security.
Again, makes one wish someone else has implemented it for you already...