Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specifying an interface in java_send throws a TypeError #2065

Closed
blinsay opened this issue Oct 21, 2014 · 5 comments
Closed

Specifying an interface in java_send throws a TypeError #2065

blinsay opened this issue Oct 21, 2014 · 5 comments

Comments

@blinsay
Copy link

blinsay commented Oct 21, 2014

Calling java_send with an interface as an argument throws a TypeError. After a quick discussion with @headius in IRC, it seems like it'd be good if the Ruby representation of an interface could be correctly coerced to a class here.

Here's a quick example:

java_import java.util.concurrent.Executors

e = Executors.new_fixed_thread_pool(2)
class Foo
  include java.lang.Runnable

  def run
    sleep 2
    puts "hi there"
  end
 end

e.submit(Foo.new)
# generates a warning:
#   warning: ambiguous Java methods found, using submit(java.lang.Runnable)

# Neither of these work!
e.java_send(:submit, [java.lang.Runnable], Foo.new)
# TypeError: cannot convert instance of class org.jruby.RubyModule to class java.lang.Class

e.java_send(:submit, [Java::JavaLang::Runnable], Foo.new)
# TypeError: cannot convert instance of class org.jruby.RubyModule to class java.lang.Class

# This is the workaround
e.java_send(:submit, [Java::JavaLang::Runnable.java_class], Foo.new)
@headius
Copy link
Member

headius commented Oct 21, 2014

Our interface proxies should be coercible (explicitly or implicitly) to java.lang.Class during dispatch. Might not even need java_send if we did that correctly.

@headius headius added this to the JRuby 9000 milestone Oct 21, 2014
@enebo enebo modified the milestone: JRuby 9.0.0.0 Jul 14, 2015
@kares
Copy link
Member

kares commented Aug 15, 2015

along the line this has been fixed with some JI ❤️ and the original issue no longer exists :

jruby-1.7.21 :001 > java_import java.util.concurrent.Executors
 => [Java::JavaUtilConcurrent::Executors] 
jruby-1.7.21 :002 > e = Executors.new_fixed_thread_pool(2)
 => #<Java::JavaUtilConcurrent::ThreadPoolExecutor:0x3c5d0d01> 
jruby-1.7.21 :003 > class Foo
jruby-1.7.21 :004?>     include java.lang.Runnable
jruby-1.7.21 :005?>   
jruby-1.7.21 :006 >       def run
jruby-1.7.21 :007?>         sleep 2
jruby-1.7.21 :008?>         puts "hi there"
jruby-1.7.21 :009?>       end
jruby-1.7.21 :010?>    end
 => nil 
jruby-1.7.21 :011 > e.submit(Foo.new)
(irb):11 warning: ambiguous Java methods found, using submit(java.lang.Runnable)
 => #<Java::JavaUtilConcurrent::FutureTask:0x4c7c233a> 
jruby-1.7.21 :012 > hi there

jruby-1.7.21 :013 >   e.java_send(:submit, [java.lang.Runnable], Foo.new)
 => #<Java::JavaUtilConcurrent::FutureTask:0x46decc20> 
jruby-1.7.21 :014 > hi there

jruby-1.7.21 :015 >   e.java_send(:submit, [Java::JavaLang::Runnable], Foo.new)
 => #<Java::JavaUtilConcurrent::FutureTask:0x32f1d73d> 
jruby-1.7.21 :016 > hi there

jruby-1.7.21 :017 >   e.java_send(:submit, [Java::JavaLang::Runnable.java_class], Foo.new)
 => #<Java::JavaUtilConcurrent::FutureTask:0x2a262e12> 
jruby-1.7.21 :018 > hi there

there's also test-cases for this already ... closing and marking the milestone as 1.7.21

@kares kares closed this as completed Aug 15, 2015
@kares kares added this to the JRuby 1.7.21 milestone Aug 15, 2015
@blinsay
Copy link
Author

blinsay commented Aug 18, 2015

Dope!

@kares @headius Is there a plan to have the include java.lang.Runnable make the call to submit unambiguous or should I just use java_send?

@kares
Copy link
Member

kares commented Aug 18, 2015

is it still ambiguous? ... please check if so open a new issue. thanks

@blinsay
Copy link
Author

blinsay commented Aug 18, 2015

@kares sure thing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants