become_java! does not support concrete class extension #2359

headius · 2014-12-29T19:41:04Z

This is a long standing issue that will likely require a major overhaul of how we do class extension. Sadly, many things require that same overhaul, and the code involved is very rough.

Original issue: http://jira.codehaus.org/browse/JRUBY-6105

Example code that fails to work:

require 'java'
require 'jruby/core_ext'

# brew install hadoop
HADOOP_ROOT = "/usr/local/Cellar/hadoop/0.21.0/libexec/"
Dir.glob( File.join( HADOOP_ROOT, "**/*.jar" ) ).each do |jar|
  require jar
end

# http://hadoop.apache.org/mapreduce/docs/r0.21.0/api/org/apache/hadoop/mapreduce/Mapper.html
# org.apache.hadoop.mapreduce Class Mapper<KEYIN,VALUEIN,KEYOUT,VALUEOUT>
Mapper = org.apache.hadoop.mapreduce.Mapper

class TestA < Mapper
end

puts "Ruby TestA class : #{TestA.name}"

puts "Test A Ancestors: #{TestA.ancestors.join(", ")}"

java_class = TestA.become_java!

if java_class.nil? then
  puts "become_java! returned nil"
  puts "TestA name = #{TestA.name}"
else
  puts java_class.interfaces.each { |i| puts i }
end

__END__
% ruby ./j.rb
Ruby TestA class : TestA
Test A Ancestors: TestA, Java::OrgApacheHadoopMapreduce::Mapper, Java::JavaLang::Object, ConcreteJavaProxy, JavaProxy, JavaProxyMethods, Object, Kernel
become_java! returned nil
TestA name = TestA

paneq · 2016-09-30T21:30:19Z

Looks like this makes using JRuby with Akka impossible:

require 'jruby'
require 'jruby/core_ext'
require './akka-2.4.11/lib/scala-library-2.11.8.jar'
require './akka-2.4.11/lib/akka/akka-actor_2.11-2.4.11.jar'
require './config-1.3.1.jar'

java_import 'akka.actor.ActorRef'
java_import 'akka.actor.UntypedActor'
java_import 'akka.actor.ActorSystem'
java_import 'akka.actor.Props'
java_import 'akka.actor.Inbox'
java_import 'scala.concurrent.duration.Duration'
java_import 'scala.concurrent.duration.FiniteDuration'

java_import 'java.io.Serializable'
java_import 'java.util.concurrent.TimeUnit'
java_import 'java.util.concurrent.TimeoutException'

class HelloAkkaJava < UntypedActor
  def onReceive(message)
    puts message.inspect
  end
end
cls = HelloAkkaJava.become_java!

system = ActorSystem.create('JRubyOnAkka')
greeter = system.actorOf(Props.create(cls), "greeter")

as you need to pass Java class to Props.create

mooreniemi · 2016-10-01T15:57:55Z

@paneq can you use dependency injection? i was able to get around this problem that way.

paneq · 2016-10-02T12:35:58Z

@mooreniemi Thanks for the suggestion, sounds very good and interesting. Could you elaborate though what you have in mind exactly? Maybe a small contrived example?

mooreniemi · 2016-10-02T16:12:43Z

@paneq The basic idea is that rather than inheriting directly on the Ruby object directly, you just delegate forward relevant calls to an embedded Ruby object.

My requirement was to have pure Ruby endpoints that all inherited from a Java framework. When I needed to inherit from BaseEndpoint I instead injected in the Ruby object I needed to call and generated an EndpointWrapper class for every injected Ruby class:

public class EndpointWrapper extends BaseEndpoint {
  // this is the JRuby endpoint we'll inject in
  protected static IRubyObject endpoint;

  public EndpointWrapper() {
  }

  // can't inject on construction, so need this setter
  public static void setEndpoint(IRubyObject rubyEndpoint) {
    endpoint = rubyEndpoint;
  }

  @Override
  protected Map execute(CheetahQuery query) throws Exception {
    ThreadContext context = endpoint.getRuntime().getCurrentContext();
    // we're forwarding the execute method to our injected dep
    IRubyObject called = endpoint.callMethod(
        context,
        "execute",
        JavaObject.wrap(
          endpoint.getRuntime(),
          query
          )
        );

    return called.convertToHash();
  }
}

So things are basically like this:

    +Cheetah----------------------------------+
    | (workerbee inserts all the below)       |
    |                                         |
    | @Endpoint("/route1")                    |
    | +Route1EndpointWrapper----------------+ |
    | |  execute(query) {                   | |
    | |    endpoint.execute(query)          | |
    | |  }                                  | |
    | |                                     | |
    | |  IRubyObject endpoint               | |
    | |  Route1Endpoint------------------+  | |
    | |  + def execute(query)            |  | |
    | |  |   super                       |  | |
    | |  |   your_custom_logic           |  | |
    | |  |   {"key": "values"}           |  | |
    | |  | end                           |  | |
    | |  |                               |  | |
    | |  | def your_custom_logic         |  | |
    | |  |                               |  | |
    | |  | end                           |  | |
    | |  +-------------------------------+  | |
    | +-------------------------------------+ |
    +-----------------------------------------+

Overbryd · 2019-01-21T09:36:06Z

I just bumped into this, I would love to be able to provide Ruby-classes to a Java framework (Apache NiFi in this case). But in order for them to work, I need them to be able to subclass from a base class of the Java framework.

The workaround I have now, is to have a generated Java-written class, that calls into the ruby class. Quite similar to what @mooreniemi has done.

headius added java integration JRuby 1.7.x JRuby 9000 labels Dec 29, 2014

headius added this to the JRuby 9.3.4.0 milestone Mar 31, 2022

headius closed this as completed Mar 31, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

become_java! does not support concrete class extension #2359

become_java! does not support concrete class extension #2359

headius commented Dec 29, 2014

paneq commented Sep 30, 2016

mooreniemi commented Oct 1, 2016

paneq commented Oct 2, 2016

mooreniemi commented Oct 2, 2016

Overbryd commented Jan 21, 2019

become_java! does not support concrete class extension #2359

become_java! does not support concrete class extension #2359

Comments

headius commented Dec 29, 2014

paneq commented Sep 30, 2016

mooreniemi commented Oct 1, 2016

paneq commented Oct 2, 2016

mooreniemi commented Oct 2, 2016

Overbryd commented Jan 21, 2019