DZone
Java Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Java Zone > Future Of Enterprise Java ...Is Clear (Java EE with/without Spring and Vice Versa)

Future Of Enterprise Java ...Is Clear (Java EE with/without Spring and Vice Versa)

adam bien user avatar by
adam bien
·
Mar. 26, 10 · Java Zone · Interview
Like (0)
Save
Tweet
5.84K Views

Join the DZone community and get the full member experience.

Join For Free

Java EE 6 and Spring 3 became very similar - at least the resulting architecture and even design will differ only in details (see also Juergen Hoeller comment). I don't expect differences in development lifecycle either - e.g. Glassfish deployment (changing a JPA entity or a Session Bean) takes only a few hundred milliseconds - but you could achieve the same easily with Spring as well (there is no reason, why not).

Spring also comes with own server. Spring has (since October 7th, 2008) similar maintenance policies to opensource servers with commercial support. If you would like to have patches for an older Spring-version - you will have to buy commercial support from SpringSource / VMWare. For serious projects you will have to sign two maintenance and support contracts - one with your application server vendor and the another one with SpringSource. That is very hard to justify having Java EE 5 / 6 in place. In mid term I only see this two options:
  1. Deploying Spring on the "proprietary" tc Server
  2. Deploying Java EE 6 applications without Spring (you could build them with Spring support, but deployment to production will be the issue)

All the migration projects will also have to make this decision, whether they will stick with Java EE, or migrate straight to Spring. This decision has nothing to do with technology - and a lot with business / strategy / politics. You could of course build Spring from source and deliver a binary by yourself. Delivering an uncertified, un-indemnified "custom" Spring-build would be impossible for "mission critical" and very hard for most commercial projects. The future of Enterprise Java is very clear - full stack Spring or full stack Java EE - but no mix any more.

From http://www.adam-bien.com

Spring Framework Java EE Java (programming language) Clear (Unix)

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • How to Generate Fake Test Data
  • Conducting Sprint Retrospective Meetings
  • Usage of Java Streams and Lambdas in Selenium WebDriver
  • API Testing for Open Banking Operations

Comments

Java Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo