There's little in that presentation which anyone would disagree with. None of it, however, means Java EE is dead or any similar statement. I've said many of the same things in my TomEE presentations as evidence on why TomEE is a "app server" that thinks differently.
We've always had the mantra: - Embedded containers rock - Take back public static void main - EARs and complex packaging sucks - If you have just one app, invert the structure: instead of putting the app in the server, put the server in the app. None of that means that JAX-RS sucks, EJB sucks, CDI sucks or Servlets suck. Unit testing with OpenEJB for example does not involve creating archives, then unpacking archives then running the test... the repeating for each and every single test. Further, we've been pushing this in the Java EE specifications. There's an Embedded EJB API so it can be used in Java SE so every single one of the bullets and items above can hold true and apply portably to any "app server". We'll only be doing more of this in Java EE -- I'd love to see the whole thing embeddable. Bottom line, APIs aren't app servers. There's great room for improvement in how we present those APIs to people. Fully agree that in Java EE we've baked in a set of assumptions on how workflow should happen to use those APIs. We're slowly tearing that down... and doing it without throwing away those APIs or declaring them dead :) The traditional "app server" packaging isn't going away any time soon, but fully agree there are other legitimate ways to consume things. Take a look at what Docker is doing. Its focus is making everything but the hardware itself the "application" and then the hardware itself is what we would typically call the "server". You create one "application" and roll it out onto the bare server. When you get down to it, the terms are loose and subjective. "Application" is just term to describe what is included in the distribution and "server" is what is provided in the target. So let's imagine four scenarios: 0. app [] -> server [java, os, metal] 1. app [java] -> server [java, os, metal] 2. app [java] -> server [os, metal] 3. app [java, os] -> server [metal] Clearly "0" is impossible: an application with nothing in it does nothing. Scenario "1": instead of calling this "fat app server" we could call this "thin application" and then we might find we like the sound of it a bit better. This is where Java "EE" originates. The advantages of a thin application are self described -- smaller applications to distribute. The "server" is fat, the "app" is light. The app is the lightest it can get, the server is the heaviest it can get. Scenario "2": here, we have all the java assets required in the app itself. This is still achievable using "EE", just use embedded containers. Seeing more support from "EE" for this deployment scenario is high on my list of things we need to accomplish as an industry. The "server" is a bit lighter and the "app" becomes a bit heavier compared to 1. Sort of a middle ground. Scenario "3": here, all the java assets and even the os goes with the "app" and the server is just the bare metal. This is the Docker scenario. The "server" is as light as it can get, the "app" is as heavy as it can get. All scenarios are fine. Depends entirely on what you're working with and where you want to put the complexity. The "fat" has to live somewhere. I find focusing on only one side of the coin leads to incomplete thinking and any scenario can be made to sound good or bad. My net take is that none of this has absolutely anything to do with specific APIs like JAX-RS, CDI, Bean Validation, etc. etc. etc. It's our job as creators and implementors of those APIs to make them work in *all* scenarios. People who use those APIs should be able to use them in any scenario. And there is the value of standards. The APIs abstract you from the implementation. Should you find your implementation is not adapting and supporting the scenario you want... change implementations. Standards aren't silver bullets, but I guarantee the transition will be a lot easier than rewriting the entire application. If your app took $1,000,000 to develop and you don't have to throw it all away, that's real savings. -- David Blevins http://twitter.com/dblevins http://www.tomitribe.com On May 11, 2014, at 4:10 PM, Anthony Fryer <[email protected]> wrote: > I think Java Application Servers left a bad impression on alot of people back > in the early ejb2/jsf1 days. It wasn't only the specs that were not great > (ie. ejb2 entity beans) but also the containers that were implemented were > incredibly resource hungry memory pigs that took an eternity to boot up. I > remember working on weblogic 8 which you couldn't run on a machine with < > 2Gb and when you booted it, you could walk away and make a coffee, come back > and if you were lucky it would have started. > > Back then alot of people looking for a better way to do things went to > spring and the spring, (tomcat|jetty), hibernate stack became really > popular. Jee was abandoned by alot of developers. > > Over the last few years with the jee spec improving massively (esp ejb3 and > jsf2) , the introduction of CDI and the development of new super lightweight > fast jee containers (tomee by far consumes the least memory in my > experiences and boots up in a matter of seconds), in my opinion jee has > definately leaped ahead of the spring, tomcat, hibernate stack. Also its a > "STANDARD" so you get a warm fuzzy feeling knowing that it's a technology > that's not going to dissappear just because its not flavour of the month at > any point in time. > > The problem these days is the people that left jee before and went to spring > are stuck in their ways and still think jee is bad and containers are fat > and bloated. Most people haven't bothered to look again. Most java devs > when I mention dependency injection think only of spring. I'm amazed how > many don't even know about CDI. There's new projects using spring to create > web services. When i asked if they looked at JAX-WS i get blank stares > back. I think there's a big education issue with java devs stuck in their > ways and too lazy to learn something new. > > > > -- > View this message in context: > http://openejb.979440.n4.nabble.com/Java-Application-Servers-are-Dead-tp4669233p4669237.html > Sent from the OpenEJB User mailing list archive at Nabble.com.
