Link Details

Link 986849 thumbnail
User 419712 avatar

By delgad9
via pragmatikroo.blogspot.com
Published: Jun 24 2013 / 14:39

The new Java EE 7 is a well orchestrated community effort delivery. It is focused on addressing three major themes. 1) Next Generation of Web Apps. 2) Development productivity and 3) Including Batch processing to the Java Enterprise platform. Bottom line: JEE 7 is defining the destiny of everybody gravitating around the Java Enterprise Community.
  • 7
  • 57
  • 4385
  • 2835

Comments

Add your comment
User 116586 avatar

Jacek replied ago:

0 votes Vote down Vote up Reply

Dropwizard is the future of Java server development. Compared to it Java EE is a bloated mess. And you can easily integrate Spring with Dropwizard to keep it going for a long time. I see zero traction for Java EE in any job posting. Check out Dropwizard everyone before you plunge into Java EE.

User 388907 avatar

MCII replied ago:

-2 votes Vote down Vote up Reply

Dopewizard? Never heard of such a thing!

User 116586 avatar

Jacek replied ago:

0 votes Vote down Vote up Reply

Ha ha. http://dropwizard.codahale.com/ Once you try the idea of creating a WAR to deploy in some other external server will seem like the stupidest idea in a long time. Dropwizard has done wonders for my team's productivity. Complete sample including Spring, Spring Security, One-Jar and Cucumber BDDs here: https://github.com/jacek99/dropwizard-spring-di-security-onejar-example

User 157014 avatar

rrahman replied ago:

0 votes Vote down Vote up Reply
User 161039 avatar

mheath replied ago:

0 votes Vote down Vote up Reply

Good job pointing out the fact that nobody Googles for "spring framework". In related news, the sky is blue. Now try a search term that people actually use: http://www.google.com/trends/explore?q=java%20ee%2C%20%20spring%20mvc&cmpt=q#q=java%20ee%2C%20spring%20mvc&cmpt=q

User 157014 avatar

rrahman replied ago:

1 votes Vote down Vote up Reply

I think I've said quite enough. The "right term to use" argument is endless, arbitrary and pointless. I could argue Java EE isn't a term that's used that frequently either as opposed to EJB, JSF, J2EE, taken together. The point is that Spring has maybe achieved co-existence with Java EE, but that's about it and even that might be fading fast. Want to look at real world Java EE users? Here are some: https://blogs.oracle.com/stories/. I've been doing Java EE for years as an independent and have never had trouble finding clients - if fact I've had to turn down a few :-).

User 1055283 avatar

pieterhvmw replied ago:

1 votes Vote down Vote up Reply

The Spring REST stack is pretty robust as well, and Spring Social is a runaway winner in OAUTH bindings.. check out the spring social page for an *impressive* array of pre-built OAUTH bindings. The recent Spring webinar on the REST stack is pretty illuminating. http://www.youtube.com/watch?v=SC0FPuDKei0

User 157014 avatar

rrahman replied ago:

1 votes Vote down Vote up Reply

As far as I've seen, JAX-RS implementations are doing quite well in the REST area. I can agree Spring still has an edge with Spring Social, but there's also a CDI based alternative in Seam Social (that is being ported to DeltaSpike and is albeit in flux).

User 388907 avatar

MCII replied ago:

-2 votes Vote down Vote up Reply

Spring became legacy in 2006 when EJB 3.0 was released.

User 116586 avatar

Jacek replied ago:

2 votes Vote down Vote up Reply

Sure, it is noticeable in all the job postings that ask for it vs Spring.

User 419712 avatar

delgad9 replied ago:

0 votes Vote down Vote up Reply

