JRuby (please use github issues at http://bugs.jruby.org)
  1. JRuby (please use github issues at http://bugs.jruby.org)
  2. JRUBY-928

Java arrays don't inherit from java.lang.Object in Rubified Java class hierarchy

    Details

    • Number of attachments :
      1

      Description

      Java arrays don't inherit from java.lang.Object in Rubified Java class hierarchy. Minor issue (I think), will fix as time permits.

        Activity

        Hide
        Charles Oliver Nutter added a comment -

        Bill: will time permit this week?

        Show
        Charles Oliver Nutter added a comment - Bill: will time permit this week?
        Hide
        Tim Dysinger added a comment -

        I can't reproduce this. I am attaching a test that asserts that arrays are Objects and that java_kind_of? java.lang.Object == true

        Show
        Tim Dysinger added a comment - I can't reproduce this. I am attaching a test that asserts that arrays are Objects and that java_kind_of? java.lang.Object == true
        Hide
        Bill Dortch added a comment -

        Yeah, java_kind_of?, which was sort of an interim solution until we could correctly reflect the Java class hierarchy in Ruby, will work because underneath it calls java.lang.Class.isAssignableFrom().

        The problem is that normal Ruby class membership operations, which now work with other types of Java class/object, don't work with arrays:

        >> java.lang.String < java.lang.Object
        => true
        >> java.lang.String[] < java.lang.Object
        => nil
        >> java.lang.String[10].new.kind_of?java.lang.Object
        => false
        

        This turns out to be a slightly tricky problem to resolve. Here's what the inheritance looks like right now.

        Non-array class:

        >> java.lang.String.ancestors
        => [Java::JavaLang::String, Java::JavaIo::Serializable, Java::JavaLang::Comparable, Comparable, Java
        ::JavaLang::CharSequence, Java::JavaLang::Object, ConcreteJavaProxy, JavaProxy, JavaProxyMethods,
        Object, Kernel]
        

        Array class:

        >> java.lang.String[].ancestors
        => [#<Class:01xe7e8eb>, ArrayJavaProxy, Enumerable, JavaProxy, JavaProxyMethods, Object, Kernel]
        

        I'll probably change ArrayJavaProxy (which contains the Ruby side of Java/Ruby array functionality) into a module, and include it into array classes, but have them descend from ConcreteJavaProxy, which is the immediate parent of the Rubified Java class hierarchy. I'll take a crack at it this weekend, but I'm leery of trying to sneak this in before 1.0. I haven't heard a complaint about it from anyone besides me...

        Very much looking forward to revamping all this post-1.0. The proxy layer must go...

        Show
        Bill Dortch added a comment - Yeah, java_kind_of?, which was sort of an interim solution until we could correctly reflect the Java class hierarchy in Ruby, will work because underneath it calls java.lang.Class.isAssignableFrom(). The problem is that normal Ruby class membership operations, which now work with other types of Java class/object, don't work with arrays: >> java.lang. String < java.lang. Object => true >> java.lang. String [] < java.lang. Object => nil >> java.lang. String [10]. new .kind_of?java.lang. Object => false This turns out to be a slightly tricky problem to resolve. Here's what the inheritance looks like right now. Non-array class: >> java.lang. String .ancestors => [Java::JavaLang:: String , Java::JavaIo::Serializable, Java::JavaLang::Comparable, Comparable, Java ::JavaLang::CharSequence, Java::JavaLang:: Object , ConcreteJavaProxy, JavaProxy, JavaProxyMethods, Object , Kernel] Array class: >> java.lang. String [].ancestors => [#< Class :01xe7e8eb>, ArrayJavaProxy, Enumerable, JavaProxy, JavaProxyMethods, Object , Kernel] I'll probably change ArrayJavaProxy (which contains the Ruby side of Java/Ruby array functionality) into a module, and include it into array classes, but have them descend from ConcreteJavaProxy, which is the immediate parent of the Rubified Java class hierarchy. I'll take a crack at it this weekend, but I'm leery of trying to sneak this in before 1.0. I haven't heard a complaint about it from anyone besides me... Very much looking forward to revamping all this post-1.0. The proxy layer must go...
        Hide
        Charles Oliver Nutter added a comment -

        If Bill's nervous about fixing for 1.0, I'm nervous. Punting to post 1.0.

        Show
        Charles Oliver Nutter added a comment - If Bill's nervous about fixing for 1.0, I'm nervous. Punting to post 1.0.
        Hide
        Charles Oliver Nutter added a comment -

        Assigning to Bill...I presume this will be fixed as part of the big JI rework.

        Show
        Charles Oliver Nutter added a comment - Assigning to Bill...I presume this will be fixed as part of the big JI rework.
        Hide
        Charles Oliver Nutter added a comment -

        Status, Bill? Did this ever get revisited?

        Show
        Charles Oliver Nutter added a comment - Status, Bill? Did this ever get revisited?
        Hide
        Charles Oliver Nutter added a comment -

        Removing target release from issues that fit any of the following criteria:

        • No known way to fix them
        • Java integration enhancements out of scope for 1.1 release
        • Other out of scope issues for 1.1
        Show
        Charles Oliver Nutter added a comment - Removing target release from issues that fit any of the following criteria: No known way to fix them Java integration enhancements out of scope for 1.1 release Other out of scope issues for 1.1
        Hide
        Charles Oliver Nutter added a comment -

        Turned out easier to fix than expected; simply rewrote ArrayJavaProxy's superclass to be Object after JI had finished initializing. All specs pass. Spec for new behavior is on its way.

        Show
        Charles Oliver Nutter added a comment - Turned out easier to fix than expected; simply rewrote ArrayJavaProxy's superclass to be Object after JI had finished initializing. All specs pass. Spec for new behavior is on its way.

          People

          • Assignee:
            Charles Oliver Nutter
            Reporter:
            Bill Dortch
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: