Javalobby - Comments for "Spring Creator Sees "The Decline of the Traditional Java EE Server""

Traditional J2EE technology

tech0513 — Fri, 04 Apr 2008 11:21:36 -0400

Traditional J2EE technology was (and still is) the worst example of OOOP (1st "O" stands for "Over-engineered"). Of course, Spring makes life of Java developer easier. Its great strenghs is that it is modular, you can use it simply as a hub for your components, and it imposes minimum restrictions. Comparing it to J2EE is like comparing an oversized culturist pumped on steroids to a flexible athlete (guess which is which).

Rod is probably partly

Andy Gibson — Tue, 01 Apr 2008 15:25:45 -0400

Rod is probably partly right, but for the wrong reasons. Consider the lineage of standard J2EE persistence. We had EJB CMP which was a mess, then Hibernate came along, then iBatis et al, and now we have a new standard with JPA which serves to encapsulate the ideas and concepts that came before it. Now JPA 2.0 should fill in the holes with things like criteria queries.

Now look at EJB itself, we had EJB 2.1 which was a mess, then Spring came along, then Guice, Seam, even web frameworks started implementing dependency injection. For EJB, the first step back on the right path was EJB 3.0, and now we have a new standard coming up with web beans that will again encapsulate a lot of the ideas that came before it.

I see web servers evolving the same way. We have Tomcat and full blown J2EE app servers which will then evolve into modular servers where you can use either the lightweight web beans container, or switch to the more heavyweight EJB driven web beans implementation.

While Spring in itself may be simple, it does nothing to reduce the complexity of the Java platform itself. Rather than have one fixed framework as a standard (a la Ruby on Rails, PHP, asp.net) , java chooses to have a set of multiple frameworks and while each one may be simple in nature, their existence introduces complexity into the Java ecosystem.

JeffS, I agree use the right

alpha512 — Mon, 31 Mar 2008 23:13:15 -0400

JeffS, I agree use the right tool for the job, I like OOP, I know in some situations OOP is not the answer but I think that's why I don't like PHP or Perl in that case and I like more Ruby or Python they are more elegant, clean and fun to work with. So in the end I think is personal preference after all.

