Hi Brian (and all),
I see where you are getting at and now understand better the Inline
philosophy. I understand that the primary idea is to write Perl functions in
other languages.
Although I must argue that in Java you cannot write a public function. You
can only write methods. All functions must be inside a class. So if one is
to scan some Java code to extract public function-type symbols, all you can
retrieve are constructors and public static methods.
So I guess if you want to bind these types of methods, it is possible to
"create" wrappers to these functions. But you will need to create them in
different namespaces that correspond to the class names. You will also be
limited to one constructor per class, and no method overloading.
I'll take a look at the Inline::Python to see if I can get any ideas from
there.
I'll let you know what comes up..
Thanks,
----------------------------------
| Patrick LeBoutillier
| SITA Montreal
| [EMAIL PROTECTED]
>From: Brian Ingerson <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: any plans on Inline::Java? - just a naive question...
>Date: Fri, 23 Feb 2001 13:03:09 -0800
>
>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'
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
