Java EE vs PHP

Areeda

Pattern Altitude
Joined
Aug 21, 2005
Messages
2,188
Location
Los Angeles, CA
Display Name

Display name:
Areeda
I seem to get more understandable answers and better advice asking weird technical questions here than any other website so here's my latest.

I've been using OO PHP (5.x) for a few years and really like it but I'm running into some maintainability issues. Specifically I'm getting a decent library of classes I want to maintain separately and share among multiple sites.

I'm just starting on Java EE tutorials and my first impression is that it is a much more robust system that will produce higher quality more maintainable code. However it will probably take me a long while to really learn it.

Does anybody use both? Any comments on whether I should spend the time learning Java EE?

Joe
 
I can't speak too much Joe as I've done very little Java development. It's a great language on paper and over time it seems like the various JVMs have improved a lot. There are definitely some parts that would make what you're wanting to do easier.

I've never really talked to a Java developer that has disliked the language. For many years I've had a negative view on Java mostly because I never used any software written in Java that seemed to work worth a ****. A lot of that really came down to the fact that I hadn't used any well-written Java software, not that well-written Java software couldn't be written. My own ignorance probably steered my view as well.

PHP really accelerated because it was easy to deploy on servers and almost every web-host supported it. They had to play a lot of catchup to get in a position where mature software development could happen. They're still behind on a lot of things and they might never catch up (do to many architecture/community differences). It's pretty silly to compile your code over-and-over with every web request. PHP caching systems help prevent that but still it's an architectural issue that shouldn't even be there in the first place.

If I was starting a large-scale web project I would certainly take Java into consideration.
 
Last edited:
Joe, if I were you, then I'd look at something else.

PHP is good at what it was made to do, ie. small web scripting tasks. It's not a good OO language, and while they've tried to play catch up, it's only resulted in a huge patchwork of different concepts. But like I said - it was never meant for large scale apps anyways.

Java is a fairy clean language, but it's not the best choice for web apps anymore. Development is just too cumbersome.

You also might want to consider that most of the talent has moved on from those two languages. Of course there's still lots of people who work in PHP or Java/Web, but the pool of good people is steadily decreasing and is almost gone for PHP. This is one of the best arguments I use when talking to clients - for them it's a hiring/HR concern, but for you it can be a library/framework development concern.

Take a look at Python/Django or Ruby/Rails. That's where most of the serious web development is happening right now, and it's also where the talent and projects are.

-Felix
 
Last edited:
As Felix says above - Python and Ruby are very much worth considering as well. I'd probably lean towards Python as I've seen more libraries and a lot less "Rails" fanboyism. Python is also supported on Google App Engine which works well for some projects.
 
Last edited:
Here is a computer tech forum that is run by a bunch of pros. Small and personal, but no matter what help is needed or the question is, some one will come up with an answer.

Computer Newbies

Noah W
 
Thanks gentlemen.

I tried Rails a while ago and got frustrated. Ruby is a fine language. I even bought the book. The tutorials went smoothly but when I tried to take a current project where most of the work was in the database and redo it in Rails it was too much fighting and not enough winning.

I think my problem in general with frameworks like Rails is that I try to fit them into my model of the world instead of fitting my thinking into theirs.

I'll try Django, I've already started with python. We'll see if I can adapt.

I may try Rails again. I'm to the point of blaming my issues on my unwillingness to do things their way.

---------------
Noah - I'll check out that forum but I participate in several techie forums, I just get better answers from these guys. I usually post this kind of question after I've waited a while for good responses in other arenas.
--------------
Wobby - I think you were joking about C++ but I have written plenty of CGI programs in C++ in the previous century. The integration with the web server that these modern approaches provide is a big plus and the "lower level" control of C is no advantage or a disadvantage.

I've done a fair amount of Java programming and it suits me well. I've done very few craplets. I tend to do either server side or thick client apps, meaning a desktop, web enabled application, when I need heavy processing or over-optimized user experience. The performance is very acceptable and the strong typed, object oriented nature fits my programming style. That might be my biggest problem with PHP and these frameworks.

