Truffle <-> Java Interop

[Jaroslav Tulach]

Dear Truffle API fans,
thanks for all your comments so far! Based on them I updated the proposal for 
Java/Truffle interoperability: 
http://source.apidesign.org/hg/truffle/rev/da7f3650facb

In addition to various bug fixes, increased test coverage, and improvements to 
Javadoc (see here: 
http://source.apidesign.org/hg/truffle/rev/da7f3650facb#l12.46) it also brings 
new @MethodMessage annotation (see at 
http://source.apidesign.org/hg/truffle/rev/da7f3650facb#l16.38) which gives 
uses of the API a chance to send other messages than just READ and EXECUTE.

I'll be glad for any comments. Thanks.
-jt

Dne Út 25. srpna 2015 09:30:00, Jaroslav Tulach napsal(a):
> ### Monday 24 of August 2015, 12:48:28 @ Jaroslav Tulach ###
> 
> > Hi,
> > I've been thinking a bit about simplifying usage of any data coming from a
> > Truffle language from Java code in recent weeks. At the end I designed
> > four
> > methods that should make it quite easy to use Truffle structures from Java
> > and also send Java objects to Truffle.
> > 
> > Please find the Javadoc with high level overview attached. Please look at
> > the test-cases to see the gory details:
> > http://source.apidesign.org/hg/truffle/file/e48bc6f62aa8/truffle/com.oracl
> > e.
> > truffle.api.interop.java.test/src/com/oracle/truffle/api/interop/java/tes
> > t/J avaInteropTest.java
> > 
> > I'll be glad for any feedback. There are many ways to handle the interop
> > and I need your use-cases to find the most optimal one!
> > -jt
> 
> On a behalf of comments made elsewhere:
> 
> Support for
> https://github.com/jruby/jruby/wiki/CallingJavaFromJRuby
> coding style - which is very similar to
> https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions
> has been requested.
> 
> Yes, this is problematic as the interop as we currently have it does not
> handle "inter-language" new operator - that would have to be added. A task
> for Matthias, I guess.
> 
> In addition to that we need special treatment for java.lang.Class - e.g. to
> expose its static methods as being IS_EXECUTABLE (in addition to handling
> the new operation). That is relatively easy and reasonable thing to do. I
> give it a try.
> 
> Then there is the "javax" object - representing a Java package. The only
> problem is that there is no "javax" package, as packages in Java are not
> hierarchic and there is no class in "javax" namespace. And package with
> classes is no package.
> 
> I am not sure how to find out there even should be "javax" object exported.
> It's way easier to implement the Nashorn like syntax - e.g.
> var ArrayList = Java.type("java.util.ArrayList")
> because it uses fully qualified name of a class at once, rather than
> segments of FQN that ultimately may (but also may not) lead to a class.
> 
> -jt