For many architects, simplicity is the theme at JavaOne.

Whether you hear the quote, “keep it simple stupid,” “simplicity is the ultimate sophistication,” or “if you can’t explain it to a six year old, you don’t understand it yourself,” you can’t help but realize people have valued simplicity for years.   Yet, Java developers have often gotten caught up in complexity.

For VMware’s vFabric Product Marketing lead, Al Sargent, simplicity has been the overarching theme for this year’s JavaOne.  In a field report today, Al outlined five simplicity-related needs that he’s heard from architects at JavaOne. The people he spoke to want:

  1. Simpler application servers

  2. Simpler ways to reduce Java memory

  3. Simpler ways to manage Tomcat

  4. Simpler ways to provision servers

  5. Simpler web services

Simpler Servers and Ways to Reduce Java Memory

As architects and developers, we pride ourselves on making smart decisions and recommendations. Yet, so many things influence the architecture of applications over time – politics, scope, innovations, budgets, etc.  Seventeen years of Java programming has lead us to overly complex and expensive application servers with over-allocated memory footprints. Perhaps led by the economy, Java teams today are looking to avoid complexity and unnecessary expense. They want lightweight runtimes to deploy quickly on virtual infrastructure and tools to help optimize infrastructure as well as frameworks to make development efficient and effective.

Simpler Ways to Manage Tomcat and Provision Servers

Developers recognize the value of Tomcat, shown by it’s marketshare. Yet, companies still need more tools to manage, monitor, and scale Tomcat.  In addition, internal IT teams want public cloud capabilities like self-serve provisioning as well as build and deployment automation.

Simpler Web Services

Traditional SOA architecture models like XML, SOAP, USDL, and UDDI are not as commonly discussed. The move is towards simpler models like JSON, REST, and HATEOAS – things that make development and integration simpler and quicker.

To learn more about how Spring and VMware vFabric solutions fit with these five needs, read the full article here.

Isn't it funny that the call for simplicity comes from a company that added another layer of complexity on top of Java EE?

I'd call that "layer of reality" on top of the layer of academic, ivory tower, "do it our way - we know what you need" specifications.

I'd call that "layer of reality" on top of the layer of academic, ivory tower, "do it our way - we know what you need" specifications.

Have you actually used the latest Java EE 6 servers, and built applications with Java EE 6?

Peace,

Cameron Purdy | Oracle

Have you actually used the latest Java EE 6 servers, and built applications with Java EE 6?

Yes.

But I've decided it's not ready yet: lack of decent security, lack of MVC, lack of easy choice of view technology (I use Thymeleaf currently). Also I have projects which must run on: WebSphere 6, WebSphere 7.

I know the clean and nice CDI, but I also know the politics behind, I remember CDI was called WebBeans and I know Gavin King's attitude. CDI is what gives JavaEE XXI century's feeling, but that's not enough to use it - at the end it's just DI container. Spring's DI much better in practice (with it's two levels of components: BeanDefinition and actual bean which gives my project a great level of managability and flexibility).

In two months since now, JavaEE will be 3 years old. In practice I *have to* both use old application servers and I want to use new techniques and libraries. I can use Hibernate 4 on WebSphere 7, I can use newest CXF on WebSphere 6 so yes - I use JavaEE6, but I just don't use Vanila JavaEE - I use what's working.

JavaEE should be split into two parts (technologies officialy constituting JavaEE):

• frameworks (for the lack of better word): Servlets 3.0, CDI, EJB, JCA, JTA, JDBC, (possibly JMS) they're dictate somehow your programming model
• libraries: JAXRS, JAXWS, JAXB, JAXRPC, JSP, EL, JSTL, BeanValidation, JPA, JavaMail, JAXP, StAX

"frameworks" may be a part of app server, they may be considered "services" the application servers provide. But "libraries" should be easily upgradable, replaceable, removable per application (mind that application server is used to run more than one application!). Application should now what particular version/implementations they're using.

regards

Grzegorz Grzybek

After reading your post i see that u still don;t have an idea what Java EE 6 is :).

Especially when i read this

"lack of easy choice of view technology"

You r funny !

Thank you

So tell me - what "Vanilla JavaEE advocates" recommend as "view technology"?