It is more a matter of scale and security than anything else. If your not working multiple teams of developers with multiple protocols and storage types and you already have perl expertise then go perl!

Java would be a significant development delay as well as well as a possible architectural burden otherwise. For the most part Java is time and performance overkill, but when it comes to unifiying a large application out of many multiple applications Java is worth the penalties.

Now the key phrase here is application language, the structure and the elegence of java comes directly from its close ties to OO. A good design falls into code when you use java. Large applications IMHO are best written in such a way. However the devil is in the implementation, java suffers from some grave implimentation issues. The java VM is bloated and even with recent advances (Hotspot et al) it still does not offer the performance that one would want. This means specifically that the java implimentations are not suited to large applications. It is this split that is the killing java projects atm, it just does not function.

Specifically with regard to java in an application server, I have no experience of Enhydra so cant comment on it directly, but in general terms it is my experience that java application servers provide a level of indirection between the coder and his code that makes debugging, maintenance and deployment more complex than it could be. They also seem to suffer from the general Java malayse (sp?) of bloat.

So in general I cannot say that perl is a good solution as I have no direct experience of using perl in this way, however it is my experience as a practicing java programmer that much as I really like the language I would not select it over perl if I had the decision before me.

Thanks so much for your reply.

you make some good points. Most interesting is that if you had a language choice on a new project, you'd choose perl.

Thanks again. I think that we will begin our development with perl, mod_perl, et. al. and parallel we'll flush out our java skills so that we can have the flexibility to choose whichever tool based on the project requirements.

:)

Aww man, and I had answered this so succinctly in QnA:
Go with your strong points and experience. Either is well suited to the task you have.

--
$you = new YOU;
honk() if $you->love(perl)

yes you did! Thanks so much for your reply.

The bottom line is that we'll be going with a perl solution.

Wheee!

I'm thinking mod_perl, HTML::Mason, Apache::Session, and Apache::DBI to start. Might need to throw in some XML eventually... (gotta be buzz word compliant) :)

If the mod_perl stuff gets icky we'll just fall back to good 'ol mod_perl, Apache::Registry, and CGI...
Thanks again!

The bottom line is always to look towards where your needs will be six months, a year, two years from now because any time you don't plan that way you can guarantee that that code will come back to haunt you...

I am a big Mason fan -- I've used it extensively across the sites that I build and maintain: here (side note: try using lynx -- it's a small vanity, but I wanted to write the component anyway).

From my standpoint, I particularly like the object-like features added to Mason 0.89 (methods, quasi-static variables, attributes), because they allow you to seperate the formatting from the content very effectively.

But wait, I'm doing OO in Perl... maybe Java would be the right answer?

Of course, it all depends -- on how many people are going to be hitting your inventory system, what kind of wait they're willing to accept, what kind of overhead the system can have...

The persistence of Java objects beyond the scope of the request and their ability to talk between machines is a distinct asset in some circumstances. The ease of writing Perl code and parsing/embedding text is an asset in others.

With Mason around there's no excuse for resorting to CGI -- Mason makes outputting any kind of HTML easier -- but as much as I prefer Perl for almost anything, don't just jump for the easy answer until you've made a full assesment: first of your needs, then your capabilities, and finally of the languages themselves.

It's a truism that most programming projects fail in the planning stage because critical assumptions are overlooked and the requirements not fully spelled out. I'd strongly urge you to fully develop the Use Cases, Entity Relationships and all that other annoying crap first and then come back with the question: java or perl?