
History of Spring Framework and Spring Boot - based2
https://www.quickprogrammingtips.com/spring-boot/history-of-spring-framework-and-spring-boot.html
======
royalghost
Spring as a framework has come a long way since the year 2006 when it required
multiple XML files for configuration to the now Spring Boot which requires
virtually zero configuration. Now it is easier to develop MVP web app using
Spring Boot than Rails. With the framework such as Angular 2, people withe
server side programming experience are finding it easier to develop client
side app with much ease. I have found Angular 2 and Spring Boot a great
combination for client server app development.

~~~
TheRealDunkirk
> Now it is easier to develop MVP web app using Spring Boot than Rails.

BWAHAHAHAHAHA! Good one.

Seriously, though, I'm really, really glad to see this come up this morning.

I've done a lot of .NET lately, but Rails has been my main tool for 10 years.
However, because it's (apparently) a strange, new, unproven-and-potentially-
exceedingly-insecure framework, and because I'm the ONLY PERSON in a company
of SIXTY THOUSAND employees who could possibly write a program with it, I've
been forced to stop using it. I took FOUR MONTHS of arguing about it with the
powers-that-be to conclude that I should use Java instead. I have 3 web
applications to write, right now, with some flavor of Java EE.

For a couple of weeks, I've been trying to bootstrap an environment to read an
existing database I had already created with Rails, and filled with production
data. I thought it would have been straightforward. I'm trying to use current
versions:

* Netbeans 8.2 * Java 1.8 * Gradle 4.6 * SpringMVC 5.0.4 * Hibernate 5.2.15

I can't find a single, working example that demonstrates this stack. Not a
single one, on the entirety of the internet! Every example I can find switches
out some part of that stack, and makes the flow different. Netbeans and
Eclipse do things differently, and both have about 3 different ways to
generate a Java web application.

Then there's the whole Maven thing. I guess most of the world hasn't really
switched to Gradle, despite their site's glowing description of the
advantages?

And what is "Spring Framework?" There's really several different pieces of
that puzzle, and that's fine, but, at the end of the day, show me the code,
AND TELL ME WHERE TO PUT IT IN THE FILE STRUCTURE TO MAKE IT WORK.

Most of the examples I can find about how to write a Java web application
never even get to the point of pulling data from a database, and so finding an
example that uses either Hibernate OR JPA is almost non-existent. This just
makes me shake my head.

My current direction, which I was all set to get serious with today, was to
use Groovy on Grails, under IntelliJ IDEA. After a couple of weeks of
experimentation, it's the only stack I've been able to bootstrap, and actually
get a listing of objects from the database. I feel it probably takes too many
liberties to simplify the workflow, and will quickly lead to a bottleneck I
don't know how to get out of, but, dammit, it's the only thing I can find some
reasonable examples for.

(But even IDEA wants to generate a stack based on the non-current Spring
4.3.14, and Hibernate 5.1.5. Spring 5 is released. Why doesn't IDEA "support"
it yet? What little examples I can find show that a lot of things are changing
from Spring 4 to 5.)

Through this learning process, I've realized just how much tribal knowledge
I've absorbed about Rails. I "grew up" with Rails. I was playing with it in
the 0.x days, got serious with it in the early 2.x era, and have stayed with
it ever since. I understood that learning how to use another web stack would
be a challenge. While the actual language is hardly a concern to me, I had no
idea that the chaos of choices and versions would complicate the process of
just trying to get started. At the very least, when you say "Rails X.0",
you've described all the major pieces of the stack, and the IDE is immaterial.
That is simply not the case in the Java world.

So I've said all of this to set the context in order to ask you this: What is
the "right" framework stack to use to create a Java web application TODAY? And
by "right," I mean "most popular," in order to make finding answers as easy as
possible. For the sake of argument, the 3 apps I need to write are essentially
simple CRUD applications, so there are no esoteric requirements to consider.
What's the most straightforward and maintainable approach, and where's the
definitive documentation on how to configure it? I'm ready to go all-in on
SOMETHING, but I'm overwhelmed with choices and a lack of examples.

