This bug refers to the case where a Ruby class subclasses a Java class. There seems to be a requirement that the Java superclass have a constructor that takes the same number of arguments as the Ruby subclass' initialize method. (Instead, it should do the check against the subclass' call to super.) This impairs the programmer's ability to design subclass constructors' signatures according to their function. Definition of Terms for text below: J=Java superclass R=Ruby subclass of J From the JRuby library source, it looks as if concrete.rb is inspecting the arguments of the wrong call. It's inspecting R's initialize's arguments. I would think it should be looking at the arguments to R's call to super (if any) in that initialize method. The source file concrete.rb can be found at: http://www.koders.com/ruby/fid4571FA39650B617F2D4BD486117CB76A32CE000A.aspx?s=cdef%3Aproxy#L1 or http://snipurl.com/261tg ...or in your JRuby installation at /lib/ruby/site_ruby/1.8/builtin/javasupport/proxy/concrete.rb. This is elaborated in the attached java-properties-viewer.rb file. In the PropertiesTableModel class' initialize, it would be preferable to have it accept a properties object as a parameter, so that the table model would be general enough to accept any java.util.Properties object. However, because of the bug, this cannot be done in the constructor, because AbstractTableModel does not have a 1-arg constructor. In some cases, there is no problem, but that is only by coincidence, since the number of arguments in the subclass' initialize method happens to be matched by a constructor of the Java superclass. There is some more information in the attached file. In some cases, I've provided two constructor methods: initialize_preferred_but_that_doesnt_work initialize ... and refactored the code common to both out into the function: initialize_common