Jakarta Blues: Are Java Wrappers for Perl Practical?

sierrathedog04 has asked for the wisdom of the Perl Monks concerning the following question:

Replies are listed 'Best First'.
Re: Jakarta Blues: Are Java Wrappers for Perl Practical? by malloc (Pilgrim) on Jun 21, 2001 at 20:41 UTC
Sierra, Hi, i just wanted to share a very simular situation that we are going through now, and see what you think. I am in the opposite box though, migrating from a J2EE system based around BEA's Weblogic Server, to a pre-existing Perl backend, while maintaining the JSP/Servlet GUI. The way that we decided to handle this is by having the database be our main way of communicating between the two. Essentially, our servlets gather all of the data, our DAO's drop them off in the tables, and a perl translator comes along and formats them for the backend and drops them in Job Tables. We never really put any thought into having java and perl get along any other way, so i would be interested to hear how it works out for you, and anyone elses experiences. Good luck! -malloc	[reply]
Re: Re: Jakarta Blues: Are Java Wrappers for Perl Practical? by RhetTbull (Curate) on Jun 22, 2001 at 01:16 UTC
I haven't used it, but I saw Inline::Java demo'd at YAPC America::North 2001 and it looks pretty slick. It even has a "Study" method that will study a Java class and automagically build a perl object interface. It might be worth taking a look at for your application. Regards, Rhet	[reply]
Re: Jakarta Blues: Are Java Wrappers for Perl Practical? by premchai21 (Curate) on Jun 21, 2001 at 20:28 UTC
Well, I know I've seen CPAN modules to put Java inside Perl, for instance Java, which makes calls to a running JVM. You might be able to use some of the code from there -- write a separate JavaServer class which takes calls from Jakarta and passes them to a Java object which you've instantiated using Java and mod_perl which then gets polled for events from Perl and has the appropriate Perl code executed... Then again, maybe not.	[reply]
(crazyinsomniac) Re: Jakarta Blues: Are Java Wrappers for Perl Practical? by crazyinsomniac (Prior) on Jun 22, 2001 at 10:19 UTC
Have you taken a close look at jakarta? It is actually apache. I don't think you should attempt to write any wrappers (there's definetly an easier way). Either consult the jakarta website and mailing list on how to configure jakarta to run perl (it'd probably include just editing one of the .xml in the /conf directory, probably server.xml), or just run a regular instance of of apache along with jakarta, and the regular apache will handle your perl stuff, and pretty much anything not contained in your jakarta document root, and jakarta will handle everything else. You can probably just run mod_j (something something, the apache mod plugin for java) from your regular apache server, and have your cake and eat it too. (perl conf's all taken care of, edit httpd.conf, point it to server.xml, load up the mod, and you're all set). My point being, wrappers you have to write from scratch, and things can go wrong (plus you have to deal with security, and java %^). It's easier to get 2 servers up and running. I've done it on my machine (granted it's win 98), even though I can't even try to run tomcat(i mean jakarta, i mean jakarta-tomcat, whatever) as a service, I've had success running the servers side by side. I also haven't had luck loading up the mod_j (something something), but I just didn't wanna use the module that bad (I got it to execute my java, I don't care how). update: Migrating to a java based website does in no way mean bye-bye perl, nor does it say helloooo wrapper. (that was funny ;-^) As for the advantages of perl-2-java-bytecode, I've seen something, but I can't find it now. But I figure the only advantage (if the bytecode is as good as if it was compiled from java) is that it'd be executed like java, including all the memory hoopla that carries. This of course will slightly dent your development time of perl scripts. Another thing to consider is the architecture of java programs, and packages for that matter. What are the consequences of compiling a perl script, which (for example) uses modules like CGI, DBI, and HTML::Template, to java bytecode. Are you going to be compiling 500K java bytecode files for a 50k perl script? Are you going to compile CGI and DBI to bytecode separately? Are you going to add a java wrapper, and all it entails (like the memory managment), on top of the overhead of running perl scripts the way they normally do? And what about mod_perl for example (or Fast CGI)? If you want perl, run perl. If you want java, run java. ___crazyinsomniac_______________________________________ `Disclaimer: Don't blame. It came from inside the void` `perl -e "$q=$_;map({chr unpack qq;H;,$_}split(q;;,qH*));print;$q/$q;"`	[reply]
Re: Jakarta Blues: Are Java Wrappers for Perl Practical? by MadraghRua (Vicar) on Jun 22, 2001 at 03:19 UTC
I'm not sure about the practical aspect of things. You might want to also check out the JPL module which comes with the standard Perl distrobution. It advertises as being able to run Perl from Java and Java from Perl. The main documentation that I have seen is in the Perl Utilities Guide, part of the Perl Resource Kit. MadraghRua yet another biologist hacking perl....	[reply]