In an interview with TheServerSide.com, the creator of the Spring framework, Rod Johnson, tells interviewer Cameron McKenzie that Java developers have a lot to learn from the Rails community. The response came from a question about what it would take for the enterprise Java community to eagerly adopt cloud based technologies like vFabric and the up and coming Code2Cloud initiative. Here is Rod's response.

Java Developers have Loads to Learn from the Rails Community

Audio of Rod's Comments on YouTube

When the CIO says: "we can’t keep going and reinventing the wheel constantly" he then answers: "So let's buy the IBM/Oracle/SAP solution..."

Very few CIO's in large enterprises go for the open source solutions.

More and more do

I also see architects producing overcomplicated designs for no good reason, as well as throwing technologies and products into the mix just because they are "cool" or "enterprise".

Same for developers, although on the smaller scale.

KISS and YAGNI are often foreign to these people.

You hit this one right on. I see this practice too many times.

To all the folks supportive of Java EE, thank you!

The way I see it, Java EE is indeed a lot like RoR. It provides a comprehensive runtime platform to minimize configuration hell, XML hell and jar hell. In addition it attempts to maximize vendor neutrality via community based standardization.

No, the JCP is not perfect, however, it does have a lot of upsides compared to many other open standards bodies. There are also active reforms driven by good folks like the London Java Community to remove the last few wrinkles that are there.

In fact, I invite folks to join the Java EE 7 initiatives that are currently underway: http://blogs.oracle.com/theaquarium/entry/javaee_7_transparency_jsrs_as.

Cheers,

Reza

Java is not open source... Just search for java lawsuit.

Well Rod's not exactly free from sins here either

In fact, it is the complexities with Java development and deployment that's fuelling the growth in other languages. It would be better if things could be made a lot simpler for it's own sake.

Lots of people have stated this message, but I think it deserves repeating. There times when the problem is complex due to complex business requirements. In those cases, it makes no difference what technology you use. It's complex because of security, auditing, compliance, scale and integration. Other times, it's complex due to over engineering and NIH syndrome. Take a typical bank situation. Bank A buys out Bank B, which uses a dozen different technology stacks acquired through acquisition. When Bank A goes to integrate stuff, the complexity is dizzying.

Open source is just as guilty of over engineering as everyone else, so it's not a Java problem. It all depends on the problem you're trying to solve. Of course all of this is made worse by bad management that doesn't know the scope of the problem.

The cynic in me feels like the critique is a variation on "use light weight framework instead of EJB". At the end of the day, everyone makes these mistakes. A good developer does it less than a noobie.

I couldn't agree more. It's real easy to make a nice clean 'lightweight' efficient solution when you are starting from scratch. Trouble is when have to stitch together a whole host of disparate solutions implemented by a range of developers where each one thinks they have the ONLY solutions to ALL of the IT worlds problems. 

Java developers have a lot to learn from the Rails community.

That's why Java has ~20% marketshare and RoR ~1%?

It's a kind of sport to complain about Java, but somewhere Java must have done something right as developers are still flocking to it, yet they abandon Ruby.

Nevertheless, Ed Burns in his JSF book has publicly stated to have been inspired by RoR and simplified a couple of things thereafter in JSF.

... like with Spring ? yeah right

The simplest way to reduce pathological complexity is to ditch Spring. I've never understood why people are willing to bow to those inexpedient configuration and indirection orgies.

indeed, and get rid of JEE while they're at it.

indeed, and get rid of JEE while they're at it.

Why? Java EE has only gotten simpler and simpler. I can now do very powerful things with very elegant and straightforward code, that took me headaches and tones of verbose lines of code only a few years ago.

and do what? write everything from scratch on every project?  Spring runs on just any app server and even in stand alone applications.  Spring is not a silver bullet, but it sure does make life easy doing things like security, transaction management, database access, etc...  I could not imagine going back to the broken, bloated J2EE, heck i would rather write my own plumbing than use that vendor driven disaster.

J2EE was indeed bloated and vendor driven, but you're living in the past. It was replaced half a decade(!) ago by Java EE, which is community driven, lightweight, free and opensource. It has a very simple and easy to learn programming model.

j2EE or JEE is all the same thing, Vendor driven JCP specs designed to get licensing fees.  What should i put in my maven pom to include jEE jars in my stand alone java app?  is taht the web profile? web profile v2? enterprise profile? super profile? complex profile?  Why do i need to care?

