Developer: Hey, in this video,
we're going to find out why should we use Spring.
So, Spring in a nutshell.
Basically, Spring is a very popular framework
for building enterprise Java applications.
When Spring first came out,
it was initially a simpler, lightweight alternative to J2EE.
They basically give you a large number of helper classes
to make enterprise development easier.
But now, you may wonder, well, what about J2EE or Java EE?
And here, they have client-side presentation,
they talked about server-side presentation
with JSP, servlets, XML, and Web Services.
They also discussed the idea of server-side business logic
using Enterprise JavaBeans, Web Services, and so on.
And all talk into a backend database.
And this all looks really good on paper
and as the developers,
we were very excited when we saw this, viewing it on paper,
but what happened is that when we actually got
into the implementation details, it was another story,
and I'll talk more about that in a second.
All right, so how did J2EE grow up?
Well, in the early days, it started out really nice.
You had servlets, JSPs back in 1999.
You also had Enterprise JavaBeans, Java Message Service,
and RMI, Remote Method Invocation.
And then over the years,
they added more support for EJB with 1.3.
They added, in J2EE 1.4, they added Web Services.
In Java EE 5, they kind of renamed it a bit,
so it's Java Enterprise Edition 5.
They dropped the J2EE thing.
And then they added some ease of use for EJB 3,
JPA, JSF, JAXB, and JAX-WS or Web Services.
And then with EE 6 again, they pruned,
meaning they got rid of some stuff that didn't work,
mainly some of the EJB problems,
and also, they made it easier to use so on and so forth.
They had a support for CDI, Context Dependency Injection.
And then finally, in Java EE 7,
they added support for JMS version two,
Batch, Concurrency, Web Sockets, and so on.
So, that's kind of how J2EE grew up over time.
So, servlets and JSPs were like the initial popular items
and then they started adding other things along the way.
Now, the one thing they added along the way
was Enterprise JavaBeans.
And so, EJB is like your cousin
or your family member that you just don't really like
because they just mess things up for everybody.
So, the early versions of Enterprise JavaBeans,
versions one and two, were extremely complexly developed.
You had to create these XML deployment descriptors.
You had to define multiple interfaces.
So, like we have on this diagram here,
to create a Bean Class, we had to have a Home Interface
and then a Component Interface,
and you basically had, like, three or three .java files
just for an actual Bean implementation.
So, just a lot of work.
It was really clunky for a developer
to write all of this code.
It was very tedious and very error prone.
But once you've finally got the Bean developed
and deployed it, and you deployed it in production,
then you are slapped with another problem: poor performance.
So, these Entity Beans,
basically mappings between Java classes and database tables,
ah, just awful slow, just terribly slow.
Like, we actually had to do,
on one deployment, we actually had to pull our code
back out of the production
and actually remove the EJB functionality
because it slowed everything down.
And so, what happened over time is that a lot of developers
started to continue to do J2EE
but they actually would do it without Enterprise JavaBeans.
And so, this kind of caught on
with other development teams too
and pretty much, a lot of folks are doing it.
So, this one fellow, Rod Johnson,
he actually wrote this great book
called J2EE Development without EJB.
So, EJB was very popular at one point,
then it fell out of favor.
And so, he pushed that out
and they also started working on the Spring Framework.
And so, they released another book,
Java Development with the Spring Framework.
So, EJB was kind of like that bad cousin
or that bad uncle that you just didn't want in the family
because they mess it up for everybody.