Hello, Daniel.
A couple of years back I completed the Oracle Certified Master Java Enterprise Architect certification. I have done nothing with PHP. Believe it or not, one of the things one is meant to know for that exam is that Java EE is not necessary for every project under the sun (or every project on the web, of course).
It was clearly stated in
course materials that sometimes you just don't need all the extra features of Java EE. If you were writing a small bulletin-board like system, or a system with lots of read-only users but only one person ever developing it, or perhaps even some more powerful systems without having to use JavaEE. However, when Java pays off, IMHO are situations like below:
* You have multiple developers writing a lot of code and you want a strongly typed, general-purpose programming language for Object Oriented development. Java was intended to help avoid certain types of common mistakes, among other things--hopefully alleviating debug.
* You want to use the tooling that is available for java (debuggers, IDEs, performance monitoring, etc.)
* You want to take advantage of a lot of pre-written (usually $ free) code that goes along with it.
* You have or want access to the folks who've learned this already.
...and that's just the Java part. For the EE (Enterprise Edition) part, here is more.
* If you are doing a lot of transactional processing, Java EE handles that well--even distributed transactions. You won't have to write the transactional code--just EJBs (which have become far more lightweight these days), unless you are doing some rather unusual transactional processing.
* If you need to have connections and object persistence with databases, Java EE can handle that as a configuration to youre server (combined with annotations to inject things).
* It handles security, propagating roles from the front end (web) to the backend (to the database connection).
* You can have resources injected into your components so that you won't have to wire things up/set things by hand.
* Multithreading is handled by just using the
EJB pool. Each one runs in its own
thread.
* You can leverage EJBs (or other beans they have now) for your componentization (breakdown of responsibilities among objects).
* You can leverage their new CDI. You can leverage Java's
JSF (I have not, but I have used
Struts as a framework, and JSPs. etc.)
* Your
Servlets / Web side technologies--even RESTful--can be done in the same server (or type of server) so nothing else to learn and run.
* You can have a fairly advanced solution for asynchronous processing just built in (MDBs and @Asynchronous EJBs). These can even be done on a timer.
* If you need it, you can use "stateful ejbs" to deal with user or server state--but they are not required very often.
* All the other JavaEE APIs can be in this one server as well--just reach out and call them.
* You can get servers--even for free--that support all this for you. There are well established companies for this. And if you grow and decide you want more support you can purchase that as well. I have known places that did not bother even with big apps.
The chief drive behind Java EE was: "we know most developers want to write business logic; they don't want to have to reinvent or become experts at things like transactions and multithreading." If you get around certain developers, these days, they will actually eschew this logic. I have been running into people especially on my last job who want to build everything themselves because they feel they can do it better than the off-the-shelf system can. If you are that advanced, perhaps you won't want what comes with
JBoss (the free server I mentioned) and you'd rather roll your own. Further, there is a pretty big community who embraces Spring as an alternative to the whole Sun/Oracle Java EE ecosystem. However, I have seen the two of them integrated and used together as well.
Another thing I will point out: transactions are going to be more associated with SQL/Relational than the newer NoSQL databases. These newer databases have many advantages, but transactions are one of their drawbacks. You can integrate JPA (the database solution from Oracle) with several of the NoSQL dbs. So if you like being able to do it all the same way (or you are mixing SQL and "Not-Only-SQL") this might help.
I Hope that Helps.