Basically, I think it is the latest attitude of the JCP for evolving the Java EE platform brand. Nowadays, JCP looks more articulated, more reactive to emergent technologies/ development approaches and it is channeling input from the community while implementing JSRs. As a result of all of these JCP improvements; JEE 7 brings a much-much better product. Bottom line JCP has learned from the Java2EE 1.0-2.1 era mistakes. On the other hand. The Spring Framework(SF) was very successful on capitalizing on the initial mistakes of JCP with Java2EE awful implementation. SF introduced dependency injection for Java Enterprise and build and outstanding framework leveraging it. However mostly Spring source people work is integration only and not innovation. I truly believe integrating other people APIs won't be enough to stay relevant these days in the Java Enterprise Community. Java EE 7 is after Spring Framework jugular and it has a lot of chances of getting it this time. Thank you jD

User 161039 avatar

mheath replied ago:

0 votes Vote down Vote up Reply

The container based architecture is already legacy. JEE only works in a container based architecture. You can go containerless with Spring with very little modifications to your app. Dropwizard is nice but it's isolated to it's own little world. I think containerless Spring is the future.

User 116586 avatar

Jacek replied ago:

0 votes Vote down Vote up Reply

Not sure what you mean Dropwizard is contained to its own little world. You can integrate anything you want with Dropwizard, it's already made out of Java best-of-breed components: Jetty (Web Server), Jersey (JAX-RS), Jackson (JSON), Logback (Logging), etc. And best of all the configuration is a breeze: ONE single YAML file. None of the multitude of XML config files (e.g. JNDI) that exist in all these Java EE containers. We'be been using Dropwizard for 9 months now and it is the best thing to happen to Java since Lombok.

User 1055283 avatar

pieterhvmw replied ago:

-1 votes Vote down Vote up Reply

mheath, I think you are right about container based archietctures being dead, and redmonk agrees with you: http://redmonk.com/dberkholz/2013/06/19/interest-withering-in-java-application-servers/?utm_source=rss&utm_medium=rss&utm_campaign=interest-withering-in-java-application-servers Spring is kicking *ss though.

User 157014 avatar

rrahman replied ago:

0 votes Vote down Vote up Reply

Frankly, that analysis is pretty dubious (note the Google Trends data I cited earlier in the thread). Here's another graph from indeed.com that contradicts their data: http://www.indeed.com/jobtrends?q=spring+framework%2C+weblogic%2C+websphere%2C+jboss&l= . It is also very strange that they ignore the obvious facts that modern application servers already embrace modularity and by and large most Spring users use an application server and will likely continue to do so in the foreseeable future.

User 419712 avatar

delgad9 replied ago:

-1 votes Vote down Vote up Reply

I wonder where I can download an enterprise "containerless Spring app"... I would like to try it. Thank you in advance

User 116586 avatar

Jacek replied ago:

0 votes Vote down Vote up Reply
User 116586 avatar

Jacek replied ago:

0 votes Vote down Vote up Reply

You can see the high level presentation I did about Dropwizard for the local JUG: https://github.com/jacek99/dropwizard-spring-di-security-onejar-example/raw/master/Dropwizard_Spring.pdf

User 157014 avatar

rrahman replied ago:

0 votes Vote down Vote up Reply

Gotta love the clever word play :-). A "containerless" stack that nonetheless uses a Servlet container (Jetty) and a DI container (Spring) that you need to configure the most brain-dead things in a totally non-standard stack...

User 116586 avatar

Jacek replied ago:

0 votes Vote down Vote up Reply

Whether it is standard means nothing. J2EE 1.4 was standard too, remember. What matters is that Dropwizard is an incredible, super productive experience. It runs circles around any WAR-based development cycle. Whether it is standard or not, I could not care less.

User 157014 avatar

rrahman replied ago:

0 votes Vote down Vote up Reply

The reality is that companies care about vendor neutrality which is why a solution bound to just one or two runtimes will never go anywhere. If it did, MS would have overtaken Java a long time ago.

User 116586 avatar

Jacek replied ago:

0 votes Vote down Vote up Reply

It is going quite far down here, thank you very much. Every single dev team I've shown Dropwizard too has dropped their traditional WAR-based dev approach and adopted it for themselves. You need to code in Dropwizard for 15 minutes and never have to redeploy a WAR file again (without the need for JRebel or any special IDE plugins, like the NB one that *only* works with Glassfish)....to realize how brilliantly simple it is. Coda Hale (Twitter, Yammer) is smarter than all the folks on this discussion combined and he has created a best-of-breed Java stack that is a joy to work with every day.

