Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
Major
-
Resolution: Not A Bug
-
Affects Version/s: JRuby 1.1.1
-
Fix Version/s: JRuby 1.6.3
-
Component/s: Java Integration
-
Labels:None
-
Environment:N/A
-
Number of attachments :
Description
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
Activity
This bug just bit me as well. Unfortunately I need to be able to add more arguments than present in the java superclass to the ruby class ctor.
What is the issue with tricking out super to call the ctor on the java object? I am aware that in java super must be invoked before any other code in the ctor, though may not be a restriction in the JVM 
. Can you explain the impediment, may have some ideas on how can adjust.
Writing a self.new is not very appealing as a permanent fixture.
Thanks
| Field | Original Value | New Value |
|---|---|---|
| Attachment | TestRubySubclassing.java [ 47735 ] |
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Assignee | Thomas E Enebo [ enebo ] | |
| Fix Version/s | JRuby 1.6.3 [ 17374 ] | |
| Resolution | Fixed [ 1 ] |
| Status | Resolved [ 5 ] | Closed [ 6 ] |
| Resolution | Fixed [ 1 ] | |
| Status | Closed [ 6 ] | Reopened [ 4 ] |
| Status | Reopened [ 4 ] | Resolved [ 5 ] |
| Resolution | Not A Bug [ 6 ] |
The problem here is that the Ruby initialize isn't really used as the constructor for the new Java object type. It's only used to initialize the Ruby side of things. What actually happens when you extend a Java class is that we define a special "new" that calls both the Ruby initialize and the Java <init> constructor separately, then combining them into the ruby/java object pair. So there's technically no way for you to override the construction of the Java object with a different number of arguments.
This code has been ported into Java recently for 1.1.4, which should make it easier to adjust how this process works. I'm not sure how best to resolve this since we've technically got two class hierarchies' initializers to call.