Java Why Choose Java Over Python, Perl, or PHP for Enterprise Web Development?

[dduardo]

In terms of enterprise web development why would you choose Java over Python/Perl/PHP? I ask this question because I've done significant web development with both Python and PHP and have recently been dabbling with jboss/tomcat/j2ee and have found that Java is very cumbersome. Not only is it a pain to program for, it is a resource hog. My personal opinion is that Java is an unweildly language obfuscated by marketing/legal mumbo jumbo. Just trying to find/download anything from Sun's website requires an immense amount of patience. I've come to the conclusion that the only companies wanting to implement any web frontend/backend in Java have a huge burning hole in their pockets.

Sorry if this sounds like a rant, but I just want some honest responses.

 

[chroot]

For back-end web development, I'd pick one of the text-processing-oriented languages like PHP, too. If I needed object-orientation, I'd pick Python.

- Warren

 

[dduardo]

I totally agree. Then why are so many companies investing in Java? Is there something special that Java provides that would compel them to choose this technology? I think Yahoo got it right:

"Yahoo is a cheap company. It can't afford to waste engineering resources."

They are currently running on php with a sprinkling of python.

 

[so-crates]

If you wanted to do anything multi-threaded, or distributed, Java makes it pretty easy.

I have not found Java servlets to be that cumbersome. I haven't tried the J2EE/Struts stuff.

PHP is good for doing simple things - but becomes a pain for large, complex projects because it is untyped.

Last time I tried Python, their DB support wasn't up to snuff, at least for the DBs I was using - PostgresSQL and MySQL(yeah I know - yuck)

 

[graphic7]

If you wanted to do anything multi-threaded, or distributed, Java makes it pretty easy.

I have not found Java servlets to be that cumbersome. I haven't tried the J2EE/Struts stuff.

PHP is good for doing simple things - but becomes a pain for large, complex projects because it is untyped.

Last time I tried Python, their DB support wasn't up to snuff, at least for the DBs I was using - PostgresSQL and MySQL(yeah I know - yuck)

Perl and Java both have the best DBCs. Even moreso, Java's DBC support is more optimized for higher-end databases like Oracle or Sybase.

 

[graphic7]

My personal opinion is that Java is an unweildly language obfuscated by marketing/legal mumbo jumbo. Just trying to find/download anything from Sun's website requires an immense amount of patience. I've come to the conclusion that the only companies wanting to implement any web frontend/backend in Java have a huge burning hole in their pockets.

Well Sun's target for Java is the professional market, not hobbyists. Java is a resource hog - 1.5 isn't that bad, but 1.4 and 1.3 both had some issues. Where Java really shines for web programming is high volume sites. You should hear some of the nightmares of people running Apache and trying to serve a high amount of users with a Perl frontend. You'll hear about all sorts of hacks (mod_perl hacks and DBC modifications) , etc. to help ease all the simultaneous database connections that are going on. I've heard of similar nightmares with Python and PHP.

Also, most companies that do use Java for web frontends don't worry about the complexities of Struts, J2EE, etc. They have programmers that just worry about writing the frontend, and system administrators that implement the applications once they've been written. I'm sure you're finding it tedious to try to program with Java and maintain a J2EE configuration. That's not what any real environment will be like, though.

 

[dduardo]

Python makes mutli-threading a piece of cake. Two interfaces are provided. The low level interface and the easy way is to basically do this:

start_new_thread(function_name, args)

You can't get any simpler than that.

The other interface is high level uses the thread class. You pass the target and various other parameters to the constructor. To start the thread you do threadname.start(). You can even daemonize a thread by using the setDaemon function.

------

As for distributed computing, just check out the original Bit torrent project. IBM also offers a good intro into grid computing with python:

http://www-106.ibm.com/developerworks/edu/gr-dw-grpintro-i.html

------

If Yahoo isn't big enough I don't know what is. Also check out Sourceforge.

------

I haven't had an issues with the postgresql bindings. If it is an issue you can always create a c++ module that uses the c++ bindings that you import into your programs. But I guess that's what they do already anyway.

 

[dduardo]

Also, most companies that do use Java for web frontends don't worry about the complexities of Struts, J2EE, etc. They have programmers that just worry about writing the frontend, and system administrators that implement the applications once they've been written. I'm sure you're finding it tedious to try to program with Java and maintain a J2EE configuration.

That's a major problem. You need more people maintaining and as a result costs a lot more money. I would prefer to throw more computers at the problem than pay full salaries.

 

[master_coda]

That's a major problem. You need more people maintaining and as a result costs a lot more money. I would prefer to throw more computers at the problem than pay full salaries.

