Michael Neale wrote: > Thanks for taking the time to reply Charles ! Things are much clearer > now. > > FWIW - I think your approach to making jruby first class Ruby is and > was the right approach. And the remaining 10% to get the smoother java > integration like groovy has will certainly happen. > With all due respect to Charlie and his team (and I do have the deepest respect for him and Thomas), if the world was on the Ruby bandwagon I'd agree. However the world is on the Java bandwagon and this make the Java integration portion even more important. But with only 2 guys working on it, it's hard to expect the world! > "I was putting in solid 14-hr days just to keep up with bug fixes, > community support, and internal fixes for other projects. It was too > much. " > This is insane.. and the fact that Sun couldn't convert business from it is also disappointing. Revenue could have lead to more resources.
I'm sure that this was a painful decision but no doubt the uncertainty created by Oracle isn't helping. One can see the same confusion existing between the JRocket team and the Hotspot team. They both desperately want to talk to each but are not allowed to until the merger is executed. One has to wonder will the sideline JRocket after all the money that Oracle has invested into making it a viable alternative (after BEA let is sink and stink). No doubt these are trying times for all involved. Regards, Kirk >> 1. Why leave Sun? >> >> First off, this was a painful decision for all of us. We loved working >> at Sun, we loved the environment and our coworkers, and we loved being >> able to say we were part of the company. It took us two months to >> finally make the decision after lots and lots of discussion and >> debate. Hardest career decision I've ever had to make. So we've >> considered every detail brought up on this list, discussed on other >> forums and blogs online, and many you all might never know about. >> Exhaustive analysis. >> >> Ultimately, it came down to a few key things for me: >> >> * In the three years we were at Sun, we never received any new >> resources on the project. Our head count stood at 2.25, never growing >> nor shrinking, even while more and more people started using JRuby. We >> also had a heavier and heavier load supporting Sun's JRuby-related >> projects like NetBeans, GlassFish, Kenai.com, and others. At one point >> I was putting in solid 14-hr days just to keep up with bug fixes, >> community support, and internal fixes for other projects. It was too >> much. >> * It's not just that we didn't know about the future. It's that we had >> no positive indications from Oracle that there was any future to be >> had. Some have said "why wouldn't Oracle support JRuby?" To them I ask >> this: how much of Oracle's product portfolio talks about alternative >> language support? We couldn't actually communicate with Oracle, and we >> certainly didn't have any solid facts to go on, but the general >> feeling was trending in a bad direction. >> * I've spent the last three years trying to convince Rubyists and >> JRubyists that Sun's not evil, Sun won't support their own products to >> the exclusion of others, Sun won't try to gouge them for support >> dollars, Sun really cares about developers and about doing the right >> thing. Now replace every occurrence of "Sun" in that sentence with >> "Oracle" and you can see how exhausting it would be to have to start >> all over again. And that's assuming those statements are actually true >> of Oracle... >> * After spending a year in meetings to set up a commercial JRuby >> support offering, we still had nothing. We on the JRuby team were >> prepared to do commercial support a year ago, and in all that time, >> through probably a dozen meetings, there still was no commercial >> support offering a year later. Meanwhile we had JRubyists practically >> begging to pay us for targeted bugfixes, flying in a JRuby dev for a >> day, and much more...but we couldn't do anything. It was very >> frustrating. >> >> Moving to EY immediately gives us Nick Sieger fulltime, the first >> resource bump we've had in three years, and likely more resources >> added to the project in the near future. It gives us access to the two >> busiest Rails core developers, so we can make sure Rails 3 fits well >> into the Java/JRuby ecosystem. It gives us a much better chance to put >> JRuby support into play. And it gives us a backer that's solidly into >> Ruby and Rails; we know exactly where their loyalties lie. Even >> better, it allows us to provide community support for all JRuby users, >> from JBoss to Oracle to IBM to Google. And I'm able to finally work on >> JRuby for Android again. >> >> 2. JRuby's Java integration priorities >> >> Make no mistake, we've worked hard to make JRuby a cracker-jack Ruby >> implementation *first*. We have always believed that in order for >> JRuby to succeed, we needed to be the best possible Ruby >> implementation before other priorities. That has meant long hours of >> testing (and writing tests), reading C code, debating features and >> optimizations, and slowly, slowly achieving compatibility. With the >> JRuby 1.2 release, we made a big compatibility push, fixing over 300 >> bugs, pushing over 1000 commits, and finally feeling like >> compatibility was a "solved" problem. >> >> This does not mean we have ignored Java integration in any way. For >> over two years, you've been able to call any Java library, implement >> any interface, extend any class using Ruby code. That's probably 90% >> of integration right there. People are using JRuby's Java integration >> to build desktop applications, wire libraries into Rails and other >> frameworks, and even in one case to build a point-of-sale terminal for >> aircraft refueling at a major international airport. JRuby's Java >> integration works great, and we've continued to improve it and support >> it all along. >> >> Now, with compatibility mostly "solved", we're increasing our >> attention to Java integration needs. We're going to solve the >> remaining gaps in that "10%" of usage: making Ruby classes usable as >> normal Java classes, supporting Java signatures and annotations, >> building an offline compiler that can produce real .class files that >> look and feel like normal Java classes, and basically removing all >> roadblocks preventing you from dropping a bit of Ruby code into an app >> where Java code used to be. There's a bit of work to do, but already >> we've accomplished a lot: >> >> * Ruby2Java is a prototype offline compiler that produces normal- >> looking Java classes backed entirely by Ruby code >> * At runtime, any Ruby class can be promoted to a Java class and used >> in java.lang.Class-aware frameworks. Hibernate and JUnit are two >> frameworks already proven to work with this feature. >> * Annotations and Java signatures can be specified in a number of >> ways, ultimately getting wrapped up in nice Ruby APIs. Here's a simple >> Hibernate example from the prototype work: >> >> class Event >> extend Hibernate::Model >> >> hibernate_attr :id => :long, :title => :string, :date => :date >> >> hibernate! >> end >> >> And bing! you have a real live Hibernate model using a Ruby class. >> >> * JRuby is working on Android, both through the Android Scripting >> Environment and through my own work to make Ruby a first-class Android >> app language. >> * JRuby can work on CDC+PBP JavaME devices (Blu-Ray and JavaTV, for >> example) via the jruby-cdc project. >> * JRuby is the first language to have integrated invokedynamic...and >> to have done it in a single codebase without breaking Java 5 >> compatibility. >> >> I blame myself for the relative lack of exposure JRuby has received in >> the Java world. With all the Ruby conferences and all the Java >> conferences to choose from, there's simply not been enough time to >> cover everything. So we've usually presented at the Ruby conferences, >> only hitting the biggest Java events. But we're going to correct that >> too, putting a heavier emphasis on Java events and Java users over the >> next year. We're going to make sure everyone knows that JRuby is a >> 100% capable JVM language. >> >> I think that covers most of the questions and theories on this list. >> I'll be monitoring for a while if anyone has questions, or you can >> feel free to email me directly or hop on the JRuby mailing lists with >> questions (www.jruby.org). >> >> - Charlie >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
