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?
And TLS/SSL, authentication using either LDAP, client-side SSL certs.
Custom filters for REST endpoints (Aspect/J-like).
We build our angularJS frontend against a Java EE backend. Works really well - we use ssh scripts to copy javascript/html changes to the app server instead of redeploying, means its 2 seconds between html/js changes and viewing it on the app (like it should be). Can be done.
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.
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.
Spring (and latest JEE editions with better support of DI) no more encourages spaghetti designs than does manual wiring of objects, so usually these giant balls of mud are the result of project management and design mistakes, not the failure of the tool. In fact, properly designed system that uses DI is indeed decoupled (because you can limit the number of interfaces between components) and modularized (because you can wire dependency of one module on interface with implementation in another one). Moreover, it opens the way to plugin architecture, because application context definition can serve also as plugin definition and there exists discovery mechanism (e.g. classpath:/plugins/*.xml in plain DI or Spring Boot AutoConfiguration).
I think maybe this comes down to the kind of injection. If you rely on variable or setter injection, you can easily create a kind of dark matter that invisibly warps the flexibility of the project.
I and others have generally found that using Constructor injection greatly decouples a design and simplifies testing.
And the Spring team have been saying so for at least as long as I've paid attention to the question[0]:
> Constructor-based or setter-based DI?
> ...
> The Spring team generally advocates constructor injection as it enables one to implement application components as immutable objects and to ensure that required dependencies are not null. Furthermore constructor-injected components are always returned to client (calling) code in a fully initialized state.
Nope. There is no difference between injection types from the coupling perspective, simply because neither blocks anything bad from happening in your architecture. There are reasons to prefer constructor injection in many cases, but it has nothing to do with modularity or coupling.
Constructor injection in Spring is more test-friendly; in turn that tends to allow us the liberty of more aggressively modularising the design. With other injection types either more bookkeeping is required to cleanly set up tests; or alternatively, "unit" testing becomes more integration-esque.
It's a second-order effect felt in the many small decisions that lead one to the mudpit.
That's why I used the analogy of dark matter. It's not directly observed, but it has gravity.
> Constructor injection in Spring is more test-friendly
If you get in the habit of using the Spring test support, where classes under test get injected, then all kinds of injection are equally friendly, and the tests don't give you feedback on the weight of the dependencies because Spring does the heavy lifting.
And, in my experience, where you do inject dependencies by hand, the design pressure is actually towards coarser-grained objects. Why? Because you need to have enough functionality to test; with fine-grained objects, you have to construct and assemble an object graph in the test, whereas with coarse-grained objects, you just new up one thing.
> If you get in the habit of using the Spring test support, where classes under test get injected, then all kinds of injection are equally friendly, and the tests don't give you feedback on the weight of the dependencies because Spring does the heavy lifting.
How do you handle the Spring context start-up time? In Spring projects I've worked on, across hundreds of unit tests it's non-trivial. But I don't make any claim to know if we were doing Spring right or not.
If you're firm on constructor injection, you can typically test the object in complete isolation without necessarily using mocks, without Spring having to be involved.
Or you can use mocks and Spring Boot's test annotations.
But with field/setter injection, that choice isn't as easy.
The context can be reused between tests. If you're not storing data in beans (which you normally shouldn't), this works well. There is a bit of subtlety in that the framework might have to create multiple context for different configurations, but each of them is reusable.
Running a single test is a bit of pain, but running the whole suite is not a lot slower than if it didn't use Spring.
> Constructor injection in Spring is more test-friendly
These are my thoughts too. No reflection or @MoreAnnotations to inject dependencies. I have an aversion to setter/field based injection because it allows you to instantiate an object in an incorrect state.
My personal pet peeve is bean validation. The goals of the API are laudable, but the fact that the implementation is annotation-driven drives me nuts.
Annotations are fine for intra-project code contracts, but using them for external validation means that if you, say, deploy on a application server with an older version of Jersey, you're suddenly SOL when none of your validation logic is executed.
With Constructor based injection its easier to see layering and coupling issues as once your constructor gets more that 3-4 parameters then it starts becoming blindingly obvious that the class has too many dependencies and needs to be refactored. This helps keep the bad out of the architecture.
The main reason to favor constructor based injection is that it stops objects becoming 'live' in an inconsistent state. I've seen actual production issues with setter based injection that can only be explained by the object being available for use before all the setters have been called.
Your arguments are valid on why constructor injection should be preferred. However, what are you talking about is the human-made decision: "Stop adding more parameters to constructor". The tool does not force you to build high-quality architecture, it is your choice based on your experience and skills. Other people who are not yet aware about the consequences may still make wrong design decisions and they'll be ok with lots of parameters.
They are two different tools needed for two different jobs.
Constructor injection is for mandatory dependencies, setter injection is for optional dependencies.
If you are writing a plugin application and some modules are optional then you cannot use constructor injection because when the optional module is not present you cannot start your whole application.
In 99% of the cases obviously constructor injection is the way to go.
That's too generic statement to be applied to anything. Some specific failures of tools (what exactly?) may be the cause of other issues, but it's not the law of nature. You can hit your finger by a hummer, but it's not because hummer brought the wrong concepts - it served millions of people to build their homes, their farms and fences, it's just because sometimes you miss the nail.
It is only generic if you completely drop the context of the discussion (Spring and dependency injection). My point is that Spring brings DI/IoC concepts which help build healthy projects.
There are so many counter-examples in the world of poorly built projects, that I don't really understand how did you came to this conclusion. DI/IoC is just a pattern, there's no way it could guide you to good architecture itself. Spring is just a tool, which adds some constraints, but which does not force you to make business decisions on scope of different domains or interaction between them that might lead to strong coupling and low modularity.
I'm not sure where I stated that Spring forces "to make business decisions on scope of different domains or interaction between them that might lead to strong coupling and low modularity".
Let me explain in other words. You said:
>It is the failure of concepts so if the tool brings the right concepts, it helps avoid such design mistakes in the first place.
In the context of Spring/DI it does not make sense, because no matter what, some developers do and will be doing design mistakes related to coupling and modularity and some will write great code, but this is neither feature nor failure of the tool. DI/IoC is too low-level concept to influence application design, because in case of Spring it affects individual classes, not components, namespaces or subsystems. It is the responsibility of the developer to make decisions and create designs that make application modular, designs that restrict number of dependencies etc, and, in general, to do all the work required to avoid creating "giant ball of mud". The result of this work done with Spring or any other IoC/DI framework will not be very different from manual instantiation of objects and wiring.
It enables such designs, by making it easy for someone to add more crap into your ball of mud. Not everyone on your team is as smart or experienced as you. When their back is against the wall with a deadline...just throw some more beans in there, who cares how they're wired together, it's all handled by Spring!
Well, you care when you have an unexpected complex circular dependency or you need to refactor and you suddenly discover how complex your dependency graph has unintentionally become.
By "decoupling" and "modularization", I'm not talking about at a code-level by using interfaces. In my opinion, that kind of decoupling and modularization isn't very important, especially when it comes to application glue--because the glue (Spring) is what decides the backing impl's of all those interfaces. That's where the important dependencies lie, and that's where your big ball of mud accretes.
It is not a tool problem. Programming tools always address two problems: coding performance and coding quality. But the design, the architecture is not something that could be fixed by a tool. Frameworks may add or remove some constraints, but there's always enough space for the side effects of human creativity. People always break or misuse the tools, creating the balls of mud. It's not a problem with these tools, it's a problem with organization of development process, with competencies of decision makers, with inadequate constraints and unclear requirements. It's easy to blame the tool, throw away the ball of mud and start from scratch with fancy new tech. But in the end you'll get the same ball of mud, because you have ignored the root causes.
> When their back is against the wall with a deadline...just throw some more beans in there, who cares how they're wired together, it's all handled by Spring!
I just came across a controller in our code that had over 50 spring injected services. Our entire code base is only like 5 years old.
The problem is that this is my first job out of college... even if I know things are messed up, I don't really have an example of an application like this that is actually done right.
I prefer controllers to have only one service. A controller should do as little as possible. Its responsibility is just to pass data from the request to the service.
The same should apply to repositories unless it is absolutely necessary. It should ideally just know enough to manage itself
A service may reference other services if it needs to coordinate actions. We need to be careful not to make huge services that contains too much logic though
I have found that this pattern makes it not only easier to structure the application, but also much easier to make mocked tests.
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.
The idea that you would add a dependency to avoid writing a try-catch in a loop is absolutely bewildering to me. What next, Spring Pad? I can see it now:
@LeftPad(width = 50)
public String getNameForDisplay() {
return name;
}
Being able to quickly change in different retry mechanisms and policies is pretty useful. Sometimes you want exponential backoff, sometimes no backoff, sometimes it depends on other state.
Not as simple as you might think. And if you're gonna be writing microservices you're going to be intimately familiar with retries.
Not what I intended to convey. I am saying that Oracle, like Pivotal and Red Hat, is interested in the relative balance of Spring and Java EE preferences in the community.
Almost every time the answer for me has been "it seems like they have, but they don't handle a critical edge case of some kind and cannot be extended to, and thus their solution is totally useless."
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%.
- Not all Spring projects seem to receive equal love. They can and do stomp on each other.
- Spring's get-going-quickly seems to mostly come from serious design assumptions. Which is fine per se but they are not made clear which is not OK.
- Spring is far too automagical. My latest bugbear is it deciding to change defaults depending on what it thinks I want. Bonus points for there being multiple settings that control the same behaviour only one of which can override.
You're not using Java anymore you're using Spring.
This is a discussion that I've occasionally tried to raise with colleagues. I usually find myself in a pretty isolated position, but anyway..
My viewpoint is, roughly:
1) DI, as described in the GoF book is a great pattern. You compose objects by passing other objects to its constructor as needed. These are the stored in final fields for the lifetime of the parent object. The pattern gives a lot of flexibility and handles a lot of use cases which it may otherwise be tempting to handle using the inferior concept of inheritance. It's simple, it's typesafe, it's easy to debug.
2) DI, as implemented by virtually any DI framework, is the Devil. Most DI frameworks is little more than a big dictionary mapping interface types (or magic strings) to implementation classes, along with some black-box magic to make it work (and bloat your stacktraces). It saves you the effort of calling constructors explicitly but any gains are lost as soon as you need to debug stuff. It shares a lot of traits with that other big dictionary where you can dump stuff for convenience: the global scope. It also has the same backdraws.
But anyway, this is a minority position so there is a large chance that I'm dead wrong and a small chance that history will prove me right.
Somehow I don't share your experience. What are the problem with DI and debugging? I had a lot WTF moments with automagical things, but not with pure DI.
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.
> Any language picked up by corporate interests is basically destined for overengineering.
I saw plenty of overengineering even with C back in the 90's.
My biggest example was a server framework that used its own concept of opaque pointers all over the code, because they abstracted data access over shared memory to all instances of the server.
So any memory access to data structures storing server state required translating between handles and pointer all the time.
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.
Whether IoC is reasonable or not does not depend on the number of classes in the project. It is still a useful pattern even if you have, like, 3 classes (component A using implementation B of the interface Ib). It's just if you have only few components, you may want to wire them manually in maybe 10 lines of code instead of dropping in Spring JARs.
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.
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.
In my experience an advantage of frameworks is that you can plop down a team with experience in that framework and have them be moderately productive quickly. I'd say they're a disadvantage in many cases depending on what type of app you're working on.
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've witnessed a similar journey, having worked on an application 15 years ago that (for various reasons that made sense at the time) used RMI calls between a bunch of presentation logic and a service layer.
It was refactored into a J2EE application after 7 years, and is now being refactored into a group of microservices, which causes a number of the longer-lived devs in the team to suggest everything old is new again.
The way I remember it is if you were single-stack from client to server, yeah, EJBs and others in the J2EE worked pretty well.
On the other hand, if you wanted to get of the rails and have clients in multiple stacks and clients who talked to different stacks, then it just all fell apart. Even multiple vendors in the J2EE space could be a problem.
Being able to do things simply hid a lot of complexity. It was hard to investigate that complexity when things went wrong.
It feels like chaos today, with myriad front-end frameworks and best practices changing every three months, but I would take this over mid-2000's Java tech because it just simply seems like less magic. I can break out Postman and just see what's going on.
I agree that there's no golden bullet, and that there's no end of crappy REST definitions. Furthermore, it's mostly not even REST, not in a HATEOAS kind of way.
But that's ok, I still feel more productive than I did 15 years ago, and I wouldn't want to go back.
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.
The original goal of EJB's was to push functional decomposition out onto the network.
Entity beans were always a disaster, and Stateful Session Beans had scaling problems, but Stateless Session beans by the time of EJB3 were an easy way to push logic out to the network while getting a whole bunch of stuff (pooling, scaling, failover, transaction management, security, etc) for free.
These days they'd be calling them micro services.
The main problem was combining everything into the big ball of mud that is J2EE. If they had let each component live and die on its own merits I think the ecosystem would be in a much better state today.
I laughed harder than I should've because I just moments ago was reviewing a stack trace with a teammate and questioned "have you ever gotten anything useful after line 50 of a Spring stack trace?"
And then we all laughed until we realized half the trace was because it got logged and thrown and then logged again...
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.
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.
I got the same feeling here. Implicits in Scala can act as statically checked dependency injection, I don't know why they are going for this runtime dependant injection instead.
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.
I can't agree enough. I can't find anything else with support that the Spring ecosystem has built for many cloud stacks (my experience is with AWS). Being able to choose from a whole host have identity providers, social, and other things for login and user data that generally just fits in to the normal auth and security mechanisms solves a problem we had for years with new applications.
It's certainly daunting if you're green to it and there isn't a grizzled vet around, but if you're trying to build for more than contrived simple solutions that you need to monitor, scale, and secure I don't know anything else out there that gets you so far down the road almost at the beginning.
I work with Spring everyday and really appreciate how it simplifies many things with enterprise Java development. However that appreciation has come with a cost.
In the original "Java Development with the Spring Framework" in 2005, it was argued that J2EE was far too complex in order to be effective. Spring was going to provide a simplifying framework to make development easier.
To me it's ironic how Spring has evolved in complexity over the years, but it's the first framework any of us turn to.
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.
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?
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.
Grails 2.x or Grails 3 ? Many sites using version 2.x haven't bothered upgrading to version 3 in the two years since it was released, nor are there many version 3 plugins converted. And very few new Grails projects are started.
We use Grails for a lot of internal applications at our company, all 2.x (2.3.x through 2.5.x).
I can't really comment on Grails 3, funnily because the applications were written before 3.x came out and we haven't bothered upgrading them yet... :) I've only taken a brief look at what's involved in upgrading them, but other stuff has always been higher priority.
It's probably worth being familiar with both versions, because Grails had plenty of adoption before 3.x came out and 2.x is still being maintained.
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.
Should save you some time if you're looking to get started with JPA, different libraries, etc.
Also, this doesn't really get at the strengths of Play as a reactive application. For example, here's a talk where I discuss using Reactive Streams with Play to stream video through Play. It's about two years old now:
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.
RE: AWS Lambda, there are a lot of shortcomings, the biggest is latency when it's cold. Another is duration, if your process takes too long and you can't break it into smaller steps (probably not a good sign, but still...) Lambda is no-go.
Configuration generally kind of sucks to manage, you don't get some of the role inheritance you can get from standard EC2/IAM, and forget running inside a VPC.
The idea behind using something like API Gateway + a Lambda for the various end points sounds awesome in theory, but going beyond contrived examples shows that we're a long way out.
There's a lot to criticize about running your own Dropwizard, Play, Spring and Java EE instances as well, including the same issue of management headaches. In fact one of the key advantages of the "serverless" approach is less devops management overhead. To consider running your own instance "management suckage free" but calling something like serverless.com a headache is definitely not an apples-to-apples comparison.
Cold start time is a known issue but frankly, not that big of a problem in practice for many apps. Definitely I feel that dismissing this out of hand (I even got a downvote) is more of an emotional reaction to something really different and new than a rational one. There's nothing contrived about implementing a REST service with FaaS -- it's just simpler. It's worth giving it a serious look even as an experienced Java developer (as I am). There are a lot of benefits to the architecture, like minimal devops and tremendous cost effectiveness.
I definitely didn't downvote and I agree that there are tradeoffs with any choice- but serverless doesn't mean Ops-less. I use Lambdas for lots of things, actually a lot of my Ops use Lambdas for various tasks (like SES catch all mail forwarding for example).
Don't think I'm dissing Lambdas (or anything like them in a non AWS context). There's a lot to love about them, not the least of which is that for small (in time to completion, request volume, and memory usage) units of work they are significantly cheaper.
There's a config management nightmare for everything but there are known ways to answer it for a traditional server/fleet approach. Run time configuration of Lambdas is still evolving and there aren't many options to choose from that are much better than just deploying the code and config as one as part of a delivery pipeline. It's workable now, but there are gaps. There aren't any gaps with running your own applications, it's literally what's always been done. There are certainly pain points, but the problem is already well understood.
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.
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.
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 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
Sure, I used to work with Java EE in the enterprise. My team switched over entirely to working with Clojure over the course of the past 6 years. We build large applications for use at the hospital. For context, the projects I work on are typically implemented over several years by a team of 5-10 developers.
We find that our projects now have drastically less code doing the same types of things. Not only that, but the code we do write is predominantly declarative in nature. Clojure makes it much easier to separate the intent of the code from the implementation details.
Conversely, having less code means we're less attached to it. When it takes a 1000 lines to solve a problem, you tend to keep them around once you get a solution working. When you have 100 lines, it's much easier to throw them away and write a cleaner solution when you understand the problem.
Clojure projects are easier to debug and maintain thanks to pervasive immutability in the language. This allows us to safely think about parts of the application in isolation. When I come back to code that I wrote a few months ago and make a change, I know that the change is local and it's not going to affect another part of the project via side effects.
Clojure facilitates interactive development by providing strong integration between the editor and the REPL. When we're building new features, we're able to experiment interactively to see what approach will work best.
Since Clojure also runs in the browser with ClojureScript, we're able to use the same language for the full stack. This also lets us share code, such as validation logic, between the client and the server.
Meanwhile, we're still able to leverage existing Java libraries, infrastructure, and reap all the benefits of using the JVM.
You are barking up the wrong tree. I am also a Clojure enthusiast and I also use it wherever I can. I was genuinely interested to hear about a Java alternative to Spring because I failed to find any. I don't use java in production anymore though, only Kotlin and Clojure.
Fair enough, from what I know Dropwizard is supposed to be pretty decent. I have a few friends working in Java shops who seem to like it. However, I haven't used it myself, so can't really comment how it compares to Spring overall.
reply