Details

    • Type: New Feature New Feature
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: JRuby 1.7.0.pre1
    • Component/s: None
    • Labels:
      None
    • Number of attachments :
      0

      Description

      The issue is to allow import of multiple Java classes in the same java_import call.

      The simplest for would be:

      java_import android.content.Context, android.content.Intent
      java_import android.view.Display, android.view.Gravity
      Another idea:

      java_import :Context, :Intent, :package => android.content
      java_import :Display, :Gravity, :package => android.view
      ...or maybe like this, my favorite:

      java_import android.content, :Context, :Intent
      java_import android.view, :Display, :Gravity
      What do you think?

        Issue Links

          Activity

          Hide
          Charles Oliver Nutter added a comment -

          Moving Uwe's comment into description.

          Show
          Charles Oliver Nutter added a comment - Moving Uwe's comment into description.
          Hide
          Hiro Asari added a comment -

          I like the first and the last. The second seems a bit too clumsy.

          Show
          Hiro Asari added a comment - I like the first and the last. The second seems a bit too clumsy.
          Hide
          Nick Sieger added a comment -

          Of the listed alternatives, I like the last as well.

          What about:

          java_import android.content => [:Context, :Intent], android.view => [:Display, :Gravity]
          

          I think the class names should be allowed to be strings too.

          java_import android.content => %w(Context Intent), android.view => %w(Display Gravity)
          
          Show
          Nick Sieger added a comment - Of the listed alternatives, I like the last as well. What about: java_import android.content => [:Context, :Intent], android.view => [:Display, :Gravity] I think the class names should be allowed to be strings too. java_import android.content => %w(Context Intent), android.view => %w(Display Gravity)
          Hide
          Uwe Kubosch added a comment - - edited

          Nick's suggestion is now my favorite. It can be combined with the first alternative as well:

          java_import android.content.Context, android.content.Intent, android.view => [:Display, 'Gravity']
          

          The class names should be allowed to be symbols or strings.

          Now for really crazy stuff

          java_import android => {:content => %w(Context Intent), :view => %w(Display Gravity)}
          

          This is compatible with Nick's suggestion.

          Show
          Uwe Kubosch added a comment - - edited Nick's suggestion is now my favorite. It can be combined with the first alternative as well: java_import android.content.Context, android.content.Intent, android.view => [:Display, 'Gravity'] The class names should be allowed to be symbols or strings. Now for really crazy stuff java_import android => {:content => %w(Context Intent), :view => %w(Display Gravity)} This is compatible with Nick's suggestion.
          Hide
          Hiro Asari added a comment - - edited

          It can surely be an aesthetic preference, but the last one looks ugly to me. It is not immediately clear what classes are imported; I have to look for package hierarchy in multiple and distant places.

          Show
          Hiro Asari added a comment - - edited It can surely be an aesthetic preference, but the last one looks ugly to me. It is not immediately clear what classes are imported; I have to look for package hierarchy in multiple and distant places.
          Hide
          Hiro Asari added a comment -

          I also note that currently support multiple imports via an array:

          $ jruby -rjava -S irb
          irb(main):001:0> java_import [java.nio.ByteBuffer, java.nio.IntBuffer]
          => nil
          

          Now that I think... it seems to me that java_import should return true when the import is successful.

          Show
          Hiro Asari added a comment - I also note that currently support multiple imports via an array: $ jruby -rjava -S irb irb(main):001:0> java_import [java.nio.ByteBuffer, java.nio.IntBuffer] => nil Now that I think... it seems to me that java_import should return true when the import is successful.
          Hide
          Thomas E Enebo added a comment -

          I think we make java_import explicitly return the class imported for single values. I think the list version was an afterthought and perhaps we should have it return a list of imported classes?

          jruby -e 'require "java"; p java_import java.lang.System'
          Java::JavaLang::System
          jruby -e 'require "java"; p java_import [java.lang.System]'
          nil
          

          I like the general concept Uwe is bringing forward, but I am unsure whether we should overload java_import or not...

          Show
          Thomas E Enebo added a comment - I think we make java_import explicitly return the class imported for single values. I think the list version was an afterthought and perhaps we should have it return a list of imported classes? jruby -e 'require "java"; p java_import java.lang.System' Java::JavaLang::System jruby -e 'require "java"; p java_import [java.lang.System]' nil I like the general concept Uwe is bringing forward, but I am unsure whether we should overload java_import or not...
          Hide
          Charles Oliver Nutter added a comment -
          commit a39a7440c21b411c4592a27d2ef9e0ca73736590
          Author: Charles Oliver Nutter <headius@headius.com>
          Date:   Fri Feb 17 13:06:24 2012 -0600
          
              Fix JRUBY-6334: Import multiple classes via java_import
              
              I opted to just go with the simple version to resolve this issue.
              I have nothing against introducing some syntax to import multiple
              classes from the same package, but I didn't see anything that we
              all agreed looked nice, and in any case you could use other Ruby
              constructs to build the list of full names you pass to java_import.
          
          Show
          Charles Oliver Nutter added a comment - commit a39a7440c21b411c4592a27d2ef9e0ca73736590 Author: Charles Oliver Nutter <headius@headius.com> Date: Fri Feb 17 13:06:24 2012 -0600 Fix JRUBY-6334: Import multiple classes via java_import I opted to just go with the simple version to resolve this issue. I have nothing against introducing some syntax to import multiple classes from the same package, but I didn't see anything that we all agreed looked nice, and in any case you could use other Ruby constructs to build the list of full names you pass to java_import.
          Hide
          Thomas E Enebo added a comment -

          This change I think is more consistent than what we had with regards to single vs multple arg imports. For people wanting to understand how to write something in both 1.6.x and 1.7.x+ and expect it to work in both:

          *list = java_import(arg)
          *list = java_import [args]
          

          In 1.6.7 the single arg call will return a sngle value which will end up as a list and in 1.7.0 it returns a list which will splat into list. [args] was broken in 1.6, but will not be a list of imports in 1.7.

          Ok, main reason for this comment. In 1.6 if I did:

          p(java_import "java.lang.System")
          p(java_import "java.lang.System")
          

          The second import would return nil to let user know the class has already been loaded (similiar to require). I can see the usefulness of this. For a list of imports I have no clue the best way to preserve that or whether we should preserve this behavior. I will say that the use case of knowing whether something has been loaded should be simple (perhaps just defined? Java::java.lang.System???).

          Uwe is spec'ing the return values with what we have committed on master now, but we should perhaps discuss whether we are really done or not for this feature.

          Show
          Thomas E Enebo added a comment - This change I think is more consistent than what we had with regards to single vs multple arg imports. For people wanting to understand how to write something in both 1.6.x and 1.7.x+ and expect it to work in both: *list = java_import(arg) *list = java_import [args] In 1.6.7 the single arg call will return a sngle value which will end up as a list and in 1.7.0 it returns a list which will splat into list. [args] was broken in 1.6, but will not be a list of imports in 1.7. Ok, main reason for this comment. In 1.6 if I did: p(java_import "java.lang.System") p(java_import "java.lang.System") The second import would return nil to let user know the class has already been loaded (similiar to require). I can see the usefulness of this. For a list of imports I have no clue the best way to preserve that or whether we should preserve this behavior. I will say that the use case of knowing whether something has been loaded should be simple (perhaps just defined? Java::java.lang.System???). Uwe is spec'ing the return values with what we have committed on master now, but we should perhaps discuss whether we are really done or not for this feature.

            People

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

              Dates

              • Created:
                Updated:
                Resolved: