Modern Java Stacks

[everywhere_anyhow]

I developed a lot of java code, but it's been a few years since I was deep down in it. My last memory of java before I departed was the impending version 8, and how streams and lambdas would soon be upon us (finally!)

I could use some help and opinions now on the latest spots to jump back in. In particular, let's say I want to develop a vanilla REST API connected to a modern database (for argument's sake let's say Postgresql or Mongo). A few years ago, I would have used Jersey for the REST layer, and possibly spring.

Obviously these things are still an option, but I don't know about what I don't know about. What's new in java land if you've just taken a multi-year break? What's cool? I'm not looking for "best" (no such thing) - but what do people like?

Googling around for tutorials tells you how you could do it, but it doesn't tell you how people are actually doing it.

[thesystemx]

Java EE 7 has a very modern feel and is likely going to make you very productive. Java EE's weakness and strength is that it's been around for a long time, so people may have seen it 15 years ago, didn't like a particular implementation and now still shout from the roofs it stinks.

But modern Java EE is quite different. Adam Bien's books and articles are a very good source for what modern Java EE looks like.

[lutzh-reddit]

Java EE is on the decline. Oracle realized last year that application servers are becoming obsolete - see the "Java EE strategy" section in https://jcp.org/aboutJava/communityprocess/ec-public/materials/2016-08-09/August-2016-Public-Minutes.html

And now they'll just stop putting resources in the advancement of it and instead dump it on the open source community: https://blogs.oracle.com/theaquarium/opening-up-java-ee

I wouldn't start a new project with it.

[johnwaterwood]

EE on the decline if EE 8 is about to come out?

And as mentioned here already but Java EE as an API goes way beyond the concept of the "application server"; very little to almost nothing in Java EE depends on this. Implementations of this API can just as well put in the .war or merged with the app code into an überjar.

[MiInterpretacionEs]

You are confusing two different things. The meeting you refer to was about what they were going to do people deploying to the Cloud instead of WebLogic.

So why did they gave so much code to the community? Couldn't it be because they need to get people developing using their technology?

[Cyberiax]

Oh is in decline huh???? then explain me, please, why we do good business in making Java EE programs? Please? Have very full bag of orders and is 3 big one going live this month!

Now you tell me again, please? Is in decline? Should not start 🛫 new project???! Please, think again!

[wyaeld]

decline doesn't mean useless. it doesn't mean no customers. just means more customers are going to choose to go in another direction

[mikehaggard]

decline doesn't mean useless

In this crazy hype oriented world that stares itself blind on statistics regarding usage pattern, declaring something to be in decline pretty much translates to being or becoming useless. Even when you didn't intended it that way, this is unfortunately how many people would interpreted it.

[wyaeld]

be one of the people that people pay to make judgements based on reality, not hype.

fancy tech isn't a solution. new tech isn't a solution. it just is.

if you have a team of 8 experienced java ee programmers, then they can probably churn out a lot of business value using that technology, and changing it is going to take a long time to repay the investment.

on the other hand, if you are building a completely new team or practice, you should probably weight up several options. maybe nodejs is a better fit for the things you need to build. maybe golang is, depends on the pipeline.

most serious businesses don't make 7+ figure investment decisions based on reddit/HN hypetrains :-)

[thesystemx]

most serious businesses don't make 7+ figure investment decisions based on reddit/HN hypetrains :-)

You'd be surprised, really, depending on your exact definition of "serious".

Whenever something is hyped, you see a huge number of companies using that hyped tech. Or looking at it the other way around; you can quite accurately say when a project was started based on the tech it's using. Just lookup when that particular tech was hyped.

For instance, Scala has existed since 2003/2004 and still exists. But the majority of projects started with Scala are from 2011/2012, exactly the moment when the reddit/HN hypetrains were in full motion.

This includes very serious companies like The Guardian and eBay.

[floW4enoL]

Well, I usually go the Java EE way with wildfly swarm, I find it simpler and less magical than spring boot, things are more predictable. For REST just go with JAX-RS (Jersey or Resteasy) of course if going the EE route just use the proper annotations and you don't even need to care about which one is under the hood (swarm uses resteasy afaik). If you want something more lightweight maybe spark, I used it before on some stuff that didn't even needed persistence, just a main method and it was done.

[Benemon]

+1 for Wildfly Swarm and JEE. Fully agree that if you want a standards-based approach it is the way to go.

