JRuby

Allow a way to resolve interface methods from with Ruby proxy modules

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: JRuby 1.6.6
  • Fix Version/s: JRuby 2
  • Component/s: Java Integration
  • Labels:
    None
  • Number of attachments :
    0

Description

I am working on a library which uses mostly interfaces. It would be really nice if java_alias (and the others) could resolve signatures of the interface, so I can:

module org::bukkit::Entity
  java_alias :teleport_java, :teleport, [org.bukkit.Location]

  def teleport(loc)
    teleport_java coerce_location(loc)
  end
end

Unfortunately, java_alias only seems to work for classes. Bonus points for whoever takes this up...Remove some truly ancient method java_alias used for a completely different purpose than the java_alias we document in our book in core_ext/module

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Alex Tambellini added a comment -

For anyone who needs a workaround, call .java_class on the interface that you pass to java_alias.

Show
Alex Tambellini added a comment - For anyone who needs a workaround, call .java_class on the interface that you pass to java_alias.
Hide
Permalink
Charles Oliver Nutter added a comment -

The correct fix here is one I've put off for a long time: get interface methods loading on to the proxy modules we set up for them. This serves Tom's purpose as well as reducing the duplication we currently have for interface methods on concrete classes (specifically, we bind them on all classes, rather than just binding them on the interface module).

This could be done for 1.7. I attempted it once before and got stuck, but I don't remember why.

Show
Charles Oliver Nutter added a comment - The correct fix here is one I've put off for a long time: get interface methods loading on to the proxy modules we set up for them. This serves Tom's purpose as well as reducing the duplication we currently have for interface methods on concrete classes (specifically, we bind them on all classes, rather than just binding them on the interface module). This could be done for 1.7. I attempted it once before and got stuck, but I don't remember why.
Hide
Permalink
Charles Oliver Nutter added a comment -

Ok, adding notes here for what I ran into.

The problem with adding the methods to the proxy modules is fairly simple: they interfere with dispatch. Interface methods do not really exist for dispatch purposes; they're only used for Java method resolution at compile time.

I tried a number of approaches:

  • If I install dummy methods on the proxies that just redispatch to super, it interferes with class hierarchies where the same interface is implemented at different levels in different ways. It also fails to work for class hierarchies where the implementation is inherited from a class that does not implement the interface.
  • If I install special methods that can't be used for dispatch purposes, method caching breaks because we have "false" methods in the lookup chain.

There were other variations but ultimately having the methods exist on the proxies as real Ruby methods always ran into chicken/egg scenarios that broke dispatching.

The best we might be able to do is provide standard class-level utilities for querying Java methods separate from Ruby methods. This is still an open question...I'll leave it up to Tom whether to keep it an open bug.

Show
Charles Oliver Nutter added a comment - Ok, adding notes here for what I ran into. The problem with adding the methods to the proxy modules is fairly simple: they interfere with dispatch. Interface methods do not really exist for dispatch purposes; they're only used for Java method resolution at compile time. I tried a number of approaches: If I install dummy methods on the proxies that just redispatch to super, it interferes with class hierarchies where the same interface is implemented at different levels in different ways. It also fails to work for class hierarchies where the implementation is inherited from a class that does not implement the interface. If I install special methods that can't be used for dispatch purposes, method caching breaks because we have "false" methods in the lookup chain. There were other variations but ultimately having the methods exist on the proxies as real Ruby methods always ran into chicken/egg scenarios that broke dispatching. The best we might be able to do is provide standard class-level utilities for querying Java methods separate from Ruby methods. This is still an open question...I'll leave it up to Tom whether to keep it an open bug.
Hide
Permalink
Thomas E Enebo added a comment -

I guess I am still hoping we can think of something clever which addresses this even if it is an idiom we post onto the wiki. The basic problem is we have interfaces as modules and it feel natural to interact with the signatures there.

Show
Thomas E Enebo added a comment - I guess I am still hoping we can think of something clever which addresses this even if it is an idiom we post onto the wiki. The basic problem is we have interfaces as modules and it feel natural to interact with the signatures there.

People

  • Assignee:
    Unassigned
    Reporter:
    Thomas E Enebo
Vote (0)
Watch (3)

Dates

  • Created:
    Updated: