Truffle <-> Java Interop
Jaroslav Tulach
jaroslav.tulach at oracle.com
Fri Sep 4 08:56:45 UTC 2015
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
More information about the graal-dev
mailing list