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