Why should i have to change my application server just because the J2ee spec changed?  Why can't i simply add a new version of a jar to my maven pom?  JEE is just all wrong from the get go. It should just be a couple jars like Spring.  You can pick and choose what you need.  It can run in a stand alone applciation and/or a web application.  Apps should be in a simple WAR file rather than the bloated complex EAR format whcih gives all sorts of class loader nightmares.

j2EE or JEE is all the same thing, Vendor driven JCP specs designed to get licensing fees.  What should i put in my maven pom to include jEE jars in my stand alone java app?  is taht the web profile? web profile v2? enterprise profile? super profile? complex profile?  Why do i need to care?

Why should i have to change my application server just because the J2ee spec changed?  Why can't i simply add a new version of a jar to my maven pom?  JEE is just all wrong from the get go. It should just be a couple jars like Spring.  You can pick and choose what you need.  It can run in a stand alone applciation and/or a web application.  Apps should be in a simple WAR file rather than the bloated complex EAR format whcih gives all sorts of class loader nightmares.

I see the problem. you're using maven, which create it's own special brand of pain and suffering.

If you have to change your application because your application server changed, you did it wrong. Don't blame the spec for your own errors, mate.

you seem confused.  Where did i say i needed to change my application because i changed containers?  And, yes, you do have to change your application to include the vendor specific configurations anyhow.  My point is, just to use the latest version of JEE, i have to upgrade my applicatoin server version and then change my code to use the new features. With Spring or Guice, i do not need to do anything to my application server.

Yes, I misread part of what you'd said. But you don't HAVE to include vendor-specific pieces to your app; the Java EE spec actually has ways to help this happen, although few bother. They just blame the spec instead.

j2EE or JEE is all the same thing, Vendor driven JCP specs designed to get licensing fees.  What should i put in my maven pom to include jEE jars in my stand alone java app?  is taht the web profile? web profile v2? enterprise profile? super profile? complex profile?  Why do i need to care?

Why should i have to change my application server just because the J2ee spec changed?  Why can't i simply add a new version of a jar to my maven pom?  JEE is just all wrong from the get go. It should just be a couple jars like Spring.  You can pick and choose what you need.  It can run in a stand alone applciation and/or a web application.  Apps should be in a simple WAR file rather than the bloated complex EAR format whcih gives all sorts of class loader nightmares.

 

Totally agreed. The main problem is not the quality of the spec but the fact that a JEE container is not necessarily embeddable. This what I really like about Spring or Guice, you just put some jars in your classpath and your ready to use the framework while with EJB3 (unless things have changed) you need to tweak your tomcat to add a lite container. This is the part that has always put me off. Most parts of JEE should be usable as is just by dropping a simple jar in my classpath. I shouldn't need to configure my web container or use a web container at all for that matter to be able to develop an application using EJB 3. 

j2EE or JEE is all the same thing, Vendor driven JCP specs designed to get licensing fees.

No! Java EE is highly driven by the community. The EG seeks out existing solutions and actively asks the public for suggestions and advice.

Java EE is just all wrong from the get go. It should just be a couple jars like Spring.  You can pick and choose what you need. 

BS. Why don't you include every class you need from Java SE in your war? Why don't you include the Servlet classes that Tomcat provides in your war? Why don't you include the entire JVM in your war? Heck, why don't you include the entire OS in your war?

Java EE isn't wrong. -YOU- are wrong.

j2EE or JEE is all the same thing, Vendor driven JCP specs designed to get licensing fees.

No! Java EE is highly driven by the community. The EG seeks out existing solutions and actively asks the public for suggestions and advice.

So there is no Oracle and IBM stamp required for JCP?  Why did Apache leave the JCP exactly?

Java EE is just all wrong from the get go. It should just be a couple jars like Spring.  You can pick and choose what you need. 

BS. Why don't you include every class you need from Java SE in your war? Why don't you include the Servlet classes that Tomcat provides in your war? Why don't you include the entire JVM in your war? Heck, why don't you include the entire OS in your war?

Java EE isn't wrong. -YOU- are wrong.

 

Why do i need to include any jars?  Why doesn't my application appear out of the nether and magically do what i want to do? Strawman is strawman.  J2EE/JEE/whatever it is branded this week, requires a specific version of an app server to work.  And you can not even do stand alone development with it.  

