Re: PERL/java interface available?
At 07:34 2003-06-09 -0600, you wrote: Would anyone happen to know if there is a PERL/java interface where these two languages could talk to each other? Java can call any native function that's packaged in a dso or dll. (But is it possible to compile Perl modules to standalone dso?) Did anyone mention B::JVM::Jasmin or JPL? See links below... -Mark - Porting Perl to the Java Virtual Machine http://www.ebb.org/bkuhn/writings/technical/thesis More about JPL http://www.oreilly.com/catalog/prkunix/info/more_jpl.html Java Native Interface Tutorial http://java.sun.com/docs/books/tutorial/native1.1/
Re: PERL/java interface available?
I believe there's a Java.pm module on CPAN that will allow a perl program to instantiate java objects and call methods on them. That may or may not be enough intercommunication for what you need. Wes Sheldahl "Charlie Smith" <[EMAIL PROTECTED]> on 06/09/2003 09:34:04 AM To:[EMAIL PROTECTED] cc: Subject:PERL/java interface available? Would anyone happen to know if there is a PERL/java interface where these two languages could talk to each other? Charlie -- This message may contain confidential information, and is intended only for the use of the individual(s) to whom it is addressed. ==
Re: PERL/java interface available?
- Original Message - From: "Charlie Smith" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, June 09, 2003 3:34 AM Subject: PERL/java interface available? Would anyone happen to know if there is a PERL/java interface where these two languages could talk to each other? Charlie Hi Charlie: Check out the 'Inline' modules on CPAN: http://search.cpan.org/author/INGY/Inline-0.44/Inline.pod You also may want to look at SWIG at: http://www.swig.org/ I have used Inline::C and SWIG for c and c++, but not for java; but they say they work... Aloha => Beau; PS: The 'Inline' modules are neat because your code is just that - inline; it's easier to see what's going on.
PERL/java interface available?
Would anyone happen to know if there is a PERL/java interface where these two languages could talk to each other? Charlie -- This message may contain confidential information, and is intended only for the use of the individual(s) to whom it is addressed. ==
Re: Java and Perl integration
-- "Lihn, Steve" <[EMAIL PROTECTED]> on 08/16/02 16:09:01 -0400 > Hi, > This may not be the most proper place to ask. > I am just curious if there is a way to call Java (or servlet) from Perl code > or such an integration project under way? Check the Inline module. It allows you to include Java (or C, C++, tkl, Python...) source in your Perl code. enjoi. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582
Java and Perl integration
Hi, This may not be the most proper place to ask. I am just curious if there is a way to call Java (or servlet) from Perl code or such an integration project under way? Steve Lihn -- Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (Whitehouse Station, New Jersey, USA) that may be confidential, proprietary copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please immediately return this by e-mail and then delete it. ==
[JOB] Apache/Perl/Java Developer Available
Hi all, I am currently seeking gainful employement in the San Diego, CA area. I'm interested in full-time or contract employement. I have lots of experience with Apache/mod_perl, databases and software design. Although I'm ashamed to admit it here, I do have experience with some other programming languages and platforms. My resume is available at http://alias-i.com/~ross/resume.html Thanks! Aaron
[JOB] Senior mod_perl / java developer for LRN, Southern California
Hey mod_perl & ASP Crew, I have the below job posting for this company LRN I have been contracting for this past couple years. They are looking for a senior developer with heavy mod_perl experience and some java too! This is a project that has snagged a few of us over the years, including our dear Ged Haywood, and our old friend Shane Nay ( where's he been anyway?! ) They really need a full time senior developer on site with the below skill sets. Is there anyone like this out there? If so, please send me resumes, code samples, etc., and I'll pass them along. Regards, Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks Founder Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051 Position Title: Web Software Developer Department: Development Brief Overview Of Position: The Web Software Developer will work with a team of other highly skilled developers to rapidly develop, deploy, and maintain Web applications based on LRN knowledge and content delivery platforms. List Essential Job Functions: - Responsible for new feature development, integrations, and extensions to our existing products - Instrumental in developing new features and applications, as well as designing and developing integrations between new and existing product offerings - Highly skilled professional software engineer, able to rapidly develop and deploy professional quality software - Independent learner, thinker, and quality minded individual; the difference between getting it done and doing it right! - Ability to learn new skills and development environments as technology landscape shifts - Conversant in both hardware and software in computer market - Ability to engage in and support position on design and development issues - Ability to lead and teach other both junior and senior developers - Good written and verbal communication skills Technical Skills Required: - 2 years minimum experience with mod_perl/Apache on UNIX platforms - 2 years minimum experience with Java & J2EE framework (including EJB and JSP) - Practical experience with high volume transactional RDBMS based web sites using DBI, preferably with Oracle - An intimate knowledge of Perl Object Oriented programming - Cross platform browser HTML eccentricities - Expertise in a wide variety of computer tools and development environments - Proven capabilities in programming and operating systems Previous Experience Required: - 5 years minimum industry experience - Experience with templates & component based architecture - Practical software engineering experience, including several full life cycles of specification, design, development paradigms, testing, deployment, documentation, and configuration management Education Required (Certifications, Degrees, Majors, etc.): - 4 year degree or equivalent industry experience Experience Preferred: - Oracle RDBMS programming (triggers, stored procedures, etc.) - Oracle 9iAS Portal Web services - Linux x86 - Solaris SPARC - Load balanced web clusters - SSL proxy servers - Caching proxy servers - Network engineering List Any Lifting or Physical Requirements of the Position: - None
RE: Java???
> Why does CPAN.org say "Comprehensive Java Archive Network" Don't forget to check the RFC sites today either. -- Steven Lembark 2930 W. Palmer Workhorse Computing Chicago, IL 60647 +1 800 762 1582
Re: Java???
On Mon, Apr 01, 2002 at 10:51:24AM -0500, John Von Essen wrote: > Why does CPAN.org say "Comprehensive Java Archive Network" Umm.. lets see.. maybe its got something to do with the phase of the moon.. no wait.. its just the day of the month. Ajit
Re: Java???
Think April 1... ;-) At 10:51 AM 4/1/02 -0500, John Von Essen wrote: >Why does CPAN.org say "Comprehensive Java Archive Network" > >-jve
Re: Java???
> Why does CPAN.org say "Comprehensive Java Archive Network" Because it's April Fools Day. xoxo, Andy -- 'Andy Lester[EMAIL PROTECTED] Programmer/author petdance.com Daddy parsley.org/quinn Jk'=~/.+/s;print((split//,$&) [unpack'C*',"n2]3%+>\"34.'%&.'^%4+!o.'"])
RE: Java???
April Fool!!! MM -Original Message- From: John Von Essen [mailto:[EMAIL PROTECTED]] Sent: Monday, April 01, 2002 9:51 AM To: Mod Perl Mailing List Subject: Re: Java??? Why does CPAN.org say "Comprehensive Java Archive Network" -jve
Re: Java???
Why does CPAN.org say "Comprehensive Java Archive Network" -jve
Re: Urgent: Can we get compiled codes(class files in java) in perl like in java
By 'compiled code ... just like that in Java' do you mean byte code? You may want to look at http://perlmonks.org/index.pl?lastnode_id=864&node_id=76685 which I found by searching for 'compiled' at perlmonks.org. Your client is making a strange request. Most people put a higher value on source code than object code, and mod_perl makes source execute as quickly as object code, on average. Side note: please wrap your lines at something like 70 characters. On Thu, Mar 07, 2002 at 11:48:51PM +0530, A.C.Sekhar wrote: > Hi all , >I need a help. My requirement is like this, we are developing one portal site >in perl5(mod_perl)-apache-linux. our client don't want the perl source code. He want >only the compiled code. Is it possible to give the compiled code in perl just like >that in Java? How can we do that, plz help us in this regard and tell me what to do >and how to do? This is a bit urgent... > > Thanks and Regards > A C Sekhar > -- mailto:[EMAIL PROTECTED] http://www.ece.utexas.edu/~thecap/ 28 70 20 71 2C 65 29 61 9C B1 36 3D D4 69 CE 62 4A 22 8B 0E DC 3E
Urgent: Can we get compiled codes(class files in java) in perl like in java
Hi all , I need a help. My requirement is like this, we are developing one portal site in perl5(mod_perl)-apache-linux. our client don't want the perl source code. He want only the compiled code. Is it possible to give the compiled code in perl just like that in Java? How can we do that, plz help us in this regard and tell me what to do and how to do? This is a bit urgent...Thanks and RegardsA C Sekhar
Re: perl with java
> I'm a java programmer. I don't know anything about > perl. I just want to know whether it's possible to > call servlets from perl scripts after validating some > data provided by the user. There's no simple way to use both in the same request. Maybe a subrequest would work, or maybe you could use mod_perl for an earlier handler and then use Tomcat for the content handler. There are also ways to directly call Perl from Java and vice-versa. It's ill-advised though. Hybrid solutions always have overhead involved in going from one to the other and they tend to combine the worst of both worlds and complicate maintenance and development. I'd advise against trying to mix the two in a single request. If you really have to use both, try to find a way to get the validation work done in the perl program and then redirect to the servlet. - Perrin
Re: perl with java
On Fri, 7 Dec 2001, nookala nagaraju wrote: > I'm a java programmer. I don't know anything about > perl. I just want to know whether it's possible to > call servlets from perl scripts after validating some > data provided by the user. Thank you very much. Sure -- if you have a servlet engine, like Tomcat running. They can behave just like CGI scripts and be the action of a form. There are also some ways of calling Java directly in Perl, using the Java.pm or Inline.pm modules, but I don't think they can handle servlets. -- Brett http://www.chapelperilous.net/ Life is a concentration camp. You're stuck here and there's no way out and you can only rage impotently against your persecutors. -- Woody Allen
perl with java
Hi! I'm a java programmer. I don't know anything about perl. I just want to know whether it's possible to call servlets from perl scripts after validating some data provided by the user. Thank you very much. nag. Nokia 5510 looks weird sounds great. Go to http://uk.promotions.yahoo.com/nokia/ discover and win it! The competition ends 16 th of December 2001.
Re: mod_perm and Java servlets
I've done both mod_perl and mod_jserv compiled and working on the same server.. I think it was a 2.5 meg httpd ;) > On Thu, 18 Jan 2001, Terry Newnham wrote: > > My boss has asked me to set up a web server on Solaris 8 with mod_perl > > and (if possible) Java servlet capabilities as well. Has anybody done > > this ? Any issues ? > > None that I know of, except that you really don't want the additional > memory overhead of mod_perl in a process that isn't using mod_perl. You > might save some memory by having a separate server that runs just > mod_perl, and having your jserv (or whatever) server send requests for > mod_perl apps to it using mod_proxy. See the mod_perl Guide for more info > on using a proxy with mod_perl. > > - Perrin -- __ JR Mayberry e-Vend.net Corporation Programmer and Systems Administrator(888) 427-8743 x226 tel [EMAIL PROTECTED]http://www.e-vend.net The information in this message (including attachments) is confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. ***
Re: mod_perm and Java servlets
I understand that mod_jk is more efficient than mod_jserv. My sysadmin has not complained about any problems integrating mod_perl or mod_jk (but then mod_jk is in the front-end as stated below where mod_perl is in the backend apache server). At 01:18 AM 1/18/2001 -0600, Les Mikesell wrote: >- Original Message - >From: "Terry Newnham" <[EMAIL PROTECTED]> >To: "mod_perl list" <[EMAIL PROTECTED]> >Sent: Wednesday, January 17, 2001 6:51 PM >Subject: mod_perm and Java servlets > > > > > > Hi > > > > My boss has asked me to set up a web server on Solaris 8 with mod_perl > > and (if possible) Java servlet capabilities as well. Has anybody done > > this ? Any issues ? > > >If you expect the server to be busy you will probably want to set up a >lightweight front end apache without mod_perl and let it proxy the >mod_perl jobs to another server. In this scheme it works well to >put apache jserve in the front end because it also uses a proxy-like >mechanism to hand off to the servlet engine (with load balancing >if you want to spread the servlets over multiple machines). The >only problem I've seen have been memory leaks in the servlets >causing the jvm to grow, but apache will restart it for you if you >have to kill it once in a while. > > Les Mikesell > [EMAIL PROTECTED] __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/
Re: mod_perm and Java servlets
- Original Message - From: "Terry Newnham" <[EMAIL PROTECTED]> To: "mod_perl list" <[EMAIL PROTECTED]> Sent: Wednesday, January 17, 2001 6:51 PM Subject: mod_perm and Java servlets > > Hi > > My boss has asked me to set up a web server on Solaris 8 with mod_perl > and (if possible) Java servlet capabilities as well. Has anybody done > this ? Any issues ? If you expect the server to be busy you will probably want to set up a lightweight front end apache without mod_perl and let it proxy the mod_perl jobs to another server. In this scheme it works well to put apache jserve in the front end because it also uses a proxy-like mechanism to hand off to the servlet engine (with load balancing if you want to spread the servlets over multiple machines). The only problem I've seen have been memory leaks in the servlets causing the jvm to grow, but apache will restart it for you if you have to kill it once in a while. Les Mikesell [EMAIL PROTECTED]
Re: mod_perm and Java servlets
Hello, TN>My boss has asked me to set up a web server on Solaris 8 with mod_perl TN>and (if possible) Java servlet capabilities as well. Has anybody done TN>this ? Any issues ? I've experimented with mod_perl and JRun on Solaris, and they've played together nicely. As long as you're hefty on memory, it'll likely be a while before you hit any significant memory problems as long as your load is distributed evenly between Perl and Java. If you use mostly one above the other, I'd do a proxied setup so you can scale them separately. The management is also easier. However, for a dev environment or a low-traffic one, having them co-exist is just fine. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: mod_perm and Java servlets
I've heard mod_perm costs a lot more than its worth. There was an open-source clone called mod_home_perm but it wasn't very successful. Some people say you should skip it altogether and just use mod_hat. On Thu, 18 Jan 2001, Terry Newnham wrote: > My boss has asked me to set up a web server on Solaris 8 with mod_perl > and (if possible) Java servlet capabilities as well. Has anybody done > this ? Any issues ? None that I know of, except that you really don't want the additional memory overhead of mod_perl in a process that isn't using mod_perl. You might save some memory by having a separate server that runs just mod_perl, and having your jserv (or whatever) server send requests for mod_perl apps to it using mod_proxy. See the mod_perl Guide for more info on using a proxy with mod_perl. - Perrin
mod_perm and Java servlets
Hi My boss has asked me to set up a web server on Solaris 8 with mod_perl and (if possible) Java servlet capabilities as well. Has anybody done this ? Any issues ? Terry
Re: Help me beat Java.
Hi Stas, On Wed, 13 Dec 2000, Stas Bekman wrote: > On Wed, 13 Dec 2000, G.W. Haywood wrote: > > There's a Perl to C translator but I don't tink you want to go there. > > It doesn't make the code run faster. It only helps if you want to hide the > source code (to make it harder to get to the source code :) > > and it won't work under mod_perl anyway. I know. I _said_ he didn't want to go there...:) 73, Ged.
Re: Help me beat Java.
On Wed, 13 Dec 2000, G.W. Haywood wrote: > Hi all, > > On Wed, 13 Dec 2000, Vivek Khera wrote: > > > j> 3. Is there a way to precomplie perl to machine code to > > > > Don't think so, but there could be. > > There's a Perl to C translator but I don't tink you want to go there. It doesn't make the code run faster. It only helps if you want to hide the source code (to make it harder to get to the source code :) and it won't work under mod_perl anyway. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Help me beat Java.
Hi all, On Wed, 13 Dec 2000, Vivek Khera wrote: > j> 3. Is there a way to precomplie perl to machine code to > > Don't think so, but there could be. There's a Perl to C translator but I don't tink you want to go there. 73, Ged.
Re: Help me beat Java.
>>>>> "j" == jleidigh <[EMAIL PROTECTED]> writes: j> faster. But now they want to do super tuning and also j> compare Resource consumption between JRun/Java Servlets j> and Apache/mod_perl. My main concern is the fact that j> apache/mod_perl child proccess can be as big as 12 MB. j> Specifically my question is j> 1. Is there a way to make mod_perl multi-threaded? Not until apache 2.0 and mod_perl 2.0 j> 2. Is there a way to lower this memory consumtion? Yes. See "The Guide". If they are going to compare Java servlets, then you must configure your mod_perl to act as a pure mod_perl server rather than a server that answers all requests. This is the front-end/back-end setup that The Guide describes. j> 3. Is there a way to precomplie perl to machine code to j> better perfomance? They are planning to do the same for j> Java and may gain performance. Don't think so, but there could be. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: Help me beat Java.
At 10:24 AM 12/13/00 -0300, jleidigh wrote: >I have written a awsome mod_perl module for Apache and >now my companie wants to transform it to Java (ik). Why would your company want to redevelop something from scratch in another language instead of making use of the product they have now that works? That seems really odd to be in a company that wishes to reinvent the wheel? >Nothing personal against java but 95% of the program is >regular expressions. Perl is king in this area. In >java they are using Oroinc 3rd party classes for the >regexs. With some prliminary bench mark test of non >mod_perl perl and Java, perl won being 12-20 times >faster. But now they want to do super tuning and also >compare Resource consumption between JRun/Java Servlets >and Apache/mod_perl. My main concern is the fact that >apache/mod_perl child proccess can be as big as 12 MB. >Specifically my question is > >1. Is there a way to make mod_perl multi-threaded? Yes, but not for the benefits you want. It doesn't matter if Perl is multi-threaded because two things lag behind -- Apache 2.0 as a multithreaded partner and CPAN modules that are within-Perl thread-safe. The first will happen given time, the 2nd is a problem that may never be solved (at least not for a year or two). >2. Is there a way to lower this memory consumtion? Some but not really that much other than being intelligent about preloading. Apache 2.0/mod_perl 2.0 models are supposed to be hooking into future versions of Perl to separate CODE and DATA segments within Perl itself. Right now Perl P-Code is mixed within data in Perl, so copy-on-write slowly degrades when it doesn't have to. >3. Is there a way to precomplie perl to machine code to >better perfomance? They are planning to do the same for >Java and may gain performance. Not really unless you are talking about not using mod_perl. I don't know of any servlet engines that exist that can load machine code compiled servlets though. I know TowerJ and products like that, but they compile an entire Java application, which doesn't fit well in the dynamically loadable apps. I think when you compile a Java app there is a possibility you may lose some capability of integrating with existing Java classesI think a similar thing holds true for compiling perl to machine code -- I am not sure if its ever gone beyond beta stage technology on Perl though. Anyway, we know that Java is better at some things. So I think its been said here before... Time to market may be an issue for your company. Can your company realistically afford to play with Java and do they really need those features you mentioned. Also, Java servlets is an app development technology. Mod_perl is MORE than that. But perhaps your company doesn't need that side of mod_perl. Anyway, Good Luck. Later, Gunther
Re: Help me beat Java.
> I have written a awsome mod_perl module for Apache and > now my companie wants to transform it to Java (ik). > Nothing personal against java but 95% of the program is > regular expressions. Perl is king in this area. In > java they are using Oroinc 3rd party classes for the > regexs. With some prliminary bench mark test of non > mod_perl perl and Java, perl won being 12-20 times > faster. But now they want to do super tuning and also > compare Resource consumption between JRun/Java Servlets > and Apache/mod_perl. My main concern is the fact that > apache/mod_perl child proccess can be as big as 12 MB. > Specifically my question is > > > 2. Is there a way to lower this memory consumtion? > I haven't had time to look into this, but Gunther mentioned a new module CGI::SpeedyCGI this enables persistent perl processes, outside of Apache. Could you reduce the number of Apache Children and replace them with SpeedyCGI backends? This should save memory and give you more waiting processes to answer requests! I haven't tested this but would be interested to know if anyone has done this comparison? I suppose it depends on whether or not you are using Apache:: modules that need to be tied into the server --- if not, then maybe SpeedyCGI will save you some memory? NIge
Re: Help me beat Java.
[some intro snipped] > and Apache/mod_perl. My main concern is the fact that > apache/mod_perl child proccess can be as big as 12 MB. even as big as 12.5MB :) > Specifically my question is > > 1. Is there a way to make mod_perl multi-threaded? http://perl.apache.org/~dougm/modperl_2.0.html > 2. Is there a way to lower this memory consumtion? http://perl.apache.org/guide/performance.html http://perl.apache.org/guide/performance.html#Know_Your_Operating_System > 3. Is there a way to precomplie perl to machine code to > better perfomance? They are planning to do the same for > Java and may gain performance. see #2 _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Help me beat Java.
I have written a awsome mod_perl module for Apache and now my companie wants to transform it to Java (ik). Nothing personal against java but 95% of the program is regular expressions. Perl is king in this area. In java they are using Oroinc 3rd party classes for the regexs. With some prliminary bench mark test of non mod_perl perl and Java, perl won being 12-20 times faster. But now they want to do super tuning and also compare Resource consumption between JRun/Java Servlets and Apache/mod_perl. My main concern is the fact that apache/mod_perl child proccess can be as big as 12 MB. Specifically my question is 1. Is there a way to make mod_perl multi-threaded? 2. Is there a way to lower this memory consumtion? 3. Is there a way to precomplie perl to machine code to better perfomance? They are planning to do the same for Java and may gain performance. Help me beat Java, please. _ UOLMAIL - Todo Argentino tiene derecho a tener su e-mail. http://www.uolmail.com.ar
RE: Perl vs Java (XML Modules)
>True. As for praise, XML::Parser does the job for me. In this specific >case, I'll be looking for something like failure in the >response to an XML request I send. I'd like to pull out just the section >that failed and be able to create another request from that XML chunk. >It's a little down the road, but I'm trying to plan today. If it's that simple, then try XML::Simple and use XMLin. That package makes basic XML stuff incredibly easy. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Perl vs Java (XML Modules)
Matt Sergeant wrote: > > On Tue, 5 Dec 2000, Drew Taylor wrote: > > > I know this goes a little off topic, so I apologize in advance. > > I changed the topic for you :-) But now it seems like flame bait ;-) > > One big sticking point with Perl I'm just starting to run into is XML. > > Yes, Perl has great XML modules, and many more promising ones. But where > > is the _validating_ XML parser? I'm doing some XML work where a > > validating parser would be very nice, speed hit or not. I can work > > around it easily (this is perl :-), but it would save me some work. > > XML::Checker. > Also see www.perl.com which links to Kip Hampton's XML.com article about > validating using XPath. I'll look more into XML::Checker. Apart from being alpha, it seems like it will work nicely. I guess I could help with the alpha status if I choose. :-) > > The XML & Java combination has a LOT more corporate resources (read $$$) > > focused on it than Perl & XML. How many Java-based XML software > > announcements have you seen lately? Now compare that to Perl-based XML > > modules. The numbers don't compare very well. What can we do about this? > > Very little, except produce our own XML modules that can do our work. And > you can help by praising those that do produce good XML modules and by > using the modules that work rather than those that don't (hint: XML::XPath > vs XML::DOM with XML::XQL). Apart from validation, what are you missing? True. As for praise, XML::Parser does the job for me. In this specific case, I'll be looking for something like failure in the response to an XML request I send. I'd like to pull out just the section that failed and be able to create another request from that XML chunk. It's a little down the road, but I'm trying to plan today. > > I can't help write a validating parser, but I would be happy to help > > test it out. IMHO, more XML support would help sell perl into more > > corporate settings. Java is big into buzzwords, and XML is one of the > > biggest there is at the moment. And as we know PHBs like buzzwords, so > > that is one more point in Java's favor. > > Actually XML is one area where mod_perl kicks Java's butt in some ways. > AxKit is *faster* than Cocoon. Please test and see for yourself if you > don't believe me. And building XML based web sites with AxKit is *really* > easy. I built modperl.sergeant.org in 10 days of spare time, including a > content management system for the news articles (note that half of the CMS > code is just a plain mod_perl handler). I'll stick an article online > shortly about how the site is constructed. When AxKit first came out, I was very excited about it but never had a chance to play with it. And it gives me (and you I'm sure) great pride that perl's XML app server is faster than the equivalent Java version. ;-) I hope to have a play server at home soon so that I can begin playing with cool new toys like AxKit and A0. My experience with XML is limited at the moment, but I'm learning quickly. -- Drew Taylor Software Engineer OpenAir.com - Making Business a Breeze! Open a free account today at www.openair.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Perl vs Java (XML Modules)
On Tue, 5 Dec 2000, Drew Taylor wrote: > I know this goes a little off topic, so I apologize in advance. I changed the topic for you :-) > One big sticking point with Perl I'm just starting to run into is XML. > Yes, Perl has great XML modules, and many more promising ones. But where > is the _validating_ XML parser? I'm doing some XML work where a > validating parser would be very nice, speed hit or not. I can work > around it easily (this is perl :-), but it would save me some work. XML::Checker. Also see www.perl.com which links to Kip Hampton's XML.com article about validating using XPath. > The XML & Java combination has a LOT more corporate resources (read $$$) > focused on it than Perl & XML. How many Java-based XML software > announcements have you seen lately? Now compare that to Perl-based XML > modules. The numbers don't compare very well. What can we do about this? Very little, except produce our own XML modules that can do our work. And you can help by praising those that do produce good XML modules and by using the modules that work rather than those that don't (hint: XML::XPath vs XML::DOM with XML::XQL). Apart from validation, what are you missing? > I can't help write a validating parser, but I would be happy to help > test it out. IMHO, more XML support would help sell perl into more > corporate settings. Java is big into buzzwords, and XML is one of the > biggest there is at the moment. And as we know PHBs like buzzwords, so > that is one more point in Java's favor. Actually XML is one area where mod_perl kicks Java's butt in some ways. AxKit is *faster* than Cocoon. Please test and see for yourself if you don't believe me. And building XML based web sites with AxKit is *really* easy. I built modperl.sergeant.org in 10 days of spare time, including a content management system for the news articles (note that half of the CMS code is just a plain mod_perl handler). I'll stick an article online shortly about how the site is constructed. -- /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: perl vs java
> Now, now...that is unfair. I was referring to writing in pure Perl vs pure > Java. > > Of course, C apis and pre-written daemon integration makes the glue > language a moot point (and favors Perl actually). Well, mine is pure perl. it can speak the protocol to integrate with a pre-written C irc daemon, but you don't *have* to use it with one. > BTW, is select() is still broken in Win32 Perl? It was 6 months ago (I > suspect because IO operates differently on win32) so you'd limit your > platform too. Last I heard, perl's select() under win32 worked for sockets, but not for pipes or ttys. Anyway, limiting myself to platforms where select() works doesn't strike me as a bad thing... -- Roger Espel Llima, [EMAIL PROTECTED] http://www.iagora.com/~espel/index.html
Re: perl vs java
On Tue, 13 Jun 2000, you wrote: > Now, now...that is unfair. I was referring to writing in pure Perl vs pure > Java. Admittedly it's not completely fair :-). I admitted that I would do (have done) it in c. Given a choice between C and perl that is. But as you say in the next paragraph, Perl is clearly a better choice than java on this. (Although if you're only supporting JDK1.1x and later, the ability to pass java objects over HTTP is really cool, and I used it extensively) > > Of course, C apis and pre-written daemon integration makes the glue > language a moot point (and favors Perl actually). > > BTW, is select() is still broken in Win32 Perl? It was 6 months ago (I > suspect because IO operates differently on win32) so you'd limit your > platform too. Honestly I don't know much about the Win32 platform. Until I had to use VMWare to look at a prototype for a product I was helping out with I hadn't used Windows in about 2 years. (BTW: Huge plug for VMWare, that's some REALLY cool software, not just for runing windows on linux, but testing other OSes... I can't say enough good stuff about vmware) Thanks, Shane.
Re: perl vs java
On Mon, 12 Jun 2000, Shane Nay wrote: > If I were to write a new version of the chat engine I wrote, I > wouldn't do it this way. In fact I started re-writing it based on a > sigqueues, and CORBA. Shane, you are a maniac! You wrote a chat server using sigqueues and CORBA? Isn't that like killing a mosquito with an atomic bomb? - Perrin
Re: perl vs java
Now, now...that is unfair. I was referring to writing in pure Perl vs pure Java. Of course, C apis and pre-written daemon integration makes the glue language a moot point (and favors Perl actually). BTW, is select() is still broken in Win32 Perl? It was 6 months ago (I suspect because IO operates differently on win32) so you'd limit your platform too. Later, Gunther At 06:21 PM 6/12/00 +, Shane Nay wrote: >(Somehow I missed Gunther's message, maybe I had a system out for a little >while, I'm replying to Roger, but really replying to Gunther) > > On Mon, 12 Jun 2000, you wrote: > > Gunther Birznieks <[EMAIL PROTECTED]> wrote: > > > 2. Would you write a chat engine in Perl? I wouldn't! (Well, actually > I did > > > 5 years ago but I am certainly not proud of that code). > >Hmm..., yes I would. At this point, long before I would write it in >Java. You >know why? Not because of anything in perl necessarily, but actually what you >can do with perl. You see, a perl XS module can take advantage of anything >inside of C. If I were to write a new version of the chat engine I wrote, I >wouldn't do it this way. In fact I started re-writing it based on a >sigqueues, >and CORBA. Corba pre-fetch of everything running around, dump into memory, >sigqueues pick up request from client via httpd protocol (obviously not port >80, this is a special purpose HTTPD engine). Stream out based on pre-fetched >CORBA content. I started writing it, but got distracted by the fact that >I ran >out of money :-), happens to the best of us. > >Java can talk to Corba natively, so the application side talks to the corba >server, and dumps/retrieves it's messages into there. Two threads involved in >the special purpose httpd engine. One that fetches content from the CORBA >engine, the other that streams out to clients based on sigqueus (Similar to >phhttpd, but much simpler). The locking issues on the Corba content is so >yucky I don't even want to discuss it (That's sort of where I left >off). I ran >some benchmarks, and the httpd engine could handle over 1000 requests per >second per server. The corba fetch was really trivial, so the only "problem" >was the communication between the applications and omniORB (Corba Object >Request Broker, really good piece of software BTW, best ORB out there in terms >of speed) > > > > > I did, just a few months ago, and it's working very nicely. > > > > > The thing about a real-time chat engine is the same issue as #1, it is > > > really inefficient resource-wise to flush messages to a persistent data > > > store or even using IPC shared memory in Perl in order to allow all the > > > Perl processes to share a common list of chat messages even if only > for the > > > last 5 minutes worth of chat. > > > > So don't do it like that :) My chat engine is a single-threaded, > > select()-based plain Perl daemon (no apache there) that takes http > > connections on a non-standard port, directly from the browser, and keeps > > them open for as long as the browser will. It speaks http on one end, > > and uses the irc-server-to-server protocol to talk to an ircd on the > > other. > >Well, yes that's the easiest way to do it with perl. The other way is to >write >some XS modules which plug into an sigqueue engine, and handle it that way. >Honestly though, if you're going to be writing XS modules to talk to signal >queues, you might as well write the damn thing in c :-). > > > Technically, yeah, select() is arguably ugly, but if you wrap it around > > OO classes for the various kinds of buffers and connections, it's all > > quite manageable. > >Select might be ugly, but it's how nearly every realtime system works. So if >you want a realtime system you need to look into select, poll (ugh), and >sigqueues. > > > Chat connections are very low bandwith, and a single-threaded design > > tends to be memory effective, so I'd expect this setup to handle a few > > hundred simultaneous users easily. If you want more, use a standard irc > > daemon as a hub, and connect several such perl servers to it; if you > > want to have a java applet client too, it can talk directly to the irc > > server. > >Nothing could be more true. Single thread is the ONLY way to go..., anything >other than that is a massive waste of trying to implement. > >Thanks, >Shane. > >-- > __ Gunther Birznieks ([EMAIL PROTECTED]) Extropia - The Web Technology Company http://www.extropia.com/
Re: perl vs java
(Somehow I missed Gunther's message, maybe I had a system out for a little while, I'm replying to Roger, but really replying to Gunther) On Mon, 12 Jun 2000, you wrote: > Gunther Birznieks <[EMAIL PROTECTED]> wrote: > > 2. Would you write a chat engine in Perl? I wouldn't! (Well, actually I did > > 5 years ago but I am certainly not proud of that code). Hmm..., yes I would. At this point, long before I would write it in Java. You know why? Not because of anything in perl necessarily, but actually what you can do with perl. You see, a perl XS module can take advantage of anything inside of C. If I were to write a new version of the chat engine I wrote, I wouldn't do it this way. In fact I started re-writing it based on a sigqueues, and CORBA. Corba pre-fetch of everything running around, dump into memory, sigqueues pick up request from client via httpd protocol (obviously not port 80, this is a special purpose HTTPD engine). Stream out based on pre-fetched CORBA content. I started writing it, but got distracted by the fact that I ran out of money :-), happens to the best of us. Java can talk to Corba natively, so the application side talks to the corba server, and dumps/retrieves it's messages into there. Two threads involved in the special purpose httpd engine. One that fetches content from the CORBA engine, the other that streams out to clients based on sigqueus (Similar to phhttpd, but much simpler). The locking issues on the Corba content is so yucky I don't even want to discuss it (That's sort of where I left off). I ran some benchmarks, and the httpd engine could handle over 1000 requests per second per server. The corba fetch was really trivial, so the only "problem" was the communication between the applications and omniORB (Corba Object Request Broker, really good piece of software BTW, best ORB out there in terms of speed) > > I did, just a few months ago, and it's working very nicely. > > > The thing about a real-time chat engine is the same issue as #1, it is > > really inefficient resource-wise to flush messages to a persistent data > > store or even using IPC shared memory in Perl in order to allow all the > > Perl processes to share a common list of chat messages even if only for the > > last 5 minutes worth of chat. > > So don't do it like that :) My chat engine is a single-threaded, > select()-based plain Perl daemon (no apache there) that takes http > connections on a non-standard port, directly from the browser, and keeps > them open for as long as the browser will. It speaks http on one end, > and uses the irc-server-to-server protocol to talk to an ircd on the > other. Well, yes that's the easiest way to do it with perl. The other way is to write some XS modules which plug into an sigqueue engine, and handle it that way. Honestly though, if you're going to be writing XS modules to talk to signal queues, you might as well write the damn thing in c :-). > Technically, yeah, select() is arguably ugly, but if you wrap it around > OO classes for the various kinds of buffers and connections, it's all > quite manageable. Select might be ugly, but it's how nearly every realtime system works. So if you want a realtime system you need to look into select, poll (ugh), and sigqueues. > Chat connections are very low bandwith, and a single-threaded design > tends to be memory effective, so I'd expect this setup to handle a few > hundred simultaneous users easily. If you want more, use a standard irc > daemon as a hub, and connect several such perl servers to it; if you > want to have a java applet client too, it can talk directly to the irc > server. Nothing could be more true. Single thread is the ONLY way to go..., anything other than that is a massive waste of trying to implement. Thanks, Shane. --
Re: Perl vs Java [Now OT]
On Mon, 12 Jun 2000, Gunther Birznieks wrote: > >Unless you use a cluster of servers for load balancing and high > >availability, in which case you're right back where you started and you > >need the Java equivalent of Apache::Session::DBI. I imagine someone has > >written one in one of the many servlet runners out there. > > 1) Many load balancers actually recognize this and do provide some load > balancing on IP address. This is definately not perfect of course (when you > have ISP proxies like AOL)... and then when a machine goes down, it's just > tough luck that the user has to get redirected and relogin or do whatever > for the session. It's that second part that is a problem for me. We do a write-through cache to deal with this, i.e. we write all data to both a local cache (shared memory, courtesy of BerkeleyDB 3) and a shared database. Reads check the cache first, and don't bother to go to the database unless what they want isn't cached. If a machine fails, we only lose the cache. I know some of the commercial java stuff does the same thing and provides a nice API for using it. Threading certainly does have its allure, and I agree that Apache::Session is neat and that Perl's TIE mechanism is inadequate for the job. - Perrin
Re: perl vs java
Gunther Birznieks <[EMAIL PROTECTED]> wrote: > 2. Would you write a chat engine in Perl? I wouldn't! (Well, actually I did > 5 years ago but I am certainly not proud of that code). I did, just a few months ago, and it's working very nicely. > The thing about a real-time chat engine is the same issue as #1, it is > really inefficient resource-wise to flush messages to a persistent data > store or even using IPC shared memory in Perl in order to allow all the > Perl processes to share a common list of chat messages even if only for the > last 5 minutes worth of chat. So don't do it like that :) My chat engine is a single-threaded, select()-based plain Perl daemon (no apache there) that takes http connections on a non-standard port, directly from the browser, and keeps them open for as long as the browser will. It speaks http on one end, and uses the irc-server-to-server protocol to talk to an ircd on the other. Technically, yeah, select() is arguably ugly, but if you wrap it around OO classes for the various kinds of buffers and connections, it's all quite manageable. Chat connections are very low bandwith, and a single-threaded design tends to be memory effective, so I'd expect this setup to handle a few hundred simultaneous users easily. If you want more, use a standard irc daemon as a hub, and connect several such perl servers to it; if you want to have a java applet client too, it can talk directly to the irc server. -- Roger Espel Llima, [EMAIL PROTECTED] http://www.iagora.com/~espel/index.html
Re: Perl vs Java [Now OT]
At 06:01 PM 6/11/00 -0700, Perrin Harkins wrote: >On Sun, 11 Jun 2000, Gunther Birznieks wrote: > > 1. Session management. Because servlets are multi-threaded they have easy, > > quick access to a shared memory pool. All the locking and shared > > persistence code used in Apache::Session is rendered moot by the shared > > memory Java model. > >Unless you use a cluster of servers for load balancing and high >availability, in which case you're right back where you started and you >need the Java equivalent of Apache::Session::DBI. I imagine someone has >written one in one of the many servlet runners out there. > >- Perrin 1) Many load balancers actually recognize this and do provide some load balancing on IP address. This is definately not perfect of course (when you have ISP proxies like AOL)... and then when a machine goes down, it's just tough luck that the user has to get redirected and relogin or do whatever for the session. 2) On the flip side of that, Java has commercial products that handle this type of shared persistence -- one that comes to mind is Gemstone. Even so, there are a lot of things about Java that make creating a session persistence engine "easier". For example, you could easily have a middleware java session persistence engine which is actually keeping all of the stuff in RAM, but then running a low-level thread to write stuff out to a database as it changes. Plus keeping a socket open to each servlet engine that it wants to let know a change in the real session made. It's very very difficult to do the same type of architectures in Perl that you can do with Java precisely because Perl is not a multi-threaded language and never will be as robust in that area -- even if Perl becomes robust in this area, the modules will have to be written to support this as well. Anyway, all languages have their advantages and disadvantages, but in cases such as session handling, Java Servlets wins out big time. Apache::Session is awesome for Perl, But take a look at all the hoops that Jeffrey has to go through to maintain it and the code inside. It's a tough piece of code because it is a matter of sharing a persistent session data amongst a whole bunch of processes that don't know anything about anyone else. And even then. Programmers of Apache::Session still have to remember to do stuff like manually set a timestamp or flush out the session data to disk if a reference to a reference in a swizzled data structure is changed becuase there is no way for the TIE interface to recognize it. These complexities are simply non-issues in Java Servlets because of the in-memory aspect. Anyway, I am not saying it is bad, Apache::Session is great! But it's definately hampered by Perl's architecture. Later, Gunther __ Gunther Birznieks ([EMAIL PROTECTED]) Extropia - The Web Technology Company http://www.extropia.com/
Re: Perl vs Java [Now OT]
WAY OT at this point :) > [OT] > My personal take: > Where (at least for me) Java has it's niche is client side, for > applets and applications. But for this, 'write once use anywhere' just > isn't true. Look at Java1.3 (which you really want to use for > GUI-intensive stuff, though their event/keyboard handling is really not > well thought out): Available on Windows. Period. In a year it *might* > be out for Linux, and in maybe 1.5 years for FreeBSD (native). Mac? > Probably not (other than OSX). This is true, I haven't looked at 1.3's event handling, but honestly what would you prefer? A single event loop? Come on.., the 1.1+ event strategy was 100x better than 1.0.2. 1.0's event handling was crap, and that's what most event loops are designed like. This was one area where I felt java technology was really far ahead. (ActionListeners are key) > Server side it looks better, you don't need the GUI and so Java 1.1x > is fine, and fairly available. But you can still write most things way > faster in perl than in Java. And in my experience 'time to market' is > way more importatnt than a program that 'looks cleaner' or maybe runs > faster with less memory consumption. And it seems that speed/memory > wise Java doesn't do any better than perl. Hmm., well..., here's my gripe with this. Server side perl is a really fast developement tool. GUI side java is a really fast developement tool. Why would you take a language that was clearly designed for GUI developement, that all it's strengths lie with GUI, and try to make it a server language?..., it's preposterous. It doesn't even have REGEX's natively..., what the hell is that!?!?! (Note: there is a really good regex library that's mostly free for java, not nearly as fast as perl native) > One advantage Java might have over Perl is that in a team environment > Java is easier to maintain. It is not that easy to goof up in Java as > badd as you can in perl, and there is just 'less language' to confuse > your fellow developer with. But again this comes with a development > speed penalty. Hehe, the funny thing is that Java is actually a huge language. I mean HUGE. But 95% of it is GUI. So if the language designers are put 95% into the GUI... well, that speaks volumes to me. String handling sucks, and GUI handling is good. If String handling isn't good..., was it designed for pushing strings to webbrowsers? Java is pretty easy to maintain, but proper perl modules are also easy to maintain. But what I see in the field is people not spending a lot of time to make good modules. Instead they're pushing projects out fast, which is easy to do. Perl doesn't put any restrictions on the developer, they are free to do things however they like. So you can have beautiful class/module hierarchies in Perl, and you can have a bunch of flat files that are impossible to make any mods to. In Java everything MUST be a class. So it forces you to design things right. But the underlying problem is what's right for one thing isn't right for others. So Perl becomes sort of a "tool for any job", Java becomes a tool only for a long term project. (Overhead to start) Shane. > > Gerd > >
Re: Perl vs Java
Well, I'll just drop my $.02 into this discussion. I've done a lot of both. The site from which this email is coming from (isupportlive.com) is developed in java technology start to finish. Everything is either a .jsp, or straight servlet. I've also developed a lot of other sites using modperl, and cgi's. (Cgi's a few years ago, but everything for the last couple years has been modperl) Also for the isupportlive site there are java applications, and java applets that use the servlets as their inter-communication method. So given that information, I'll give you the run down on how I feel about it. After spending 6 months developing all that stuff, I think it would have been wise to have the entire backend done in C or perl instead. I've done bench marks on both, and Java is a huge memory hog, and not too much in the way of stable. Speed wise, a perl solution would have been better, but really for what I was doing C is the only way to go, or maybe threaded perl when modperl2 comes out. There's a lot of cool stuff "built in" to servlet technology that's not immediatly obvious in perl technology. But with stuff like Embperl, Apache::ASP, and Mason, it sort of levels the playing field. The worst thing about Java though for me is that the community isn't as "giving". The perl community is built on a very open tradition, and the language itself is more extendable with native plugins. (I.e. you can build something in C in XS, and have it run non interpretted) So the MOST important thing about perl is, well..., basically you guys!, the perl community. Java doesn't have that. Native languages have it, but not as organized as CPAN, etc. Java doesn't have it... not at all. People are not nearly as open with their class files as people are with their .pm's. Honestly though..., I love the java language. But the best thing about java has nothing to do with Servlets. It has everything to do with the GUI class layout. The inheritence there is pure beauty. Have you every tried to use String tokens in java and run a benchmark on it and compared it to a regex? PATHETIC. String handling is crap in Java. The explanations I've heard are overhead for creating string objects for each token seperator. Oh well, those are my disorganized thoughts :-) Shane. On Sun, Jun 11, 2000 at 09:37:14AM -0600, dreamwvr wrote: > hi, >this could be a can of worms but anyhow here goes. Has anyone timed the > actual efficiency of Perl vs Java? Reason being is i wrote a state engine as > a perl module that seemed quite fast ~ 0.33 to 0.54 of a second for slurping > up values. With recall being about .25 to .35 of a second which seemed quit fast > to me. Then i was shown a jsp page which i really don't know much about.. > reminded me actually of SSI syntax wise. Well it was doing the same thing using > Java persistance objects and seemed very fast. Any idea how the languages > compare as always trying to use the best tool for the job. > TIA > [EMAIL PROTECTED]
Re: Perl vs Java [Now OT]
They pretty much all support Perl. Very few if any would ever support mod_perl at US$10/month. There is a list of ISPs in the guide (or on the web site?) that support mod_perl, but you have to expect to pay more than US$10/month for those services. At 12:53 PM 6/12/00 +1000, Peter Skipworth wrote: >Sorry to butt in - I'm sure this question is answered elsewhere, but is >there a list of "$10 a month ISPs" supporting perl and/or mod_perl code >somewhere on the web ? > >Thanks, > >P > > > > The other thing is portability. In Perl, I can test everything I do >on a > > $10 a month ISP and yet scale it to a mod_perl server later. Can't do that > > with Java servlets. Try finding a $10 a month ISP that supports servlets... >.-. >| Peter SkipworthPh: 03 9897 1121 | >| Senior Programmer Mob: 0417 013 292 | >| realestate.com.au [EMAIL PROTECTED] | >`-' __ Gunther Birznieks ([EMAIL PROTECTED]) Extropia - The Web Technology Company http://www.extropia.com/
Re: Perl vs Java [Now OT]
Sorry to butt in - I'm sure this question is answered elsewhere, but is there a list of "$10 a month ISPs" supporting perl and/or mod_perl code somewhere on the web ? Thanks, P > The other thing is portability. In Perl, I can test everything I do on a > $10 a month ISP and yet scale it to a mod_perl server later. Can't do that > with Java servlets. Try finding a $10 a month ISP that supports servlets... .-. | Peter SkipworthPh: 03 9897 1121 | | Senior Programmer Mob: 0417 013 292 | | realestate.com.au [EMAIL PROTECTED] | `-'
Re: Perl vs Java [Now OT]
hi, this has been great! although my thoughts were that DB_File is way faster than anything there is in java as a state engine.. but then again i could be wrong.. been there done that! Best Regards, [EMAIL PROTECTED] > Unless you use a cluster of servers for load balancing and high > availability, in which case you're right back where you started and you > need the Java equivalent of Apache::Session::DBI. I imagine someone has > written one in one of the many servlet runners out there. > > - Perrin
Re: Perl vs Java [Now OT]
On Sun, 11 Jun 2000, Gunther Birznieks wrote: > 1. Session management. Because servlets are multi-threaded they have easy, > quick access to a shared memory pool. All the locking and shared > persistence code used in Apache::Session is rendered moot by the shared > memory Java model. Unless you use a cluster of servers for load balancing and high availability, in which case you're right back where you started and you need the Java equivalent of Apache::Session::DBI. I imagine someone has written one in one of the many servlet runners out there. - Perrin
Re: Perl vs Java [Now OT]
At 06:39 PM 6/11/00 -0500, Gerd Knops wrote: >dreamwvr wrote: > > hi Gerd, > > that was very much what i was looking for! hmm.. seems that perl is > > definately one of the most mem efficient langs whereas java is not. > > cool and definately great reading although "talk about detail!" this > > is good! Java has become acceptable for a compiled language. now here > > is a question i really am trying to understand. i really see java's > > greatest virtue of write once use anywhere being less sensational > > once perl becomes fully compiled lang. Well it will take some reading > > but definately is fascinating reading. Thanks! > > >[OT] >My personal take: >Where (at least for me) Java has it's niche is client side, for >applets and applications. But for this, 'write once use anywhere' just >isn't true. Look at Java1.3 (which you really want to use for >GUI-intensive stuff, though their event/keyboard handling is really not >well thought out): Available on Windows. Period. In a year it *might* >be out for Linux, and in maybe 1.5 years for FreeBSD (native). Mac? >Probably not (other than OSX). Yeah. Although applets can be useful for doing certain tricks such as providing real time pricing feeds to a web based trading engine using persistent HTTP streams. >Server side it looks better, you don't need the GUI and so Java 1.1x >is fine, and fairly available. But you can still write most things way >faster in perl than in Java. And in my experience 'time to market' is >way more importatnt than a program that 'looks cleaner' or maybe runs >faster with less memory consumption. And it seems that speed/memory >wise Java doesn't do any better than perl. I would disagree about speed/memory wise that Java does not do any better than Perl. I think algorithmically this is true, but there are some practicalities that would be REALLY interesting to benchmark. Here are a couple of things I would EXPECT would be much faster in Java than Perl if you benchmarked a program that made use of the following features: 1. Session management. Because servlets are multi-threaded they have easy, quick access to a shared memory pool. All the locking and shared persistence code used in Apache::Session is rendered moot by the shared memory Java model. 2. Would you write a chat engine in Perl? I wouldn't! (Well, actually I did 5 years ago but I am certainly not proud of that code). The thing about a real-time chat engine is the same issue as #1, it is really inefficient resource-wise to flush messages to a persistent data store or even using IPC shared memory in Perl in order to allow all the Perl processes to share a common list of chat messages even if only for the last 5 minutes worth of chat. Furthermore, if your chat engine supports an applet trick to keep an HTTP stream open consistently pulling messages out of the stream, then launching a separate Perl interpreter for each HTTP stream carries a lot of overhead that simply having another thread off to the side does not have. BTW, I would recommend the highest versions of JDK (stable) for server side java, as the higher JDKs do tend to be faster and tend to have more recent versions of libraries built for them (eg XML coding). >One advantage Java might have over Perl is that in a team environment >Java is easier to maintain. It is not that easy to goof up in Java as >badd as you can in perl, and there is just 'less language' to confuse >your fellow developer with. But again this comes with a development >speed penalty. I would agree with this. It does take longer to develop stuff in Java. The other thing is portability. In Perl, I can test everything I do on a $10 a month ISP and yet scale it to a mod_perl server later. Can't do that with Java servlets. Try finding a $10 a month ISP that supports servlets... Perl has a greater open source community because economic and technical boundaries do not exist for Perl that do exist for Java when writing web applications. Later, Gunther
Re: Perl vs Java [Now OT]
dreamwvr wrote: > hi Gerd, > that was very much what i was looking for! hmm.. seems that perl is > definately one of the most mem efficient langs whereas java is not. > cool and definately great reading although "talk about detail!" this > is good! Java has become acceptable for a compiled language. now here > is a question i really am trying to understand. i really see java's > greatest virtue of write once use anywhere being less sensational > once perl becomes fully compiled lang. Well it will take some reading > but definately is fascinating reading. Thanks! > [OT] My personal take: Where (at least for me) Java has it's niche is client side, for applets and applications. But for this, 'write once use anywhere' just isn't true. Look at Java1.3 (which you really want to use for GUI-intensive stuff, though their event/keyboard handling is really not well thought out): Available on Windows. Period. In a year it *might* be out for Linux, and in maybe 1.5 years for FreeBSD (native). Mac? Probably not (other than OSX). Server side it looks better, you don't need the GUI and so Java 1.1x is fine, and fairly available. But you can still write most things way faster in perl than in Java. And in my experience 'time to market' is way more importatnt than a program that 'looks cleaner' or maybe runs faster with less memory consumption. And it seems that speed/memory wise Java doesn't do any better than perl. One advantage Java might have over Perl is that in a team environment Java is easier to maintain. It is not that easy to goof up in Java as badd as you can in perl, and there is just 'less language' to confuse your fellow developer with. But again this comes with a development speed penalty. Gerd
Re: Perl vs Java
hi Gerd, that was very much what i was looking for! hmm.. seems that perl is definately one of the most mem efficient langs whereas java is not. cool and definately great reading although "talk about detail!" this is good! Java has become acceptable for a compiled language. now here is a question i really am trying to understand. i really see java's greatest virtue of write once use anywhere being less sensational once perl becomes fully compiled lang. Well it will take some reading but definately is fascinating reading. Thanks! [EMAIL PROTECTED]
Re: Perl vs Java
On Sun, 11 Jun 2000, Matt Sergeant wrote: > There are posts in the archive about this. Here's a quick summary: > > You can make Java slow. You can make mod_perl slow. > Java (servlets, jsp, etc) can use a lot of memory. mod_perl can use a lot > of memory. > Servlets can be very fast. mod_perl can be very fast. > > I think that covers most of the arguments. This cracked me up! Thanks Matt. - Perrin
Re: Perl vs Java
dreamwvr wrote: > hi, > this could be a can of worms but anyhow here goes. Has anyone timed > the actual efficiency of Perl vs Java? > > [cut] > I found this of some interest: Computer Languages compared http://wwwipd.ira.uka.de/%7Eprechelt/documents/jccpp_tr.pdf Gerd
Re: Perl vs Java
hi, thanks.. well i walked into that one;-)) anyways really was trying to see which was better from a web serving point of view.. in maintaining state between cgi pages.. since i have not done any real java proggies since the first year of jdk coming out i really was surprised how fast it was since my previous experience had been that java was very slow. yeah..yeah the args about scripting vs compiled to go on forever but just wanted to see which offered the best efficiency according to tests that had been made using basically the same i/o . TIA
Re: Perl vs Java
On Sun, 11 Jun 2000, dreamwvr wrote: > hi, >this could be a can of worms but anyhow here goes. Has anyone timed the > actual efficiency of Perl vs Java? Reason being is i wrote a state engine as > a perl module that seemed quite fast ~ 0.33 to 0.54 of a second for slurping > up values. With recall being about .25 to .35 of a second which seemed quit fast > to me. Then i was shown a jsp page which i really don't know much about.. > reminded me actually of SSI syntax wise. Well it was doing the same thing using > Java persistance objects and seemed very fast. Any idea how the languages > compare as always trying to use the best tool for the job. There are posts in the archive about this. Here's a quick summary: You can make Java slow. You can make mod_perl slow. Java (servlets, jsp, etc) can use a lot of memory. mod_perl can use a lot of memory. Servlets can be very fast. mod_perl can be very fast. I think that covers most of the arguments. -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Perl vs Java
hi, this could be a can of worms but anyhow here goes. Has anyone timed the actual efficiency of Perl vs Java? Reason being is i wrote a state engine as a perl module that seemed quite fast ~ 0.33 to 0.54 of a second for slurping up values. With recall being about .25 to .35 of a second which seemed quit fast to me. Then i was shown a jsp page which i really don't know much about.. reminded me actually of SSI syntax wise. Well it was doing the same thing using Java persistance objects and seemed very fast. Any idea how the languages compare as always trying to use the best tool for the job. TIA [EMAIL PROTECTED]