~~~
zorkw4rg
Just mentioning your IDE as an essential part of the "stack" shows how little
core understanding you have. You should read up on the documentation of the
basics of java, gradle and spring first. Not sure maybe rails developers
expect everything to be spoon fed to them in pieces of 5 minute screencasts or
something?

~~~
TheRealDunkirk
> shows how little core understanding you have

Really? You dismiss my clearly-not-ignorant comments by belittling me? OK. I
should have known.

Part of the frustration here is this: given a clean sheet of paper, and a
desire to write a Java-based web application, where do I start? What files do
I download? I don't know! How do I start developing with Spring? The site says
"add this line to your build file." WTF does that even mean, to a Java noob?
What's the file I'm supposed to be putting that configuration into? Unless you
have a file structure bootstrapped, and know that they're talking about
pom.xml, in the case of Maven, or build.gradle, in the case of Gradle, it
doesn't mean anything!

How did I figure that out? By using an IDE and generating example file
structures for a "web application" based on those 2 options in the stack. So
getting started with Spring requires an existing bootstrapped structure that I
STILL don't know how to generate by hand. (Feel free to enlighten me. How do
YOU start a new Spring project?) Hence, my frustration with the various IDE's,
and their multiple ways of generating what should be a pretty standard stack
of files to get started.

As I tried to indicate, I "get it" that I have a lot of this stuff
internalized with respect to Rails, and that's what I'm trying to get across.
I don't think that the Spring folks understand what they need to do to
"onboard" someone to their system. At least Grails seems to do a better job
with this.

~~~
vbezhenar
You might not like it, but I think that you need to start from scratch. Learn
Java language, learn how javac compiler could be called, compile simple
application from console. Then learn about Maven or Gradle, how to use them to
build things. Then learn a bit about IDE. I suggest Idea, but Eclipse or
NetBeans should work fine. Learn about Java Servlets, it's the underlying
library for almost every Java web application. Deploy simple servlet to
tomcat, learn how to handle GET/POST requests. Learn about JDBC, combine
servlets and JDBC. Actually here you can stop and write production code for
some simple REST service, for example. Only after you have some understanding
about every underlying part, you should start with Spring framework, JPA, etc.
And still it'll take a lot of time to learn those things.

I'd suggest not to search for various "stacks". They might be written poorly
and incomplete. Learn each part and learn how to combine them.

I guess Rails is a complete solution, with Java there are many libraries which
you should choose and glue together. Every non-trivial application probably
will use somewhat unique combination of libraries.

------
jimmy1
When I was doing Java development full time, it felt, like at the time, Spring
Boot was a direct response to Dropwizard, which I was using everywhere I
could. In either case I am almost certain Dropwizard's rise in popularity
placed a fire underneath Spring and eventually Spring Boot caught up and the
ecosystem as a whole was better off, IMO.

~~~
niftich
FWIW, the SPR-9888 JIRA issue [1], which prompted the creation of Spring Boot
and is quoted in the article, actually names Dropwizard as an inspiration.

The article quotes:

 _" I think that Spring's web application architecture can be significantly
simplified if it were to provided tools and a reference architecture that
leveraged the Spring component and configuration model from top to bottom.
Embedding and unifying the configuration of those common web container
services within a Spring Container bootstrapped from a simple main() method."_

The very next lines are:

 _" Though there are many frameworks and platforms today that no longer
