Java EE 6 Is Nice, But It Is Too Late....
"Java EE 6 Is Nice, But It Is Too Late...." I see this statement more and more often. Its similar category to "EJB 3 are too heavy" :-).
You should consider, however, that customers, sponsors etc. only care about the end result, development and maintenance costs. Whether something is new or old - they actually don't care. They even shouldn't.
In huge companies politics, long-term contracts and golf-course decisions could overrule this strategy - what often leads to huge and overcomplicated "enterprise" projects (and so consultants-heaven :-)).
Java EE 6 development model is comparable with the other alternatives, but it will run on most application server in near future, like Java EE 5 did. So you can get lot better support, licensing conditions etc, that it was the case at the J2EE time. Your application remains server independent - a good insurance for the future. And you have only to negotiate once - with a single vendor.
iPhone was too late - and see what happened. iPad is extremely late (there are more powerful alternatives on the market for several years) - let see how it works.
Both products have something in common - they provide very good - out-of-the-box customer experience, are easy to use and set-up.
People telling that Java EE 6 is too should look at the past!
Otherwise they would know that 15 years ago I heard from Cobol or Delta programmers OO is nice but it's too late.
And now see what happened!
Also people saying that J2EE 1.4 application server are still strategic in their company Spring is still important to them must recognize that every change takes time.
Within the next five years a lot of projects will use Java EE 6. But Cobol and J2EE 1.4 will still be there in 2015.
Posted by Simon Martinelli on March 19, 2010 at 11:55 AM CET #
@Simon,
"...must recognize that every change takes time."
I made the following experience: in the times of economic downturn rational arguments do significantly speed-up the decision making process. People just have to care about their budgets... It is also known as "consolidation" :-)
thanks, as always, for your comment!,
adam
Posted by Adam Bien on March 19, 2010 at 12:09 PM CET #
In Brazil, managers still fears JavaEE, remembering the lack of productivity of the ancient J2EE 1.4. I don't know why they think Tomcat+Spring is more productive than Glassfish+JavaEE.
Posted by Eduardo Costa on March 19, 2010 at 02:42 PM CET #
Eduardo,
both are viable solutions - but Java EE + Spring mixture isn't any more. In longer term we will find full-stack Java EE 6 or (not and) full-stack Spring with own "proprietary" server.
The productivity of full-stack Spring is similar to e.g. Glassfish. The difference here: if you are using Glassfish you are not dependent on it. You could easily switch to JBoss, Resin. etc.
Will write a post about that,
thanks for your brazilian insight! :-)
adam bien
Posted by Adam Bien on March 19, 2010 at 02:48 PM CET #
For me, the problem is not that it is too late, but that it is too slow! I've seen some of the marvels of it yesterday in a talk by Antonio Goncalves, and for each of those marvels I couldn't help thinking that my customers use Weblogic 10 or JBoss 4, and given the magnitude of their golf-ware investments, it will take an awful lot of time for them to upgrade to a JavaEE6-compliant version of whatever they are using. And by the time they do, there will still be a lot more innovation available in community-driven alternatives like Spring. Think of OSGi support, think of AMF integration. There's just too much inertia in the "standard" world. I almost hope that Oracle will crush the JCP so that we can come back to a richer technological competition instead of slow-motion implementation competition.
Posted by Sebastien Arbogast on March 19, 2010 at 03:43 PM CET #
@Sebastien,
there are always two possibilities: to crush JCP or to improve that. In my eyes JCP is unique and huge advantage of Java comparing it to the other platforms.
JCP works actually better, than one would assume: SpringSource + Google managed to release a specification in only few weeks...
A few week cycle is short than enough for a standard, isn't it?
Too slow? I don't think so. Even Java EE 5 was perfect for 80-90% of typical applications and now it is almost 4 years old...
thanks for your comment!,
adam
Posted by Adam Bien on March 19, 2010 at 04:00 PM CET #
While I am not completely comfortable with the fact that Spring has decided to get into the field of application servers, I don't see how using the Spring Framework would force a dependency on Spring servers.
We regularly develop applications using the Spring Framework and deploy to Tomcat servers in the development environment, and have no problems deploying to WebSphere servers in test and production environments. Is there something I don't know about in the roadmap for Spring Framework that will limit it to working only on Tomcat or their Spring dm server?
I really don't believe the people at Spring Source would allow the Spring Framework to become dependant on deploying to Spring dm or Tomcat servers since they would lose a large portion of their customer base, especially their major enterprise level customers, and partners, who are probably unwilling to switch servers they have already invested alot into.
Also, as to the iPhone and iPad, I think their success is related more to Apple and Steve Job's marketing skills than anything. I owned a Zen Vision M which had a much better out of box experience then the iPods of the time, but the iPods won the popularity contest anyway.
Posted by Chris Messina on March 19, 2010 at 04:02 PM CET #
Sorry, to be more correct the references to Tomcat in my previous post should probably be to Spring tc server instead.
Posted by Chris Messina on March 19, 2010 at 04:08 PM CET #
JEE 6 is way better than JEE 5, and JEE 5 was actually viable development platform. The problem is, unfortunately, that JEE 6 is the platform. It's tightly tied to underlying runtime. So it's not that easy like switching few jars in Your project and use it. It's like switching whole platform. Tough reality is: first we have to wait for runtime to catch up (I'm talking about big players WebLogic, JBoss, WebSphere) which are traditionally rather slow in adoption. I except that we will have those certified servers in, hope, a year. Then we will have to wait for Our nice infrastructure departments to migrate whole stuff. And it's obvious they are not very happy with this dirty 'migration' word. So, realistically I expect myself to be able to start thinking about JEE 6, in 1.5 year timeframe. That's the problem, with the platform compared to framework. With all the alternatives I have right now, right here I actually don't care much about JEE 6. Being an architect I do care abut solution architecture, and don't care much about infrastructure architecture, unless I have to. And it's how big companies are working. Period. Hope JCP will understand this, and hope JEE 7 motto will be: modularity and cloud computing. Let's keep core platform (core container, JTA, JCA, HTTP, and whole infrastructure stuff) and frameworks (EJB, DI, etc) separate. Core stuff is quite stable for many, many years. Real innovation is on the framework level. Why not use this advantage? Why framework is so much tied to the platform? Why we just cannot run EJB 3.1 on top of older containers? Why we have to wait for new 'versions'? Do they rally *have* to rollout new version of the whole platform just to get EJB 3.1? As a side note: Other thing is that times of big, monolithic heavyweight containers are gone. That's the fact. We have to understand it or JEE is doomed in few years.
Posted by Artur Karazniewicz on March 20, 2010 at 09:48 AM CET #
When your make your application you'll have some "hard" minimal requirements like JAVA 5... And even that could depend of what your production environement has available. (Us still have 1.4 production environnement).
It's already a big problem but if you manage to have the JVM version you want (1.5 or more for exemple), then you will add another dependancies like application server version or you'll need to wait 2 or even 5 years for it to be available.
But by that time JEE6 would not be that great. If you bundle required jar with your app, you control their version, can change it when you want or need to, and your are done.
Another application could have differents requirements and still work on your server.
Also what i still see everywhere is :
- Struts 1
- Spring
- Hibernate.
That what most web project where using by the time, and they still here. People modify, update and develop new modules for theses products.
They didn't care about JEE5. They don't care JEE6 is out. They capitalise on what they have. And when they make a new application chance are the application will remain a struts application because it's easy to find a Struts developper, but not so easy to find a JEE6 developper.
It's been a long time that if they wanted more automatisation that all their DAO code is automaticaly generated for exemple. And from time to time they just need to male a direct SQL request or even call a stored procedure.
From my experience, keep the DataBase code in the database as stored procedure and you need far less time to produce it, still is run 10, 100, 1000 time faster than with all that fancy framwork. And you and up with less bug ! Why shoud i invest into something that just use complex framework just for slower performance and need more developements to get the job done ?
And for the UI ? JSF, even the JSF 2.0 one is not something i would invest into. No one use that there. And it's so outdated. GWT, Zk, Flex are good solution. But why should i use JSF and all that face thing ? It's complicated, very slow and still can't make what other framework can do !
And face it, many people just want a web server that is able to show a nice GUI of their 10 ou 20 year old base code, writen in RPG, PL-1, PL-SQL or other thing like that. They will not change to EJB 3.1 just because you want them to...
If they go to the web thing, they just need a good UI framework. And definitively, JSF is not a good one.
Posted by Nicolas on March 20, 2010 at 11:03 AM CET #
JEE may have put lipstick on the surface but it is still the same inefficient bloatware under the hood. Pooled *stateless* session beans?? stateful-server-side view technology?? This is 2010 not 1997. Oh and by the way, actual servers implement network protocols, not object containers..
Posted by Dimitris on March 20, 2010 at 01:06 PM CET #
Artur, I think you shouldn't make such a big distinction between upgrading the platform and upgrading the jars that you package along in your .war file.
Every upgrade includes a certain risk, but upgrading from Java EE 5 to Java EE 6 via E.g. JBoss AS 5 to JBoss AS 6 is not inherently more risky than upgrading from Spring 2 to Spring 3.
If you somehow 'delude' your system administrator who tells you not to upgrade by 'secretly' shipping a new version of Spring in your .war, then IMHO this is just a case of a silly power game. In the end, the underlying JVM is just running Java code and to the VM it doesn't matter whether this code was packaged with your .war or present in some directory of your JBoss installation.
If your sole reason for wanting to ship jars with your .war is so that you can sneak upgrades past those who otherwise forbid you to upgrade, then maybe you should look deep in your heart and ask yourself whether you really want to play such a game?
Posted by Robert Tuinman on March 20, 2010 at 01:44 PM CET #
@Dimitris
>JEE may have put lipstick on the surface but it is still the same inefficient bloatware under the hood.
I strongly reject this sentiment. We're currently deploying on JBoss AS 5 and this is certainly not bloatware. Not on the outside and not under the hood. The programming model is extremely elegant and the performance is top notch. JBoss AS' only downside is its slow startup time, but this is not Java EE's fault. Glassfish V3, which I'm currently playing with, starts up in mere seconds. M2 of JBoss AS 6 is also a good deal faster and I fully expect the GA to be even faster than that (JBoss actually has this faster startup as a major JIRA issue for JBoss AS 6).
>Pooled *stateless* session beans??"
Yes, pooled AND stateless. The stateless term refers to the fact that there is no usable state for the client of such beans between calls. Yet, such beans might be injected with relatively expensive resources, and those are maintained between calls. So, you can be assured that those services, JMS queues and maybe socket connections are there every time you make a call to such bean and don't have to worry about each and every call requiring all of that to be re-instantiated again. This is what gives stateless session beans such high performance.
You can compare this to a traditional JDBC connection pool. Connections are stateless for the user in between calls. You can't do work on one connection, close it, request a connection again from the pool and expect to be able to continue that work. It might be by chance the same connection you got before, but it might also be a completely new one. Yet, what doesn't happen is that with each new connection you request, a complete physical connection with the DB is setup.
>stateful-server-side view technology?
Indeed, because state is simply something that exists. No matter how long and hard you wish it to not be there, it's still there. On platforms that don't support such state, the programmer typically has to fiddle with long and complicated GET requests or with hidden parameters on a form, both which are tedious to program and are quite error prone.
Java EE 6 has a very elegant solution to this: the CDI conversation scope. Extremely easy to use, yet very powerful.
Posted by Robert Tuinman on March 20, 2010 at 02:02 PM CET #
Robert
Upgrade to JEE 6 means upgrade of framework (EJB 3.1) *and* runtime. In any non-trivial enterprise environment it's hard, lengthy and risky path. Believe me. Upgrade of spring means upgrade of framework, and usually nothing more. By definition framework upgrade is up to software architect (me), upgrade of whole platform is plus framework involves infrastructure architects, software architects and, usually management (trainings, licences, migrations, much more testing, SLA, significant downtime, legacy code migration to name just few etc.). Here's how it works in most but trivial enterprise environments. I see this 'migration of JEE 6 servers in no big deal' sentiments still and still. Usually from the guys who hardly worked in such an environments. Sure upgrade of glassfish on my desktop is as trivial as upgrade of spring. But things are *completely* different in enterprise, which JEE is all about, no?
Posted by Artur Karazniewicz on March 20, 2010 at 02:58 PM CET #
Arthur, it's debatable to what actually constitutes a run-time. You might just as well consider JBoss AS a single Java application that runs on the runtime, which is the JVM. Just package your application inside the JBoss deploy folder and then deploy the resulting whole as a single Java application to the JVM run-time.
I've worked for fairly large organizations, and increasingly this is exactly how they are starting to look at a Java deployment. The entire thing gets even more interesting when you consider virtual servers, which are now starting to dominate the enterprise.
With those, the view that 'the server' is a fixed installation of some AS (say JBoss) quickly diminishes. You as an application developer get a VM as-in a virtual server allocated, and you can deploy there what needs to be deployed. Whether it's a new JVM, or a new JBoss or a new war or a new ear.
At the end it's the stability of the end application that matters. It's utterly silly that only you, the software architect, have the final say and sole responsibility about a risky upgrade like a framework upgrade, yet when it concerns the same kind of software stack that is only installed a little differently, suddenly a whole bunch of people start to interfere.
This is just WRONG. It's wrong on so many levels that I take it you must see it too.
Consider installing Tomcat and Spring on some server and then deploying your Spring apps to that? What is the big difference? There really isn't one! If people think there really is a difference between upgrading Spring libs that ship with a war vs upgrading Spring libs referenced on the classpath by a single Tomcat instance, they simply don't understand how things work.
Again... in the end the stability of the app is all that matters. If I would upgrade the Spring libs of some of our Spring based applications, then a thorough testing session is required, including performance testing, security testing, stability testing etc. The exact same is needed when upgrading Java EE. I don't use Spring just to sneak my upgrades past the 'infrastructure architects' and 'management'.
You talk about legacy code migration, but sorry, that's just bull. If you upgrade Spring you'll have to do legacy code migration just as well. With Java EE, I've successfully migrated J2EE 1.4 applications to Java EE 5 and currently I'm looking into migrating to Java EE 6. Overall backwards compatibility is quite excellent. There is very little I *had* to migrate.
I do take your word for it that in the truly huge, embarrassingly bureaucratic enterprises, with twisted power plays between various fractions of people, Spring might have a small edge for its ability to sneak upgrades into production.
That makes Spring a good candidate for the heavyweight, bureaucratic development environments. Java EE on the other hand is a perfect fit for sane enterprises without idiotic power plays and with a lightweight and agile development process.
So, basically you have simply confirmed Java EE's success. It has been pushing toward a lightweight, easy development model, while Spring has fallen pray to be favored by the heavyweight and bureaucratic organizations.
Based on that insight, let developers choose what they are most comfortable with. There is a place is this world for both, but I certainly know what I prefer ;)
Posted by Robert Tuinman on March 20, 2010 at 04:21 PM CET #
Robert Tuinman,
So, how do you update the programming model? Do you really think any infrastructure/operations group wants to support a new version of an app server because you want an updated programming model e.g. EJB 3.1?
Do you think infrastructure/operations wants support run 5 different versions of an applications server?
Not even mentioning the licensing concerns
Keeping the programming model separate from the server alleviates this issue.
Posted by Darryl Smith on March 20, 2010 at 04:46 PM CET #
It's not even a matter of Java EE vs Spring anymore. I see a lot of customers moving to .net. The better question is how does EE 1.6 or spring 3.0 stack up against .net 4.0.
Posted by sboulay on March 20, 2010 at 04:59 PM CET #
Darryl,
How do you update the programming model? Well, you just start using it for new code. It's as simple as that.
>Do you think infrastructure/operations wants support run 5 different versions of an applications server?
How does this differ from upgrading Spring? Do you think infrastructure/operations wants [to] support run[ning] 5 different versions of Spring?
And what licensing concerns are you talking about? You probably don't worry about a changed license between Spring 2 and Spring 3, why would this then be a problem when upgrading from JBoss AS 4 to JBoss AS 5? For your information, there are plenty of FREE and OPEN SOURCE Java EE implementatons, including JBoss AS, Glassfish, Geronimo, Resin, ...
>Keeping the programming model separate from the server alleviates this issue.
But what IS the server? Do you see the server as the physical machine? The dom0 Linux installation on top of it? Any of its XEN hosts? The installed JVM? The deployed AS on the JVM? Or even the deployed application on the AS?
As I explained before, the thinking error is that somehow you perceive the jar files that make up JBoss strictly as a monolithic part of 'the server' that is set in stone. Don't do that... just don't do that. This is an outdated and old way of thinking.
If you only consider the JVM as 'the server', then JBoss AS simply becomes a Java application that you deploy to it. JBoss AS == the programming model. Again, this becomes even more the case when you consider todays ubiquitous virtual servers with Apache front-ends.
JBoss AS + your war/ear == the application, just as Spring + your war/ear == the application.
Posted by Robert Tuinman on March 20, 2010 at 05:52 PM CET #
> How does this differ from upgrading Spring? Do you think infrastructure/operations wants [to] support run[ning] 5 different versions of Spring?
To them its just another war/ear, that development team is responsible for ensuring it runs on the application server that OPS supports...
Posted by Darryl Smith on March 20, 2010 at 07:03 PM CET #
>To them its just another war/ear, that development team is responsible for ensuring it runs on the application server that OPS supports...
The mistake here is that OPS considers the AS as something they should support.
Tomcat + Spring is also an AS, yet they thus don't feel the need to support this since the AS part is hidden inside the war. Yet, technically its the same thing. This is what I mean by sneaking things past common sense.
I remember a nice anecdote from a Microsoft employee: in the 80-ties a team of Microsoft staff was positioned to work at IBM. They were not allowed to have a water heater in their room, so security was about to remove it from them. But, there also was the rule that security was not able to meddle in anything that was labeled as MS confidential. So, when the guard was about to remove said heater, one clever MS employee grabbed a pen and scribbled 'MS confidential' on the heater. The guard backed down and suddenly it was okay.
The bureaucratic nonsense of this is just beyond belief, but it strongly reminds me of what you're trying to tell me. When the same kind of functionality sits bare on the HDD of some server, OPS supposedly feels some need to 'support' it, which in practice just seems to mean 'nothing may ever be changed'. Yet, package this same functionality in a war/ear and it's suddenly the sole responsibility of the development team?
Don't you see the utter stupidity there? It's technically the exact same thing and the only difference is about bureaucratic rules.
Let the development team be responsible for the whole application that JBoss AS + the ear represents and let OPS worry about the Linux root installation, the XEN configuration, the firewall etc.
But maybe, just maybe.. JBoss should release a "JBoss-the-war-edition", which would be a complete JBoss AS instance, just hidden inside a war. Once executed, it would completely take over and the net run-time result would be just as if you executed directly on a normal JBoss installation.
Now, let me guess, suddenly this is going to be alright, wouldn't it? Now your 'holy OPS' would consider this just another war/ear and would leave it alone despite being the exact same thing? There simply seems to be no limit to the stupidity of some organizations. If you choose to work at such place, it's your call but I suggest finding a more sane organization.
Posted by Robert Tuinman on March 20, 2010 at 07:45 PM CET #
>There simply seems to be no limit to the stupidity of some organizations. If you choose to work at such place, it's your call but I suggest finding a more sane organization.
You lost any chance at a reasonable discussion here..
Posted by Darryl Smith on March 20, 2010 at 08:01 PM CET #
Guys, as a regular application developer I couldn't care less about the politics of who's responsible for installing what. I find that line of discussion rather boring.
What I do care about is what programming environment has the best features and actually let's me be productive. Java EE 6 wins hands down for me here. It just has this coherent feel and it helps me a lot with the whole chain from user input to database and all the way back.
Posted by Dexter Hughes on March 20, 2010 at 08:24 PM CET #
well, the platform web framework is jsf. Some people just don't like it and never will. Why not do like Microsoft and provide a killer mvc framework too? I think jax-rs would be a good basis for that.
Posted by minow on March 21, 2010 at 05:04 PM CET #
Microsoft too has a bit of a problem here, as there seems to be a battle going on in .net land with asp.net vs asp.net mvc.
JSF is very close to ASP.NET really and unlike the name of the new MS framework would let you believe already an MVC framework too.
Posted by Dexter Hughes on March 21, 2010 at 06:51 PM CET #
@sboulay
>It's not even a matter of Java EE vs Spring anymore. I see a lot of customers moving to .NET. The better question is how does EE 1.6 or Spring 3.0 stack up against .NET 4.0.
It's an interesting question indeed. First of all I think .NET is a really interesting platform too where a number of interesting things are happening.
Two important downsides to .NET is that it's strictly tied to MS platforms and that it's closed source. It's not that I desperately want to make changed to their code and distribute these, but simply peeking in the code when a method doesn't quite do what I expected it to do is a real time saver.
It's maybe also interesting to note that .NET has the same model as Java EE. It doesn't require the user to assemble bits and parts from different sources, but is presented as one integrated whole.
Posted by Robert Tuinman on March 21, 2010 at 07:32 PM CET #
What's interesting to me is the fact that most Resin customers don't seem to have any trouble upgrading and do it quite frequently. The same is pretty much true of GlassFish, Tomcat, Jetty users and for the most part, JBoss, WebLogic users. It seems to me that the WebSphere guys are people with the upgrade problem - that's somewhat understandable I guess if you are working for an "IBM shop" dominated by COBOL, mainframes and DB2. If that's the fundamental argument for Spring adoption rather than developer productivity centric technical decisions, I think that's rather unfortunate and not something most Java EE adopters need to be overly concerned about. For one thing, WebSphere users could always use Seam that brings you a lot more of the Java EE features than Spring does or ever will.
As to Spring being "ahead", I predict Spring development will slow to a crawl in the next few years while Java EE development will accelerate under Oracle. Indeed, I suspect the same will happen to Tomcat now that it is no longer the reference implementation for the Servlet API and Sun will no longer contribute to it.
Cheers,
Reza
Posted by Reza Rahman on March 27, 2010 at 07:02 PM CET #