User 157014 avatar

rrahman replied ago:

0 votes Vote down Vote up Reply

Best of luck to you then - I'll take it seriously when I actually see some adoption in the job listings you seem to be so big on. BTW, Java EE is totally agnostic of GlassFish and/or NetBeans - that's part of what people have told us for years they want from Java. All you need is text editor and something as small as TomEE. I'll stay out of the your (brain) is clearly bigger than mine discussion :-).

User 116586 avatar

Jacek replied ago:

0 votes Vote down Vote up Reply

OK, let's turn down the heat. I didn't want this to turn into a flamewar. There are a lot of good parts in Java EE (CDI, JPA, JAX-RS, etc). I just do enjoy Dropwizard a lot and think folks should know they have other options besides Spring or Java EE. Cheers, no hard feelings.

User 157014 avatar

rrahman replied ago:

0 votes Vote down Vote up Reply

No heat here whatsoever. As to flame wars, last I checked I didn't start a thread trying to trash arbitrary technologies and curry favor to ones' own sacred cow. In fact, notice that I didn't even say I agree with what the title of the link says. However, Olive Branch accepted anyway :-).

User 116586 avatar

Jacek replied ago:

-1 votes Vote down Vote up Reply

Cool. :-) No doubt about it, if I hand't discovered Dropwizard I would be using Java EE. It's the second best option out there *grin*. P.S. On the other hand, the title of the blog post is somewhat inflammatory to begin with...

User 157014 avatar

rrahman replied ago:

1 votes Vote down Vote up Reply

That we can both agree on. If the point was to promote Java EE 7, there were more constructive ways of doing that.

User 419712 avatar

delgad9 replied ago:

1 votes Vote down Vote up Reply

Jacek, I apologize if the title is perceived the way you described... This is just an opinion of developer that has work with Java and Java Enterprise since pretty much its inception. I've worked extensible with different flavors of Java Enterprise: J2EE 1.0-2.1, JBoss Seam and SF. You can visit my blog at http://pragmatikroo.blogspot.com/?view=flipcard for my SF showcases. I truly believe that JCP has released a great product (JEE 7) and has a great road map for next JEEs too. JCP is executing really well and has a lot of momentum, based on what I learned on Wed June 12, 2013. Live WebCast Introducing JEE 7. Please leave it to the time: The title will reveal as premonitory not the other way. Thanks jD

User 161039 avatar

mheath replied ago:

0 votes Vote down Vote up Reply

Granted the term "containerless" isn't the best. Regardless, the idea that I have to have an application server before I can run my application is ridiculous. It is so much easier for both development and ops to just run the application. Our industry seems to be headed in this direction anyway, just like at item #53 here: http://www.thoughtworks.com/radar Maybe JEE will actually react to this and build a standard that doesn't require an application server but since JEE is driven by the big application server vendors, this is very doubtful.

User 157014 avatar

rrahman replied ago:

1 votes Vote down Vote up Reply

Look into using Apache Cargo+Maven with a solid implementation like GlassFish. It basically does exactly what you just described, in a completely vendor and runtime neutral fashion.

User 361295 avatar

Shane K Johnson replied ago:

1 votes Vote down Vote up Reply

That makes sense for a desktop application. However, the purpose of a container is to provide enterprise services. If your application requires enterprise services (e.g. peristence / messaging / transactions / inject), it requires a container unless you want to create, configure, and integrate those services yourself.

User 419712 avatar

delgad9 replied ago:

0 votes Vote down Vote up Reply

I agree with you Shane... Probably we will have to start all over with the version of C++ of Dropwizard. I am sure is in the roadmap. Regards jD

User 1055283 avatar

pieterhvmw replied ago:

-1 votes Vote down Vote up Reply

