Truffle <-> Java Interop

Jaroslav Tulach jaroslav.tulach at oracle.com
Tue Aug 25 07:30:00 UTC 2015


### 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.oracle.
> truffle.api.interop.java.test/src/com/oracle/truffle/api/interop/java/test/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



More information about the graal-dev mailing list