Link Details

Link 904559 thumbnail
User 525967 avatar

By germanescobar
via germanescobar.net
Published: Jan 11 2013 / 14:59

The problem isn't Java. The problem is the Java Enterprise Edition (JEE).
  • 6
  • 22
  • 2024
  • 2235
User 236075 avatar

henk replied ago:

2 votes Vote down Vote up Reply

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.

User 525967 avatar

germanescobar replied ago:

-2 votes Vote down Vote up Reply

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

User 157014 avatar

rrahman replied ago:

4 votes Vote down Vote up Reply

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

User 525967 avatar

germanescobar replied ago:

-3 votes Vote down Vote up Reply

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

User 236075 avatar

henk replied ago:

3 votes Vote down Vote up Reply

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.

User 157014 avatar

rrahman replied ago:

2 votes Vote down Vote up Reply

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.

User 525967 avatar

germanescobar replied ago:

-2 votes Vote down Vote up Reply

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).

User 236075 avatar

henk replied ago:

2 votes Vote down Vote up Reply

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 :)

User 1099985 avatar

john.hubbart replied ago:

5 votes Vote down Vote up Reply

>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.

User 157014 avatar

rrahman replied ago:

5 votes Vote down Vote up Reply

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.

User 525967 avatar

germanescobar replied ago:

-4 votes [show comment] Vote down Vote up Reply
User 157014 avatar

rrahman replied ago:

3 votes Vote down Vote up Reply

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.

User 157014 avatar

rrahman replied ago:

1 votes Vote down Vote up Reply

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

User 157014 avatar

rrahman replied ago:

1 votes Vote down Vote up Reply

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!

User 157014 avatar

rrahman replied ago:

1 votes Vote down Vote up Reply

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

User 157014 avatar

rrahman replied ago:

1 votes Vote down Vote up Reply

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" :-).

User 338269 avatar

Miloskov replied ago:

4 votes Vote down Vote up Reply

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.

User 157014 avatar

rrahman replied ago:

2 votes Vote down Vote up Reply

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

User 525967 avatar

germanescobar replied ago:

-1 votes Vote down Vote up Reply

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.

User 157014 avatar

rrahman replied ago:

2 votes Vote down Vote up Reply

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...

User 157014 avatar

rrahman replied ago:

2 votes Vote down Vote up Reply

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.

User 983885 avatar

infovation_Softwares replied ago:

-4 votes [show comment] Vote down Vote up Reply

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.

Apache Hadoop
Written by: Piotr Krewski
Featured Refcardz: Top Refcardz:
  1. Play
  2. Akka
  3. Design Patterns
  4. OO JS
  5. Cont. Delivery
  1. Play
  2. Java Performance
  3. Akka
  4. REST
  5. Java