Spring Framework 4.0 will support this "containerless" option out of the box. Nothing to download yet, but you won't have to wait long... look for more information on this closer to SpringOne2GX 2013: https://springone2gx.com/conference/santa_clara/2013/09/session?id=29409

User 157014 avatar

rrahman replied ago:

1 votes Vote down Vote up Reply

Not sure it is worthy of the exalted "containerless" club, but here's basically how you can run a Java EE 7 application right from the command line using embedded GlassFish 4 and the maven plugin: https://blogs.oracle.com/brunoborges/entry/glassfish_4_beta_and_maven :-).

User 116586 avatar

Jacek replied ago:

-1 votes Vote down Vote up Reply

And BTW nothing stops you from using CDI, JPA, etc. in Dropwizard. Many people do it as well. So you can get the best parts of Java EE without all the other baggage.

User 157014 avatar

rrahman replied ago:

1 votes Vote down Vote up Reply

Except that you have to configure everything yourself as opposed to having an application with just standard Java + annotations and no necessary configuration of any kind for 80% use cases :-).

User 116586 avatar

Jacek replied ago:

-1 votes Vote down Vote up Reply

So?... it's like 20 lines of Java, After that it's regular annotations all the way.

User 157014 avatar

rrahman replied ago:

1 votes Vote down Vote up Reply

Pointless configuration is pointless configuration that people need to learn, know about and maintain. Here's how Spring looks like compared to Java EE even for the simplest stuff: http://www.rahmannet.net/downloads/spring_javaee_comparison.pdf. It gets much worse for larger applications and/or older versions of Spring.

User 116586 avatar

Jacek replied ago:

-1 votes Vote down Vote up Reply

That does sound a bit overblown. We have a huge app with large amount of components (domain, DAOs, business services, JAX-RS resources, etc). They are all wired together using @Inject, nothing else. The only config is those 20 lines of Java code that glue Spring and Dropwizard together. Whether you have 10 Java classes or 1,000...that config does not change or grow in size. And in terms of config size all of the Dropwizard config is in a single YAML file (no XML), which is extensible do add your own elements: http://dropwizard.codahale.com/manual/core/#configuration-defaults

User 157014 avatar

rrahman replied ago:

1 votes Vote down Vote up Reply

Frankly, I can't comment on your solution since I haven't written an application with it. Whenever I see inane things like persistence configuration, it makes me really wonder what will happen when you throw in things like messaging, batch, concurrency, scheduling, email, websocket, etc that's all too common for most realistic applications. If you say you do better than Spring in those cases, I guess I'll have to believe you for now.

User 116586 avatar

Jacek replied ago:

0 votes Vote down Vote up Reply

Sure, we extend the same YAML config file to add a section for connecting to our NoSQL database. It's 3 extra lines of YAML that Dropwizard automatically maps to a POJO we @Inject everywhere that needs it (e.g. DAO). No need for JNDI (nothing wrong with JNDI itself, but configuring JNDI datasources in XML files on a prod server is a rather verbose experience, depending on the container-specific format of the config files).

User 157014 avatar

rrahman replied ago:

1 votes Vote down Vote up Reply

Look into @DataSourceDefinition. It's totally portable and XML free. I've used it for years now. As to NoSQL, there are plenty of solutions out there now (EclipseLink NoSQL, Hibernate OGM, DataNeuclus) that enable POJO to NoSQL mapping via JPA annotations/API (most major NoSQL databases are supported). Here is a talk on it: http://www.slideshare.net/reza_rahman/using-nosql-with-jpa-eclipselink-and-java-ee.

User 361295 avatar

Shane K Johnson replied ago:

1 votes Vote down Vote up Reply

What's the baggage? Modern application servers are built on modular, dynamic service architectures. If you don't need a particular component, don't use it and it won't be there. It will be like it never existed.

User 308270 avatar

adij replied ago:

4 votes Vote down Vote up Reply