Why does my programming model change the second i leave the web app realm?  It makes no sense other than Sun/Oracle can not get license fees for that.  Care to address that or just restate the JEE BS?

If you don't understand Java EE, don't make comments. A spec is created by the EG based on community input, existing solution and some original work. Everyone can join the EG; companies, OSS organizations and individuals. EG group members all vote for this spec. There is no IBM stamp. Oracle validates that an implementation conforms to the spec. Apache's Java EE offering is certified, the dispute was/is about Java SE. Get it?

Oracle validates that an implementation conforms to the spec.

so you agree, there is the ultimate Oracle stamp on anything.  Which is what the JCP rule is.

Oracle validates that an implementation conforms to the spec.

so you agree, there is the ultimate Oracle stamp on anything.  Which is what the JCP rule is.

There indeed needs to be one steward of the language that verifies an implementation conforms to the specifications. This is a Good Thing for users, as they have assurance that the software they are using is reasonably compliant. For JBoss AS 6, JBoss decided not to certify their offering for the full profile (although it theoretically implements it). There was a bit of a row over this in the community, which means actual users care about this.

It's not the evil thing that you undoubtedly are trying to suggest we should think it is. It's a small fee that vendors pay Oracle, who basically runs something that you might think of as a kind of unit test suite (the TCK). If the software passes, it's allowed to be called "Java EE".

But don't forget that the thing Oracle tests for is the specification that has been created by the EG, which as mentioned contains members from many companies, organizations and individuals who on their turn get their input from the community, that is, developers like you and me.

So bluntly put, Oracle verifies whether JBoss has implemented the feature that -you- asked for correctly, and charges JBoss (Red Hat), not you, a small fee for that service.

 

Why does my programming model change the second i leave the web app realm?  It makes no sense other than Sun/Oracle can not get license fees for that.  Care to address that or just restate the JEE BS?

Bryan Ceniza already gave you a very good reply, but I would like to add here that you seem seriously confused about Java EE. Either that, or you're just a Spring zealot trying to spread the kind of FUD that was typical a couple of years ago, but has gotten old since then and which doesn't fool people anymore.

Anyway, Sun/Oracle does not get any license fees from you using Java EE. I can use excellent implementations like Resin 4, Glassfish and Jboss AS without ever paying a dime to Oracle or even to Caucho or Red Hat. It's true that vendors have to pay a certain amount to Oracle for being allowed to call their product Java EE, but that's a one time fee for the certification only, not for number of users, downloads, or whatever. The exact same holds for Java SE implementations as well.

With this model, your conspiracy theory that Oracle somehow tries to keep features strongly tied to Java EE for the sole reason of extra revenue is utterly insane.

The reason that there is a Java SE and Java EE is because otherwise you would have one giant platform that contained everything. Java SE/Java EE was basically the first attempt to modularize the Java platform.

Nevertheless, even though they originate from Java EE or are included in Java EE, technologies like JPA, CDI, JTA, JMS, and EJB3 can all be used standalone in Java SE. Many of them have very specific sections in their spec documents for usage outside of Java EE.

A technology like JSF or JAX-RS would be a little awkward in its current form to use in Java SE, but it can be trivially added to a Servlet container like Tomcat or Jetty. Jetty can also be used in embedded mode, so even Servlets can be used in Java SE.

This means that basically everything can be used 'standalone'. Of course, by simply downloading Resin you get everything in a very convenient single package and it's guaranteed to work well together.

Just to add to this - the truth is that the licensing fees are not that cumbersome even for a small company like Caucho. In fact, I highly doubt the licencing fees even cover the cost of running the JCP/developing TCKs.

In addition, Sun/Oracle has always been pretty good about waiving the licensing fees for non-profits. Granted that Apache Harmony is a strange wart - but it is largely an exception and not the rule. In fact, I think that wart will also go away once the Oracle/Google lawsuit is settled. Unlike Sun, Oracle has no great emotional ties to maintaining a pointless JVM hegemony.

j2EE or JEE is all the same thing, Vendor driven JCP specs designed to get licensing fees.  

Its ok to offer opinions and conspiracy theories but it is better if we present some facts. Like the fact that glassfish, jboss, jonas and many more java ee compliant servers are free as in free beer while there is another fact that using spring is another version of vendor lock in. Another fact that spring 3 requires java se 5 and production servers stock on java se 1.4 will also get stock with spring ancestors unless they convince I.T. to upgrade java se or buy support from Spring. Another fact that the JCP is not only about JEE, it is also about JSE, JME, etc., so if you got JCP allergy why use JSE. You should have stayed away from java to begin with.

