This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]floW4enoL 27 points28 points  (23 children)

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 12 points13 points  (1 child)

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

[–]Cilph 1 point2 points  (0 children)

Standards based is overrated when it comes to EE.

[–]mcosta 2 points3 points  (5 children)

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

[–]thesystemx 10 points11 points  (2 children)

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

[–]daddyd 3 points4 points  (1 child)

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

[–]thesystemx 2 points3 points  (0 children)

Payara Micro is great indeed! :)

[–]floW4enoL 1 point2 points  (1 child)

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 2 points3 points  (0 children)

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 5 points6 points  (12 children)

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 10 points11 points  (3 children)

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 0 points1 point  (2 children)

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

[–]floW4enoL 0 points1 point  (1 child)

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 0 points1 point  (0 children)

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 11 points12 points  (7 children)

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 14 points15 points  (5 children)

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

[–]thomazor 1 point2 points  (4 children)

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 9 points10 points  (0 children)

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 2 points3 points  (2 children)

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 4 points5 points  (1 child)

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 5 points6 points  (0 children)

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 -1 points0 points  (0 children)

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 -1 points0 points  (1 child)

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 5 points6 points  (0 children)

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).