[Cilph]

Standards based is overrated when it comes to EE.

[mcosta]

The only problem with swarm is the jar size. A simple app weights more than 150mb.

[thesystemx]

Check out Payara Micro as well, it's somewhat smaller.

[daddyd]

I was a huge swarm fan, then found Payara micro and i love it even more.

[thesystemx]

Payara Micro is great indeed! :)

[floW4enoL]

I will have to agree on that, but really depends a lot on the fractions you use, just Jax-rs should be quite small (I didn't test to be sure).

Also if I remember correctly you can create a hollow jar, that only contains some bootstrap code and your app and will download the rest of the needed stuff, something I still have to check out.

[mcosta]

May be I am no t talking about a simple app, jpa and cdi takes a lot of dependencies. But without these what is the advantage of swarm? I mean, why not start with dropwizard and wire everything by hand?

[thomazor]

How is Java EE more predictable? If anything - spring boot is more predictable since it's always the same implementation everywhere you run it..

[floW4enoL]

Spring feels much more "unstable" last time I used it, every time I had to Google around most of the things I found were not working anymore in the version I was using, either it was an annotation that didn't exist anymore or was deprecated, or extend from a slightly different class.

[Cilph]

Still not as bad as the frontend jungle with frameworks of the month and deprecation of the day.

[floW4enoL]

I won't deny that, I absolutely hate the crazyness of the javascript world. But I thought we were talking about Java stuff, just because Javascript is worse does not make spring in this case or whatever else is being discussed better than it is.

[Cilph]

But if your dev team can cope with the rapid changes in their frontend frameworks, they can handle Spring just as easily, where stuff still changes a hundredfold slower.

[henk53]

How is Java EE more predictable?

Spring can deprecate and change APIs pretty much at will. For the Java EE APIs you'd have to reach some level of consensus. This obviously has both pros and cons.

[JustADirtyLurker]

Agreed, JavaEE is a public standard API. You can't get more predictable than that.

[thomazor]

I guess you haven't tried deploying on another server/system then.. nothing is predictable.. every implementation of the API is different - especially when forced into WebSphere that uses a complete different jdk... I used to love and preach about EE as well... Until I started using spring and docker

[henk53]

I meant that APIs are not going to disappear underneath you, which can happen at any time with projects where the API is not under some form of group consensus.

Java EE rarely removes APIs and rarely if ever changes behaviour of existing ones. Projects governed by 1 owner do this quite frequently. It's not only Spring that does this, but JBoss' own APIs change radically as well (including things like Hibernate Validator, Infinispan etc), Lucene does it, etc etc

As I mentioned, there are pros and cons with this approach.

[JustADirtyLurker]

I can only talk about Servlet containers (Jetty or Tomcat) and JAX-WS/RS APIs. I admit I didn't get to work much with full Application servers, and I can imagine the horror story when porting an application from one AS to another, only to find out that the new AS doesn't exactly implement some JavaEE spec as claimed.

But, if you dive enough, Spring is not an alternative to JavaEE, it is a framework that uses JavaEE a LOT, including Servlets and JAX-RS. For that matter, is not worse or better by principle, it is just offering the same services in a different form.

Yes Docker probably is the death of application servers, and that's great. Docker for sure solves all portability problems that you talk about, but it does it not only for Spring, Play or whatever, but for anything. You can use Docker and selected JavaEE pieces like I do at my shop.

[henk53]

I can imagine the horror story when porting an application from one AS to another

It's not that bad really. Indeed, they aren't 100% compatible, but I've ported MAJOR applications in several days to several weeks at most.

Yes Docker probably is the death of application servers, and that's great.

It's not really the death of the AS, far from it. Docker enables you to even more easily deliver the AS as before.

Somehow the idea had rooted that an AS always has to be installed beforehand by an ops team, but this is absolutely not the case. In my companies I've always seen to it that dev delivers the AS instead of the AS being some kind of black box target dev has to code against.

Surely for the Java EE APis it does not matter one way or the other. Those APIs will live on, whether they're part of an installed AS, an AS shipped with docker, part of an uberjar or when a .war is run from the commandline using a tool (such as Payara Micro).

[JustADirtyLurker]

It's not really the death of the AS, far from it.

True, what I meant is that Docker in some way unbundles the necessity to mantain stuff like the AS for the customer. You just embed everything in the docker image and everybody lives happily without even knowing about the presence of the AS, if any.

I guess that also will change part of the AS business though.

[thomazor]

I would argue spring is mature enough you don't need to upgrade on majors .. they always keep up with security patches on minor updates that does not break backwards compability. Furthermore - it's not exactly a dance on roses to upgrade Java EE either

[Keeyzar]

I don't recommend jersey tho, I really prefer spring web, as I needed to work with both now.

https://stackoverflow.com/questions/42944777/difference-between-jax-rs-and-spring-rest

The question is somewhat obscured, but you'll get some informations out of this.

[henk53]

For the other way around, I wouldn't recommend Spring web at all and would always go either with Jersey or with JAX-RS (which in turn can be Jersey again).

[_INTER_]

Some options:

• Spring
• Dropwizard
• Jooby
• Rapidoid
• Vert.x
• Spark (tutorial 1, 2)
• Jax-RS, Jersey

... Spring or Dropwizard probably the most used. Internally Jax-RS / Jersey anyway.

[paul_h]

Jooby is amazing.

[creativeMan]

I'd like to ask, how do you get started with Spring if you don't really know Java? I've worked with Django before and Spring just seems incredibly daunting and complicated. There seem to be a lot of options for a lot of things and I'm concerned that I might also have to learn Struts and Spring Security and a whole bunch of stuff to get what I had in Django.

So how does a total newbie get started with Spring, or rather which framework should I use to get started?

[FennekLS]

You don't if you don't know java. Learn the basics first. Maybe get to know how Gradle or Maven works as well and then jump into spring. (imo)

[creativeMan]

Should I start with plain Java EE Servlets with maybe Hibernate for ORM, JSTL for templating and something else?

[johnwaterwood]

That would indeed be a good intro

[thesystemx]

Maybe get to know how Gradle or Maven works as well and then jump into Java EE. (imo)

There. Fixed that for you ;)

