
Ask HN: Which Java framework will replace Spring? - roschdal
Spring has a strong position as an enterprise framework for Java. Which new framework or technology will replace it?<p>I&#x27;m asking because I don&#x27;t want to learn more of Spring, and want to technologically leapfrog it.
======
needusername
I agree with PaulHoule. I would add two things. First the focus on and support
for testing in Spring is exceptional. Second the Spring Core courses used to
be excellent and done by committers themselves. AFAIK this was outsourced and
I don't know how their quality is these days.

If you want to have a look at something else you may want to give Dagger 2 a
shot. While I think it's a better, more idiomatic, approach to DI for Java
you'll quickly become aware how limited it is compared to Spring. I built a
small demo app and even for that I said to myself "gee I wish I had X from
Spring" available about three times.

------
PaulHoule
(1) Spring is not as bad as you probably think. A few years ago I got thrown
into the deep end of several large projects that involved Spring and found it
was particularly painful.

I got over it by reading the Spring manual cover to cover at the gym and then
got confident enough to look at the source code and write my own extension
modules.

If you learn Spring by "making little changes to an existing codebase" and
"looking up answers on Google and Stackoverflow" you are D00MED. If this is
how people have been building your codebase, you are D0UBLE D00MED.

If you understand how it works, it is not so bad.

(2) Many of the alternatives are worse. I built a huge Silverlight GUI app
before my recent Java Jag and initialization issues were a continuous pain in
the ass. Every time we changed something about the app, the order in which
things had to initialize in the app changed and things would break and we were
always suffering. Spring figures out what depends on what and takes a big
burden off your shoulders. Teardown was not such a big issue with that app,
but I build a lot of data processing apps where teardown is critical or
otherwise transactions don't get completed, data files are corrupted, and
similarly Spring handles that for me.

(3) The "Spring X" subframeworks are hit-or-miss, just as the many off-brand
products that are sold under the "Microsoft" or "Oracle" brands. The real
Spring Framework is excellent, but "Spring Batch" and "Spring Data" and many
things like that tend to suck.

(4) I'm building my own framework now that is starting to eat the Spring
framework in my projects. The center of it is a system that converts RDF to
Java data and converts Java data to RDF. With the backwards-chaining inference
capabilities in RDF it is easy to do the topological sort and figure out which
order things need to happen in.

Unlike Spring this system is bidirectional (you can snapshot something that
already exists) and you can use SPARQL to do queries of either the "system
map" or the objects created from the "system map" and you can do all kinds of
inference. You can even turn Spring bean descriptions to and from RDF (these
are Java objects too) so one of the big questions is if and how much stuff
from Spring we decide to incorporate into the system.

Practically though I am using less Spring and more Turtle.

We haven't made a hard decision about making this thing open source but we are
learning in that direction. See

[http://ontology2.com/the-book/rdf-a-new-slant.html](http://ontology2.com/the-
book/rdf-a-new-slant.html)

~~~
copperx
Thank you for your insight. I'm starting a web app in Java and I'm trying to
find a suitable framework. Play was my first choice, but it look like there's
so much magic behind the scenes.

I'll probably pick Spring. What's the book that you suggest?

Also, what do you think of Spring Boot?

~~~
davelnewton
"Too much magic"? That sounds more like a lack of understanding than anything
else. There's no magic.

The primary purpose of frameworks is to remove boilerplate and allow the
developer to focus on what's actually _important_. There are many routes to
this: convention, introspection, etc.

The whole _point_ of a framework is to appear "magical", but it's still just
code, and ultimately, generally easy to pick apart _how_ it does its magic.
I'd even argue that gaining that understanding, and the ability to _discover_
that understanding, is far more important than any particular framework: the
understanding drives the ability to both make use of whatever framework you're
investigating, but more interestingly, to apply that knowledge across
frameworks and domains.

If you want to "leapfrog" relatively "static" frameworks, you must understand
how "magic" is constructed and utilized, and _make use of it_. At that point
you might as well be using the framework.

Leapfrogging demands new knowledge and new comfort levels.

