As JRuby guys jump ship, what does that say for future of Java under Oracle?

I've been mulling over the implications of the news that Sun's JRuby team leaders, Charles Nutter and Thomas Enebo, are leaving Sun because of uncertainty about the future of their project after the Oracle acquisition. They will be joining Rails specialist Engine Yard. This is the key quote from Nutter:

To be honest, we had no evidence that Oracle wouldn't support JRuby, but we also didn't have any evidence that they would.

JRuby is by all accounts excellent - I'm aware that developers at ThoughtWorks use it, and Ruby advocate Martin Fowler (who works there) told me that it works very well for them, observing that some enterprises who would be reluctant to deploy the native Ruby runtime are more comfortable with running Ruby applications on the JVM (Java Virtual Machine). It is foolish of Oracle to let the JRuby guys slip away, particularly bearing in mind the trend towards dynamic languages (like Ruby) rather than static-typed languages (like Java).

What does this suggest about the future of Java itself under Oracle's stewardship? If Oracle could have done more to reassure Nutter of its continuing commitment to JRuby, so too it could do more to reassure the rest of us that investment in Java and its community will continue as strongly under Oracle as it did under Sun. Maybe it will, maybe it won't; though culturally I suspect the new company will be averse to Sun's habit of investing heavily in projects with little obvious potential for direct revenue. The failure to monetize Java fully, along with the failure of its bold experiment in open source, is one reason for the acquisition itself.

That does not imply that Java will go away - Oracle itself is a heavy user, and defending its future was likely a factor in its willingness to purchase Sun. Still, it would not be surprising if the community is a little less warm, and Oracle's investments more focused on its own needs rather than those of the wider platform.

Despite Oracle, there is no reason to be gloomy about Java's future. There is another way to look at the move of the JRuby team, which is that they've found a way to continue working on the project with or without Oracle's support. Java is bigger than Oracle, just as it was bigger than Sun. 

IBM worked tirelessly to free Java as far as possible from Sun's control, developing its own JVM and creating the Eclipse tools project to foster alternative tools and frameworks. Those efforts will have a new context and relevance.

Maybe Oracle will do great things for the Java platform. Maybe it will do little, and momentum will shift to those outside the home company. Either way, investment in Java development is as safe as anything can be in our uncertain industry.

 

 

0 TrackBacks

Listed below are links to blogs that reference this entry: As JRuby guys jump ship, what does that say for future of Java under Oracle?.

TrackBack URL for this entry: http://www.itjoblog.co.uk/blogadmin/mt-tb.cgi/110

2 Comments

Hi Tim,

good roundup about the issue. I think that the switch is good for Java, JRuby, and for the developers regardless if Sun or Oracle was behind it. Sun did a great job for developing JRuby and make it rock. Sun was always about the technical things, but never quite understood how to reach the community, and I don't expect more from Oracle. On the other side, Engine Yard is involved in the Ruby/Rails community and know how it works. So, from my perspective, this is the chance that JRuby now gets widely accepted by the community which is great.

infernoz said:

There is no significant trend to dynamic languages, just a very vocal minority who don't have to maintain large systems, or work to tight deadlines, with minimal faults. Ruby has already been seriously critiqued by ex-insiders, particularly for Rails!

As one commentator on Artima stated, static compiler checks give you numerous checks for free, it would take quite significant extra work, and discipline, to implement those in unit tests for dynamic languages.

I generally find that dynamic code actually takes longer to develop, including testing and debugging than static code, this especially applies to GUI code, which can be quite difficult to test automatically.

So BS on this article about fad language developers.

Leave a comment

Current Vacancies from CWJobs

(* Required field)










Preferred format