Personally, I haven't heard anything about renewed debates related to Spring vs. JEE in many years. And if you read the Gartner report in question[1], it's not about that at all. Hmm. Maybe I'm just cynical, but when I saw he was part of the company behind Spring I thought maybe this was more of a contrived argument. The truth is, framing a debate as Spring vs JEE perhaps stands to benefit both technologies since in many people's minds they are both complex and bloated. It's just about positioning; yes, Spring is "lightweight" compared to traditional JEE, but so is everything!
"lightweight" compared to traditional JEE, but so is everything!
This isn't going to make me popular on HN but: I don't think this is actually the case.
Back in the mid 2000s I built EJB services by defining simple interface and implementation classes. I consumed the service by by injecting the interface into my clients. I tested my consumers by mocking the interface.
Now I build REST services. I have to define and document a complex dance of verbs, nouns, and payloads. Client code requires stitching together text fragments into URLs and JSON. There's no typechecking across API boundaries and testing requires me to stub out crappy HTTP libraries.
Hmmmm.
There are good things to say about REST (like transparency and ubiquity), but it's not totally clear to me that the world is better off now than we were back in those Dark Days. Yeah, there was a lot of awful EJB code, but I'm finding no shortage of shitty REST microservice code floating about nowadays.
I like Java, but I've never tried diving into the Spring or Java EE world. The little I've looked at it seem daunting and complex and I'm not sure what it really gives you at the end of the day. What functionality does it provide, what are the killer features? And is all this complexity justified?
I work with Spring and Java EE professionally, prefer Spring wherever I can. Also use Spring for private/side projects (if not plain Java). But I'll talk about Spring here.
I see two import aspects that Spring provide: first, dependency injection/inversion of control as basis and then a way to 1000+1 things "right".
Dependency injection is important because it provides a healthy way to compose an application from many components or services. It's not exclusive to Spring of course, you can do DI/IoC without Spring (even without any framework), but it's baked into the very nature of Spring.
Next, Spring provides "right" way to do a lot of more-or-less standard things. You have solutions for ORM, REST interfaces, security, batch processing and a thousand more tasks. From my experience, Spring solutions are mostly good or very good, at least much better than I'd design in a limited time frame. This gets me faster to the working solution.
I also don't thing that Spring brings that much of a complexity overhead. Once you got past the first threshold (like, you can assemble you application from a few components) you're good to go. Ok, you will eventually need to learn concepts of individual Spring components (like ORM or security), but you'd need to learn them anyway.
Eventually you'll need to fight Spring here and there, I won't deny it. This is normally related to the "automagical" stuff like autowiring or autoconfigurations - things which make your work easier in 98% but might make you crazy for the rest 2%.
The Spring that I've used (the DI Framework, Spring Integration, Spring MVC) is mainly designed to simplify and standardize enterprise applications. Mostly this involves standard and automated ways to "wire" together applications. This includes DI, but also includes configuration (e.g. configuration to enable a deployment pipeline), communication between components/services (client and server mapping of messages in a message bus to their ser/de impl and schema definitions, database interfaces), service and UI implementations themselves (SpringMVC, Spring Boot), etc. The benefit is that Spring is a glue layer that integrates all these various pieces of "enterprise" systems with minimal boilerplate.
I don't have much experience with Java EE, so can't comment. My experience with Spring is not very positive--it enables and encourages applications and systems to have complex dependency graphs, and so often I've seen this result in giant balls of mud that, despite Spring's claim that it enables decoupled and modularized design, are rat's nests of unexpected coupling and hard-to-predict behavior.
I've spent multiple-year periods using each of Java EE, Spring, and no formal framework (in practice, Guice for DI, Tomcat/Servlets for web, lots of libraries, and lots and lots of homebrew stuff). I can say with confidence that if your goal is just to build a sophisticated application, there's no advantage to using the frameworks.
They include a lot of functionality, but beyond demo-scale applications, you will spend as much time fighting the framework as you save by using it.
The frameworks probably do save you time in getting started; Spring Boot certainly has a pretty smooth experience going from nothing to a running project with a controller, database, etc. But that's a tiny expense in the lifetime of a project.
EE might give you some kind of confidence that you can port your app between app servers (or different releases of an app server!). If you work in an environment where some idiot up the hierarchy has decided everyone should use app servers, that might be useful, but there's no point setting out to create such an environment.
Both Java EE and Spring provide a huge amount of functionality and do it in an uniform way, so you don't have to glue lots of different libraries together. They aim for enterprise world, where this functionality is required. Not every project need it, so sometimes it might be not necessary. IoC is awesome on huge projects, but if your project is 10-20 classes, it's just unnecessary abstraction. Distributed transactions increase robustness, when you're working with multiple databases and message queues, but if you're creating website with a single database, you just don't need it. WebServices implementation is a must, when you have to integrate with someone, who's exposing their API via webservice and you'll drown in details, if you'll try to implement it manually, but if you're using lightweight REST APIs, it's quite possible to do it without any frameworks.
So it's good when you need it, and it's unnecessary over-engineering for simple projects.
It is daunting for sure. I stewed myself in the ecosystem last year by writing a couple open source libraries and fell in love with it. Java was the sexy language of the 90's, ironic because The best way I can describe it is the exact opposite of the current sexy language, JavaScript.
Java is great, the best, when I'm trying to build something creative. It's like having access to an entire parts warehouse vs a toolshed for most other languages. Unlike especially JS, most libraries are well tested and most people agree on doing things a certain way. There's not a lot of unknowns, almost no flux, and once you know the rules you can focus on your problem and ignore the "ecosystem" almost entirely.
The complexity can be looked at from a different perspective, I see it as similar to Roman characters vs Chinese. Learning 26 characters is a hell of a lot easier but with a couple thousand you can say the same things with a lot less writing. Once you've gotten over the cognitive hill of learning the complexity it doesn't really get in the way. It's there when you need it, and you ignore it when you don't.
Contrast this to JavaScript where most advancements redefine workflows or parts of the language core libraries. It feels like the most exciting thing about JavaScript is how unstable it is, something that scares the hell out of me after working on 15+ year old code. What you trade off with complexity in Java is definitely less work than keeping up with js for more than a year.
This sort of became a js/Java comparison because there's a ton of similarity in the hype between them and their lifecycle so far. Java was not always so complex after all. You can see the complexity of the JS ecosystem and language growing steadily and I have no doubt that in five years it will be just as complex as Java. The complexity is driven by the big guys that actually need it, and being the big guys, they also have the most influence on what the language eventually becomes.
So to recap, no, for the vast majority of projects the complexity is definitely not justified. It's there so the language can support the 1% of projects that need all that. On the other hand, once you know your way around it's fairly easy to ignore those parts. What access to all this stuff really gives you is power. As a footnote, give JS some time and it will be the same. Any language picked up by corporate interests is basically destined for overengineering.
JavaEE provides a lot of the stuff programmers like me want in a way that is more or less consistent between different vendors.
Typically this includes database access, ORM, message bus access etc.
It also does so in a very integrated way so you can easily have for example a transaction that spans database modification and sending to a message bus.
I like it. I found that embracing it allowed me to simplify lots of code.
Depends on what you're trying to solve. If you need to use a database, serve or get data over HTTP, run things every hour etc. chances are you'll save time and have a more stable and performing solution by using libraries from other parties. For example Spring libraries.
I'll put my disclosure up-front: I work for Pivotal on a Cloud Foundry project. Pivotal employs many members of the Spring team. I am not speaking for either Spring or Pivotal.
Both Spring and Java EE are very featuresome because of a long period of evolution across multiple partial paradigm shifts (3-tier, CORBA, Web 1.0, App Containers, SOA, VMs, Web 2.0, Containers...).
I'm personally only familiar with Spring. And by "familiar" I mean I've learnt enough to be dangerous. But I've also learned to ask, before doing something: "Have the Spring team already solved this?"
Take, for example, retrying an operation. A slightly hacky way to achieve this is to nest try-catches. A slightly less hacky way is some sort of loop. Then we extract this functionality out. I dunno, lambdas maybe?
Or: I could use Spring-Retry[0].
That's just one example from my own experience.
It used to be that Java EE was it. And it had to be: the mega-buyers insisted that there were sufficiently rigorous standards that they could switch vendors. Every giant corporation bleeds gold to some ancient vendor and they have an immune reaction, nearly a spasm allergy, to vendor lockin[1].
Opensource tools kinda sail around this, because ... uh ... what vendor lockin? Who has you grasped, by what kind of delicate hair? Nobody. It's opensource. You can wait for community action, or engage a consultancy, or a related product company, or hire specialists, or sponsor something ... you have a wider range of options.
Oh sure, there's tech lockin, but that's true of any decision. Either you exploit the features of a platform and tie yourself to it, or you write a rubber-room abstraction layer and tie yourself to that instead, but at your expense.
In my observation as a 1st? 2nd? party, the Spring team pay close attention to the standards and support them. And, not coincidentally, many standards look -- gee, just awfully similar to something Spring had road-tested a few years prior.
I think a lot of the shade thrown in this debate is happening because of money. Pivotal backs Spring very strongly, because it helps to sell our version of Cloud Foundry (imaginatively: Pivotal Cloud Foundry).
Meanwhile, Oracle owns a lot of Java products, some inherited from Sun, as well as being the stewards of the Java EE standards process. Red Hat own a solid suite of Java EE-capable and platform products, a portfolio largely overlapping with Pivotal's, IBM's and SAP's.
In each of these cases there's a zero-ish sum-ish game underway. A company that bets on Red Hat doesn't bet on IBM. A company going all-in with Oracle (RIP your chequebook) isn't going to buy much from Pivotal.
Meanwhile, the Spring team are just writing software. I lurk some of their internal Slack channels. It's almost exclusively technical and usually very thoughtful. As a Pivot indoctrinated by Pivotal Labs, I appreciate having a very different example of how to develop high-quality software.
I used to like spring in favor of JEE Application servers. But of late, spring is getting too bloated, too complicated and buggy. OTOH, newer java frameworks are simpler and easier to work with. For example, spark application framework or retrofit for rest APIs. At this point spring is very similar to JEE.
If I want to build a web app from scratch which should have some basic features (user identification, some standard level of security, REST interface, database integration) and I have some okay knowledge of Java (mainly CLI applications and some Android programming), which framework would you recommend for me to get started?
I'm afraid to get lost in the details too quickly, so a framework that provides a working example which can than be adjusted to my needs would be very welcome. Any suggestions?
Dropwizard and Play are very good alternatives to Spring if you don't need the whole kitchen sink or you absolutely want to use X library for Y application function and Spring doesn't necessarily have very good out of the box support for said library.
The upside of Spring over Dropwizard or Play (or any of the lighter touch frameworks) is that it's so much more than an MVC or REST controller framework. The report in question is literally comparing it against the entire Java EE ecosystem. Spring is not a library or a framework anymore, it's practically an entire stack that you can pick and choose from.
Play and DW are likely to be easier to get your head around than Spring, there's a lot of magic going on in there and (not unlike getting into the JS world these days) you will find that setting the thing up from scratch takes a whole lot more time than you ever would have guessed. There's 1000 ways to do the same thing and sometimes doing it one way is a real issue later on, and worst of all it may not be apparent that that is the root source of some seemingly unrelated issue.
Spring Boot aims to solve a lot of that by taking an opinionated approach to how the project should be laid out, libraries, and default configuarations- more along the lines of a .NET MVC + database, etc. There's still the same amount of complexity and configuration, it's just hidden from you until you need to dig in.
I generally use Spring Boot to start greenfield projects these days, we deploy to AWS and their extra libraries for handling and working with that save a lot of boilerplate that's so common with Java.
I would suggest you get your feet wet with either GP or DW, but don't forget about Spring Boot down the road. I've gotten to the point where I've got a stack including Vault (secrets) + Spring Config Server (distributed config application) + a fleet of various Spring Boot microservices running in Docker on AWS and they (mostly) just startup and run the way I wanted them to. It's really awesome, and wildly overkill for that proof of concept API or personal project we would be doing a lot of, but allows me to run my company without a huge team.
Play framework is easy to get started with if you just go by their documentation. I switched from php to play and was happy with the result. Admittedly, I did not try spring, so I don't know how it compares.
This question usually comes from a person trying to build their resume. My suggestion would be to do a search for Java jobs in your area and see what other libraries they are using. That will be way more useful to you in the long run than learning what the HN crowd thinks is fashionable. In my experience around here that means Spring, but it could be different in your area..
Take a look at JHipster: https://jhipster.github.io/. Web application generator for the front and back ends using development best practices. Can be extended to be used with Docker, Kubernetes, and CI/CD.
Having used both I'd say JavaEE 7 is more concise and less complex of an API than the Spring framework. Unfortunately it's hard to predict the future of EE and its implementations thanks to Oracle. Spring uses some EE technologies and adds its own abstractions on top of them, which adds a whole layer of complexity.
I'd say Spring Boot. When you use JPA for basic data access, you don't have to have much in the way of data code. It's really easy to use Spring MVC for web front ends with Thymeleaf. It's really easy to make REST for when you don't want to render server side. All of this plugs into a free version of Eclipse called Spring STS. You can also use IntelliJ if you so chose. The nice thing about all of this is that you can simply deploy a JAR. No need for Tomcat or some other web container.
There is also a huge number of tutorials from the horse's mouth on the topic.
These are good answers but nowadays we would be remiss not to mention so-called "serverless" frameworks. Dropwizard et al are good suggestions for running your own instance, but more and more the serverless approach is an attractive alternative to implementing a web app.
AWS Lambda now supports Java, so perhaps we could consider API Gateway, Cognito and DynamoDB/Aurora as one of the new "frameworks". Google has their own competing offering as well, e.g. Cloud Functions. Firebase deserves a special mention as a rapid development framework, although at the moment it only supports Node.js. Like many frameworks it has pros and cons, but in my opinion full-on websockets support OOTB is a pretty cool pro.. especially since Lambda/Cloud Functions/FaaS can't do websockets on their own.
In terms of the popularity of the two frameworks, all I can say is that I have been interviewing 2-3 Java engineers per week for the past few months, and almost all of them put Spring on their resume and not Java EE.
> for example here’s a copy from Lightbend (the company behind Scala, Play & Lagom)
I use Play 2 for most of my projects and frankly knowing what I know about Spring and J2EE (even though having never worked with them for the same reason) I couldn't really think of any reason to choose either of these outdated behemoths. With something like Play 2 and Slick/JOOQ you could run circles around these two.
You call Spring an outdated behemoth yet you have never worked with it. I've worked with EJB, Spring, Play, Dropwizard and a bunch of other stuff an I can tell that the current version of Spring is cutting edge and since they introduced java-based configuration you can really do stuff with it without the hassle which comes with other frameworks. Make yourself a favour and don't make a fool of yourself by bashing something you haven't even tried.
Same here, Scala rocks ! Too bad play 2 is now using guice and promots runtime dependency injection like in Java world. Compile dependency injection is much better, I fear they'll try to mimick spring more and more in order to attract java crowds.
Our stack uses both Play and Spring. Of course, Play is becoming more and more "opinionated" and not playing with others as well newer versions, so we are moving Spring Boot for the flexibility it provides.
Opinionated frameworks are fine to get started quickly, but for larger scale companies, you are gunna want flexibility beyond that.
I don't get reactive or functional. I get, step 1 do something, step 2 if something then do step 4 else step 3. Those were really the days. I guess if I could have my dream framework today it would be just Java and some Apache jars and some Google jars, maybe an odd jar here or there. And Eclipse, always Eclipse.
I'd also steer clear of anyone who can quote GoF or Fowler.
Spring and EJB 3 are like Django, Rails, and their ilk: big bloated frameworks that include everything you need to build multi tier apps, plus or minus a few features here and there. Convergent evolution is a wondrous thing.
Spring vs. JavaEE is a topic that stopped being relevant five years ago. I cant believe anyone seriously considering any of these heavy duty teach stack in 2017. There are much much better choices out there even for Java developers, and if they can come out of their comfort zone a bit there is Clojure, Scala, Kotlin etc with MUCH nicer fraemworks
[+] [-] dlandis|9 years ago|reply
1. https://www.gartner.com/doc/reprints?id=1-3N8E378&ct=161205&...
[+] [-] stickfigure|9 years ago|reply
This isn't going to make me popular on HN but: I don't think this is actually the case.
Back in the mid 2000s I built EJB services by defining simple interface and implementation classes. I consumed the service by by injecting the interface into my clients. I tested my consumers by mocking the interface.
Now I build REST services. I have to define and document a complex dance of verbs, nouns, and payloads. Client code requires stitching together text fragments into URLs and JSON. There's no typechecking across API boundaries and testing requires me to stub out crappy HTTP libraries.
Hmmmm.
There are good things to say about REST (like transparency and ubiquity), but it's not totally clear to me that the world is better off now than we were back in those Dark Days. Yeah, there was a lot of awful EJB code, but I'm finding no shortage of shitty REST microservice code floating about nowadays.
[+] [-] jacques_chester|9 years ago|reply
I'm just going to leave this one at the doors of the bosses, both at vendors (like Pivotal) and buyers (like MegaGloboCorpotronic Consolidated Inc).
Disclosure: I work for Pivotal, on a Cloud Foundry project.
[+] [-] openasocket|9 years ago|reply
[+] [-] orless|9 years ago|reply
I see two import aspects that Spring provide: first, dependency injection/inversion of control as basis and then a way to 1000+1 things "right".
Dependency injection is important because it provides a healthy way to compose an application from many components or services. It's not exclusive to Spring of course, you can do DI/IoC without Spring (even without any framework), but it's baked into the very nature of Spring.
Next, Spring provides "right" way to do a lot of more-or-less standard things. You have solutions for ORM, REST interfaces, security, batch processing and a thousand more tasks. From my experience, Spring solutions are mostly good or very good, at least much better than I'd design in a limited time frame. This gets me faster to the working solution.
I also don't thing that Spring brings that much of a complexity overhead. Once you got past the first threshold (like, you can assemble you application from a few components) you're good to go. Ok, you will eventually need to learn concepts of individual Spring components (like ORM or security), but you'd need to learn them anyway.
Eventually you'll need to fight Spring here and there, I won't deny it. This is normally related to the "automagical" stuff like autowiring or autoconfigurations - things which make your work easier in 98% but might make you crazy for the rest 2%.
[+] [-] cle|9 years ago|reply
I don't have much experience with Java EE, so can't comment. My experience with Spring is not very positive--it enables and encourages applications and systems to have complex dependency graphs, and so often I've seen this result in giant balls of mud that, despite Spring's claim that it enables decoupled and modularized design, are rat's nests of unexpected coupling and hard-to-predict behavior.
[+] [-] twic|9 years ago|reply
They include a lot of functionality, but beyond demo-scale applications, you will spend as much time fighting the framework as you save by using it.
The frameworks probably do save you time in getting started; Spring Boot certainly has a pretty smooth experience going from nothing to a running project with a controller, database, etc. But that's a tiny expense in the lifetime of a project.
EE might give you some kind of confidence that you can port your app between app servers (or different releases of an app server!). If you work in an environment where some idiot up the hierarchy has decided everyone should use app servers, that might be useful, but there's no point setting out to create such an environment.
[+] [-] vbezhenar|9 years ago|reply
So it's good when you need it, and it's unnecessary over-engineering for simple projects.
[+] [-] shouldbworking|9 years ago|reply
Java is great, the best, when I'm trying to build something creative. It's like having access to an entire parts warehouse vs a toolshed for most other languages. Unlike especially JS, most libraries are well tested and most people agree on doing things a certain way. There's not a lot of unknowns, almost no flux, and once you know the rules you can focus on your problem and ignore the "ecosystem" almost entirely.
The complexity can be looked at from a different perspective, I see it as similar to Roman characters vs Chinese. Learning 26 characters is a hell of a lot easier but with a couple thousand you can say the same things with a lot less writing. Once you've gotten over the cognitive hill of learning the complexity it doesn't really get in the way. It's there when you need it, and you ignore it when you don't.
Contrast this to JavaScript where most advancements redefine workflows or parts of the language core libraries. It feels like the most exciting thing about JavaScript is how unstable it is, something that scares the hell out of me after working on 15+ year old code. What you trade off with complexity in Java is definitely less work than keeping up with js for more than a year.
This sort of became a js/Java comparison because there's a ton of similarity in the hype between them and their lifecycle so far. Java was not always so complex after all. You can see the complexity of the JS ecosystem and language growing steadily and I have no doubt that in five years it will be just as complex as Java. The complexity is driven by the big guys that actually need it, and being the big guys, they also have the most influence on what the language eventually becomes.
So to recap, no, for the vast majority of projects the complexity is definitely not justified. It's there so the language can support the 1% of projects that need all that. On the other hand, once you know your way around it's fairly easy to ignore those parts. What access to all this stuff really gives you is power. As a footnote, give JS some time and it will be the same. Any language picked up by corporate interests is basically destined for overengineering.
[+] [-] reitanqild|9 years ago|reply
Typically this includes database access, ORM, message bus access etc.
It also does so in a very integrated way so you can easily have for example a transaction that spans database modification and sending to a message bus.
I like it. I found that embracing it allowed me to simplify lots of code.
[+] [-] nugator|9 years ago|reply
[+] [-] sz4kerto|9 years ago|reply
[+] [-] jacques_chester|9 years ago|reply
Both Spring and Java EE are very featuresome because of a long period of evolution across multiple partial paradigm shifts (3-tier, CORBA, Web 1.0, App Containers, SOA, VMs, Web 2.0, Containers...).
I'm personally only familiar with Spring. And by "familiar" I mean I've learnt enough to be dangerous. But I've also learned to ask, before doing something: "Have the Spring team already solved this?"
Take, for example, retrying an operation. A slightly hacky way to achieve this is to nest try-catches. A slightly less hacky way is some sort of loop. Then we extract this functionality out. I dunno, lambdas maybe?
Or: I could use Spring-Retry[0].
That's just one example from my own experience.
It used to be that Java EE was it. And it had to be: the mega-buyers insisted that there were sufficiently rigorous standards that they could switch vendors. Every giant corporation bleeds gold to some ancient vendor and they have an immune reaction, nearly a spasm allergy, to vendor lockin[1].
Opensource tools kinda sail around this, because ... uh ... what vendor lockin? Who has you grasped, by what kind of delicate hair? Nobody. It's opensource. You can wait for community action, or engage a consultancy, or a related product company, or hire specialists, or sponsor something ... you have a wider range of options.
Oh sure, there's tech lockin, but that's true of any decision. Either you exploit the features of a platform and tie yourself to it, or you write a rubber-room abstraction layer and tie yourself to that instead, but at your expense.
In my observation as a 1st? 2nd? party, the Spring team pay close attention to the standards and support them. And, not coincidentally, many standards look -- gee, just awfully similar to something Spring had road-tested a few years prior.
I think a lot of the shade thrown in this debate is happening because of money. Pivotal backs Spring very strongly, because it helps to sell our version of Cloud Foundry (imaginatively: Pivotal Cloud Foundry).
Meanwhile, Oracle owns a lot of Java products, some inherited from Sun, as well as being the stewards of the Java EE standards process. Red Hat own a solid suite of Java EE-capable and platform products, a portfolio largely overlapping with Pivotal's, IBM's and SAP's.
In each of these cases there's a zero-ish sum-ish game underway. A company that bets on Red Hat doesn't bet on IBM. A company going all-in with Oracle (RIP your chequebook) isn't going to buy much from Pivotal.
Meanwhile, the Spring team are just writing software. I lurk some of their internal Slack channels. It's almost exclusively technical and usually very thoughtful. As a Pivot indoctrinated by Pivotal Labs, I appreciate having a very different example of how to develop high-quality software.
[0] https://github.com/spring-projects/spring-retry
[1] You will often find companies accusing each other this.
[+] [-] snambi|9 years ago|reply
[+] [-] folli|9 years ago|reply
[+] [-] manyxcxi|9 years ago|reply
The upside of Spring over Dropwizard or Play (or any of the lighter touch frameworks) is that it's so much more than an MVC or REST controller framework. The report in question is literally comparing it against the entire Java EE ecosystem. Spring is not a library or a framework anymore, it's practically an entire stack that you can pick and choose from.
Play and DW are likely to be easier to get your head around than Spring, there's a lot of magic going on in there and (not unlike getting into the JS world these days) you will find that setting the thing up from scratch takes a whole lot more time than you ever would have guessed. There's 1000 ways to do the same thing and sometimes doing it one way is a real issue later on, and worst of all it may not be apparent that that is the root source of some seemingly unrelated issue.
Spring Boot aims to solve a lot of that by taking an opinionated approach to how the project should be laid out, libraries, and default configuarations- more along the lines of a .NET MVC + database, etc. There's still the same amount of complexity and configuration, it's just hidden from you until you need to dig in.
I generally use Spring Boot to start greenfield projects these days, we deploy to AWS and their extra libraries for handling and working with that save a lot of boilerplate that's so common with Java.
I would suggest you get your feet wet with either GP or DW, but don't forget about Spring Boot down the road. I've gotten to the point where I've got a stack including Vault (secrets) + Spring Config Server (distributed config application) + a fleet of various Spring Boot microservices running in Docker on AWS and they (mostly) just startup and run the way I wanted them to. It's really awesome, and wildly overkill for that proof of concept API or personal project we would be doing a lot of, but allows me to run my company without a huge team.
[+] [-] Joeri|9 years ago|reply
[+] [-] narak|9 years ago|reply
Definitely not all batteries included, but a great minimalist web library to get started with.
[+] [-] andrewwharton|9 years ago|reply
You use Groovy, but it's pretty similar to Java and there's plenty of resources to bring you up to speed.
[+] [-] Consultant32452|9 years ago|reply
[+] [-] Yhippa|9 years ago|reply
[+] [-] gresrun|9 years ago|reply
[+] [-] EtienneK|9 years ago|reply
I have been writing Java for 10 years now. I've used many different frameworks and libraries. But now all my new projects are Spring Boot projects.
[+] [-] naranha|9 years ago|reply
[+] [-] privacyfornow|9 years ago|reply
It is a very lightweight framework with support for most of the plumbing a developer might want without imposing its will on anyone.
If you are not that worried about having a REST or HTTP or TCP front-end, LMAX disruptor is amazing as well.
[+] [-] reitanqild|9 years ago|reply
I have had great success with the examples from TomEE (free) + the (paid) videos from Adam Bien (I normally shun videos but lke his).
The examples from TomEE often come in the form of something you can run with a single maven command.
[+] [-] iampims|9 years ago|reply
http://www.dropwizard.io/1.1.0/docs/getting-started.html
[+] [-] sandGorgon|9 years ago|reply
[+] [-] virmundi|9 years ago|reply
There is also a huge number of tutorials from the horse's mouth on the topic.
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] abalone|9 years ago|reply
AWS Lambda now supports Java, so perhaps we could consider API Gateway, Cognito and DynamoDB/Aurora as one of the new "frameworks". Google has their own competing offering as well, e.g. Cloud Functions. Firebase deserves a special mention as a rapid development framework, although at the moment it only supports Node.js. Like many frameworks it has pros and cons, but in my opinion full-on websockets support OOTB is a pretty cool pro.. especially since Lambda/Cloud Functions/FaaS can't do websockets on their own.
[+] [-] twblalock|9 years ago|reply
[+] [-] EtienneK|9 years ago|reply
After using Spring Boot for 2 years now, I'll never go back to EE.
[+] [-] springsux|9 years ago|reply
[+] [-] neverminder|9 years ago|reply
I use Play 2 for most of my projects and frankly knowing what I know about Spring and J2EE (even though having never worked with them for the same reason) I couldn't really think of any reason to choose either of these outdated behemoths. With something like Play 2 and Slick/JOOQ you could run circles around these two.
[+] [-] edem|9 years ago|reply
[+] [-] gbersac|9 years ago|reply
[+] [-] kazagistar|9 years ago|reply
Opinionated frameworks are fine to get started quickly, but for larger scale companies, you are gunna want flexibility beyond that.
[+] [-] sgt|9 years ago|reply
[+] [-] springsux|9 years ago|reply
I'd also steer clear of anyone who can quote GoF or Fowler.
[+] [-] codecamper|9 years ago|reply
[+] [-] marktangotango|9 years ago|reply
[+] [-] specialist|9 years ago|reply
I never understood (the point of) EJB. Shamefacedly admit I was once a huge Hibernate fan. But I got over it.
Can't speak to Django nor Rails.
---
Prior joke: Spring is an stacktrace obfuscation framework.
New joke: NodeJS is a control-flow obfuscation framework.
[+] [-] scaleout1|9 years ago|reply
[+] [-] edem|9 years ago|reply
[+] [-] jrwiegand|9 years ago|reply