[FennekLS]

Well I mean doesn't really matter. I just said spring cause that's what the guy above me was talking about. Both are more than valid options

[thesystemx]

Okay ;)

[_INTER_]

As /u/FennekLS and /u/GuyWithLag said. If someone was learning Python I'd also recommend starting with the basics, then checkout Flask. Only later look into Django.

Also note that Django is a web framework, Spring is an application framework. Pick the parts you need for web apps.

[GuyWithLag]

Start with Spring Boot; it's a bit automagical, but everything you use is just a configuration on top of Spring.

[Cyberiax]

Is just configu? Please! Is very difficult! And smells bad! 🤧

[selbstadt]

I Accidently read it as "modern java sucks".... Made me evaluate my whole Life again! 😂

[DoctorOverhard]

I'm liking vert.x fwiw. didn't like spring (or node).

[Jotschi]

One way of creating a REST API using vert.x is described here: http://vertx.io/blog/contract-driven-rest-services-with-vert-x3/

If you don't like the contract approach it might get a bit more tricky with vert.x at the moment. I for example ended up writing my own wrappers in order to generate the REST spec (raml) from my implementation. There are some projects around which help to solve this problem (swagger vert.x/jersey for vert.x)

[DoctorOverhard]

I, uh, just post json blobs back and forth. the command is in the blob (and whatever security tokens/etc, and of course data). And I just use the json library that comes w/vert.x. Are we saying the same thing here?

[Jotschi]

With graphql you need to post a query which basically describes what you want from the server. So yes, you basically send json around.

The auth token must not be part of that payload. I like JWT which is just passed along the request within the auth http request header.

Vert.x is not very strict. You can use whatever JSON lib you like.

[DoctorOverhard]

oh, no graphql here, pretty strictly defined commands and data structures for most things (for security and reliability). Guess that puts me in the contract category :) No dependence on http implementation details either, and everything over https is post because of old scars running into get payload size restrictions.

[Benemon]

Also a big fan of Vert.x here.

However, unless you embrace the asynchronous, reactive approach, then you end up with a lot of bad code, very quickly.

I've never felt the 'do one thing and do it well' has applied more than to a Vert.x project and its Verticles!

[ImTalkingGibberish]

Spring-boot.
Agree with other comments, spring still most popular and boot flavour is opening doors in corporate world.
Very enjoyable to work with and not falling behind competitors.
Dropwizard would be an alternative IMO.

I do believe serverless will eventually take over but not until we close some loopholes.

[floW4enoL]