I agree. Almost any language can be made to work in a situation if you're willing to throw enough time and money at it. What does that tell you about the language? Almost nothing.

People are far too willing to forgive programmers and companies that produce overly complex products and then justify it after the fact by claiming that the tool is only "designed for professionals". There's a big difference between "designed for professionals" and "you need lots of time and money to burn in order to make this work". The second doesn't necessarily imply the first.

 

[graphic7]

People are far too willing to forgive programmers and companies that produce overly complex products and then justify it after the fact by claiming that the tool is only "designed for professionals". There's a big difference between "designed for professionals" and "you need lots of time and money to burn in order to make this work". The second doesn't necessarily imply the first.

Are you referring to Java in this statement?

 

[so-crates]

If Yahoo isn't big enough I don't know what is. Also check out Sourceforge.

And what language does Yahoo use for Yahoo! Games?

 

[master_coda]

Are you referring to Java in this statement?

Somewhat; for things like J2EE (which actually was designed for large, heavyweight systems) I don't think it's wrong to tell someone that this tool wasn't designed for them. So long as it's done up front.

 

[graphic7]

Somewhat; for things like J2EE (which actually was designed for large, heavyweight systems) I don't think it's wrong to tell someone that this tool wasn't designed for them. So long as it's done up front.

Well, if you disect the J2EE acronym you get Java 2 Enterprise Edition. This should tell you whether or not it's designed for you. I won't argue the fact that J2EE is a very complex product. You have Tomcat, ant (I believe, they're including this nowadays), and the whole administration interface, a few plugins for LDAP, Web Start (this allows rapid remote deployment of Java applications - very nice, too), plus J2SE.

Disecting J2SE, we have Java 2 Standard Edition. I don't think anyone would argue that J2SE is overly complex. There's the JVM, the bytecode compiler, source code, the API documentation, a few other little things (like the debugger, remote debugger, Web Start client, etc.)

 

[dduardo]

And what language does Yahoo use for Yahoo! Games?

so-crates, of course Java can be used to make online games, but I actually prefer flash games because the stupid JVM doesn't keep on crashing. Regardless, the focus of this thread is on server-side programming, not client-side.

 

[dduardo]

Well, if you disect the J2EE acronym you get Java 2 Enterprise Edition. This should tell you whether or not it's designed for you. I won't argue the fact that J2EE is a very complex product. You have Tomcat, ant (I believe, they're including this nowadays), and the whole administration interface, a few plugins for LDAP, Web Start (this allows rapid remote deployment of Java applications - very nice, too), plus J2SE.

This is what I mean by marketing mumbo jumbo. If I forked Python and renamed it to Python Enterprise Edition, other than being a really bad acronym (PEE) , does this make it any more appropriate for enterprise level programming?

 

[master_coda]

Well, if you disect the J2EE acronym you get Java 2 Enterprise Edition. This should tell you whether or not it's designed for you. I won't argue the fact that J2EE is a very complex product. You have Tomcat, ant (I believe, they're including this nowadays), and the whole administration interface, a few plugins for LDAP, Web Start (this allows rapid remote deployment of Java applications - very nice, too), plus J2SE.

Disecting J2SE, we have Java 2 Standard Edition. I don't think anyone would argue that J2SE is overly complex. There's the JVM, the bytecode compiler, source code, the API documentation, a few other little things (like the debugger, remote debugger, Web Start client, etc.)

Just sticking "Enterprise Edition" into a name isn't being upfront. Sure, I know that some guy running a server out of his basement shouldn't use it, but how large should a company have to be before they have enough resources to get a J2EE-based system working?

I think the standard edition is unnecessarily complex, but it's still good enough to be useful. I just wish more of an effort was made to make the language good at doing simple things.

 

[graphic7]

This is what I mean by marketing mumbo jumbo. If I forked Python and renamed it to Python Enterprise Edition, other than being a really bad acronym (PEE) , does this make it any more appropriate for enterprise level programming?

Would PEE have LDAP plugins, a rapid remote installation service, Tomcat, a Python make, a web administration interface?

If PEE did have a simple package that contained Python, bundled with Apache and some plugins, a sleek web administration interface to distribute the Python apps to multiple servers, I would consider that Enterprise. If you haven't gotten it by now, an "Enterprise" package is something that is easy to administer for a high volume of users. J2EE has a all of thus: a) the web administration interface makes it very, very easy to move Java apps/containers across systems b) for client-side apps, show me a utility that does something like Web Start c) there's plenty, plenty of API documentation.

Java could be streamlined a bit more. What people neglect to think of is that Java is a whole language. C has been around for much longer, and it's integration into an operating system is much cleaner. Sun, however, has to produce a version of Java for Linux, Solaris, and Windows, which is by no means an easy task. Each of those OSs are supported as well as the other ones (there are a few exceptions pertaining to file i/o and SWT). Sun also produces an Enterprise distribution for each of those respective platforms. Does Perl, PHP, or Python have a single package for Linux, Solaris, and Windows to install that configures Apache, comes with a slick web interface, and much more? No, you do it yourself, and that does not qualify it as enterprise-worthy.

Edit: Zend, a PHP server that is propiertary, is an exception to the above statement about Enterprise readiness.

 

[master_coda]

Java could be streamlined a bit more.

You are the master of understatement.

 

[so-crates]

Hmm, I found http://www.flat222.org/mac/bench/ quite interesting. I'll have to d/l the latest versions of Java, Python and Perl and see if its true. Wouldn't look too good for Python if it is.

I think part of the reason for Java's success is it had a very easy to use, platform independent (OK, Unix and Windows) GUI long before Python or C++ ever did, and it people started using it for other things despite some of its deficiencies.

 

[dduardo]

Python's ldap implentation is on par with Java's implentation. Just see this report:

http://www.blasum.net/holger/wri/comp/net/7appl/ldap/bochum2003/paperen.pdf

Python also has an enterprise package developed by the Zope Corporation.

 

[dduardo]

so-crates, I agree that java is generally faster than python, but you must also understand that speed is not the only factor. The cost of development and mantaniance are major issues. If it takes a week to do something in python that would take a month to do in java the savings are huge. I also find that python's syntax very clean and easy to maintain. The nice thing about python is that if there is a major bottleneck you can easily write a C module and import it into python.

 

[exequor]

I use php and although it is relatively new I think that a lot of development will take place for this language, such as PEAR.

 

[so-crates]

Can Python be compiled? I hadn't realized it was an interpreted language. If so it would be interesting to see if it was still slower than Java.

 

[ramollari]

Can Python be compiled? I hadn't realized it was an interpreted language. If so it would be interesting to see if it was still slower than Java.

Python is an interpreted language, and it seems that thus far there aren't any just in time compilers for it. Personally I'm using the Jython interpreter for Python, which is implemented in Java. So python code interpreted by a Java interpreter cannot be faster than the same code written in Java!

 

[dduardo]

Yes python can be compiled just like java with Psyco as opposed to JIT. You can even compile python into java by using Jpython and into .NET using IronPython.

The thing with Psyco is just like java, it requires a lot of memory. You always have the tradeoff of memory versus speed in programming.

That said, the benchmark you gave isn't apples to apples because it is comparing compiled java to python without being compiled.

 

[master_coda]

That said, the benchmark you gave isn't apples to apples because it is comparing compiled java to python without being compiled.

I do think it was a fair comparison. There's nothing wrong with comparing a standard Python installation to a standard Java installation.

Of course, it does limit the usefullness of the benchmark. If you need to seriously optimize code, then you shouldn't be using nothing more than a base installation.

 

[faust9]

I do think it was a fair comparison. There's nothing wrong with comparing a standard Python installation to a standard Java installation.

Of course, it does limit the usefullness of the benchmark. If you need to seriously optimize code, then you shouldn't be using nothing more than a base installation.

But it's not a good comparison because Python can be compiled whereas Java cannot run as a scripted language. The scripted version of Python was pitted against the non-scripted version of Java. Plus the comparison doesn't show the system resource utilization for the different comparisons(RE: Java takes a meteric ton of resources while Python/C++ take very little).

The only useful data available from these benchmarks is that perl is faster at most tasks than python.

 

[master_coda]

But it's not a good comparison because Python can be compiled whereas Java cannot run as a scripted language. The scripted version of Python was pitted against the non-scripted version of Java. Plus the comparison doesn't show the system resource utilization for the different comparisons(RE: Java takes a meteric ton of resources while Python/C++ take very little).

The only useful data available from these benchmarks is that perl is faster at most tasks than python.

Oh, I don't think the benchmark was good. I just think it was fair. It doesn't matter if one was compiled and the other wasn't; what mattered was that the benchmark used the standard installation, in the manner they would normally be used.

Besides, it's wrong to say that Java was compiled and Python wasn't; both Python and Java run from bytecode on top of a VM. If one of the VMs uses JIT compilation internally to speed things up and the other doesn't, that's a weakness in the VM, not a weakness in the benchmark.


You did catch an important problem with the benchmark, though. It doesn't measure resource usage, only runtime. And of course, the benchmark uses horrible tests. Any benchmark that just takes a single operation and does it over and over is generally useless; your test is going to be biased towards whatever language is particularly good that the operations your testing.