What should i put in my maven pom to include jEE jars in my stand alone java app?  is taht the web profile? web profile v2? enterprise profile? super profile? complex profile?  Why do i need to care?

Stand alone app? I have news for you, this site is called theserverside and we are supposed to be talking about server side enterprise applications and not desktop or utility applications. But I'll give you a tip about your maven problem, you can go to this site, www.google.com and almost all questions will be answered.

Why should i have to change my application server just because the J2ee spec changed?  

De ja vu? This is like asking why should I change to java se 5 from the previous versions just because there is already spring 3? Or maybe there are really no production environments running prehistoric java versions and SpringSource knows of this for ages and they kept it a secret so that SpringSource can market Spring as the framework that can run in any version of java (Just a theory).

Why can't i simply add a new version of a jar to my maven pom?  JEE is just all wrong from the get go. It should just be a couple jars like Spring.  You can pick and choose what you need.  

If spring is just a couple of jars, why pick and choose? Just put everything and be done with it. If this is how spring devs do their work, Rod Johnson should have said The Spring Community has a patho...

It can run in a stand alone applciation and/or a web application. Apps should be in a simple WAR file rather than the bloated complex EAR format whcih gives all sorts of class loader nightmares.

Whats it? Can you please give me of an example of a server side enterprise application which doubles as a desktop application at the same time? I can also think of other types of stand alone applications like http servers, rmi servers, mediaplayers, jms servers, ldap servers, database servers, but I can't imagine them doing web application stuffs at another time. :-)

But I suspect that when you say stand alone app, you were actually referring to a web application in which the application itself is the one bootstrapping the http server and the servlet container, the one managing transactions, managing security, managing db connection pooling hence stand alone. On the other hand, web applications are web applications which only contain the business functionality code leaving the plumbings to the container it is deployed in. And hey, if I'm so concerned with bloat, why should I choose the stand alone way? Unless your standalone app is not an enterprise app which is only meant to be a utility application to be embedded in devices such as routers.

You see: 

Stand alone spring web applications trying hard to become enterprise level app = very bloated

spring web applications on top of tomcat = just bloated.

spring web application on top of jboss/glassfish/other java ee servers = is the worst bloat.

spring web app on top of tcat server = almost all meat, but you have to pay.

java ee 6 enterprise apps = almost all meat, but you don't have to pay.

 

Stand alone app? I have news for you, this site is called theserverside and we are supposed to be talking about server side enterprise applications and not desktop or utility applications. But I'll give you a tip about your maven problem, you can go to this site, www.google.com and almost all questions will be answered.

 

Whats it? Can you please give me of an example of a server side enterprise application which doubles as a desktop application at the same time? I can also think of other types of stand alone applications like http servers, rmi servers, mediaplayers, jms servers, ldap servers, database servers, but I can't imagine them doing web application stuffs at another time. :-)

But I suspect that when you say stand alone app, you were actually referring to a web application in which the application itself is the one bootstrapping the http server and the servlet container, the one managing transactions, managing security, managing db connection pooling hence stand alone. On the other hand, web applications are web applications which only contain the business functionality code leaving the plumbings to the container it is deployed in. And hey, if I'm so concerned with bloat, why should I choose the stand alone way? Unless your standalone app is not an enterprise app which is only meant to be a utility application to be embedded in devices such as routers.

I have a standalone app which processes over 20k transactions a second, invokes both SOAP and RESTful services and does a whole lot more.  If that is not enterprise, i am not sure what is.  I guess you do not consider that enterprise because it does not use EJB?  Can't use EJB because i am not running in a Server container; anyhow, does not make sense, as there is nothing a JEE server does which i can not do much simpler outside said container.

If you do not use Maven what do you use to build with?  Do you have your build server fire up eclipse and build from there?  Or do you rewrite an Ant build for every project?  How do you manage dependencies? Ivy?  Maven is not perfect, however it sure does make things simple and most importantly, consistant.

 

Stand alone app? I have news for you, this site is called theserverside and we are supposed to be talking about server side enterprise applications and not desktop or utility applications. But I'll give you a tip about your maven problem, you can go to this site, www.google.com and almost all questions will be answered.

 