This post is nothing but feed for flame wars. It contains less content and more sensationalism. See https://www.youtube.com/watch?v=3KW-2tLur3c. It is more constructive debate. Developers use frameworks based on need. We have projects on pure JEE, Spring+JEE, Play-Scala developed parallel. I wish people who have interest in promoting JEE spend their time on educating the community with real examples rather than participating in these flame wars. Here is a example of that, http://tomee.apache.org/examples-trunk/index.html. Show developers the code, let them make decisions. I don't think most developers are not stupid enough to choose frameworks based on posts like this.

User 157014 avatar

rrahman replied ago:

1 votes Vote down Vote up Reply

Really great point. BTW, we have a Java EE 7 hands-on lab that shows quite a bit of code: https://glassfish.java.net/hol/ (it's pretty self contained - just give it a spin and let us know what you think :-)).

User 419712 avatar

delgad9 replied ago:

1 votes Vote down Vote up Reply

Thank you to rrahman on the link provided. How come I missed to mention it!. BTW There is a series of 3 articles on the same tutorial in the Java Magazine as well.

User 157014 avatar

rrahman replied ago:

1 votes Vote down Vote up Reply

I think you mean the free Java EE 7 tutorial and starter app? That's here: https://blogs.oracle.com/thejavatutorials/entry/java_ee_7_tutorial_released .

User 419712 avatar

delgad9 replied ago:

1 votes Vote down Vote up Reply

rrahman, This is the one I am referring to: http://www.oraclejavamagazine-digital.com/javamagazine_open/20130506#pg27. Regards jD

User 157014 avatar

rrahman replied ago:

1 votes Vote down Vote up Reply

Ah, I see - hadn't seen that one yet. Maybe it's best if we reference it on our HOL page - I'll see what I can do.

User 308270 avatar

adij replied ago:

1 votes Vote down Vote up Reply

Thanks. I will give a try. The things that driven me towards tomee is it's maven plugin. You can bootstrap application in minutes. You can remove default stack easily, for example, replace OpenJPA with Hibernate. If you need any libs that should go to container lib, for example db drivers, you can configure specify it using ivy like syntax in plugin configuration.

User 157014 avatar

rrahman replied ago:

1 votes Vote down Vote up Reply

Just out of curiosity, do you know about the GlassFish Maven plugin: https://maven-glassfish-plugin.java.net/ ?

User 308270 avatar

adij replied ago:

1 votes Vote down Vote up Reply

No. I didn't even evaluate Glassfish. I am a JBoss guy but for one of our projects, customer wanted it to be on tomcat because their other apps run on tomcat. Even we didn't see significant differences, we obliged. I will give a try for any new project.

User 157014 avatar

rrahman replied ago:

1 votes Vote down Vote up Reply

Sounds good. Don't hesitate to reach out if you need anything.

User 361295 avatar

Shane K Johnson replied ago:

1 votes Vote down Vote up Reply

There is a JBoss Maven plugin as well. It can handle things like that datasource configuration and deployment too. In addition, JBoss provides a number of archetypes, the Java EE API artifacts, and a Java EE BOM (Web / Full Profile) to include said artifacts. This is my reference EE / Maven application. https://github.com/shane-k-j/jboss-trading

User 308270 avatar

adij replied ago:

1 votes Vote down Vote up Reply

I used JBoss for 7 years, and I follow every project related to it closely. In fact my last project runs on JBoss 7. For one of the project, I needed something simple, so I went with tomee. For large projects I don't even go anywhere near maven because custom flows are hard to do. I stick to ant+ivy, even to manage JBoss life cycle.

User 361295 avatar

Shane K Johnson replied ago:

1 votes Vote down Vote up Reply

But... "The things that driven me towards tomee is it's maven plugin." Out of curiousity, what makes TomEE 'simple' in comparison to JBoss AS / WildFly?

User 419712 avatar

delgad9 replied ago:

2 votes Vote down Vote up Reply

Hi Adij, I agree with you... These are my examples using SF: http://viralpatel.net/blogs/author/jose-delgado/ and http://pragmatikroo.blogspot.com/ I am in the process of reimplementing my showcases using JEE 7, so I can't provide you with a link right now. My post is an opinion that what JEE 7 means to the Java Enterprise Community in my view. That's it. Thank you jD

