Link Details

The problem isn't Java. The problem is the Java Enterprise Edition (JEE).

Posted by germanescobar  |   Jan 11 2013 / 14:59

Add your comment


Html tags not supported. Reply is editable for 5 minutes. Use [code lang="java|ruby|sql|css|xml"][/code] to post code snippets.

Comments

User 236075 avatar

henk replied ago:

I don't agree one bit with this article. The author is so misinformed that it hurts. An AS exists because of history and politics??? The AS exists to run your Java EE application! Nothing else. Does Ruby or Python run directly on the hardware? Don't they need a runtime and a VM just as well? In essence, the AS and its containers are an extended VM, an elaborate runtime and at the end of the day a library or framework.

Reply 2 votes
User 525967 avatar

germanescobar replied ago:

Are you serious? The AS a library? "Extended VM" "elaborate runtime" This is just the complexity I'm talking about.

Reply -2 votes
User 157014 avatar

rrahman replied ago:

Please elaborate your point. Echoing someone else's statements a question is not a point :-)

Reply 4 votes
User 525967 avatar

germanescobar replied ago:

I'm actually expecting the author of the comment to elaborate on that first ;)

Reply -3 votes
User 236075 avatar

henk replied ago:

Java EE is ultimately a collection of libraries. You can pretty much put JSF, JPA, CDI, EJB, JAX-RS, JTA and many more in your war. You'll have the exact same APIs to code against and it's 90% the same code that gets executed at runtime. What you get with an AS is a tested distribution of those libraries, and as a bonus you get a better integration between those libraries. For instance, a separate libraries every lib will do its own scanning for annotations. JPA will scan all your classes, CDI will do it again etc. When using them as one integrated distribution this will typically only be done once. Then the Java EE model is that those libraries are installed at the server and not included in your war. This means you don't have to deploy the same libs over and over, and as an extra bonus, the annotation (and other artifacts) scanner will not scan those libraries when you deploy your war. So, your app gets *much* smaller and deploys much faster. It's not *that* different from putting all those libraries directly into the /lib dir of Tomcat or Jetty. Does JPA suddenly stop being a library and does it become something else as soon as you copy it there? The same goes for Spring btw, the Spring libs can be copied to the /lib of Tomcat or Jetty as well. And guess what, SpringSource actually offers such a configuration. As for the extended VM argument, the idea here is that a container (and yes, Spring is a bean container as well) manages some part of your classes in a transparent way. Just as the JVM manages instantiation of objects and handles the garbage collection among others, the container as seen as an extended VM handles a much finer grained life-cycle of your beans. In that sense, a specific usage of annotations comes close to language features. For instance, there's the synchronized keyword in Java, but the same behavior could be implemented with an @Synchronized annotation. In that case, a bean container manages synchronization, just as the lower level JVM would handle it in case of the language keyword. In fact, the @Lock annotation in Java EE that's used with a singleton achieves an effect quite like that and in every day uses feels just like using a language keyword. The annotation however is more flexible.

Reply 3 votes
User 157014 avatar

rrahman replied ago:

I would actually offer a troll alert here :-). Your first post had enough detail to start with for anyone that knows much about server-side Java.

Reply 2 votes
User 525967 avatar

germanescobar replied ago:

So, I was right. The AS *is not* a library as you first said. Anyway, so there are some libraries in your application and others on the AS. You have some configuration in your application and other in the AS. That way you save a couple of MB's on the deploy. What you are not getting is the complexity this adds. The JVM is enough abstraction. Don't put configuration in different places. There's no need. Don't move your Spring libs to Tomcat. A better approach is to use Maven and let you CI Server handle the library problem. Use env variables to control different app environments. Really, you don't need an application server! That just widening the gap between your dev/prod enviroment. You should checkout Jogger (https://github.com/germanescobar/jogger).

Reply -2 votes
User 236075 avatar

henk replied ago:

There's hardly any complexity in an AS and configuration can still be put in the war archive if you need it. And what gap between dev/prod are you talking about??? I use JBoss AS to develop my app on my workstation, and we use JBoss AS in production. If there's a new version of the JDK I have one installed on the server. If there's a new version of JBoss AS we deploy a new JBoss AS. If there's a new version of the app I'm coding we deploy that app. Yes, it's -that- simple :)

Reply 2 votes
User 1099985 avatar

john.hubbart replied ago:

>Are you serious? The AS a library? "Extended VM" "elaborate runtime" This is just the complexity I'm talking about. What complexity? It makes things really simple! A full Java EE app with a separate view and business code is just 3 files. See http://jdevelopment.nl/minimal-3tier-java-ee-app-xml-config No jars that need to be bundled, no frameworks that need to be configured. Just those very basic files. If you don't want to have the separation you can also deploy a single .jsp or just a single Servlet class or JAX-RS class. Then you have something running with just one file.