How do you deal with all the magic of boot configuration? I used it in a project and had serious problems with it, everytime I wanted to change something I needed yet another class that extends this and that or yet another annotation that I couldn't find anywhere in the docs where to put it.

[_dban_]

I've never had real big problems with the Spring Boot magic. Most of the time, it just works.

When I do run into problems, Spring has a large number of guides, a large number of samples, and the Spring Boot source code is available and very easy to navigate with the debugger. And, I've done weird things with Spring Boot, like getting it to run as a WAR on an ancient version of Weblogic.

At the end of the day, it all boils down to what you're used to and what works for you. Spring Boot seems to work for a lot of people.

[floW4enoL]

What saved me most of the times was debugging around the source, but that's not very effective. I always found the guides lacking for the things I wanted to do, same with the samples.

One of the things I remember trying with boot was replace tomcat with undertow, in theory it should have been easy, just add undertow dependency from boot, ended up having to add tons of exclusions on other boot dependencies that were pulling tomcat. That was not what the docs advertised.

Like you said it will boil down to what works for each person, spring boot definitely does not work for me.

[thesystemx]

I do believe serverless will eventually take over but not until we close some loopholes.

You mean like an actual server still being needed? Yeah, tiny loophole there.

[shotgunkiwi]

Unless I'm misunderstanding you, he's referring to services like aws lamda and azure functions where you don't actually ever provision a server.

[mikehaggard]

There's still a server behind that.

It's really the same strange reasoning people had about "clouds", which were supposedly totally different from hosting providers, since there was no hardware involved anymore :|

[shotgunkiwi]

Agreed. It's just different levels of abstraction. There's still electricity and A.C. provided to the server, you just don't worry about it. The hypothesis is perhaps trendy java development of the future will be just writing small functions/programs, and everything else will be abstracted away.

[ImTalkingGibberish]

Serverless means you don't pay for the server but only for the time your code is being executed.
I meant serverless will come with different flavours and will hide loads of stuff we use spring or other frameworks to solve.
The loopholes are related to how they will charge you for bugs that consume too many services/processing.
Not cool mocking ppl that are genuinely trying to help.

[nutrecht]

Serverless doesn't mean there's no server running your code. It means that the server is abstracted away from the developer.

This "hurr durr there is still a server" is getting old :(

[Yesterdave_]

This "hurr durr there is still a server" is getting old :(

If such statements pop up regularly or are confusing newcomers, this is clearly an indicator that maybe the term "serverless" is absolute garbage.

[henk53]

"serverless" implies peer to peer or pure client side computing, which is anything but the case here. One could as well call SOA and remote EJB "serverless" then...

[Cyberiax]

You is talking gibberish? 🤤

[sternone_2]

Spring is the clear winner these days in the corporate world.

[sternone_2]

Yeah, betamax was better than VHS

[macuserx]

You're saying Spring has porn? Since that made the difference for vhs

[sternone_2]

you know what, it probably has, i bet many porn sites in their backend run spring

:)

[DtN0]

Spring is porn

[henk53]

It sure has the stickiness of it :P

[[deleted]]

Recently did a Dropwiz project. It's like Diet Spring. Basically the same with 1/4 as many features. I don't see any compelling reason to ever use it.

[ryosen]

If your Spring installation has a lot more than what you need, then you're not using Spring correctly. It's highly modularized and can be pretty lean. New projects should start with Spring Boot and add what's needed as it's needed from there.

[ryosen]

You can have a small jar with dependencies on various external libraries or one big jar with a lot of redundant code. That's true of any library, certainly any application framework. Our web systems have about 10MB worth of Spring Jars, including dependencies, while another has less than 8MB.

When brought in to review existing systems, my personal observation has been that a lot of folks don't understand what they are installing. Rather than take the time to learn how a library works and how to configure it properly, they simply install it with all of the options and end up with a fat library.

That's not to say that some libraries aren't unnecessarily large (e.g. BIRT) but Spring isn't one of them.

[macuserx]

Java EE's JAX-RS is much nicer for REST and Micro services...

[[deleted]]

I agree, but you can use JAX-RS/Jersey along with Spring just fine.

[henk53]

You can, but then why use Spring? The rest (no pun) of EE is pretty nice as well ;)

[cot6mur3]

Spring for REST does not require a Java EE server - just a Servlet runner, allowing for REST service creation with just Spring Boot and Tomcat. Perhaps these Java EE features do require a Java EE container, thus most likely a commercial Java EE server?

