Re: Philosophical Issues of JPL & perljvm/Jasmin

On Fri, 10 Mar 2000, Flynn, Rick wrote:

> 
> Can someone please help me understand the aims of JPL versus those of
> perljvm/Jasmin?  This really is a naive question on my part - just trying to
> understand where the two efforts are coming from, headed to, and whether
> they are anticipated to intersect or possibly even combine at some date in
> the future.  I've poked around on the perl5-porters archives, various
> READMEs, etc. but still feel somewhat unclear about who is trying to
> accomplish what via which methods when. 
I thought it's the same differences between Jacl and Tcljava.Both has to
be a bridget between the two different language. And One of them
(perljvm/jacl) has to be rewritten in Java. Perljvm and Jacl (and
Jpython) also has the responsibility of saying whether to replicate all
sorts of nice and gentle wrappers over Java's JFC or give you direct
access to them. Two points for building the wrappers is providing those
who are familiar with sockets, Tk, mail and whatnot from a scripting
language point of view with less responsibility to rewrite their scripts,
another benefit is you'll have access to Java reasources through tie and
hash structures which helps you to code faster, it will also come with
perl like documentation--which is quite more helpful than your regular
JFC doc dumps. But the cost of these wrappers is overhead and duplicated
efforts (an difficulty translating perl services into wrappers over java
classes--Jacl was quick to give up on translating Tk early on--it's not
easy). TclJava and JPL provides you a chance to leave your scripting
languages unchanged, abut still allow your Java programs a glimps into the
script and vise versa. You have to know both language either way, but at
least you're not trying to pretend that you can fully embed the spirit of
a scripting language into Java (which is hard to achieve but probably
still is a worthwhile endeavor). That's my perl newbie perception
(distance from 2 star systems away) and understanding on the subject.

Scripting in Java only works if you have something to script...with the
browsers crashing left and right, you can't even getthe simplest applet to
run reliably on most platforms--how can you consider a embedded
interpreter in addition to the java classes on the server side?

On the embedded hardware side, people are afraid of coding the Java way
even with Java (they code like they are C programmers) on the iButtons and
Pilots and JavaCards. But these are devices that beg to be scripted. Sun
suggest that you do it by proxy. Write a tiny socket based remote control
into the device and have a real server on a network control  it--and
provide a prettier face. So with that in mind you won't be putting the
interpreter (perljvm/jacl/jpython/rhino) on the chip--but remote control
it from the server--and let XML-RPC or plain old text (SMTP) do the rest
over the socket/card reader.

On the large system side, there's alot of potential for perljvm or JPL,
because if you were one of those retard who bit hook, sinker, and bait
into the Middleware Scam--you will realize that even a interpreter in a
JVM or interpreter-glued-to-JVM performs steadier and faster and dance
around web problems so much better than any middle ware.. 

Some combinations include:

Apache+J servelets (with Javascript Rhino/Navtive JS to script the servlet
classes--there is a open source freeware servlet engine you can download 
today that works exactly this way) 

Apache+Jserv (Jserv interconnected via JPL to separate perl daemons to
deal with tasks best left to perl)

People don't maek too much mention of perljvm stage because it seems to be
in a hush hush stage. The last post to this mailing list was that someone
has volunteered to work on it full time, and it's radio silence since
then. I personally can't find any websites or download sites for perljvm.
I just hope whoever is working on it is having a great deal of fun and
solving some pressing problems he's having at work (the same way Larry got
Perl started) while he is at it. Good luck whoever you are!! :)

-- Li

 > > thanks
in advance, > 
> rick
>