We'll see. It looks like I have a few weeks of playing with tutorials and frameworks before I can decide.

Joe
 
Thanks gentlemen.

I tried Rails a while ago and got frustrated. Ruby is a fine language. I even bought the book. The tutorials went smoothly but when I tried to take a current project where most of the work was in the database and redo it in Rails it was too much fighting and not enough winning.
Certainly understandable, Joe. Rails has become much more process agnostic over the last few years, but it's certainly still more opinionated than other frameworks. While that does require some changes, those changes are more often than not for the best as far as web applications are concerned - this is why I don't have a problem recommending Rails. Your DB issue is a good example - Rails does favor (although not very strongly) having your model logic in your application models rather than your DB, and that's a good thing for web apps as scalability, transparency, and especially testing DBs is a major problem. That said, fitting a Rails app on top of an existing legacy DB schema is a major problem.

Django isn't bad, either, but it's not quite as far along as Rails, and Ruby does have some aspects that are nicer than Python. But these differences are relatively minor compared to PHP vs. almost anything ;)
 
I laughed at 'craplets'. Amen to that concept. :D

I think PHP is going to be way better at "adapting to an existing worldview" -- WAY more than JSP, and more than C# (which you didn't mention, but which is the other C-syntaxed web language with relevance)

I code all 3, and C# does great with large projects, but I find it somewhat limiting in what it lets me get away with. This is great for apps that need to be written the same way, but I find having the freedom to do something 'wrong' first aids my learning curve tremendously.

PHP will let me do it 'wrong' all day long, as I beat myself up by going down the wrong path and get the "ah ha!" cookie (or nutpunching) at the end when I realize why it was the wrong path.

JSP only has only one way to do anything, it seems. :) Big dumb companies with a large payroll in bangalore love JSP for a reason.

...It sounds like you learn like I do -- I want to make something functional now, and then hash out why it's junky code later as I maintain it. I don't want to get a PhD in the language before I even write "Hello World". PHP was easy for me to hop into and start swinging. C# less so. I'd gladly burn all of my JSP books.

I did not find Ruby enjoyable for the reasons you mention. I haven't "gotten" the hype yet, but I have written some surprisingly powerful apps with it using not much code. It has a ton of potential, but I hate its syntax, and as a database nerd, I *really* hate its SQL syntactical sugar. I can see why SQL-phobes love it.

$0.02

- Mike
 
I'm somewhat in the same boat right now, Joe. I currently work for a company as a rogue non-IT employed web scripter/programmer. We're doing stuff that the IT programmers would never be able to do due to the fact that we are physically at the facilities doing the activities that we want to speed up with web tools.

All of our tools are very data-heavy in that they compile a ton of data from our Oracle database (sometimes combined with data from a MSSQL and/or MySQL database) and present it in useful information format. The issue we are running into now is the hit that we are putting on the database server with our connections. Before I got here, they were using Excel to run queries and a bunch of vlookups to get the info that they wanted. Right before I got here, they moved up to PHP. As the only person on our team with a legitimate IT background and schooling, I am trying to figure out the best direction to push us for the future. Our tools are getting complex enough now that I'm trying to figure out if a compiled app would be faster or if there is another scripting language out there that would allow us to manipulate the data as easily as PHP does (with 'cleaner'/faster connection to the database being a big bonus).

I was forced to use RoR last fall for my MIS capstone project. It has a very steep learning curve. Once I got a good feel for it, I put together a fairly complex project. I'm not sure how well it would work for non-MVC data sources, though.

I'll be interested to see/hear what you come up with.
 
At some point Chris - you'll either have to:
1.) make the database hardware faster
2.) make the database more efficient (better indexes, etc)
3.) cache before the database (memcached, etc)
4.) replicate the database to additional servers

It sounds like the inefficiencies you're mentioning have nothing to do with your applications execution time / cpu cost as much as the database server hitting a bottleneck. No language is going to help with that.

This sort of stuff is going to be pretty hard to accomplish without your IT folks on board.
 