User 157014 avatar

rrahman replied ago:

2 votes Vote down Vote up Reply

The debate whether Spring is legacy notwithstanding, thanks for the post and the initiative to write Java EE 7 examples. If you are not already, please consider joining the JCP and help shape Java EE (the time to talk about Java EE 8 and beyond is now). Definitely let us know if we can help with anything - I like to think I'm pretty easy to reach and responsive :-).

User 419712 avatar

delgad9 replied ago:

1 votes Vote down Vote up Reply

rrahman, Great, I wonder if you can review my showcases blog site -http://pragmatikroo.blogspot.com/?view=flipcard- and tell me if you find any of the showcases relevant to move to JEE 7. Ideally a list of showcases if would be possible. If you don't find anyone good . Well just tell me that -no worries- and I try to come up with something fresh. Regards jD

User 157014 avatar

rrahman replied ago:

1 votes Vote down Vote up Reply

OK, I'll try and do that. Can you do me a favor and send me an quick note at reza.rahman@oracle.com? That way, I can respond back when I can?

User 308270 avatar

adij replied ago:

1 votes Vote down Vote up Reply

Thanks, I will look into it

User 230813 avatar

sivaprasad replied ago:

2 votes Vote down Vote up Reply

Oh, still people are discussing Spring Vs JavaEE... wonderful...good way to burn some time..

User 157014 avatar

rrahman replied ago:

1 votes Vote down Vote up Reply

I agree it's definitely pointless - there's already so much decent material on this topic. At any rate, personally it keeps me sharp as long as things stay at least somewhat civil.

User 334116 avatar

Grzegorz Grzybek replied ago:

1 votes Vote down Vote up Reply

Aaaah - nothing causes such discussion as putting "spring" and "legacy" in a single blog title :) I wonder whether this thread will live as long as the famous http://bill.burkecentral.com/2012/03/13/java-ee-wins-over-spring/. I also wonder why do some people still repeat that spring is dead today, when it has lost 15 months ago... Don't they remember the time when Ruby won over Java around 2008? regards Grzegorz Grzybek

User 419712 avatar

delgad9 replied ago:

1 votes Vote down Vote up Reply

Hello Grzegorz Grzybek, Legacy doesn't means dead at all... Cobol is a considered a "legacy" programming language. After all these years Cobol still there and will be for many-many years to come. The point that you make on Ruby is true. I took a little longer to the Java platform stakeholders aka (JCP) assimilated the foundational concepts of configuration by convention, dry and dependency injection and now is delivering JEEs incarnations based on them. In my opinion there is still something -very important- that Ruby delivered to the Web development community that Java platform doesn't have: RoR. In fact Spring Framework people created the closest Java product to RoR: Spring Roo. I really don't think Spring is dead. I wish not; I hope not. It will stay with the community many years to come. I just think JEE 7 -and subsequent releases- will be very-very dominant -like never before- on the Java Web Development ecosystem. Thank you jD

User 157014 avatar

rrahman replied ago:

2 votes Vote down Vote up Reply

Not to continue this stale discussion any further than is necessary, but Java EE actually adopted command line code generators far before Spring did with seam-gen (Seam 2). Nowadays, seam-gen has evolved to Forge ( http://forge.jboss.org/ ). It's from JBoss, but it's really a container agnostic tool. That being said, I've clearly stated many times in the past that Java EE needs Spring as much as Spring needs Java EE. The solution stacks have different strengths, heavily adopt from each other and keep each other honest. I hope that's the way it always is to keep things vibrant in the Java EE ecosystem for years to come.

User 334116 avatar

Grzegorz Grzybek replied ago:

1 votes Vote down Vote up Reply

Well said! Amen :)

User 419712 avatar

delgad9 replied ago:

1 votes Vote down Vote up Reply

