Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
java_send/java_alias and perhaps others are not finding the proper method #5631
This is largely an issue with Java 9+ issue but if we call something like:
java_import java.awt.Canvas; java_import java.awt.Graphics; java_import javax.swing.JFrame; class Drawing < Canvas def paint(g) g.fillOval(100, 100, 200, 200) g.java_send :translate, [::Java.int, ::Java.int], 10, 10 end end frame = JFrame.new("My Drawing"); canvas = Drawing.new canvas.setSize(400, 400) frame.add(canvas); frame.pack frame.setVisible(true)
The java_send to translate will find the method from the object it represents. So it asks for its class and finds:
Ordinary method bindings on Java proxy classes appear to call the right method so it is unclear if there is an issue there.
java_send is fixed by just using isExported and isPublic. Similar fixes can be done for java_alias and java_field.
@kares: this may need a more general solution though...Java integration currently skips methods it can't trySetAccessible (via Modulator), when all it really needs is for their package to be exported (added feature to Modulator today) and the class and method public. We may be cutting out more packages than we need with current logic. Have a look at my commit above and let me know what you think/
The java_send changes were apparently more invasive than I expected, and some specs regressed. I'm fixing that now.
@enebo I have to change the logic to allow searching private classes because we have specs that expect that behavior. This may be a case where we need some Java 9-specific behavior above and beyond the module logic (i.e. be less aggressive on 9 because it yells at us).
@kares I know about the logic to setAccessible Java methods during setup, but do you know of anywhere we're explicitly backing just because we're on 9, rather than via module checks? (e.g. "if (!on_java_9) set_something_accessible")