I don't know whether it is any help to you but I've used abstract classes in JRubyArt/propane and this works for me https://ruby-processing.github.io/propane/classes/library_proxy
https://github.com/ruby-processing/propane/tree/master/library/library_proxy
https://github.com/ruby-processing/propane/blob/master/library/library_proxy/library_proxy.rb
https://github.com/ruby-processing/propane/blob/master/src/monkstone/core/LibraryProxy.java

Ok the usual way we improve these features is by getting some new specs in place. Class extension has needed an overhaul for years but the specs are very weak. Can you folks collab to figure out both what we do now and what we want to do? The new impl is not terribly hard if we have good specs and can throw away the current impl.

OK just to clarify works for me as expected, but may'be that's my peculiar/particular case, I'd be happy to collaborate on a spec. My Simple test case also works as expected:-

package monkstone.reflect;

public abstract class SimpleAbstract {
    public abstract void javaMethod();    
}

require 'java'
require '/home/tux/reflect/reflect/target/reflect-1.0-SNAPSHOT.jar'
class SimpleRubyClass < Java::MonkstoneReflect::SimpleAbstract
  def java_method
    puts 'java_method from ruby'
  end
end

reflect = SimpleRubyClass.new

reflect.java_method

Now definitely that's just too simple for a test case, but put together with my real world example that does involve java reflection I think that current impl does work, but perhaps not as ScottHanley wants.

@monkstone - If I am looking over the examples that you provided it seems like you are focusing more on overriding an abstract method from a Java class in a Jruby class. That situation seems to work fine for me in testing as well. I am concerned with the .constructor.new_instance call chain specifically.

The issue does look like a bug, because if I call puts JrubyConcreteClass.java_class.constructor from the example repository that I linked in my original post I get back "public com.almondbranchsoftware.jruby_abstract_class.SimpleAbstractClass()". So it looks like calling .constructor for the concrete class is giving me back the constructor from its parent class rather than its own constructor for some reason. The error message that I am seeing about not being able to create an abstract class looks like it is because of getting the abstract parents constructor by mistake.

@headius - I don't mind putting some effort towards it. From looking at the code it seems like the current spec is jruby/spec/java_integration/types/extension_spec.rb. Are there more specs that would need to be updated as well or just this one?

@ScottHaney So long as my use case keeps working I'm happy. I create a custom abstract class, with the sole purpose to to gain access (in ruby) to java methods (on processing PApplet class) that have a reflective access via java. I only posted just in case you had a similar problem. As far as I knew the use case for the reflective constructor in jruby is to cope with different java class constructor signatures.

So I'm back to work after some vacation...and I think what you are asking for here is that the Java-facing concrete class have a no-argument constructor, yes?

It's not impossible to do (and maybe not difficult) but this is the sort of thing we want to get right once. Currently the concrete class created does not have an easily-usable constructor. This logic was written many years ago and we have resisted rewriting it due to its complexity.

I believe the current logic would allow you to construct the object via a more complex constructor signature, perhaps one that takes the JRuby "Ruby" runtime object and the RubyClass object associated with the new class, but that may not be convenient for what you are doing...

@headius I believe that you have it right. The java facing class of the class that I create in ruby code needs to have a default constructor in order for the third party java code that I am interacting with to work.

To make sure that I understand the scope right the spec that would be affected by the changes would be jruby/spec/java_integration/types/extension_spec.rb correct? I am new to the code base and haven't looked through it a lot, but from glancing, the code files that look like they have code related to this issue are:

core/src/main/java/org/jruby/RubyClass.java
core/src/main/java/org/jruby/javasupport/JavaClass.java
core/src/main/java/org/jruby/javasupport/Java.java

Is this the right area? Also if you could give more specific details on the scope of the changes that you are looking for I could get a better idea of what to include in the updated spec.

As far as the workaround you mentioned at the end of your last post, unfortunately the creation of the object is deep inside a third party Java library. So I can't change it to use the workaround that you suggested unfortunately.

@headius I spent some time looking over the source code and I think I have a better understanding of your recommendation to use the JRuby "Ruby" runtime object.

I tried the following:

runtime = org.jruby.Ruby.getGlobalRuntime
names = java.util.HashSet.new
names.add('methodName1')

proxy = org.jruby.javasupport.proxy.JavaProxyClass.newProxyClass(runtime, org.jruby.javasupport.JavaClass.for_name(ruby, 'org.companyname.classname'), nil, names)

This creates a java object that has the methods that I need on it and also inherits from the java class that I want it to, however, the proxy constructor has an extra argument of type org.jruby.javasupport.proxy.JavaProxyInvocationHandler. Since I need the constructor to have zero arguments this extra parameter makes the proxy unusable, even though it is close to usable.

I also found the become_java! method, but this seems to not create anything for ruby classes that inherit from java classes. If I run it using a pure ruby class it works, but inheriting from a java class causes it to fail. I am thinking that the java proxy is the way to go, but it doesn't seem like there is a way to get rid of that extra constructor parameter.

Alternatively I could add another constructor if it were possible, I did see an extend_proxy method but wasn't sure how to call it on the proxy class. Would there be a way to add a no argument constructor to the proxy class using extend_proxy somehow?

Fixed by #6422