JRuby

I am sitting in the alumni lounge, waiting for the sessions of day 2 to begin. I was thinking about attending the Oracle General Session, but decided to take it easy for a while instead.So, where were I yesterday? Well, the Technical General Session ... [More] was really interesting. As I mentioned yesterday, Charles and Tor did a great demonstration that was very well received. We also got some more on the technical side of JavaFX. Very nice.After that, I attended Web Algorithms. It was a very accomplished presentation, detailing a few important things you can use to make life in computing easier, beginning with swap-XOR and credit card validation, going through public key cryptography and looking at Google MapReduce. It was a good presentation, but nothing new in it for me though, which was sort of sad.The next presentation I went to was about the next generation of Web support in Java. The Servlet 3.0 specification and so on. The presentation was quite vague and didn't say much new things, really. Ok, so next generation servlets will use annotations, and there will be support for Rest style things and better security and more non-idiotic defaults? Not surprising.After that presentation I was feeling really tired, so I went back to my hotel and tried to rest some. That didn't go so well so I finished writing chapter 11 instead. Then it was back to Moscone center to see a BOF on web development in Java EE compared to Ruby on Rails, with tool support. This talk was quite disappointing; it wasn't that well executed, and it was very un-nuanced in detailing the good and bad parts of Ruby on Rails. It seems that when people do these comparisons they just talk about how easy it is to do CRUD-style applications, but seems to forget that Ruby on Rails can do harder things (http://studios.thoughtworks.com/) and that the benefits from the Ruby language in development productivity scales. If you compare doing a small-sized web app in Java and Rails to each other, you will get some kind of percentage. But if you do a comparison between a medium-sized app in Java and Rails, that percentage will be greater, since the Ruby languages scales development time in a totally different way from Java. Not to mention maintainability after the fact.Last I went to Neal Gafters BOF on Closures in Java. I really like the way Neal does presentations, but we couldn't really get into the meat of stuff, since half the people on the BOF didn't know closures from their elbows. So most of the presentation was spent rehashing what they are and why they're needed in Java.After that, I was beat. And now it's a new day, started with breakfast meeting with Roy Singham. Very interesting and entertaining. I'm more and more convinced that I'm going to love working for ThoughtWorks. [Less]

Charles O Nutter and Tor Norbye just got on stage here, and showed of deploying Mephisto as a WAR-file, and then changing it to add text-to-speech functionality, with a Java library that generates an audio file. The total code they wrote on stage was ... [More] about 10 lines of Ruby... The power of Java and Ruby together: it's beautiful.I already knew what they would do, having helped fix many of the issues getting in the way for Mephisto, but it's still incredibly cool. Charles and Tor got several impromptu applauds from the audience too, so I'm pretty sure people think it's neat.Right now, I'm starting to get curious why people continue to use the term "scripting language". It doesn't seem to fit either Ruby nor Groovy anymore. Oh well. Nitpicking.Next up is Arun Gupta. He's talking about jMaki and Phobos, both very nice usages of JavaScript and other languages. [Less]