Whats it? Can you please give me of an example of a server side enterprise application which doubles as a desktop application at the same time? I can also think of other types of stand alone applications like http servers, rmi servers, mediaplayers, jms servers, ldap servers, database servers, but I can't imagine them doing web application stuffs at another time. :-)

But I suspect that when you say stand alone app, you were actually referring to a web application in which the application itself is the one bootstrapping the http server and the servlet container, the one managing transactions, managing security, managing db connection pooling hence stand alone. On the other hand, web applications are web applications which only contain the business functionality code leaving the plumbings to the container it is deployed in. And hey, if I'm so concerned with bloat, why should I choose the stand alone way? Unless your standalone app is not an enterprise app which is only meant to be a utility application to be embedded in devices such as routers.

I have a standalone app which processes over 20k transactions a second, invokes both SOAP and RESTful services and does a whole lot more.  If that is not enterprise, i am not sure what is.  I guess you do not consider that enterprise because it does not use EJB?  Can't use EJB because i am not running in a Server container; anyhow, does not make sense, as there is nothing a JEE server does which i can not do much simpler outside said container.

If you do not use Maven what do you use to build with?  Do you have your build server fire up eclipse and build from there?  Or do you rewrite an Ant build for every project?  How do you manage dependencies? Ivy?  Maven is not perfect, however it sure does make things simple and most importantly, consistant.

I won't speak for others. My definition of enterprise requires integration with a half dozen systems with lots of complex requirements like fine grain access controls, single sign-on, encryption, business rules, third party calls, batch processes, data transformations, BI and data warehousing.

What's your definition of enterprise? Transactions per second? or some other measurement?

 

 

I have a standalone app which processes over 20k transactions a second, invokes both SOAP and RESTful services and does a whole lot more.  If that is not enterprise, i am not sure what is.  I guess you do not consider that enterprise because it does not use EJB?  Can't use EJB because i am not running in a Server container; anyhow, does not make sense, as there is nothing a JEE server does which i can not do much simpler outside said container.

If you do not use Maven what do you use to build with?  Do you have your build server fire up eclipse and build from there?  Or do you rewrite an Ant build for every project?  How do you manage dependencies? Ivy?  Maven is not perfect, however it sure does make things simple and most importantly, consistant.

I won't speak for others. My definition of enterprise requires integration with a half dozen systems with lots of complex requirements like fine grain access controls, single sign-on, encryption, business rules, third party calls, batch processes, data transformations, BI and data warehousing.

What's your definition of enterprise? Transactions per second? or some other measurement?

well, this project only integrates with four third parties so I guess it is not enterprise. LOL. u mad bro?

 

 

I have a standalone app which processes over 20k transactions a second, invokes both SOAP and RESTful services and does a whole lot more.  If that is not enterprise, i am not sure what is.  I guess you do not consider that enterprise because it does not use EJB?  Can't use EJB because i am not running in a Server container; anyhow, does not make sense, as there is nothing a JEE server does which i can not do much simpler outside said container.

If you do not use Maven what do you use to build with?  Do you have your build server fire up eclipse and build from there?  Or do you rewrite an Ant build for every project?  How do you manage dependencies? Ivy?  Maven is not perfect, however it sure does make things simple and most importantly, consistant.

I won't speak for others. My definition of enterprise requires integration with a half dozen systems with lots of complex requirements like fine grain access controls, single sign-on, encryption, business rules, third party calls, batch processes, data transformations, BI and data warehousing.

What's your definition of enterprise? Transactions per second? or some other measurement?

well, this project only integrates with four third parties so I guess it is not enterprise. LOL. u mad bro?

I was just curious, since you claim to have an "enterprise" application. Having worked on a wide variety of applications from order management systems to large health care systems, every says they work on "enterprise" applications. Without qualifying and quantifying what "enterprise" means, it's an empty claim. In most of the applications I've worked on the minimal number of external components were 6-7 with a max of 20.

I'll give you a concrete example. When I worked for a telecomm, we had to integrate with msdn, yahoo, real networks and 4 other external systems. Each one of them had different status definitions, so our system had to map all those account statuses. To make things worse, sometimes one of the external systems would be "unavailable". Of course that mean we had to queue transactions and have retry logic. A transaction in this particular case involved several sub transactions. Even then not all transactions are "equal". When you add calls to other internal systems, the integration points starts to get rather complex.

