JRuby

Greetings!Google's Summer of Code for 2008 is starting up again, and we're looking for folks to submit proposals. The JRuby Community or Sun or me or someone will sign up as a mentoring organization, so start thinking about or discussing possible ... [More] proposals. Here's a few ideas to get you started (and hopefully, there are many other ideas out there not on this list):Writing a whole suite of specs for current Java integration behavior...and then expanding that suite to include behavior we want to add. This work would go hand-in-hand with a rework of Java Integration we're likely to start soon.Collect and help round out all the profiling/debugging/etc tools for JRuby and get them to final releasable states. There's several projects in the works, but most of them are stalled and folks need better debugging. This project could also include simply working with existing IDEs (NetBeans, etc) to figure out how to get them to debug compiled Ruby code correctly (currently they won't step into .rb files).Continue work on an interface-compatible RMagick port. There's already RMagickJR which has a lot of work into it, but nobody's had time to continue it. A working RMagick gem would ease migration for lots of folks using Ruby.Putting together a definitive set of fine and coarse-grained benchmarks for Rails. JRuby on most benchmarks has been faster than Ruby 1.8.6...and yet higher-performance Rails has been elusive. We need better benchmarks and better visibility into core Rails. Bonus work: help nail down what's slower about JRuby.Survey all existing JRuby extensions and put together an official public API based on core JRuby methods they're using. This would help us reduce the hassle of migrating extensions across JRuby versions.Please, anyone else who has ideas, feel free to post them here or on the mailing list for discussion. And if you have a proposal, go ahead and mail the JRuby dev list directly.Update: Martin Probst added this idea in the comments:Another idea might be to "fix" RDoc, whatever that means. That's not really JRuby centric, but still a very worthwhile task, I think.A documentation system that allows easy doc writing (Wiki-alike) and provides a better view on the actual functionality you can find in a certain instance would be really helpful. Plus a decent search feature.And that makes me think of another idea:Add RDoc comments to all the JRuby versions of Ruby core methods, and get RI/RDocs generating as part of JRuby distribution builds. Then we could ship RI and have it work correctly. Ola Bini has already started some of the work, creating an RDoc annotation we can add to our Ruby-bound methods.Update 2: sgwong in the comments suggested implementing the win32ole library for JRuby. This would also be an excellent contribution, since there's already libraries like Jacob to take some of the pain out of it, and it would be great to have it working on JRuby. And again, this makes me think of an few additional options:Implement a full, compatible set of Apple Cocoa bindings for JRuby. You could use JNA, and I believe there's already Cocoa bindings for Java you could reuse as well, but I'm not familiar with them.Complete implementation of the DL library (Ruby's stdlib for programmatic loading and calling native dynamic libraries) and/or Rubinius's FFI (same thing, with a somewhat tidier interface). Here too there's lots of help: I've already partially implemented DL using JNA, and it wouldn't be hard to finish it and/or implement Rubinius's FFI. And implementing Rubinius's FFI would have the added benefit of allowing JRuby to share some of Rubinius's library wrappers. [Less]

When talking about how dynamic scripting languages are designed, people have a tendency to divide them into "There is more than one way to do it" and "There is one way to do it". Perl is the quintessential example of "more than one way", and Python ... [More] is the opposite, going so far as to make it impossible to have your own indentation.These different ways of doing things really divide programmers. Some hate the way Python gives you a bondage strait jacket and no scissors, while some programmers love that they don't need to make any choices and that everyone's code will be equally readable.From a pure perspective, the Python philosophy seems to be the right one, but it just doesn't work for me. In the same way, I agree with Perl's way of doing things, but the problems that cause in most Perl code is just amazing. Sometimes it feels like the Python way is actually directly a result of someone reacting extremely badly to a Perl code base and decided to never allow that to happen in Python.So what's the point? Well, the point is Ruby. In fact, Ruby has almost all of the flexibility of Perl to do things in different ways. But at the end of the day, none of the Perl problems tend to show up. Why is this? And why do I feel so comfortable in Ruby's "There is more than one way to do it" philosophy, while the Perl one scares me?I think it comes down to language design. The Python approach is impossible for the simple reason that what the language designer chooses is going to be the "one way", by fiat. Some people will agree, and some will not. But what I'm seeing in Ruby is that the many ways have been transformed into idioms and guidelines. There are no hard rules, but the community have evolutionary evolved idioms that work and found out many of the ways that doesn't work. This seems to be the right way - if you do the choice as a language designer, you have actually chosen the people that will use your language: that's going to be the persons who doesn't dislike the language designers choices. But if you leave it open enough for evolutionary community design to happen you can actually get the best of both world: both a best way to do things, and something that works for a much larger percentage of the programmer world.I have come to believe that this is one of the major reasons that Ruby feels so good to me, and is such a good language. And it's a lesson for language designers. When you choose philosophy, make sure to take the possibility of communities and idiom evolution into account. [Less]

I'm taking a break from some bug fixing to bring you this public service announcement:Ruby's Thread#raise, Thread#kill, and the timeout.rb standard library based on them are inherently broken and should not be used for any purpose. And by extension ... [More] , net/protocol.rb and all the net/* libraries that use timeout.rb are also currently broken (but they can be fixed).I will explain, starting with timeout.rb. You see, timeout.rb allows you to specify that a given block of code should only run for a certain amount of time. If it runs longer, an error is raised. If it completes before the timeout, all is well.Sounds innocuous enough, right? Well, it's not. Here's the code:def timeout(sec, exception=Error) return yield if sec == nil or sec.zero? raise ThreadError, "timeout within critical session"\ if Thread.critical begin x = Thread.current y = Thread.start { sleep sec x.raise exception, "execution expired" if x.alive? } yield sec # return true ensure y.kill if y and y.alive? endendSo you call timeout with a number of seconds, an optional exception type to raise, and the code to execute. A new thread is spun up (for every invocation, I might add) and set to sleep for the specified number of seconds, while the main/calling thread yields to your block of code.If the code completes before the timeout thread wakes up, all is well. The timeout thread is killed and the result of the provided block of code is returned.If the timeout thread wakes up before the block has completed, it tells the main/calling thread to raise a new instance of the specified exception type.All this is reasonable if we assume that Thread#kill and Thread#raise are safe. Unfortunately, they're provably unsafe.Here's a reduced example:main = Thread.currenttimer = Thread.new { sleep 5; main.raise }begin lock(some_resource) do_some_workensure timer.kill unlock_some_resourceendHere we have a simple timeout case. A new thread is spun up to wait for five seconds. A resource is acquired (in this case a lock) and some work is performed. When the work has completed, the timer is killed and the resource is unlocked.The problem, however, is that you can't guarantee when the timer might fire.In general, with multithreaded applications, you have to assume that cross-thread events can happen at any point in the program. So we can start by listing a number of places where the timer's raise call might actually fire in the main part of the code, between "begin" and "ensure".It could fire before the lock is acquiredIt could fire while the lock is being acquired (potentially corrupting whatever resource is being locked, but we'll ignore that for the moment)It could fire after the lock is acquired but before the work has startedIt could fire while the work is happening (presumably the desired effect of the timeout, but it also suffers from potential data corruption issues)It could fire immediately after the work completes but before entering the ensure blockOther than the data corruption issues (which are very real concerns) none of these is particularly dangerous. We could even assume that the lock is safe and the work being done with the resource is perfectly synchronized and impossible to corrupt. Whatever. The bad news is what happens in the ensure block.If we assume we've gotten through the main body of code without incident, we now enter the ensure. The main thread is about to kill the timeout thread, when BAM, the raise call fires. Now we're in a bit of a predicament. We're already outside the protected body, so the remaining code in the ensure is going to fail. What's worse, we're about to leave a resource locked that may never get unlocked, so even if we can gracefully handle the timeout error somewhere else, we're in trouble.What if we move the timer kill inside the protected body, to ensure we kill the timer before proceeding to the lock release?main = Thread.currenttimer = Thread.new { sleep 5; raise }begin lock(some_resource) do_some_work timer.killensure unlock_some_resourceendNow we have to deal with the flip side of the coin: if the work we're performing raises an exception, we won't kill the timer thread, and all hell breaks loose. Specifically, after our lock has been released and we've bubbled the exception somewhere up into the call stack, BAM, the raise call fires. Now it's anybody's guess what we've screwed up in our system. And the same situation applies to any thread you might want to call Thread#raise or Thread#kill against: you can't make any guarantees about what damage you'll do.There's a good FAQ in the Java SE platform docs entitled Why Are Thread.stop, Thread.suspend, Thread.resume and Runtime.runFinalizersOnExit Deprecated?, which covers this phenomenon in more detail. You see, in the early days of Java, it had all these same operations: killing a thread with Thread.stop(), causing a thread to raise an arbitrary exception with Thread.stop(Throwable), and a few others for suspending and resuming threads. But they were a mistake, and in any current Java SE platform implementation, these methods no longer function.It is provably unsafe to be able to kill a target thread or cause it to raise an exception arbitrarily.So what about net/protocol.rb? Here's the relevant code, used to fill the read buffer from the protocol's socket:def rbuf_fill timeout(@read_timeout) { @rbuf << @io.sysread(8196) }endThis is from JRuby's copy; MRI performs a read of 1024 bytes at a time (spinning up a thread for each) and Rubinius has both a size modification and a timeout.rb modification to use a single timeout thread. But the problems with timeout remain; specifically, if you have any code that uses net/protocol (like net/http, which I'm guessing a few of you rely on) you have a chance that a timeout error might be raised in the middle of your code. You are all rescuing Timeout::Error when you use net/http to read from a URL, right? What, you aren't? Well you better go add that to every piece of code you have that calls net/http, and while you're at it add it to every other library in the world that uses net/http. And then you can move on to the other net/* protocols and third-party libraries that use timeout.rb. Here's a quick list to get you started.Ok, so you don't want to do all that. What are your options? Here's a few suggestions to help you on your way:Although you don't have to take my word for it, eventually you're going to have to accept the truth. Thread#kill, Thread#raise, timeout.rb, net/protocol.rb all suffer from these problems. net/protocol.rb could be fixed to use nonblocking IO (select), as could I suspect most of the other libraries, but there is no safe way to use Thread#kill or Thread#raise. Let me repeat that: there is no safe way to use Thread#kill or Thread#raise.Start lobbying the various Ruby implementations to eliminate Thread#kill and Thread#raise (and while you're at it, eliminate Thread#critical= as well, since it's probably the single largest thing preventing Ruby from being both concurrently-threaded and high-performance).Start lobbying the library and application maintainers using Thread#kill, Thread#raise, and timeout.rb to stop.Stop using them yourself.Now I want this post to be productive, so I'll give a brief overview of how to avoid using these seductively powerful and inherently unsafe features:If you want to be able to kill a thread, write its code such that it periodically checks whether it should terminate. That allows the thread to safely clean up resources and prepare to "die itself".If you need to time out an operation, you're going to have to find a different way to do it. With IO, it's pretty easy. Just look up IO#select and learn to love it. With arbitrary code and libraries, you may be able successfully lobby the authors to add timeout options, or you may be able to hook into them yourself. If you can't do either of those...we'll, you're SOL. Welcome to threads. I hope others will post suggestions in the comments.If you think you can ignore this, think again. Eventually you're going to get bitten in the ass, be it from a long-running transaction that gets corrupted due to a timeout error or a filesystem operation that wipes out some critical file. You're not going to escape this one, so we should start trying to fix it now.I'm hoping this will start a discussion eventually leading to these features being deprecated and removed from use. I believe Ruby's viability in an increasingly parallel computing world depends on getting threading and concurrency right, and Thread#raise, Thread#kill, and the timeout.rb library need to go away. [Less]

It's 5am in Brussels and I'm awake. That can only mean one thing. Time to blog!This weekend I'm presenting JRuby at FOSDEM, the "Free and Open Source Developers European Meeting." I was invited to talk, and who could pass up an invitation to ... [More] Belgium?I've been trying to shake things up with my recent JRuby talks. At Lang.NET, I obviously dug into technical details a lot more because it was a crowd that could stomach such things. At acts_as_conference, I threw out the old JRuby on Rails demo and focused only on things that make JRuby on Rails different (better) than classic Ruby on Rails development, such as improved performance, easier deployment, and access to a world of Java libraries. And FOSDEM will include all new content as well: I'm spending Friday putting together a talk that discusses JRuby capabilities and status while simultaneously illustrating the impact community developers have had on the project. After all, it's an OSS conference, so I'll continue my recent trend and try to present something directly on-topic.For those of you unable to attend, it turns out there will be a live video stream of some of the talks, including the whole Programming Languages track. I don't think I've ever been livestreamed before. [Less]

So, next week and the week after that I'll be in San Francisco. I'll participate in the ThoughtWorks code jam on Tuesday and Wednesday, and do a tech talk at Google sometime by the end of the week.If someone is interested in meeting up, talking about JRuby, Ruby or programming languages in general, just get in touch.

Today, Tom got the JRuby 1.1 RC2 release out. It's an astounding collection of performance improvements and compatibility fixes. Here's Tom's JRuby 1.1 RC2 announcement.Let's recap a little bit:There have been additional performance improvements in ... [More] RC2 over RC1. Long story short, performance of most trivial numeric benchmarks approaches or exceeds Ruby 1.9, while most others are on par. So in general, we have started using Ruby 1.9 performance as our baseline.Unusual for an RC cycle are the 260 bugs we fixed since RC1. Yes, we're bending the rules of RCs a bit, but if we can fix that many bugs in just over a month, who can really fault us for doing so? Nobody can question that JRuby is more compatible with Ruby 1.8.6 than any other Ruby implementation available.We've also included a number of memory use improvements that should reduce the overall memory usage of a JRuby instance and perhaps more importantly reduce the memory cost of JIT compiled code (so called "Perm Gen" space used by Ruby code that's been compiled to JVM bytecode). In quick measurements, an application running N instance of JRuby used roughly 1/Nth as much perm gen space.So there's really two big messages that come along with this release. The first is that JRuby is rapidly becoming the Ruby implementation of choice if you want to make a large application as fast and as scalable as possible. The thousands of hours of time we've poured into compatibility, stability, and performance are really paying off. The second message comes from me to you:If you haven't looked at JRuby, now's the time to do so.All the raw materials are falling into place. JRuby is ready to be used and abused, and we're ready to take it to the next level for whatever kinds of applications you want to throw at it. And not only are we ready, it's our top priority for JRuby. We want to make JRuby work for you.And that brings me to the "What's Next" portion of this post. Where do we go from here?We've got a window for additional improvements and fixes before 1.1 final. That much is certain, and we want to fill that time with everything necessary to make JRuby 1.1 a success. So we need your help...find bugs, file reports, let us know about performance bottlenecks. And if you're able, help us field those reports by fixing issues and contributing patches.But we also have a unique opportunity here. JRuby offers features not found in any other Ruby implementation, features we've only begun to utilize:Inside a single JVM process, JRuby can be used to host any number of applications, scaling them to any number of concurrent users.This one applies equally well to Rails and to other web frameworks rapidly gaining popularity like Merb. And new projects like the GlassFish gem are leading the way to simple, scalable, no-hassle hosting for Ruby web applications. But we're pretty resource-limited on the JRuby project. We've got two full-time committers and a handful of part-timers and after-hours contributors pouring their free time into helping out. For JRuby web app hosting to improve and meet your requirements, we're going to need your use cases, your experience, and your input. We're attempting to build the most scalable, best-performing Ruby web platform with JRuby, but we're doing it in true OSS style. No secrets, no hidden agendas. This is going to be your web platform, or our efforts are wasted. So what should it look like?The GlassFish gem is the first step. It leverages some of the best features of the Java platform: high-speed asynchronous IO, native threading, built-in management and monitoring, and application namespace isolation (yes, even classloaders have a good side) to make Ruby web applications a push-button affair to deploy and scale. With one command, your app is production-ready. No mongrel packs to manage, no cluster of apps to monitor, and no WAR file relics to slow you down. "glassfish_rails myapp" and you're done; it's true one-step deployment. Unfortunately right now it only supports Rails. We want to make it not only a rock-solid and high-performance Rails server, but also a general-purpose "mod_ruby" for all Ruby web-development purposes. It's the right platform at the right time, and we're ready to take it to the next level. But we need you to try it out and let us know what it needs.JRuby's performance regularly exceeds Ruby 1.8.6, and in many cases has started to exceed Ruby 1.9.At this point I'm convinced JRuby will be able to claim the title of "fastest Ruby implementation", for some definition of "Ruby". And if we're not there yet, we will be soon. With most benchmarks meeting or exceeding Ruby 1.8.6 and many approaching or exceeding Ruby 1.9 we're feeling pretty good. What I've learned is that performance is important, but it's not the driving concern for most Ruby developers, especially those building web applications usually bounded by unrelated bottlenecks in IO or database access. But that's only what I've been able to gather from conversations with a few of you. Is there more we need to do? Should we keep going on performance, or are there other areas we should focus on? Do you have cases where JRuby's performance doesn't meet your needs?JRuby performance future is largely an open question right now. A stock JRuby install performs really well, "better enough" that many folks are using it for performance-sensitive apps already. We know there's bottlenecks, but we've solving them as they come up, and we're on the downward slope. Outside of bottlenecks, do we have room to grow? You bet we do. I've got prototype and "experimental" features already implemented and yet to be explored that will improve JRuby's performance even more. Of course there's always tradeoffs. You might have to accept a larger memory footprint, or you may have to turn off some edge-case features of Ruby that incur automatic performance handicaps. And some of the wildest improvements will depend on dynamic invocation support (hopefully in JDK 7) and a host of other features (almost certain to be available in the OpenJDK "Multi-language VM" subproject). But where performance improvements are needed, they're going to happen, and if I have any say they're going to happen in such a way that all other JVM languages can benefit as well. I'm looking to you folks to help us prioritize performance and point us in the right direction for your needs.JRuby makes the JVM and the Java platform really shine, with excellent language performance and a "friendlier" face on top of all those libraries and all that JVM magic.I think this is an area we've only just started to realize. Because JRuby is hosted on the JVM, we have access to the best JIT technology, the best GC technology, and the best collection of libraries ever combined into a single platform. Say what you will about Java. You may love the language or you may hate it...but it's becoming more and more obvious that the JVM is about a lot more than Java. JRuby is, to my knowledge, the only time a non-JVM language has been ported to the JVM and used for real-world, production deployments of a framework never designed with the JVM in mind. We've taken an unspecified single-implementation language (Matz's Ruby) and its key application framework, (Rails) and delivered a hosting and deployment option that at least parallels the original and in many ways exceeds it. And this is only the first such case...the Jython guys now have Django working, and it's only a matter of time before Jython becomes a real-world usable platform for Python web development. And there's already work being done to make Merb--a framework inspired by Rails but without many of Rails' warts--run perfectly in JRuby. And it's all open source, from the JVM up. This is your future to create.I think the next phase for JRuby will bring tighter, cleaner integration with the rest of the Java platform. Already you can call any Java-based library as though it were just another piece of Ruby code. But it's not as seamless as we'd like. Some issues, like choosing the right target method or coercing types appropriately, are issues all dynamic languages face calling into static-typed code. Groovy has various features we're likely to copy, features like explicit casting and coercing of types and limited static type declaration at the edges. Frameworks like the DLR from Microsoft have a similar approach, since they've been designed to make new languages "first class" from day one. We will work to find ways to solve these sorts of problems for all JVM languages at the same time we solve them for JRuby. But there's also a lot that needs to come from Ruby users. What can we do to make the JVM and all those libraries work for you?I guess there's a simple bottom line to all this. JRuby is an OSS project driven mostly by community contributors (5 out of 8 committers working in their free time and hundreds of others contributing patches and bug reports), based on an OSS platform (not only OpenJDK, but a culture of Free software and open source that permeates the entire Java ecosystem), hosting OSS frameworks and libraries (Rails, Merb, and the host of other apps in the Ruby world). All this is meaningless without you and your applications. We're ready to pour our effort into making this platform work for you. Are you ready to help us? [Less]

The JRuby community is pleased to announce the release of JRuby 1.1 RC 2Homepage: http://www.jruby.org/Download: http://dist.codehaus.org/jruby/JRuby 1.1RC2 is the second release candidate of JRuby 1.1.  JRuby 1.1 represents a concerted focus on ... [More] speed and refinement.  Ruby code can completely compile in an Ahead Of Time (AOT) or Just In Time (JIT) mode; yielding a faster Ruby!  It also uses less memory than our previous releases.We need people to download JRuby 1.1RC2 and give us feedback.  Test your applications and help us make JRuby 1.1 a great release.Highlights: - 260 issues resolved since JRuby 1.1RC1- Large IO refactoring- Memory improvements for JIT'd methods:  - Control total number of methods JIT'd  - Support a JIT cache between runtimes to return permgen  - Reduce codesize of generated methods (50-70% reduction)Vladimir Sizikov has been added as a core committer.  His amazing workon fixing rubyspec failures has made him a welcome addition to the team.We want to thank all the people who gave us feedback this last release cycle.We ended up resolving a tremendous number of issues in a short period of time.Issues fixed since 1.1RC1:JRUBY-251       Concurrency Issue with IRuby.evalScript(), require etc.JRUBY-334     Process module does not implement some methodsJRUBY-781     Can't reference java classes that start with a lower case characterJRUBY-864     ant test does not run successfully with thread pooling enabledJRUBY-867     Iconv character set option //translit is not supportedJRUBY-919     autoload?, autoload, const_defined? do not work well with Colon2's (e.g. autoload Object::Foo, 'blah.rb')JRUBY-939     Improve automatic conversion between JRuby BigDecimal and java.math.BigDecimalJRUBY-1003     Rubinius string_spec failuresJRUBY-1047     IO.for_fd missingJRUBY-1050     If there is a file named date.rb in the same dir that contains a file that requires 'yaml' an exception is thrown when you run the file requiring 'yaml'JRUBY-1057     Rubinius core/exception_spec failuresJRUBY-1064     Rubinius core/object_spec failuresJRUBY-1067     Rubinius core/thread_spec failuresJRUBY-1068     Rubinius core/time_spec failuresJRUBY-1103     Settting -Xmx and -Xss through environment variable would be more convientJRUBY-1106     Process.euid() not implemented, causes MailFactory failureJRUBY-1114     Exception when running instance_eval on a Java ObjectJRUBY-1124     Import broken with RakeJRUBY-1128     Regular expression bugJRUBY-1142     #! shebang in cygwin uses cygwin pathsJRUBY-1145     Testcase: testBasicStringScalarLoad(org.jvyamlb.YAMLLoadTest): FAILEDJRUBY-1148     Array#== doesn't use custom to_ary method for RHS argumentsJRUBY-1151     BigDecimal to_s displays incorrect number when number has no whole partJRUBY-1188     JRuby base64 encoding methods appear as both public and private methods.JRUBY-1214     The behaviour of File.flock is not same with C RubyJRUBY-1222     Net::HTTP response error using SSL connectionJRUBY-1272     UNIXSocket not available on JRubyJRUBY-1277     Mongrel clashes with JVM for the right to handle SIGUSR1JRUBY-1279     Serialization/Persistence FixJRUBY-1294     crash starting jar-console on trunk, r4214JRUBY-1304     Problem talking to processes. JRuby's read hangs.JRUBY-1358     Failure in ruby_test String#aset testJRUBY-1361     Failure in ruby_test Numeric#to_int testJRUBY-1362     Failure in ruby_test Numeric#truncate testJRUBY-1371     testTime.rb doesn't work correctly on some configurationJRUBY-1373     Cannot run JRuby through 'java' when having space in path in JRuby's homeJRUBY-1397     testUTF8Regex.rb doesn't even run anymoreJRUBY-1399     Reflection-based execution is totally brokenJRUBY-1402     spurious warning messages when yaml is analized with debug option.JRUBY-1414     ArgumentError using to_time string conversionJRUBY-1433     File::Stat.uid needed for rubyzipJRUBY-1455     Cloning ARGF in IRB results in a java.lang.ClassCastExceptionJRUBY-1471     YAML dumping or loading is mucking up object IDsJRUBY-1485     Some names not being interned by parser / evalJRUBY-1493     Methods do not always have the right line number in the ASTJRUBY-1495     When a negative Float is YAML::dump'ed, the negative sign is lost.JRUBY-1496     Update to 1.8.6 stdlibJRUBY-1501     Update to current RubyGems, hopefully the long-awaited version currently in betaJRUBY-1502     Trap not returning a proc as the previous handlerJRUBY-1507     Ruby String aset ([]=) with 3 args does not work is start index is one past string lengthJRUBY-1509     0o00 is brokenJRUBY-1511     bad shebang line in gemJRUBY-1516     FileTest#chardev? is not currently implemented.JRUBY-1517     Embedded null characters in source cause premature EOFJRUBY-1524     Dynamic classes/classloaders may not be using the appropriate containing classloader, resulting in permgen leaksJRUBY-1526     NullPointerException when deriving non-existant (lowercase) java-classJRUBY-1530     Some conflict when using JSON Pure to create a JSON string from a Hash with non-ASCII characterJRUBY-1532     String#chomp misbehaving in 1.1b1JRUBY-1534     ThreadLibrary Queue#num_waiting and Zlib to_io method not bound correctly.JRUBY-1535     <clinit> must be generated with static modifierJRUBY-1536     Giving YAML.load a non-IO object raises a Java error instead of a Ruby errorJRUBY-1537     Sun JVM-specific signal handler should be used only when availableJRUBY-1540     Process.pid does not give the correct PIDJRUBY-1545     Trying to extend an interface (e.g. class Foo < Interface) NPEs and gives no clueJRUBY-1552     /o regexp modifier (Ruby compatibility)JRUBY-1553     Generator sometimes hangs upJRUBY-1554     Time.gm should not allow negativeJRUBY-1558     RubyBigDecimal does not dump/load properly when MarshallingJRUBY-1560     ArrayIndexOutOfBoundsException -1 in RubyString.split(RubyString)JRUBY-1563     RubyYaccLexer not returning EOF properlyJRUBY-1564     AbstractVisitor doesn't provide empty implementation for visitPreExeNodeJRUBY-1567     StringScanner missing #get_byteJRUBY-1568     File.symlink shells out to /bin/ln unnecessarilyJRUBY-1571     Calling map on string causes java.lang.ArrayIndexOutOfBoundsExceptionJRUBY-1581     Signal#trap doesn't handle failure of trapping gracefully.JRUBY-1585     Incompatible behavior in Comparable#==JRUBY-1586     Array#initialize_copy is public, but should not beJRUBY-1589     Float#coerce fails when invoked with String argumentJRUBY-1590     Completely wrong Float::MAX_10_EXP value (negative)JRUBY-1593     Range#step produces wrong error messageJRUBY-1594     Range#new breaks when 3rd parameter is not booleanJRUBY-1596     Range#eql? works incorrectly for char rangesJRUBY-1597     Struct#new behavior differs from MRIJRUBY-1598     Struct#select allows for non-block argumentsJRUBY-1599     Symbol#to_int should produce warning in verbose modeJRUBY-1600     Serious incompatibility in Thread#join(limit)JRUBY-1601     JRuby incorrectly/incompatibly handles "TZ" environment variable (Time spec failures)JRUBY-1605     Hash#[]= and Hash#store don't follow dup semantics for keysJRUBY-1607     File#truncate works incorretly deleting entire file contentJRUBY-1610     DynamicScope could benefit from some custom impls that use Java fields rather than an arrayJRUBY-1611     Variable access with depth > 0 should be more staticJRUBY-1612     File#truncate creates a new file if the file doesn't existJRUBY-1614     File.open should throw Errno::EACCES when opening non-permitted fileJRUBY-1617     RubyZip Zip::ZipFile#read raises TypeError under JRuby; does not do so under MRIJRUBY-1618     rescue doesn't work with SystemExit exceptions (Regression)JRUBY-1619     File.open(1) throws TypeErrorJRUBY-1625     File.fnmatch works incorrectly with case sensitivityJRUBY-1626     IO.popen("ruby") hangsJRUBY-1635     Bug in generatorsJRUBY-1640     Generator created from empty Enumarable, just hangs during constructionJRUBY-1643     Generator.new can't handle blocks, and its yield method works incorrectlyJRUBY-1645     Process.kill support through JNAJRUBY-1652     Time#gmt_offset returns incorrect values for DSTJRUBY-1653     JRuby incorrectly calculates / and divmod against Rational numberJRUBY-1655     JRuby fails built-in unit tests from time.rb libJRUBY-1658     Float's multiplication is incorrect when used with non-built-in type (like Rational)JRUBY-1659     YAML.load can't handle some valid inputJRUBY-1661     JRuby 10x slower than Ruby on "Wide Finder" scriptJRUBY-1663     IO.each_line incorrectly reads empty linesJRUBY-1664     IO.read(1) after ungetc always returns nilJRUBY-1665     Unhandled Java exception from jMongrel running RailsJRUBY-1669     IO.puts doesn't follow the specificationJRUBY-1671     jruby bash script fails with bash 2.03 (Solaris 8)JRUBY-1675     Rails hangs occasionally with JRubyJRUBY-1682     JRuby files should work with limited functionality within Jar filesJRUBY-1684     Numerous StringIO spec test failuresJRUBY-1686     OutOfMemoryException while reading from a FIFOJRUBY-1689     Tempfile class random behavior and "Bad file descriptor (Errno::EBADF)" exceptionJRUBY-1696     test_dir fails under WindowsJRUBY-1700     rio gem problemsJRUBY-1702     NegativeArraySizeException starting JIRB (ByteList/RubyString)JRUBY-1704     Broken stdin ( java.lang.OutOfMemoryError ) in Linux environmentJRUBY-1706     [PATCH] Bad format for "frozen" error messagesJRUBY-1708     Compiler blows up with "NoVarsDynamicScope cannot be grown; use ManyVarsDynamicScope"JRUBY-1715     Incompatible behavior for ||= in HashesJRUBY-1723     String#initialize and String#replace on frozen strings behave incompatibly with MRIJRUBY-1736     Jruby on rails application crashes when starting mongrelJRUBY-1769     Constructing a transient singleton class should hold the receiver until completeJRUBY-1776     Exception when installing mongrel gemJRUBY-1784     The JNA library bundled with JRuby is built against glibc 2.4 JRUBY-1798     JRuby JIT should have an upper limit on how many methods can be compiled, to avoid eating too much permgenJRUBY-1808     uninitialized constant OpenSSL::X509::StoreJRUBY-1810     JIT should attempt to locate a previously-compiled method of the same name and position before creating a new oneJRUBY-1821     jruby-webstart integration: open-uri (actually net/http.rb) causes java.security.AccessControlExceptionJRUBY-1822     jruby-webstart integration: copy and paste via system clipboard in jirb.jnlp does not workJRUBY-1865     java.lang.LinkageError: attempted duplicate class definition for name: "append_features28277251_29404618Invokerjava_class__8Fixed0"JRUBY-1874     HttpOutput flush doesn't send headersJRUBY-1879     Random Empty Response with Rails 2.0JRUBY-1891     JRUBY-1890Cloned IO objects can be closed independentlyJRUBY-1892     JRUBY-1890pipes should not flush write to read when not in sync modeJRUBY-1893     JRUBY-1890Missing method: File#isattyJRUBY-1894     JRUBY-1890Missing flush after File.open with a block?JRUBY-1896     JRUBY-1890Missing method: IO#statJRUBY-1902     AOT compiler does not produce usable outputJRUBY-1907     Monitor synchronize hangsJRUBY-1908     IO#reopen with File with File::CREAT mode failsJRUBY-1909     IO#reopen should be able to handle argument of arbitrary type if it responds to "to_io"JRUBY-1910     IO#reopen incorrectly handles self as an argumentJRUBY-1911     YAML short-hand hashes cause the parser to crashJRUBY-1915     Failure to load YamlJRUBY-1917     File#link and File#symlink should not accept non-string argumentsJRUBY-1918     File#link and File#symlink never report any errorsJRUBY-1919     File#symlink? returns false on broken symlinksJRUBY-1921     File#link and File#symlink break hard on WindowsJRUBY-1922     Pathing issues (pathname? realpath?) on Windows with GlassFish gemJRUBY-1923     STDIN not working under Kernel.systemJRUBY-1925     Incompatibility: JRuby 1.1 can't run Glassfish gemJRUBY-1926     File.new doesn't accept Pathname as its argumentJRUBY-1927     File.lstat on MS Windows should be the same as File.statJRUBY-1928     FileUtils.fu_windows? doesn't return trueJRUBY-1933     NullPointerException in SSLSocket.javaJRUBY-1934     divmod with 0.0 argument should raise FloatDomainError: NaNJRUBY-1939     UnsatisfiedLinkError: Native Library libjnidispatch.jnilib already loaded in another classloaderJRUBY-1940     Fixnum# and Fixnum#* return Fixnum in cases when Bignum is neededJRUBY-1941     ThreadLocal caches for regexp in RubyString and joni cause classloader leaks in app serversJRUBY-1943     FileUtils.cp_r incorrectly produces "same file" error when files to be copied already exist in destination directoryJRUBY-1945     The "-y" or "--include-dependencies" is not needed anymore with the most recent rubygems.JRUBY-1946     -0 flag not supportedJRUBY-1947     -C flag not supportedJRUBY-1948     -c flag not supportedJRUBY-1952     -T flag not supportedJRUBY-1953     -W flag not supportedJRUBY-1955     Lucene index search causes major memory bloat slowdown in 1.1RC1, but not 1.1b1JRUBY-1956     Class#inherited gets invoked regardless of visibilityJRUBY-1957     IO#dup behavior shows channels should be loosely held by IO objectsJRUBY-1959     Rubyspecs failures for Array#pack with 'ils' patternsJRUBY-1963     gem install activerecord-jdbc-adapter hangs while installing ri doc on clean svn co and build of JRuby r5607JRUBY-1965     Problem with glob test running under bambooJRUBY-1966     AR models backed by views fail to workJRUBY-1970     Time.now has low precisionJRUBY-1971     Time#getgm and Time#getlocal work incorrectly when usecs presentJRUBY-1979     NullPointerException when tracing script requiring java moduleJRUBY-1980     Marshal#dump incorrerctly serializes objects that respond to _dump.JRUBY-1983     File.utime and File.mtimeJRUBY-1984     TCPServer.new should allow a single port parameterJRUBY-1985     TCPServer.accept should set thread status to 'sleep' before waitingJRUBY-1986     String extracted with a regular expression cannot be used as pattern in File.fnmatchJRUBY-1987     dup'ed stream reopened by IO.new stream from file descriptor appears to get lostJRUBY-1988     Kernel#exec should return subprocess exit value and immediately bubble out of callerJRUBY-1989     Can't create Zip files using RubyZipJRUBY-1990     File.dirname, File.link and File.symlink failed rubinius spec testJRUBY-1992     Date::Infinity handling is incorrectJRUBY-1993     ObjectSpace#define_finalizer behavior does not match MRIJRUBY-1994     higher javasupport "threads step on each other" test now failing regularlyJRUBY-1995     Warnings from redefining Java classes is annoyingJRUBY-1998     Regression: JRuby prints Exception in thread "main" when it shouldn'tJRUBY-1999     Time#strftime week of year is broken on some systemsJRUBY-2000     IO#tty? returns false for "/dev/tty"JRUBY-2001     Kernel#sprintf returns result in incorrect register with 'x' patternJRUBY-2002     rexml/document references undefined variableJRUBY-2004     Const definition on non-class/module breaks JRuby hardJRUBY-2005     Buffered writes in IOHandlerNio (sockets, stdio, other non-file IO) are corruptJRUBY-2009     -S script does not set $0 to script launchedJRUBY-2010     Errno errors should allow no-arg constructorJRUBY-2013     YAML doesn't like serializing ActiveRecord has many associationsJRUBY-2017     Dir.chdir raises a SystemCallError if the original directory no longer existsJRUBY-2019     YAML.tagged_classes retuns very few items compared to MRIJRUBY-2021     Thread Problem: Exception in thread ... attempted duplicate class definition..JRUBY-2023     Serious NIO-multithreading breakage in print/puts on WindowsJRUBY-2024     IO#open, IO#popen, File#open with block should not raise error when io is closed inside the blockJRUBY-2025     jirb_swing not working (r5707), regression in r5665JRUBY-2026     Update retroweaver jars to 2.0.3JRUBY-2030     Attempt to load broken Java class breaks JRubyJRUBY-2031     SystemCallErorr rubyspec regressions and new specs failuresJRUBY-2033     Attribute assignment is twice as slow as MRIJRUBY-2034     loading a gem (hpricot) which requires a jar not working in webstart with jrubygemsJRUBY-2036     Spec failure in TCPSocket on MacJRUBY-2037     String#unpack with "Q/q" patterns always returns Bignums even for small valuesJRUBY-2038     IO#seek/pos=, StringIO#seek with non-Fixnum args break JRubyJRUBY-2039     Various socket spec failuresJRUBY-2043     Temp local variable indices overwriting normal local variables in stack and boxed variable compilersJRUBY-2044     IO#write breaks JRuby when writing object with special to_s implementationJRUBY-2045     IO#write should not really check if IO is writable if nothing to write (e.g. empty string)JRUBY-2046     Ranges in conditions are brokenJRUBY-2050     List module does not allow [Range] and [Num, Num] gettersJRUBY-2052     FileUtils.mkdir_p is broken on WindowsJRUBY-2054     File#join can't handle recursive arraysJRUBY-2055     Time - () explodesJRUBY-2056     Time#<=> behavior is incompatible with MRIJRUBY-2057     Array#join can't handle nested recursive arraysJRUBY-2060     Eval positioning information from binding is incorrect again.JRUBY-2061     JRuby should support Unix Domain SocketsJRUBY-2062     Add ids and convenient data to SyntaxException and IRubyWarning interface to make their life easierJRUBY-2064     Array.shift leaksJRUBY-2066     RubyIO and RubyFile have bad conditional translating /dev/null to Windows NUL: device.JRUBY-2067     AOT Compiler does not FunctionJRUBY-2068     rbconfig missing localstatedirJRUBY-2069     Instantiating Java subclasses is excrutiatingly slowJRUBY-2070     IO#syswrite can't write non-string objectsJRUBY-2073     IO#foreach failures and crashes with rubyspecsJRUBY-2075     IO#gets failures with latest rubyspecs (tainting, lineno, $.)JRUBY-2076     RubyBigDecimal.getValue() neededJRUBY-2077     File#lineno= breaks JRuby if non-integer argument suppliedJRUBY-2081     Gem server failsJRUBY-2083     Yaml parsing error with application in JRuby (war format of application)JRUBY-2084     RubyUNIXSocket read() cases IllegalArgumentExceptionJRUBY-2085     visibilty faiure on class method defined with 'class << self'JRUBY-2088     Using the simple package-class syntax for JI gives unintuitive answers when giving argumentsJRUBY-2090     Passing readonly mode to File.new gets File not found error.JRUBY-2092     Upgrade to jline-0.9.93 fixes 64-bit Windows jirb.JRUBY-2095     Test failure in run-junit-precompiled (trunk, WinXp)JRUBY-2096     File#open should not change permissions of existing file, even when permissions specified in argumentsJRUBY-2097     File#umask blows up on WindowsJRUBY-2101     Fix deprecation warning in build on clean targetJRUBY-2104     7 rubyspecs failures for $~ due to recent changesJRUBY-2105     Method and UnboundMethod do not strictly behave like in MRIJRUBY-2106     Regression after recent JI changes: Some unit tests cannot be executed, just exitJRUBY-2109     JRUBY-1890Rubicon test_io's test_reopen1 fails after IO reorgJRUBY-2113     Regexp behavior differs a bit from MRIsJRUBY-2118     File#truncate crashes JRuby with NPE when invoked on closed file [Less]

I usually don't mention the G word in my blog - the results have a tendency to be less than palatable. This time I'm going to make an exception though. The reason is that this meme has been floating around as an argument for Groovy, and I really ... [More] don't agree with it. In fact, the reason I'm writing about it is because I think the meme in itself generally can be bad for Groovy.The thing I'm talking about is the saying that Groovy is just like Java. That you can start using Groovy directly without learning anything about Groovy and that basically all Java syntax is valid Groovy.Now, the last part has never been really true, since there are a few valid Java constructs that are not supported in Groovy (anonymous classes, I'm looking at you). This might be fixed in the 1.5 version. I don't really know, but that's not the point. Since Groovy isn't using the Java parser there will always be a few small corner cases that are not valid in Groovy but Java accepts. This is not a problem, by the way. The only way it can be a problem is when you're using Groovy the wrong way, or you absolutely need to do something that Groovy doesn't support. Since one of the Groovy catch calls is that you shouldn't implement everything in Groovy, this can't really be a concern either. If you're using Groovy correctly, you should just drop down to the Java layer for that particular feature.Now that that part is out of the way, let's take a look at the other parts of this idea. Namely that you should choose Groovy because it's just like Java, and you can start writing Java code directly in Java. These statements are definitely true, since you can absolutely pick up a language that way. In my mind, though, this misses the whole point of using another language on top of the JVM. If you're building an application and chooses to use Groovy for this instead of Java, isn't the reason that you're doing that the fact that you expect Groovy to give you something Java does not? And if that's the case, doesn't it sound like a disservice to people picking up Groovy to say that they can begin by just programming Java. There is no gain here. Really. In fact, the equivalent program in Groovy and Java will perform much worse on Groovy since there are several layers of dispatching in Groovy that you don't have in Java. The result? An application with exactly the same source code, but running 10 times slower.Since this message is mostly used in marketing and introduction facilities, the people it's geared at are by definition newbies to the Groovy world. Many of them are totally new to dynamic languages. And the first thing they do is write Java in Groovy, find it slow and obviously, from that point don't understand why you should use Groovy. This is bad for Groovy. Groovy has some extremely powerful features and libraries that can really make your life on the JVM blissful (compared to using Java, for example). Groovy's integration with Java is top notch, which means that you can always fall back to Java when you need Java specific features. If you're using Groovy, I think you should use the full power of the language so you can actually get the full benefit of Groovy. [Less]

I hadn't read this specific c2 post, but it's funny how much of what I write is just a rehash of stuff Cunningham and company came up with 15 years ago. Well. I guess that's why they're the masters and I'm not.Incidentally, this is my 300th blog post, since starting this blog a little bit more than 2 years ago. Time rushes by, don't it?

Someone asked in a comment where my Scala exploration were going. It's a fair question.I did a first implementation of the core of the system I was using. Most of if was tested using Specs (which incidentally is very good, and even more importantly ... [More] - have a responsive creator). Now, I realized a while back that the implementation weren't really using Scala properly. I had mostly used the imperative way of doing things. So I'm planning a rewrite of these parts, using pattern matchin, case classes and more recursive algorithms correctly. It's kinda funny. I didn't expect this to happen since I have so much experience with functional languages. But apparently, the fact that Scala looks like Java in many regards makes it very easy to slip into the Java imperative mode. Not good.Right now I'm spending some time working on the next release of JtestR, writing on a book, and doing some pesky day time work. =) Also, JRuby needs to have its 1.1 release. I expect to get back to Scala within one or two weeks, though. [Less]