require a container I think inspiration can be drawn most from DropWizard
([http://dropwizard.codahale.com/](http://dropwizard.codahale.com/)).

Another project I've seen inspired by DropWizard but leveraging Spring is
HalfPipe
([https://github.com/32degrees/halfpipe](https://github.com/32degrees/halfpipe)).
Though I don't think HalfPipe goes far enough. I think to truly provide
simplification the entire architecture, wherever reasonable, must be embedded
within the Spring container rather than without. Though it does have several
other interesting ideas."_

[1]
[https://jira.spring.io/browse/SPR-9888](https://jira.spring.io/browse/SPR-9888)

~~~
jimmy1
I know my comment here isn't adding much -- but that is awesome.

------
pritambarhate
The price one pays for the flexibility Spring offers is in terms of
performance. Spring uses a lot of reflection. It makes it very slow. The
startup time of Spring applications tends to be around 20-30 secs. If you add
Hibernate to the mix the situation becomes even worse.

Yes, Spring offers a lot of flexibility in terms of IoC and testability. I
generally avoid Spring for B2C apps. (For B2C apps, I tend to favor Jersey +
MyBatis) But for B2B apps and in-house enterprise apps, Spring is a very good
candidate.

~~~
jacques_chester
> _Spring uses a lot of reflection. It makes it very slow. The startup time of
> Spring applications tends to be around 20-30 secs. If you add Hibernate to
> the mix the situation becomes even worse._

The load time of Spring apps is dominated by the number of classes loaded from
disk, which is a function of the libraries pulled in. This is because the JVM
loads classes out of JARs more or less linearly.

Think about it for a second: which is faster, in-memory operations
(reflection) or I/O (loading classes from disk)?

Dave Syer has done more actual empirical investigation[0] of Spring's
launchtime behaviour than anyone. If you can produce better evidence of
_actual_ behaviour, I'll be very surprised.

[0] [https://github.com/dsyer/spring-boot-startup-
bench](https://github.com/dsyer/spring-boot-startup-bench)

Disclosure: I work for Pivotal, we sponsor Spring development. I do not work
on Spring.

------
JTenerife
Spring is a very powerful but complex framework. It's very easy to get started
(Spring Boot). I especially love JPA as I just need the persistence to be
getting done. The architecture is clean and standardized.

However, you have to be prepared for a serious learning curve when needing
customizing (e.g. attribute based authorization with Spring Security and AOP).
It's a jump in the cold water after the pain- and effortless start using
Spring Boot.

I haven't mastered Spring yet (in depth understanding of DI, AOP and the
configuration), but I feel that when mastered, Spring is the ultimate
framework to build concise and clean applications.

~~~
viach
> However, you have to be prepared for a serious learning curve when needing
> customizing

Can be said about everything in this world, right?

~~~
hardwaresofton
Yes and no -- I often found the difference between a well architected and
modularized (when possible) system and one that isn't is that the learning
curve is more linear.

Frameworks that are large often have lots to learn in them, necessarily, but
_how_ that learning has to be done can differ. Good frameworks will be simple
enough that you can almost ignore the ocean of complexity until you need to
dive in, and when you dive in all of the pieces that you now must need to
learn and know are almost obviously necessary.

For example, compare/contrast a system like express (nodejs) with a system
spring in java. The func(req, res, next) paradigm gets you VERY far, but
doesn't expose you to too much before you need to. Implementing middleware is
much more delightful in nodejs (and other frameworks that adopted the
func(req, resp, next) abstraction) than it is in Sprint.

~~~
vbsteven
Implementing simple middleware in Spring (boot) is pretty much the same. One
class with one method that has access to req, res and the next filter. The
@Component annotation is all it takes to enable the filter in your web stack.

    
    
      @Component
      public class MyMiddleware extends OncePerRequestFilter {
      
          @Override
          protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
              // your code
              filterChain.doFilter(request, response);
          }
      
      }

~~~
hardwaresofton
I think this is a good example of the difference in complexity grades of both
langauges/frameworks. That spring boot example is indeed pretty simple (for
java), but to understand it, here's what I'm pretty sure has to happen:

1\. Set up your spring boot project properly

2\. Set up all the XML that supports your beans properly

3\. Know how and when to use @Component

4\. Know that OncePerRequestFilter exists, and/or to extend it, which method
to override

5\. Know to call filterChain properly

Most of these are trivial with some IDE support and maybe a templating school,
and probably not even an issue after your second week with Spring boot (or
spring in general), and it's an improvement over what life used to be like but
compare this with the general jist of how to do it in JS:

1\. set up expressjs properly (usually a two-liner). It won't have things like
@Cachable that spring boot provides to you out of the gate, but it generally
has enough to get you up and serving requests.

2\. Know what req/res are (the fact that calling res.send(...) sends stuff and
.ends as well is arguably nontrivial) and how to use next

3\. Know what a function is.

the code snippet I'm thinking of is:

    
    
        app.use(function(req, res, next) {
          // your code
          next();
        })
    

It is "pretty much" the same, but how much work it is really depends on who
you ask -- you can get up to speed with a simply built expressjs app in tens
of minutes (many express apps follow a very simple setup pattern), but I've
never seen that happen in a spring boot app for an absolutely fresh developer,
even worse if the codebase is transitioning from spring to spring boot or has
some other hacks in it.

Spring Boot is marvelously simple one of it's best parts (it _almost_ makes me
want to use Java for a greenfield project), but there's so much noise in that
code -- it should just be a function -- IMO all started with the decision in
1.1 (??) to choose Runnable over lambdas. Most of the complexity I'm ribbing
Java over is just due to _how you write the langage_ \-- java on it's simplest
day just can't be as simple as some of the stuff that came after it, since
they had the benefit of hindsight.

~~~
vbsteven
1\. setting up a Spring Boot project is just File/New Project/Next/Next/Next,
or download a starter project from
[https://start.spring.io](https://start.spring.io)

2\. It's 2018, we don't use XML anymore, a Main class annotated with
@SpringBootApplication is all the configuration you need (and autogenerated by
step 1)

3\. All you need to know about @Component before you get started is if you
annotate a class with it, it will get instantiated with all its dependencies
and made available for use in the container

4./5\. Yes, to know about Filter, the filterChain and how to use it might take
some minutes looking into the documentation or stack overflow, but that is
what you are going to have to do anyway if you are going to use a framework.

I put knowing how to use @Component and figuring out what you need from the
docs on the same level as knowing about the (req, res, next) pattern and
knowing about async/callbacks/promises.

I agree that Java is verbose and has much ceremony but modern IDE's take away
a lot of that pain. For my filter example the only things I typed are:

* the class name

* extends OPRF<tab>

* <alt><enter> <enter> to generate the 1 method to implement

* the `// your code` comment and filterChain.doFilter()

I'm not sure what you mean about choosing Runnable over lambdas. Runnable `is`
a functional interface so anywhere you can use a Runnable, you can pass a
lambda (or method reference)

------
tootie
Article is already a bit date because Spring 5 and Spring Boot 2 are both in
GA now. A big new feature of Spring Boot is first-class support for Kotlin.
Sprint Boot 2 + Kotlin is really a dream.

~~~
rattray
That's awesome! I experimented with server side kotlin some time ago and
couldnt quite get things comfortably working (I had no previous JVM
experience).

Do you know of any good intro materials?

------
djhworld
Spring as a whole is pretty great, but due to its long history there's a lot
of out of date information on the web out there, from the likes of mkyong and
so on.

Not a problem with the framework per se, but it does add an extra layer of
frustration when trying to search for an answer to your specific problem

~~~
gldalmaso
Some stuff is out of date on best practices, but usually a lot is still
supported, which is another reason Spring is popular, you can mostly follow
the releases without much rework on code if at all.

------
geodel
Recently I wrote a service using embedded tomcat libraries. It contains few
lines of code to boot up tomcat, add servlets, set some context parameters.
There are no configuration files, no annotations or a readymade stack of libs
that I must use. Now it works fine but no hope of going in production because
it does not use the next generation state of the art Spring boot microservices
framework as recommended by architecture group.

I guess point here is unless code is smothered with multiple layers of
frameworks companies will not like it.

~~~
stephen
FWIW this is just the way life is in large companies: you have to trade-off
individuality vs. company-wide productivity.

Granted, both extremes are bad, and finding a happy medium is hard.

 _Hopefully_ the architecture group's "recommended"/mandated stack also
includes great out-of-the-box, company-wide tooling like metrics, error
logging, etc., etc.

If their solution doesn't provide these perks, well, yes, that's not as
useful.

~~~
geodel
> Hopefully the architecture group's "recommended"/mandated stack also
> includes great out-of-the-box, company-wide tooling like metrics, error
> logging, etc., etc.

Mostly they jump on hype train. Few months back it was netflix stack now it
seems they are moving to something else. My main work is on a large(ish)
application which is in production long before merger. So for now I am not
forced on to jump on their architectural astronautery. I just play around with
other technologies etc.

------
guru4consulting
I'm a big fan of SpringBoot and have been using it since the beta version. For
enterprise environments that often involve things like security,
ActiveDirectory/LDAP integrations, SSO tokens, SOAP/XML, OWASP filters, CSRF
tokens, custom logging, audit trails, etc, SpringBoot provides good plugins.

But if I'm doing a new greenfield project, I would rather prefer serverless
architectures with light weight libraries and no frameworks (and perhaps
golang). Yes, the serverless still lacks proper tooling and has few gotchas
like no resource/connection pooling, cold starts, etc.. but the pros far out-
weigh the cons. I'm still highly productive with springboot, but I am willing
to discard my favorite tool and as I clearly see serverless stack as the next
evolutionary step for application development.

~~~
jacques_chester
As it so happens, a lot of Spring team members are working on Project Riff,
which is a FaaS system.

------
exabrial
I see CDI as all the good experiences learned in Spring, rolled up and
distilled. Spring was my first though, and it's extensibility had withstood
the test of time.

~~~
needusername
Not sure if serious or trolling.

1\. CDI has no testing story, this is the biggest point, everything else pales
to this. Arquilian is a joke compared to Spring TestContext Framework and
strictly speaking not part of CDI.

2\. CDI is in general lacking what Spring calls "enterprise integration",
convenience layers over a lot of the a bit annoying to use Java EE layers like
JDBC.

3\. CDI is in general hampered by the Java EE / JCP release model. Spring can
in general and does roll out new features quickly. For example we got new
functionality into 5.0.4 within a few weeks without having to wait three years
for a specification to be perfect and another three years for a supported
application server to ship.

4\. CDI/Java EE has still no caching story, even in 2018.

5\. CDI has no MVC story.

~~~
NovaX
4\. JCache (jsr107) is really awful. I don't think you want one.

~~~
needusername
I was not particularly asking for JCache/JSR-107. Since you seem to have
insight in this area would you mind sharing it? Is your beef with the API or
the RI?

~~~
NovaX
The API, though I am not a fan of the RI for one reason. It is the first JSR
RI that I am aware of where the authors advice against using, it is
unsupported, and intentionally low quality. All other RIs that I know of were
production grade quality to ensure it met user's needs. This one was to pass a
specification requirement.

\- The API violates many of Josh Bloch's guidances [1], including items in
Effective Java.

\- Many of its features are incompatible with itself. For example, the AOP
support cannot be used with loaders, writers, or listeners.

\- The AOP support does not support atomic memoization (dog piling [2]) and
can crash if initializing the same cache concurrently.

\- The JavaDoc dictates implementation details that matched the lead's
product, rather than being open ended to allow alternative algorithmic
choices.

\- The JSR defines an configuration API that is not suitable for production
use and promotes the silent usage of unbounded anonymous caches.

\- The interfaces do not attempt to feel natural alongside the Java's
Collection Framework nor the direction that the language has been heading. It
redefines terms, like "access", in an incompatible way.

\- Despite numerous delays in being accepted, the JSR was not modified to take
advantage of significant changes in the language (java.time, lambdas,
CompletableFuture, etc).

\- The TCK is not robust, does not check concurrency, and bugs in it
languished.

\- Most importantly, writing code using JCache is not enjoyable and it is
often not flexible enough to solve most needs.

There are likely many more, but that is a short list that comes to mind in a
few minutes.

[1] [https://www.infoq.com/articles/API-Design-Joshua-
Bloch](https://www.infoq.com/articles/API-Design-Joshua-Bloch)

[2]
[https://en.wikipedia.org/wiki/Cache_stampede](https://en.wikipedia.org/wiki/Cache_stampede)

~~~
needusername
Thank you for sharing.

~~~
NovaX
I should have mentioned that the API flaws breaking with Bloch's advice can be
really nasty. I bundled up a bunch of items under that, which might mundane if
you don't know of them. Some of the wonderful design choices are,

\- Cache.iterator() may return a null entry, despite null key or value is
disallowed. This occurs when the cursor points to an entry that no longer
exists - hasNext() was true, but the entry disappeared due to
removal/eviction/expiration. This is a performance optimization to avoid
underlying I/O that leaks to users and violates their assumptions.

\- Cache.putAll(map) first invokes CacheWriter.writeAll(list<entry>) prior to
storing them. The writer uses an in/out parameter so that if an exception is
thrown, the user must remove the successfully written entries first. Then
cache must store those successfully written entries before propagating the
exception to the caller.

\- An amusing bug was that their custom future could not be consumed by
multiple threads. It used notify(), not notifyAll(), so only one waiter would
wake up. The concerning part was that this existed for a few years due to lack
interest in releasing a new version.

------
chasd00
I've been using Spring and now Spring Boot for years. I'll I say is thank God
for Maven heh

------
dlhavema
We used spring boot heavily at my last job. It was very fast to stand up
services and it led us to move away from a massive monolithic weblogic stack..
changes were pushed out so much faster...

------
chris_wot
Why do or don't people like IoC?

~~~
jmspring
Personally, when I build something, I prefer to know exactly what will happen
prior to compile/build, not hope some configuration will handle things.

I can deal with both, but just a preference.

In general, dynamic integrations like IoC, etc make things harder to
troubleshoot/debug as well.

~~~
exabrial
Exactly, right? That's what DI/IOC allows you to do. You can test a component
where the variables always return simple deterministic results for one unit of
code, or/[preferably] and you can also have a set of tests where you integrate
all components.

~~~
chris_wot
I think he's talking about autowiring.

~~~
dullgiulio
Exactly, and a lot of Spring discussions conflate the things and blurry the
image a lot.

Inversion of Control is really good and there are no reasons not to use it.
When you have something that can be done in multiple ways, make a small
interface and several implementations for it.

The trick now is how to decide what to use. The simplest way is just to parse
your configuration file or application flags/arguments in main and instantiate
the concrete implementation of your classes there, then pass them down all the
way until you need them. This is explicit, simple and clean.

Spring makes you (at least) do two things wrong:

1\. Configure the concrete implementations the wrong way. You don't want your
users to decide which class implements a certain interface. You want them to
decide something higher level, like for example "get crash data via e-mail" or
"get crash data in logs". The rest is implementation details.

2\. Annotations for autowiring: my feeling is that those are just to go around
Java verboseness. Instead of typing "VeryLongName veryLongName = new
VeryLongName()", "@autowire" it easier to type. I have always seen it misused
(used for stuff that is not Inverted/Configurable) and it makes code more
magic. Even worse, you are back at having classes pick their dependencies,
even if they are interface implementations. If your classes take their
dependencies as constructor parameters, everything is much more explicit.

~~~
jacques_chester
> _If your classes take their dependencies as constructor parameters,
> everything is much more explicit._

This is the guidance that Spring team members give, to the point that Spring
now defaults to injecting constructors without annotations.

I agree that field/setter autowiring is Satan's handicraft.

Not all of this is Spring's fault. Java has the JavaBeans standard, which
created a universe in which setter injection is common. JPA, for example,
_requires_ no-arg constructors. It makes me sad.

