Give it a try: Truffle <-> Java Interop

[Jaroslav Tulach]

### Friday 04 of September 2015, 10:56:45 @ 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.

Hi there!
I've just integrated the Java/Interop into the Truffle repository[1]. 
Documentation is available at
http://lafo.ssw.uni-linz.ac.at/javadoc/truffle/latest/com/oracle/truffle/api/interop/java/package-summary.html

I hope you'll find it useful. Let me know of any issues you run into.
-jt

[1] http://lafo.ssw.uni-linz.ac.at/hg/truffle/rev/e70b20f4bb00

> 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.ora
> > > cl
> > > e.
> > > truffle.api.interop.java.test/src/com/oracle/truffle/api/interop/java/te
> > > s
> > > 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