Patrick LeBoutillier wrote:
>
> Hi all,
>
> I've been working on an Inline::Java implementation for about 2 weeks now,
> and I'm about half way through.
Cool!
>
> The first reason I didn't inform this mailing list of my activities is that
> I didn't (and still don't) know how much time I'll be able to put into this
> project.
That's ok. That's why there's a community :)
> The second reason is that I'm developing this in a different way
> and I don't know if it will be approved by the Inline community.
If you work with the community it can't help but be approved. Besides,
there can be more than one implementation of Java. Inline supports that.
> Here goes! I think all the existing Inline modules use the .so/DynaLoader
> technology.
Not true. The concepts of build() and load() are completely abstract.
You can do whatever you want to get your connection going. For instance,
you could invoke a network connection to a remote JVM if you wanted. The
only things Inline guaratees are:
1) It will call Inline::Java::build() if the MD5 fingerprint of 'java
object' does not match.
2) It will call Inline::Java::load() every time.
NOTE: A 'java object' can be anything you want. It is a file with the
extension you specify in Inline::Java::register()
NOTE: Compiled languages can use the super class (Inline.pm) load()
function, which uses Dynaloader.
NOTE: Inline::Python is a great example of all this abstraction.
> I didn't know how to do this in Java (is it possible? The only
> way I could think of was to use an open source Java SDK link it into a .so).
> So the way I went about Inline::Java is the following:
>
> 1- The build() function compiles the users Java code (plus other stuff) into
> a Java executable.
> 2- The load() function forks+execs the Java executable (java) and starts the
> code. My wrapper code actually start a small server. Then the perl
> scripts connects via TCP to the Java program.
> 3- The java server listens on the socket and serves all the requests using
> the java.lang.reflect API. All created objects are kept in a HashMap so they
> can be referenced.
> 4- On the perl side the objects store basically an objid to the Java object.
> 5- Then AUTOLOAD and tie do their magic...
The implementation plan that Neil and I sketched out earlier this year
goes like this:
1) Have build() compile the java into a .class file. Somehow, poll the
class to retrieve all the public methods. Save this information in a
.jdat file.
2) Have load() ensure that a JVM is running. Bind the functions in the
.jdat file to Perl. These functions know how to get to Java and back.
This is very sketchy, and no work has been done on it, but I just throw
it out FYI. Please continue on your current path, if you're seeing
success.
Your end goal should be the same as Inline's:
"Make it as easy as possible for people to use Java in Perl"
NOTE: You (Inline::Java::load()) should know in advance which method's
you will bind to. That's the Inline way. AUTOLOADing any possible perl
sub call to Java is a fine idea, but then there's no reason to put the
Java inside (inlined in) the Perl code. The basic idea (look and feel)
of Inline is to write Perl subroutines/methods in other languages. If
your implementation doesn't work that way, it's probably not a good
Inline candidate. For example:
In Inline::C, if you want to bind to an external function, you always
write a wrapper that calls the external function. In some cases this may
seem like an extra step, but it gives you fine grained control on how
that function will be represented in Perl space. And that's almost
always a good thing. For Inline::Java I would start by only supporting
methods that used the fundamental types of integer, number, and string.
Then your Inlined Java method could use more complex (external) classes
to do whatever you want. But you keep the Perl to Java crossover dead
simple. And the only Java you put into Perl is the stuff that you call
directly from Perl.
> Like I mentioned this is somewhat different from the other Inline modules,
> but I think it should work OK.
> This is also the first CPAN perl module I write, so the release time
> overhead might be heavy at first.
We can help you there too. If you are interested in getting help you
should make your current code available by ftp. Of course, this would be
remain your project (owned by you), and all final decisions would be
yours to make.
Cheers, Brian
--
perl -le 'use Inline C=>q{SV*JAxH(char*x){return newSVpvf
("Just Another %s Hacker",x);}};print JAxH+Perl'
