> In REBOL's case, I'd also mention that Java has support for many
> mundane features, like printing, that REBOL now lacks, not to mention
> other niceities like PDA sychronization. So if there were a
> jREBOL.class, and I ran into a feature-gap, I could put a Java wrapper
> around it and move forward.
>
> There would also be the part about distributing my application in Java
> bytecode, to hide the source.
>
> -Ted.
Indeed. There is such a huge amount of API's available for Java that it
seems such a shame to ignore it. On the other hand jPython (AFAIK) is mostly
used for scripting java objects, in particular for embedded scripting within
aplications and for testing purposes. i.e. Python->Java. Whether REBOL is
suitable for this role I doubt.
But with REBOL you can do things like parsing and internet functionality
much easier than in Java so typically it would be useful doing Java->REBOL.
This is slightly different to the typical uses of JPython (let me know if
I'm completely wrong on this one). The solution suggested a while back
involved running a REBOL server and using TCP/IP sockets to communicate from
Java to REBOL. Imaginative but still ugly and possibly slow (I'll be trying
it out soon hopefully). Ideally a Java Native Interface to REBOL would be
nice but platform-specific so we can discount it. Perhaps there is no
better way ;-(
Jamie