To me handling 20,000 transactions per second doesn't really mean anything without context. What are those transactions doing? Is there SLA for these transactions? Are some transactions routed to different systems with different flows? I often find complexity occurs for many reasons and most of them aren't because Java community has a pathological desire. I've also done .Net development and it's no different there either.

and do what? write everything from scratch on every project?  Spring runs on just any app server and even in stand alone applications.  Spring is not a silver bullet, but it sure does make life easy doing things like security, transaction management, database access, etc...  I could not imagine going back to the broken, bloated J2EE, heck i would rather write my own plumbing than use that vendor driven disaster.

You must have suffered with Websphere. If that's the case, I feel you pain. In fact, I'm feeling that pain right now. Luckily there are options like tomcat, jboss and glassfish. Isn't Tomcat part of the EE stack? Doesn't Spring have their own TC offering? Vendors like IBM love bloat, it has higher commissions. Blame the sales guys who excel at their job. Just because some sales droid convinced an executive to use an entire bloated stack, it doesn't JEE stack was bad. Of course, often developers are told to do stupid things by clueless executives, so that's just life.

>> if someone finds a better way to do something, within 30 days, everybody does it,

The Rails community is far far small comopared to java. Historically whn you have a smalle communites things get's done easily and apparently faster.

Moeover I believe that the applications build using rails won't go too complex (compared to java).

Spring is one of the worst complexity evildoers ever, a bloatware crammed full of absurd "abstractions" and "patterns". 

For your convenience and pleasure I compiled a list of some bizarre Spring classnames: AbstractSingletonProxyFactoryBean,  BeanFactoryConversationAttributeSourceAdvisor, ContextSingletonBeanFactoryLocator, CallbackPreferringPlatformTransactionManager, DelegatePerTargetObjectIntroductionInterceptor, FormattingConversionServiceFactoryBean, HandlerExceptionResolverComposite, SimpleBeanFactoryAwareAspectInstanceFactory, SimpleRemoteStatelessSessionProxyFactoryBean (my favorite), SmartInstantiationAwareBeanPostProcessor, TransactionAwareConnectionFactoryProxy, and finally UserCredentialsConnectionFactoryAdapter

Some food for thought for the folks making statements on the supposed difficulty in application server upgrades:

* For APIs that are frequently used, it places an additional configuration burden on the developer to not provide them by default in the runtime. In fact, this is why both Java EE and RoR aim to provide complete platforms that simply work out of the box for a majority of cases.

* A majority of Java EE APIs are pluggable and can be upgraded when needed, albeit with some knowledge of application server class-loaders. OSGi based application servers like GlassFish will even allow you to easily upgrade core APIs like EJB, CDI and Servlet.

* Application server upgrades are a fact of life for the simple reasons that old versions are not supported for ever. It's smarter to stay on a regular upgrade schedule rather than doing upgrades at the last minute.

* Upgrading commercial offerings like WebLogic and WebSphere in very conservative, large corporations can be a pain. However, if you give it an honest try, you’ll find that upgrading more modern, “sane” application servers like JBoss, GlassFish and Resin is a snap.

* You can also simply run a new instance of an application server and run the newer applications on those and leave the old applications alone. Running a few new servers is trivial for most modern enterprises, especially with the cloud :-).

Cheers,

Reza

@Reza

I respect your opinions and work, but you always says this:

Upgrading commercial offerings like WebLogic and WebSphere in very conservative, large corporations can be a pain. However, if you give it an honest try, you’ll find that upgrading more modern, “sane” application servers like JBoss, GlassFish and Resin is a snap.

Upgrading WebSphere is not pain - it's impossible. In my projects we're working with WebSphere 6 without any possibility to upgrade to newer version. Event upgrading to v7 would gives us only JavaEE5. My experience (~10 years) is that AppServer should be treated as a piece of architecture which results not from technical but from management decisions. Consultants who prepare companies to public tenders construct the requirements to contain e.g. "A service bus which have integrated development environment allowing to model the flows in a graphical manner and has extensible documentation publicly available". Add some more such "independent" requirements and in practice, all ~100 of them could be replaced with one: "use IBM WebSphere ESB". So WebSphere is not a result of technical debate - it's a requirement.

So developers and architects which come after the contract has been signed has to deal with what's irreplaceable - with particular JavaEE product. Spring products allow to minimize negative impact of such non-technical decision - they can be put the WEB-INF/lib and let the application survive political changes. I know the "vanilla JavaEE" arguments - lighter WARs, faster deployment. But I also know how to hack classloaders, how to strip classes from WebSphere Application Client JARs and that invoking EJBs on WebSphere7 from Tomcat/JBoss is not possible without hacking WebSphere App Client.