Rainer with Spring you don't need Application servers, just Tomcat, it is very lightweight, I think it's more lightweight and better performance than using LAMP, Thats have been my experience(some people say the reverse but I don't trust in benchmarks). Also you can use BlazeDS with Spring and Flex with a high performance and keep your business logic on the middleware so if in the future Flex is not anymore the hype then you can move to another presentation layer without problems. I suggest not to move the business logic to the client side. IMHO thick clients sucks, It's better thin clients. Of course also depend of the requirements and the users but it is more healthy for the users thin clients.

LAMP is a big player,

rainwebs — Mon, 31 Mar 2008 15:38:24 -0400

LAMP is a big player, because of the bunch of providers offering this stack worldwide. Did you ever tried to find something similar (same price, same management easiness) for a Java stack, say Tomcat++, the years ago? Today, here and there are offers, but more expensive, etc.

There are already excellent implementations, like Typo3, that prove that LAMP can compete with Java at the enterprise level. There are trends that are influenced by the Spring Framework, like Flow3, that foreshadow, that the LAMP guys have understond what's important in enterprise environments. I'm happy with this, because I'll get even more Java-like quality features on a very cheap provider stack ;-).

Although, there are a lot of projects LAMP is an excellent base today, Java is still the better answer for the big iron projects. But, the number of projects where such investments are really necessary goes down.

If I have a look at Flex for the next-generation frontend development, where a big part of the application logic can be moved back to the client, in some years we may rethink to use Java in the backend. What, if LAMP delivers a similar persistence layer, as Hibernate today, but with lesser maintenance problems? Compare Apache Web Server plus its mods with todays Application Servers, like Glassfish...

So, I agree with Rod in the end. Although I add the question: why use an application server at all?

"Jeffs, Have you programmed

jas_ejb — Sun, 30 Mar 2008 21:13:14 -0400

"Jeffs, Have you programmed with PHP?"

Yes.

"Looks like you only speculate about LAMP but programming with PHP really is a pain in the neck"

Nope, no specutlation - real experience. And I don't consider PHP's dynamism, ease of deployment, multitude of useful functions designed specifically to solve the web problem, and general RAD principles, to be a "pain in the neck".

"a real mess language, painful, ugly and bad designed, figure it was extracted from Perl"

Perl and PHP weren't designed for prettiness, or paradigm purity, or general elegance that make academics and posters at JavaLobby go "ooh, ahh, wow!" ;-)

They were designed for usefulness, and to help solve problems easily. And in those two aspects, both Perl and PHP certainly excel, IMHO. Actually, it's not my opinion, it's been proven in the real world, time and time again.

"I think Perl is much better language than PHP."

For certain problem domans, I agree 100%. Perl is particularly good as a Unix admin scripting tool, it's great at text processing (actually, arguably unequalled), it's good at CGI (particularly with mod_perl), and a multitude of "duct tape", "swiss army knife" type functionalities.

PHP is particularly good at solving a multitude of web problems very well, and very very easily.

"I prefer Java 100 times more than PHP or heck Ruby or Python are much better languages for LAMP. "

I prefer Java also, for certain things - cross platform GUI development, heavy lifting JEE or Spring POJO apps that benefit from domain driven design, large apps where strong typing makes debugging easier and the compiler catch problems ahead of time, certain networking problem domains, etc.

I also think that Ruby or Python are good for LAMP, but not necessarily better or worse than Perl or PHP. It boils down to preference - Perl and PHP's extreme usefulness and flexibility, or Ruby and Python's extreme readability, cleanliness, and greater "OOP purity". AS for "OOP purity", I tend to get turned off. OOP is great, but not great for all programming problems. There is no "one size fits all".

I like what Larry Wall said about what programming paradigm Perl is really good at. He said "WOP - Whatever Oriented Programming" (in typical Wall humor). But with Perl, you can do OOP, functional programming, generic programming, procedural programming, or just simple scripts. It's as easy or sophisticated as you need/want it to be. C++ is the same way - Stroustrup calls C++ a "multi paradigm language". That's the same as Walls "WOP". PHP is also a "WOP" language. All three bring a certain amout of inelegance, and not the best OOP implementation one could ask for, or plain old ugliness, but in exchange, they bring their extreme usefulness and flexibility.

By contrast, one of my gripes about Java (don't worry, I love Java, and I have gripes about all other languages), is that it seems to force OOP down your throat, for better or worse. Most of the time, that's a good thing, particularly for large projects, and for GUI programming. But some times it simply adds complexity (ORM, anyone? why are people so afraid of plain 'ol SQL?), or some business processes don't fit well into class hierarchies.

The usual cliche' continues to hold true - just use the right tool for the job.

Jeffs, Have you programmed

alpha512 — Sat, 29 Mar 2008 23:21:11 -0400

Jeffs, Have you programmed with PHP?, Looks like you only speculate about LAMP but programming with PHP really is a pain in the neck, a real mess language, painful, ugly and bad designed, figure it was extracted from Perl, I think Perl is much better language than PHP. Even at this time PHP5 doesn't have namespaces heheh.

I prefer Java 100 times more than PHP or heck Ruby or Python are much better languages for LAMP.

Personally I don't agree

kennethmark — Sat, 29 Mar 2008 06:38:41 -0400

Personally I don't agree with Rod prediction.

We use both Spring and J2EE ( and recently move to JEE5) and both of them have their own pro and cons.

I just don't feel right saying that Spring ( or others ) will replace JEE. All solutions will get benefits from others as Soren mentioned above.

It is natural that Rod

sorend — Sat, 29 Mar 2008 03:21:15 -0400

It is natural that Rod Johnson is quite enthuiastic about his own product. Who wouldn't be :)

How I see it though, is Spring and JEE as complementing technologies/frameworks. I use Spring extensively in almost all projects nowadays, and while Spring is many things, it is not a JMS provider, it is not a transactions manager, etc. Without these JEE defined "standards", there would be missing some well-defined concepts in Spring, and I would have little use of it in my projects.

No I don't agree with

jvissers — Fri, 28 Mar 2008 23:16:46 -0400

No I don't agree with him.

A lot of Rod's remarks nowadays have to do with spreading FUD about JEE and standards in general. I like open source as it pushes standards to a higher level. Open source initiatives start out with a relative green field - in order to 'fix' or 'make easy/easier' what the 'current' standard has overlooked, left out or solved 'the wrong way'. Examples are well known with regard to EJB entity beans -> hibernate/toplink -> JPA, as well as EJB 1.0,2.0,2.1 -> spring wiring/aop/di -> EJB3.0, 3.1. At a certain time the open source initiative will start to crumble under its weight, depending on the 'installed base' and legacy of backward compatibility. The open source initiative will become overly complex, and the 'new' standard has the ability to introduce improved functionality by making more use of language features, without the burden of backward compatibility. I think we're on the verge of that happening - Spring trying to keep up with the next wave of improved industry standards (e.g. Java 6, 7 and JEE 6).

I agree with Rod. Spring has

cplusstudent — Fri, 28 Mar 2008 14:15:34 -0400

I agree with Rod. Spring has made my life easier as a Java developer. I don't think that JEE servers are going to fall off of the map, but we will see "the decline of traditional JEE server". I was just talking to a colleague 10 minutes ago about some of the many features of Spring and how Spring can help a small team of developers get their work done with less headaches. I think that Java developers still need to understand what core JEE is all about, but they should not be concerned about the details of implementation if they do not want to be.

Of course Rod is predicting

jas_ejb — Fri, 28 Mar 2008 13:20:26 -0400

Of course Rod is predicting the demise of JEE app servers, in favor of the modular Spring framework - Spring is how earns his wares.

Similarly, I saw a post (linked to by Java Lobby) from Andi Gutmans (of Zend/PHP fame) saying how the LAMP stack is dominant and prferable for web apps, well over anything Java, becaue Java is too difficult and cumbersome in comparison to LAMP. Of course Gutmans said that, Zend/PHP is how he earns his wares.

So, in both cases, big pinch of salt, please.

But going forward, I see most new Java Enterprise projects going to the lighter weight, more modular approach of Spring and OSGI. Most traditional JEE app servers are used in legacy apps, or in very large corps with already huge investments in that space, and converting is too expensive.

Really, going forward, the only time a big monolithic JEE app server makes sense is in the biggest of the big back end corporate apps, where they absolutely need all the APIs and services that a JEE has (and is already plugged in and configured). That's maybe 5% of apps out there. Everything else benefits from the lighter weight, more modular approach.

However, for that remaining 95%, I'd say the Spring/OSGI approach is attractive, but I find the LAMP stack to be even more attractive, due to much greater ease of development and deployment, more agility, more dynamism, and it is proven to scale, perform, and provide robust security and up time (just look at Yahoo, Facebook, and many other very large scale Web 2.0 apps that use PHP (or LAMP in general).

So that kind of puts the Spring or OSGI approach in a precarious middle ground. On one end it's LAMP that's more appropriate, and on the other end, it's a big JEE app server that's more appropriate. How large that middle ground where Spring is appropriate is debateable.

Yeah I'm agree with Rod,

alpha512 — Fri, 28 Mar 2008 12:14:56 -0400

Yeah I'm agree with Rod, Spring makes my life easier as Java developer, JEE will still have it place but Spring is going more strong everyday and with version 3 of Spring I think it will be the choice for Java for the Enterprise development.

Thanks to Rod, SpringSource and the community for the wonderful Spring framework!.

Javalobby - Comments for "Spring Creator Sees &quot;The Decline of the Traditional Java EE Server&quot;"