I really believe we have to leave to our colleagues the decision if this is a "stale" or "pointless" discussion. Everybody is welcome to participate and entitled to their opinion. I extensible worked with Seam and I liked very much. Spring created Spring Roo far much better and Seam.IMHO. Last time I visted/tried Forge was still far behind Spring Roo. BTW, I don't think your point on Forge is stale or without value. It remind me that I have to look Forge again. Thanks jD at http://pragmatikroo.blogspot.com/

User 157014 avatar

rrahman replied ago:

1 votes Vote down Vote up Reply

If you believe Forge needs improvement, I would suggest working with Lincoln. He is a great guy and is genuinely interested in growing the Java EE ecosystem. I used Forge about a year ago and found it quite sufficient for my team's needs. As much as I appreciate your kind words about Java EE and the JCP, as a well-wisher I really hope you are paying attention to the negative votes your post is getting. It always worries me when I see things that can and do easily turn attention away from the technology and evoke emotions instead. Again, this is a well intended remark and I hope you see it as such.

User 419712 avatar

delgad9 replied ago:

-1 votes Vote down Vote up Reply

Actually the negative votes are good... I'll tell you why after a little bit of context below Context: We always talk about the mythological concept of STANDARDS in Software Development and scratching our heads on how come the Computing hardware industry counterpart always moves faster and is more productive. The fact is that you are able to plug your USB device regardless the source to any USB outlet regardless the device. And it will work. You can install any IC 555 timer regardless the manufacturer to any board and it will work. I don't think that ideal of standard will happen in the Java Ecosystem if major players are pulling frameworks in different directions. I will like to add another wish to my list. A total unification of frameworks for the Java Enterprise. Impossible? Well will keep walking in circles and having these "stale" and "pointless" discussions then. I told you, I'll tell you "why negative votes are good thing". It tell you a measure on how close/far the Java ecosystem to get standardized. Your are right I doesn't look good at all for the standardization camp. Think about that... On the other hand. Please send me the link of the Forge projects you mentioned -if possible- since a I'm really interested in JAVA-RAD. Regards jD

User 334116 avatar

Grzegorz Grzybek replied ago:

-1 votes Vote down Vote up Reply

Hmm. The USB analogy is not quite good... HTML standard had to wait for IE10 to let us say that "standard" HTML page will look [b]almost[/b] the same in all major browsers. For a closer (to Java) analogy - I've tried to use EclipseLink instead of Hibernate for [b]JPA annotated classes[/b]. But the required change in the environment (postprocessing classes, etc.) was not worth the effort. So I'm not using JPA. I'm using Hibernate in particular version. And switching from e.g. Hibernate 4.2.2 to 4.3.0.Beta is generally a matter of looking at JIRA. Sticking only to JPA standard is not sufficient. Another example - JSON. JavaEE7's approach to use JAXP-like model is nice. But it should rather be done 5 years ago. Now I'm just using Jackson from Codehaus. Spring MVC integrates well with Jackson and for this content negotiation scenario is quite good.

User 419712 avatar

delgad9 replied ago:

-1 votes Vote down Vote up Reply

Hmm... Thank you on your analogy on HTML5. I totally missed. How many-many-many hours of web development addressing cross-browser issues on 10 ten years before HTML5 on global scale. One hour, 10 hours, 100 hours... 1 googol, 1 googplex? maybe. On global scale and turned in to currency. Believe it will be a lot!. Unfortunately a lot of waste. Grzegorz Grzybek, Thank you for providing a real example of pros/cons of standardization for the Software industry. jD

User 157014 avatar

rrahman replied ago:

1 votes Vote down Vote up Reply

I think you have some misconceptions about standards that are worth pointing out. Standards can never guarantee 100% compatibility. If they did, it would instantly kill all innovation in that space. What good standards attempt to do is make it possible for the common cases to be vendor-neutral so that porting between implementations is far easier, but not necessarily effortless. Now, whether or not you care about vendor neutrality is a value judgment. In my decades of experience, I've seen that most IT decision makers do care about vendor neutrality. Standards also can and should take time as ideas need to mature properly and remain long-lasting. Attempting to standardize JSON in 2009 definitely would have been premature. Now, it's true Java EE 7 took longer than anyone was hoping for but the reality is that the folks doing most of the heavy lifting for Java EE went through a pretty complex acquisition of one very large company by another and had to deal with a shift in focus away from the cloud.