Reply 5 votes
User 157014 avatar

rrahman replied ago:

I agree this article is pretty low quality and flame bait. It fails to first make the case for why anyone should consider moving from Java EE and assumes the reader simply take the authors word for it.

Reply 5 votes
User 525967 avatar

germanescobar replied ago:

Reply -4 votes [show comment]
User 157014 avatar

rrahman replied ago:

That's a well-known logical fallacy called "begging the question". Without first estabilshing what exactly "opened your eyes" (all of which could be outdated or invalid reasoning) the rest of the post has little value but a is a potential waste of the readers time. If your point is simply to inform readers about some emerging technologies, the Java EE part should have been left out altogther instead of trying to incite unproductive flames. I am afraid you have opened the doors to being challenged on your thought process.

Reply 3 votes
User 157014 avatar

rrahman replied ago:

I suggest responding to me on your own blog post where commenst will be widely read instead of here :-)

Reply 1 votes
User 157014 avatar

rrahman replied ago:

Alerts to anyone thinking about posting to this individual's blog -- he has started to arbitrarily delete posts that do not suit the cause of advancing his product agenda!

Reply 1 votes
User 157014 avatar

rrahman replied ago:

Good - looks like he has restored my posts...

Reply 1 votes
User 157014 avatar

rrahman replied ago:

FYI: This individual has now declared on his blog that he will be selectively deleting my posts because "he won't talk to a person like me" :-).

Reply 1 votes
User 338269 avatar

Miloskov replied ago:

We all know J2EE it was driven by corporate agendas and it was plain crap. But Spring and others resurrected Java and Java EE from that mess. As of today Java EE 6 or Spring and others are easy as the dynamic languages. As for this blog post I dont agree much with the author, It seems he wants to promote his own framework. All the languages are capable to do Web development as Java, Python and Ruby but as this days the cap is very small. You can see it in the pet clinic for Java EE 6 that somebody ported is very very clear and compact the code as any dynamic language. rrahman and other commenters are right the author is behaving is strange manners to promote his product, I love DZone but sometimes you have to be careful because there is lots and lots of trolls posting blogs trying to get traction to their own needs.

Reply 4 votes
User 157014 avatar

rrahman replied ago:

Thanks so much for injecting some rationality into this. For anyone that thinks the JCP is not community-driven, I cordially invite you to join the Adopt-a-JSR online meeting: https://blogs.oracle.com/theaquarium/entry/join_adopt_a_jsr_online

Reply 2 votes
User 525967 avatar

germanescobar replied ago:

Wow, I can't really believe you guys. It's ok to write a post against Spring, but you will troll any article against JEE. Really impressed. It's like you are getting paid to ... oh.

Reply -1 votes
User 157014 avatar

rrahman replied ago:

If you are referring to Arun's article (https://blogs.oracle.com/arungupta/entry/why_java_ee_6_is), let's get some things in the clear. As I stated on that thread, firstly I think Arun is justified precisely because of Springs years of negative merketing tactics (tactics now you seem to have copied). Secondly, Arun's post was strictly professional - he never said anything like "moving away from Spring", "the long list of problems with Spring" or "Spring is hurting Java". His message was clear -- the gap that Spring filled no longer exists. To boot, Java EE now does what Spring used to do with less code, less configuration, less dependecies and more guarantees of vendor neutrality. Your post is nothing comparable to Arun's and starts out with outright flame bait that you assume the user will just agree with and you do not need to justify. Don't see it yet? Take a look at the negative votes aganst yoour post...

Reply 2 votes
User 157014 avatar

rrahman replied ago:

It's really interesting your continued insistence on spinning conspiracy theories. As I've already pointed out, I've been a Java EE advocate far longer than I've had anything to do with any vendor. My viewpoints on Java EE hasn't changed in years. And I can certainly tell you that the others posters are independent voicing their opinions with no conflicts of interest. You can hardly claim that yourself. It would perhaps been a little more convincing if your anti Java EE FUD was decoupled from your product pitch.

Reply 2 votes
User 983885 avatar

infovation_Softwares replied ago:

Reply -4 votes [show comment]

Recommended Links

Scala
Written by: Ryan Knight
Featured Refcardz: Top Refcardz:
  1. Apache Hadoop
  2. Play
  3. Akka
  4. Debugging JavaScript
  5. Design Patterns
  1. Apache Hadoop
  2. REST
  3. Java
  4. Git
  5. Java Performance
Connect with DZone