At some point Chris - you'll either have to:
1.) make the database hardware faster
2.) make the database more efficient (better indexes, etc)
3.) cache before the database (memcached, etc)
4.) replicate the database to additional servers

It sounds like the inefficiencies you're mentioning have nothing to do with your applications execution time / cpu cost as much as the database server hitting a bottleneck. No language is going to help with that.

This sort of stuff is going to be pretty hard to accomplish without your IT folks on board.

Yep. We are in the process of getting a replicated database (through IT) for us to use for our apps so we don't have to hit the live server for our queries.

IT's biggest balk about our apps is that Oracle (or at least their setup of Oracle) prefers persistent connections. Apparently, the legacy apps that the other guys have written create a new connection on each query, rather than opening a connection, running multiple queries, then closing the connection.

I've got one of the guys using more OOP in PHP, so he can create one connection for multiple queries. It's getting better, but we still need to get rid of using Excel for db connections.

Just curious if any of the languages out there make 'cleaner' connections, or if it's a wash in that area.
 
Yep. We are in the process of getting a replicated database (through IT) for us to use for our apps so we don't have to hit the live server for our queries.

IT's biggest balk about our apps is that Oracle (or at least their setup of Oracle) prefers persistent connections. Apparently, the legacy apps that the other guys have written create a new connection on each query, rather than opening a connection, running multiple queries, then closing the connection.

I've got one of the guys using more OOP in PHP, so he can create one connection for multiple queries. It's getting better, but we still need to get rid of using Excel for db connections.

Just curious if any of the languages out there make 'cleaner' connections, or if it's a wash in that area.

Man - you'd almost have to *TRY* to tear down/rebuild your connection for each query. Persistent connections can be done in PHP but it's not worth doing unless you're handling hundreds of persistent requests and even then you need your reasons. Connection pooling would be rather difficult to achieve which is a bit different then persistent connections. Persistent connections would likely use more of their servers resources because you'd be using connections for absolutely no reason when reports aren't being ran.

If you're opening a connection, using it for the page load, and closing at the end there shouldn't be an issue. Establishing a connection is a bit more expensive in Oracle versus PHP but I'd expect your app isn't really taking on any real traffic. So as long as you're not opening/tearing down for each query you'll be fine.
 
Last edited:
I laughed at 'craplets'. Amen to that concept. :D

I think PHP is going to be way better at "adapting to an existing worldview" -- WAY more than JSP, and more than C# (which you didn't mention, but which is the other C-syntaxed web language with relevance)

I code all 3, and C# does great with large projects, but I find it somewhat limiting in what it lets me get away with. This is great for apps that need to be written the same way, but I find having the freedom to do something 'wrong' first aids my learning curve tremendously.
I didn't mention C# because I don't have a reason to do Windows centric apps anymore, let alone pay for MS development tools. My understanding is C# is a MS only Java substitute, so I haven't even looked at it. I could be wrong.

PHP will let me do it 'wrong' all day long, as I beat myself up by going down the wrong path and get the "ah ha!" cookie (or nutpunching) at the end when I realize why it was the wrong path.
Amen

JSP only has only one way to do anything, it seems. :) Big dumb companies with a large payroll in bangalore love JSP for a reason.
Interesting. I haven't learned enough to come to that conclusion, but I haven't seen anything to dispute it.

...It sounds like you learn like I do -- I want to make something functional now, and then hash out why it's junky code later as I maintain it. I don't want to get a PhD in the language before I even write "Hello World". PHP was easy for me to hop into and start swinging. C# less so. I'd gladly burn all of my JSP books.
I think so. I spent a lot of time years ago going through Analysis, Design, Implementation, Maintenance steps. The main thing I came away with in those days is all the feedback comes after something gets implemented. Everybody including the analysts say uh-uh that looks good until they see it in action.

So like you I'd rather write code to get an idea how things will work THEN talk to people and then throw out most of the code I wrote. A prototype program is much less work and much better communicator than a design document.

