tags: Java
, Architecture
, PHP
, J2EE
posted: Saturday, April 9th, 2005
You’ll probably notice an emerging theme over the next few weeks of comparing PHP to Java. Please understand, that I know very little PHP. I am a Java Architect and Developer. But that said, there are a lot of problems in the Java industry right now, and I’m finding it very interesting to compare it to PHP. Perhaps, at the very least the Java community can learn some valuable lessons from PHP.
The Server Side has an article about comparing CMS/Portals in Java and PHP. They found what I have found in comparing many other apps, and that is that PHP generally offers more choices and more functionality. You can read more here.
One of the replies to the article was by Dave C, and I just have to put the text of his comment here. Its has some truth in it. Java can of course, be as simple as he is describing PHP, but as he says, “Java programmers tend to overengineer everything”. I have a gut feeling that he is right, and that in the past, I may well have done that myself.
Here are the rest of Dave C’s comments:
It’s just a royal pain compared to PHP (or equiv). Part of it is because of the dynamic/scripting nature of PHP, but a big part of it is that Java programmers tend to overengineer everything. Consider showing a list of content entry titles. In Java, you’d probably set up some DataContainers/JavaBeans, a big layer of abstraction to access the database, and a bunch of session beans to keep everything nice and separated. In PHP, you’d just (forgiving some syntax errors):
$count=0;
while ($row = $db->sql_fetchrow($db->sql_query("select id,title from content order by id desc")))
{
$id = $row['id'];
$title = $row['title'];
// Output them as HTML/links whatever
$count++;
if ($count == 10) { break; }
}
the PHP solutions won’t result in the cleanest most maintainable code (phpNuke is a f**king mess), but it’s really easy to implement, doesn’t result in poorly performing code, and can allow you to implement lots of features quickly. Meanwhile, the Java guys are deciding how to implement the Abstract Factory pattern and writing XML configurations for PicoContainer….
I have a lot more thoughts on the future of Java and web development and over engineering, and I’ll probably use this blog to help walk through those thoughts, and possibly even come to some very new conclusions for myself.
Comments (2)
Leave a Comment
The problem is that Java is huge, PHP is focused.
If one takes EJB out of the equation.
and takes Frameworks out of the equation.
The Java code is straight forward, hardly more complex than the above, and easier to read.
Frameworks are killing Java… Java is not that complex, but the marketing has made everyone thing that EJB is java… that scares newbies, sp’s and EJB is a swear word in many companies.
EJB is NOT Java, and if the Java community doesnt have the savvy to see that EJB is killing Java… it is doomed.
Java is simple, EJB is a nightmare.
Add beans to the above, introspection, JNDI, SOA, and an XML parser… and it would also be something no one wants to use.
There is too much crap on top of Java…
Our code does the above in as many lines… in Java… its simple if you keep it simple.
I share your thoughts…
RSS feed for comments on this post. TrackBack
Yup, this is a huge issue. I deliver business applications in J2EE and there is no question that from a business perspective J2EE development is just too expensive. The developer productivity is lower than other platforms, and while the quality and maintainability of the result is excellent we as a community need to do a lot of work on the productivity angle or someone else (some other technical platform) is going to eat our lunch.
I’ve done some PHP and it is just too easy by comparison. Apparently the object-oriented features in PHP5 will offer (but not enforce) the ability to produce a better engineered result.
The best thing we as a J2EE community have going for us is the dedication to engineering quality among the community. As I was helping one of the UI guys here resolve a session management problem, I came back to the same realization as always - in 2005, at this point in the maturity of Java, why are we solving this problem? We should be spending our time building business functionality instead.
Jeff