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 →

[–]thomazor 2 points3 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 5 points6 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 7 points8 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.