I'm sitting in the general session hall, waiting for the first technical general session to begin. Yesterday was CommunityOne, where we had some interesting discussion about dynamic languages within the context of the RedMonk Unconference. Aside from ... [More] that, the best parts of the day way announcing that Mingle runs on JRuby, and meeting up with all my soon-to-be fellow ThoughtWorkers. They're a great bunch of people, and we had good fun.Today was the opening general session, where Rich Green announced some very interesting developments. Among these are the fact that the open sourcing of Java is now complete, that Sun is coopering quite heavily with UN to provide resources for education to areas of the world where this have long been a huge problem. But the most important announcements were about something called JavaFX. I can't really say I understand it completely yet, but it seems to be an effort to tackle Microsoft Silverlight, and also fix several deficiencies in Swing by providing JavaFX Script (which looks very much like F3. I'm not sure if it actually is F3 or something else.). This obviously begs the question why Sun finds it prudent to invent a new language, instead of using one of the many great efforts existing in the dynamic language communities for this problem. For example, both Groovy, Jython and JRuby have different versions of SwingBuilders, which allow you to rapidly create Swing interfaces with a specialized DSL for this.Except for that, the general session and keynote was more or less like usual. Very flash, very markety, but still more technical than I imagine other conferences are. And it was fun to see Rich Green being compared to Steve Jobs...The first technical session I went to was called "Cool Things You Can Do with the Groovy Dynamic Language", and was presented by Guillaume Laforge and Dierk König. It was a quite good session, but I can't get away from my general opinions about the Groovy language. So, before I say something about the presentation, I need to describe my feelings for Groovy. Remember, these are my personal opinions, and some are definitely based on feeling without any specific rationalization.I would really like to like Groovy, but I can't. I've really tried, but I can't find the Groovy language to my liking. And believe me, for some circumstances, Groovy should be able to fill the gap between Ruby and Java better than JRuby, at least in some cases. The Java integration in JRuby is quite hard, dispatch and overloading makes calling Java code complicated (from an implementation point, not for the user). All of this would be much simpler with the Groovy approach. But no, I still can't get along with Groovy. The main reason, I believe, is the feeling I get from all code that the language Groovy have grown piecemal, adding stuff that's neat wherever. I'm not sure this is the actual way Groovy was designed, but it feels like a modern version of Perl. The syntax doesn't mesh, and there are numerous (small, but nonetheless there) inconsistencies in how things are handled; many of the things that the language provide for you is things that really shouldn't be part of the language, but part of a library instead.So, from this point of view, the presentation walked through several new features of Groovy, and lots of things you can do with it. They talked a bit about the new support for annotations and the plans for generics. Some of it was quite cool; I like the builders (but I prefer Markaby to the XMLBuilder), and some of the features are quite handy. But looking back at my earlier feelings I still see a design process more focused on finding problems with Java, and duct taping them with Groovy. (Like this: in Groovy, all exceptions get handled automatically, making it look as if all exceptions are unchecked.) I have no problem with many of these features, but I don't think it's a good way to create a general purpose language.I'll be back later with more info on the rest of the days sessions. [Less]

Big news today from ThoughtWorks Studios! Their collaborative development project management solution Mingle (think SourceForge, but pretty and usable) will be the first commercially-distributed Rails application to run on JRuby. Jon Tirsen ... [More] summarizes the justification for this move in a Studios blog post.The reasons are obvious ones to those of us who've poured our hearts and souls into making JRuby succeed, but they're excellent points to call out for the Ruby community at large. Mingle 1.0 will be released running with a Jetty web front-end and a Derby database back-end. Mingle 1.1 will be released as a WAR file (Rails-in-a-WAR courtesy of GoldSpike) targeting any app server and any database.This is a big day for JRuby. ThoughtWorks is one of the most respected names in the Ruby world, and we're proud that they've chosen JRuby as their enterprise deployment solution. We're happy to have ThoughtWorkers like Ola Bini on the team, and look forward to collaborating with ThoughtWorks to continue improving JRuby into the future. [Less]

Here's the deal: ThoughtWorks first product offering is called Mingle. The kicker is, it will be deployed on JRuby. I have been involved with this for a while, getting everything in good working order, and I'm sure TW won't regret this decision. ... [More] JRuby is important in their strategy, and Mingle, as the first commercial JRuby application is a huge deal.You should go and read more about this exciting news at http://studios.thoughtworks.com/2007/5/7/mingle-to-run-on-jruby. [Less]

As I mentioned in my last post, that server/client thing wasn't the only thing I worked on during the flight. I also did a very useful hack of mongrel_cluster, and turned it into mongrel_jcluster. It's not very large changes, actually... Almost ... [More] everything is the same, except that this mongrel plugin only runs in JRuby, and will start several mongrels in the same JVM.jruby -S gem install mongrel_jclustercd your_rails_appjruby -S mongrel_rails jcluster::configure -p 4000 -N 3 -e production -R 20202 -K thesecretkeyjruby -S mongrel_rails jcluster::startThe only difference in the configuration parameters are -R and -K which is the JRuby server port and key respectively. Now, after executing these commands, it will take some time for the mongrels to get online, so be patient (or monitor the progress in the log-files generated).I need to warn you that this is still quite experimental and not guaranteed to work in any way. =) But it does for me.Another thing, if you start Mongrel in production mode, the defualt Rails front-page will give you an error if you try to get at the properties. This is the expected behavior in production mode, though, and nothing wrong with JRuby. [Less]