User 419712 avatar

delgad9 replied ago:

1 votes Vote down Vote up Reply

I hope the misconceptions end one day... and the story of Java Enterprise ended as with HTML5. Of course "without killing innovation". Please not.:)

User 157014 avatar

rrahman replied ago:

1 votes Vote down Vote up Reply

I think what you are trying to say is that the fragmentation in Java EE for things like DI and basic container services such as transaction management, etc has gone a bit too far. I certainly see that point, especially with nonsensical things like Spring calling itself a de-facto standard (basically a euphemism for a monopoly using/abusing open source as a crutch). I think that viewpoint is definitely going to be proven wrong in favor of more effective vendor neutrality if it hasn't been proven wrong already. At the same time, I'd hate for Spring to be marginalized out of relevance. It's an important source of innovation/healthy competition, clearly is right for some folks and at the end of the day still heavily dependent on Java EE in all reality (it's not hard to see given Oracle's rather large revenue stream from customers running Spring on WebLogic for example). BTW, the HTML 5 evolution is likely to be much like Java EE. It'll likely co-exist with existing rich client solutions for a period of time before an eventual long term convergence. Even then, there will always be non-standard browser extensions to HTML 5 and perhaps cases where HTML 5 doesn't make sense at all in favor of something non-standard. BTW, personally, I've called on the Spring folks to become a certified Java EE implementation a long time ago and adopt CDI and perhaps even EJB 3. In my view, that's the safest way forward for them and the Java EE community as a whole while still allowing them to retain their core adopters and remain competitive. That way, they could have still maintained Spring as an embeddable CDI container just like Weld, albeit with some "legacy" proprietary features and non-standard extensions.

User 157014 avatar

rrahman replied ago:

1 votes Vote down Vote up Reply

I think we're taking the negativity bandwagon a bit too far :-). The reality is that standardization, vendor-neutrality and portability has worked and will continue to work in the Java EE ecosystem for a long time. That's precisely the reason you have the choice to run frameworks like Spring on pretty much any runtime of your choice (even just a plain Servlet container) or choose vanilla Java EE if it's right for you. My experience has been that Java EE has been slowly and quietly gaining traction as it should - hopefully with a net effect of mutual co-existence in the long run and a trend towards greater vendor-neutrality.

User 419712 avatar

delgad9 replied ago:

1 votes Vote down Vote up Reply

negativity?... Not in my vocabulary. I accept you reality on standardization as you stated. No problem. Thanks jD

User 157014 avatar

rrahman replied ago:

1 votes Vote down Vote up Reply

Hmm - I already did post a link to Forge? At any rate, here it is again: http://forge.jboss.org - I am also happy to get you in touch with Lincoln personally if needed.

User 419712 avatar

delgad9 replied ago:

1 votes Vote down Vote up Reply

Yes, you did... indeed. I was more interested in "I used Forge about a year ago and found it quite sufficient for my team's needs" stuff if available. Kind of real world apps. Reza you are great-great colleague for exchanging opinions. I am learning a lot from you. Thank you very much. jD

User 157014 avatar

rrahman replied ago:

1 votes Vote down Vote up Reply

I see. Unfortunately I can't share that code since it's not in the public domain and the sole property of my (former) client. Lincoln does have a few pretty good samples here: http://forge.jboss.org/docs/using/samples.html . I think he has more on GitHub somewhere. The best bet is to get in touch with him or get on the Forge forums. His twitter handle is @lincolnthree.

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.

Java Performance Optimization
Written by: Pierre-Hugues Charbonneau
Featured Refcardz: Top Refcardz:
  1. Design Patterns
  2. OO JS
  3. Cont. Delivery
  4. Java EE7
  5. HTML5 Mobile
  1. Node.js
  2. Debugging JavaScript
  3. OO JS
  4. JSON
  5. Ajax