I did not find Ruby enjoyable for the reasons you mention. I haven't "gotten" the hype yet, but I have written some surprisingly powerful apps with it using not much code. It has a ton of potential, but I hate its syntax, and as a database nerd, I *really* hate its SQL syntactical sugar. I can see why SQL-phobes love it.
I still need to actually do something with RoR. Perhaps I can approach it by writing the app then populate the database with an external program to translate the existing db, rather than get it to work with the existing db.

Joe
 
Chris,

I had the same impression Jesse did. A compiled language or more efficient interpreter like Java could reduce the CPU load on your web server but wouldn't do anything for the remote db server load.

My PHP stuff uses one connection per page. I have a Database object that opens the connection on creation and I run all my query/update commands through it. Connection pooling would be the next step in scaling if I needed to serve a large number of simultaneous users.

What fun.

Joe
 
Man - you'd almost have to *TRY* to tear down/rebuild your connection for each query. Persistent connections can be done in PHP but it's not worth doing unless you're handling hundreds of persistent requests and even then you need your reasons. Connection pooling would be rather difficult to achieve which is a bit different then persistent connections. Persistent connections would likely use more of their servers resources because you'd be using connections for absolutely no reason when reports aren't being ran.

If you're opening a connection, using it for the page load, and closing at the end there shouldn't be an issue. Establishing a connection is a bit more expensive in Oracle versus PHP but I'd expect your app isn't really taking on any real traffic. So as long as you're not opening/tearing down for each query you'll be fine.

I think we're ahead of the game with at least using PHP. I think the problem lies in the legacy stuff they have with the Excel tools. We have one worksheet that has 8-9 different 'panels', each with their own unique query to run at different refresh rates. The guys that originally wrote that stuff would open/close a connection for each panel when it would update.

Now that we're moving to web-based tools instead of Excel based tools, we can open a connection for the page, and have each 'panel' update itself through the page's connection rather than creating a connection for each panel individually.

I just want to make sure that we don't get everything switched over to PHP and realize that we could have been better off with a different platform. It sounds like there really isn't anything better than anything else for what I'm looking for.

P.S. Sorry to hijack your thread, Joe.
 
Well for a lot of this reporting you might be better off with a reporting tool like:
http://www.pentaho.com/products/
Chris you're not hijacking my thread, this is the kind of stuff I want to hear about.

A reporting tool MIGHT be cool if it's just assembling data from the db.

One thing cool about having a PHP Database class is that it can log queries and time them. That has help me a lot when optimizing db accesses.

I forgot where I learned this but you know you can create an html table and give it an excel mime type to open the table as a spread sheet.

Joe
 
This is the IT version of "High Wing v. Low Wing"!

And Perl solves everything by being a biplane and having both!
 
This is the IT version of "High Wing v. Low Wing"!

And Perl solves everything by being a biplane and having both!
I'm not sure if your serious Jeff.

I feel languages and development environments have real advantages and disadvantages depending on what you're doing.

One of the reasons I'm looking into a Java solution is the strong typing and compile time error checking that is missing from PHP and perl. Add in refactoring support and I tend to make fewer errors that have to be discovered with unit and Beta testing.

I've done quite a few cgi scripts in perl and don't find them as easy to write or debug.

Now as far as High Wing vs Low Wing, the only significant differences are on the ground. You can get in and out of a high wing in the rain without getting as wet. Also you can park a car under the wing in a hangar. But I judge a plane by how it flies so I am ambi-avius. But the one time I flew in a Stearman, I really liked it.

Joe
 
Joe,

I couldn't agree more...it depends on the application what's the best language.

If I have an app that has to parse a ton of text, I like perl...it works great for that!

If I want to do a bunch of DB calls, PHP is great.

If the app is running on windows, I can easily do C# or VB.

Lots of funky math...you'll shudder at this, but I can do FORTRAN in a pinch.

Raw speed you're looking for...nothing beats hand-tuned assembler, but honestly the complexity is to a point that most compilers can beat all but the 1-2 human beings who actually understand all the paths through the cores, cache, and CPUs on a system...and the human tuning will lose as soon as you move it to another computer!
 
Back
Top