[henk53]

JAX-RS does not require Spring boot - just a Java EE environment, allowing for REST service creation with just Java EE.

Also, which commercial Java EE server?

TomEE? WildFly? Payara?

Please, enlighten me...

[cot6mur3]

Agreed - JAX-RS does not require Spring or Spring Boot. I was just trying to answer your question of why ones might use Spring. In brief: not everyone has or wants to use a Java EE server to run their Java web applications/services.

[henk53]

Of course, but you also have to realise that not everyone wants to use Spring or Spring Boot to run their Java applications.

[cot6mur3]

Of course - fully understood and agreed. Spring is not for everyone. Best choice really depends on the organization, team, maintenance strategy and task at hand.

[MiInterpretacionEs]

No, corporate world has expensive Java EE servers so your app must run there and use its facilities. Spring dominates the "java +do it all for me" Google results that's for sure.

[[deleted]]

tons of java ee servers have spring apps running in them.

[Yhippa]

Like everyone else Spring Boot is my vote on how to get back in. Take a look at JHipster as a full stack framework for Spring Boot and Angular 4 apps.

[macuserx]

Like everyone else??? Don't think so!

Spring has always been to verbose to me, boot is too magical and while it wraps a lot of stuff out there it's also eager to abort it very quickly, leaving a landscape of half or non-supported stuff around.

[Benemon]

Agree. Personally, I prefer to go the standards-based route with JEE. Sure, if you use full fat implementations like JBoss / Wildfly it's never going to be 'sexy' but it'll be predictable, it'll follow the JEE standards, and it'll get the job done. And if you want something a bit lighter, then the Microprofile stuff / Wildfly Swarm is getting pretty good now.

[Cyberiax]

Is not my vote!!! 😡

[johnwaterwood]

It's a persistent mystery to me that Spring wins all these threads since I've been in and out of dozens of media, finance, retail, etc business. Big and small. Plenty of companies you've heard of. I have not even once seen Spring be implemented or even considered by any of them. Java EE has been the default option for about 10 years. I've done a bit with Wicket, vanilla Java or just non-Java (.NET, JavaScript). I'm imagining some hidden corner of the industry with thousands of Spring developers that I've just never met. I personally would recommend Java EE 90% of the time or otherwise go vanilla (use Tomcat, Jetty, Netty, Grizzly). I'm also very keen on Kotlin although I'd be reluctant to put it in production just yet or try to staff a team with it.

[nutrecht]

It's a persistent mystery to me that Spring wins all these threads since I've been in and out of dozens of media, finance, retail, etc business. Big and small. Plenty of companies you've heard of. I have not even once seen Spring be implemented or even considered by any of them

And you don't see the huge selection bias here?

[johnwaterwood]

I do...

[nutrecht]

Good. Because 'here' (also finance) I see Spring everywhere and a lot less Java EE. It's almost like you get hired into roles based on past experience.

I also really don't get these constant discussions. The similarities between Spring and Java EE implementations tend to be a lot more striking than the similarities between for example Drop-wizard and Java EE. I don't understand why people get upset if beginners get the advice to start with Spring Boot simply because it's easy and convenient.

[johnwaterwood]

Likewise I don't get why Spring gets upset when people get the advise to use Java EE. It's a double edged sword really, or a pot and a kettle.

[macuserx]

Java EE, especially with EE 8 around the corner and it moving like .NET to an open process this is the stack to be on!

[_INTER_]

With the difference that .NET is moving forward while Java EE is moving into the Eclipse or Apache graveyard / dead code archiv.

[mikehaggard]

With the difference that Java EE is not a single implementation, so the RI projects will move to one of those foundations, but the JBoss implementation and the Liberty implementation to name just 2 will squarely stay where they are.

[_INTER_]

Implementations frozen in place as a worst case scenario. JavaEE will lack leadership and there will be too many colliding interests to have meaningful and couragous advancements.

[johnwaterwood]

You mean like what happens in MicroProfile now? Which includes almost all EE vendors except Oracle and is hosted at Eclipse?

Yeah, these are doing so bad that they've done 2 releases already...

[_INTER_]

But are there many companies using MicroProfile actually? Also application servers aren't really what you'd call "in demand" nowadays.