I spent some time on the flight to SF hacking on an idea I've had for a while. The result was checked in yesterday in JRuby trunk, and the important files are bin/jrubysrv and bin/jrubycli. This is still quite experimental, and only guaranteed to ... [More] work in *NIX environments right now.So, what is it? Well, if you don't want the overhead of running one JVM for each JRuby process, these two commands allow you to start a JVM that listens on a specific localhost port, and then you can send JRuby commands to that port. You need a key as password, otherwise the process will fail. Right now, this isn't as high security as it should be, since the key is passed as a command line parameter. This is still not that big of a problem, since the most common scenario is to start a bunch of things, and then not start anything more. Let me illustrate what you can do with a very simple example.Say that you have a Rails application, and Mongrel for JRuby installed. Go the the base directory of your Rails app and do this:jrubysrv -p 20202 -k secretkey &jrubycli -p 20202 -k secretkey -S mongrel_rails -p 4000jrubycli -p 20202 -k secretkey -S mongrel_rails -p 4001jrubycli -p 20202 -k secretkey -S mongrel_rails -p 4002jrubycli -p 20202 -k secretkey -nNow, if you are patient, in a while there will be three Mongrels running, listening on ports 4000, 4001 and 4002. And they will run inside the same JVM, but in different JRuby runtimes. Quite neat, and very simple. You may wonder about the last command, with the -n flag. That flag tells the JRuby server running at port 20202 to not start any more JRuby processes. In this way, you can start what you need, and then close it down. Due to problems with thread scheduling and safety, I haven't implemented a way to kill a single runtime. What you instead need to do is use jrubycli with the -t flag, which will kill the whole JRuby server.Stay tuned for my next post, on what I've actually used this functionality to create. (If you have some slight amount of imagination, you should be able to guess from this blog post...)But now, of to the races. Or CommunityOne in this case. See you there. [Less]

Tomorrow morning I'll leave Stockholm for San Francisco. I'll be arriving 5:ish PM at SFO and will stay at the Handlery Union Square Hotel. I will not present at either JavaOne or RailsConf, though, so I will have a fair amount of time for fun stuff. ... [More] I will attend the RedMonk unconference at CommunityOne, participate in the DynLang event, and then attend regular JavaOne. If you see me (I'll be wearing my black hat...), please say hi!Next Saturday me and my coworkers will move out of SF and take a car to Portland, where we plan to arrive on the following Tuesday or Wednesday, just in time for RailsConf. We leave from Portland early Monday after the conference.Hope to see many of you there! It will be exciting, that's for sure. I will also try to report as much as possible from all events. [Less]

Yes, I've managed to secure a small order of JRuby t-shirts for giveaway at JavaOne and RailsConf. And they're pretty sweet, have a look at the logo on the front:And the back will have in white the words:include JavaHow cool is that? The logo was ... [More] designed and contributed by "Liz" (Liz, let me know if you want me to post contact info or anything...great work) and arranged by Damian Steer, longtime JRuby contributor. I handled the legwork of arranging the shirts, and managed to secure a little funding to get them paid for.So! How does one get one of these slicko t-shirts? Well, the first round of giveaways goes to folks who've made contributions in the past year. And by contributions I mean either patches or some serious research and legwork on a bug. Obviously there's a core group of folks that should automatically get shirts, so contact me about it if you think you qualify and I'll try to set one aside.Otherwise...You've got the next week or two to fix a bug, post a patch, and otherwise make yourself useful to the JRuby project. I'm gonna be pretty strict on this...if you want the goods, you've got to help out. May is 1.0 cleanup time, with an RC coming out soon and hopefully a final not too long after. So if you'd been considering helping out, now's the time!Visit the JRuby homepage, check out the JRuby bug tracker, and grab JRuby source. The details of contributing are linked from the front page of the JRuby wiki.Update: Oh yeah...how will you get the shirts. The easiest way will be to hunt down Tom and I at the JRuby booth (in Sun's section) between 1PM and 3PM every day. We'll verify that you're not a slacker and make the arrangements. We're looking forward to meeting contributors in person. Otherwise, email me and we'll try to make other arrangements.For RailsConf, I'll just have the shirts at the hotel, and we'll figure something out. Maybe I'll just bring the box to our training and session there. [Less]

Tom and I are giving our JRuby on Rails talk twice at JavaOne next week, and while wrestling with ScheduleBuilder I discovered something surprising: the thursday session is already FULL! Perhaps I underestimated how many people would be interested in ... [More] seeing us prattle on about the future of Java web development with Rails. I expected that two sessions was extremely optimistic of the scheduling committee. It appears I was quite wrong!If you haven't signed up for the JRoR session yet, you better do it quick. I'd hate for any of my regular readers to miss out on attending the session. It's gonna be a great show! [Less]