regards

Grzegorz Grzybek

Like Reza mentioned, your situation is indeed painful. It's actually not technical, but political pain you have. You use Spring not as a technical superior solution, but as a way to sneak updates past the absurdity of managers and operations.
Maybe Oracle or Red Hat etc should release a version of Glassfish or JBoss that completely runs out of a war for guys like you.

You use Spring not as a technical superior solution

Actually I use Spring as a technical superior solution. I don't sneak any updates I just use a given platform (OS + AppServer) in a safest (for the company I work in) way - in a way that lets me write, test and run application without any problems in devs' machines, in Hudson/Jenkins (tests), Tomcat, JBoss, WebSphere and anything that's valid for a particular month (I don't have influence on what licences the custemer actually have, is going to have or should have, but IBM refused to give in a required number).

Did I mention I'm eager to put Glassfish/JBoss into my WAR (or maybe all of them, selected with Spring's ~1GB XML files?) - I don't remember I've said that.

You use Spring not as a technical superior solution

Actually I use Spring as a technical superior solution.

Yet above you only mentioned that you used Spring, because at your place Java EE can't be upgraded.

 

I don't sneak any updates I just use a given platform (OS + AppServer) in a safest (for the company I work in) way 

In my book that's just justifying your own 'crime'. Your management team or your operations team (or perhaps both) have forbidden you to upgrade the application server, which they see as critical infrastructure that should be as stable as possible. This may be rightfully so, or it may be a silly and ill-advised. Managers might have come to that decision because of political reasons or because of not understanding the technology, while operations in general always hate to upgrade stuff and love to deny requests made by developers (okay, I'm over-generalizing).

Either way, you feel the developers are the ones who should make this decision (for the reasons you give, and I agree), so instead of using the application server that operations installed, you sneak a completely different application server inside the war (Spring). This sneaky application server maybe uses 1% of the installed AS (basically only the HTTP connector). Everything else is provided by your war.

Now both management and operations thinks they are running on Java EE provided by Websphere. Operations have done trainings on how to administer Websphere, maybe how to configure EJBs (a stupendous task to delegate to operations) and how to create JMS queues (an equally stupendous task), but almost surprisingly to them they never have to apply that knowledge, since the Websphere/Java EE functionality simply isn't used.

Now I don't say I don't agree with you and I thus indeed agree that both management and operations shouldn't interfere with decisions that only developers can reasonably make, but that does not mean you are not using Spring to sneak an AS past them.

It's a little like how web services via HTTP port 80 undermine operations as well. They first spend a lot of time to block each and evert port to make it as difficult as possible for developers to do stuff like RMI, and then somebody invents web services and everything that operations previously blocked happily travels via the one port they cannot block.

Actually, TomEE does exactly that: http://openejb.apache.org/3.0/apache-tomee.html. You can dop in a war to turn Tomcat into a Java EE 6 Web Profile server.

Having done WebSphere upgrades myself, I have to disagree that "it is impossible". It is indeed difficult, but doable nonetheless.

It's a little misguided to say "pathological desire." But if you are selling somethng...   Java has moved like a Ouji board these last ~15 years. And under Sun it moved with market forces towards the sweet spot.  Technology doesn't stand still (RoR) and lots of these learnings have been folded in, or at least, have tempered discussion smells.

So not to address which technology is best, but more to the point, address how does a technology evolve, I'd say what's on top of the VM or how we design software (public/private cloud) on a VM has been revolutionary and still is while the VM has been evolutionary.  The community techniques/ideas that RoR has highlighted is getting adopted.  Just not at a pace to move everyone to the cloud overnight.

Maybe Rod has a patholgical desire to get companies to rewrite their apps to run on a cloud.  I don't think it's a complexity problem and he's pandering to non-technical execs who just want it to be simpler.  I think he has good product but don't ding technical people for systems they devloped with 5-10 year old technologies and understandings.  

Remember; every silver lining has its cloud.

I agree that a lot of the RoR philosophy is gradually finding it's way into Java (because they are good ideas worth adopting).

Also agree on the "cloud mania" point...

It's curius to hear it from someone who created spring, a framework that takes like zillion configurations to simply run.