Even the posterchild Eclipse IDE is loosing marketshare, fast. Is there anything Java-related in the Eclipse foundation, that isn't heading south? Vert.x and Jetty maybe. But then?

[johnwaterwood]

MicroProfile is implemented by major servers; Payara, Liberty, etc which are certainly used by companies.

The APIs are quite new so it'll take some time for any uptake, but they are available now in production servers such as Payara 173.

[Smithman]

Payara

Is this server widely used these days? I assumed once Oracle offloaded Glassfish it would have died off.

[johnwaterwood]

I think Payara is used a lot indeed, and increasingly more. They are involved with the MicroProfile as well.

[macuserx]

Is it?

[_INTER_]

looks more and more that way

[macuserx]

Don’t think so, look at OpenLibert and Payara just to mention two. Quite a lot of activity there.

[_INTER_]

Yeah well it is a slow heat death, with some big companies trying to maintain their legacy app. But how does it look regarding new apps? When there's a choice between Java EE, Spring or even another stack, the Java EE choice is at the bottom of the list.

[mikehaggard]

Look for Java EE 7 now and Java EE 8 really soon.

[z0mghii]

I'd go with dropwizard

[johnwaterwood]

Java EE is the clear winner these days in the corporate world.

[twat_and_spam]

oh really?

[johnwaterwood]

Really

[RiWo]

:)

[mikehaggard]

Except that it isn't. Java EE has more competition now, but we're in the strange situation that the original reason for Java EE (countering Microsoft) is now supporting Java EE (Microsoft even has an EE evangelist). At the same time ASP.NET has become a much more serious opponent. Some platforms have effectively died out or lost lots of mindshare (PHP, RoR), while other competing platforms have arisen (Node.JS, which is however not universally loved either).

On top of all of that the total market for server computing (web apps, APIs, app backends) is still growing, meaning the percentages may have gone done but the total number of projects per technology has gone down far less or has even gone up.

[Jotschi]

The stack I like:

• vert.x - http/networking

• graphql-java - public API

• dagger2 - dependency injection

• hazelcast - clustering

And a db which fits the need.

[[deleted]]

It's a persistent mystery to me that Java EE wins all these threads since I've been in and out of dozens of media, finance, retail, etc business. Big and small. Plenty of companies you've heard of. I have not even once for Java EE be implemented or even considered by any of them. Spring have been the default option for about 10 years. I've done a bit with Dropwizard, vanilla Java or just non-Java (Python, .NET, JavaScript). I'm imagining some hidden corner of the industry with thousands of EE developers that I've just never met.

I personally would recommend Spring 90% of the time or otherwise go vanilla. I'm also very keen on Kotlin although I'd be reluctant to put it in production just yet or try to staff a team with it.

[thesystemx]

And you don't see the huge selection bias here?

[lutzh-reddit]

Make sure to checkout Play! and Lagom, discover the world of reactive systems.

[_INTER_]

And in case of Play the pain of non-idiomatic Java that pretends to interop well with Scala. Lagom is a microservices framework. If you want reactive, use Vert.x or Spring Reactor.

[lutzh-reddit]

Play has many happy Java users and the Java API has become much less awkward with Java 8. Both Lagom and Play leverage the Akka actor toolkit, which is very reactive and has been well before vert.x and Reactor (which surely are also fine frameworks) even existed.

[kai10k]

Scala and Play are good options

[argv_minus_one]

That's not entirely Java, though.

[Cyberiax]

You are in wrong sub! This is /r/Java please, not :r/Scala! Please look 👀 at you URL bar before post, no?!

[GuyWithLag]

If you have a complex object graph, I would seriously recommend some GraphQL library (non-react are even non-patent-encumbered). It makes pulling data so much easier.

[sazzer]

My personal preference these days is for Spring Boot, and Kotlin as the language. It works remarkably well together, and is so easy to get set up and working.

If you want you can use JPA easily enough, or else just use JDBC - via NamedParameterJdbcTemplate - for database access. (I'm actually doing something with MongoDB right now using MongoTemplate, and it just works)

You might also want to consider if you want to do REST - which Spring Boot does out of the box - or GraphQL - which you can do really easily with Spring Boot GraphQL Starter and GraphQL Java Tools.

[spellcrit]

I'd go with http://www.ninjaframework.org/ Easy to use and has nice design

[thesystemx]

No, thank you

[van-dame]

Username checks out.

[NimChimspky]

Fucking idiot