I remember the days, when the Spring framework was advertised as a lightweight alternative to Enterprise java beans (ejb); now Spring outgrew the pretence of being lightweight, don't know when that happened. A year and a half ago, i got back to work with java and spring boot, and i was overwhelmed by the prevalence of annotations in spring boot.
It's a decompiler that is listing all annotations, so it becomes easier to grep a text file in order to detect the dependencies between annotations.
it is using the asm library https://asm.ow2.io/ to inspect the bytecode files, so as to extract the class signature, along with the reference and declaration of annotations included in a classpath, or class files included within a directory structure. A limitation/feature is, that it is inspecting already compiled bytecode files.
Indeed. I have a dozen or so microservices supported by team. Most are SpringBoot a couple of them I wrote myself with plain java and embedded tomcat. Needless to say Springboot stuff is rather complicated for such a simple business functionality. Errors are indecipherable being swamped by thousand line framework exception trace. But being an "enterprise standard" framework all projects must be move to this turd of a framework.
And in 99% of cases that little microservice will suddenly need thread pooling, logging, some more advanced db management or God help some random messaging service and you are back to re-implementing the myriad features of spring in a shittier way.
It is not an accident that things like ruby on rails are popular. These are well-tested toolboxes with a solution for almost every conceivable problem. There are exceptions where it is not needed, but for business applications those are not numerous.
I don't think people have any issues with the fact that spring is batteries included. It seems to me (and this is my personal experience too) that the large amounts of abstraction and indirection through annotations makes the code very hard to parse. It makes it hard to create a mental graph of how it all works together
My experience is that it's not only the usage of annotations, but the way Spring handles/implements those annotations which is confusing.
As an example, Micronaut[1] also uses annotations a lot, but their implementation is a lot easier to reason about, because there is less indirection with proxy objects and other weird stuff that Spring uses.
Micronaut does not implement nearly as many annotations as Spring though, which basically means less functionality pre-built. I'm not sure that's a bad thing, but it could be.
I found the real challenge to be that it's very difficult - if not impossible - to determine how spring functions simply by reading code and using it. In simpler libraries or frameworks, I normally just read the source to understand how I should be using it. With Spring, I've had to spend a lot of time reading and re-reaading docs to understand what's going on.
I think that this is sometimes a hard shift for developers who otherwise have spent their lives with an ability to puzzle out the constructs that they come across.
I absolutely understand it, but I think the correct, although bit inconvenient approach is the one you mentioned — properly learning the framework either through docs or other materials.
Way too many developers try to write spring (but also jpa and many other useful, but complex tool) by trial and error, which let’s be honest, not a good tactic even if one can easily inspect the source. (The recently posted microsoft blog post “even if the precondition doesn’t do anything, you still have to call it” comes to mind)
Looks like an IDE / language server that unrolls the annotation generated code might be what's missing here. I like my abstractions to be hidden, but I like to be able to peek under the hood. That's one of the problems of C++ templates, sometimes I want to look at the expanded code.
The GNAT Ada compiler has an option to output a much-simplified code. Not compilable Ada, but very inspectable unrolled, expanded code. Makes for a great teaching tool. Aaaaaaah this generic mechanism does that!
Lucky me, there were libraries available, for mail, JMS, Kafka, logging and so on. Also implementing things in shittier way than Spring is difficult feat to achieve for my modest skillset.
However there were some impossibly complex requirement like thread pool and with great effort I was able to found a solution in standard JDK like :
> It is not an accident that things like ruby on rails are popular.
Now if we could have that without the magic (neither from annotations nor from open classes), and with strong type safety and proper sum types... That'd be great!
> I have a dozen or so microservices supported by team.
Why do you need a dozen of microservices? Why not to use role-based monoliths? Why not to keep your "microservices" as independent modules, pack them as one app and let such app to configure itself with proper set of services and dependencies according to the config or CLI parameters?..
Just a developer there. So not calling shots on overall architecture. And yes we do not need probably 80% of that crap but not in position to make them see reason.
I'm in an enterprise and have successfully lobbied people to use anything other than Spring. Such organizations and teams while rare do exist so don't give up hope! (or just move to a more progressive org)
> I'm in an enterprise and have successfully lobbied people to use anything other than Spring.
I was in a team that used Spring Boot for a greenfield project. The documentation was great, there was tons of help of Stackoverflow (as it's Spring) and the consideration given to testing was first class. Deployment was also easy, as we just created a fat JAR. No application server necessary.
I have also been in multiple organizations where Spring was used, including "modern" Spring Boot and greenfield projects, and people who knew every nook and cranny of Spring.
I don't agree with any of the things you bring up.
Spring documentation is and has always been poor and the sheer volume of outdated documentation (let alone ways to do the same thing) makes it needlessly difficult to find an answer to any given question.
Differences between the real app and real http requests to the app, and using the Spring test application context and Spring HTTP tests, result in tests misleadingly passing when things are actually broken. (or vice versa)
This is different to eg DropWizard where you actually boot the app (no different to how it does in a real env ie no "test application context") and make real http requests to it. (not some watered down fake Spring HTTP test requests)
Ability to deploy a standalone jar without the need for an application server is hardly unique to Spring.
Add in the horribly, horribly ingrained, unidiomatic ways people use Spring (eg sprinkling field autowiring all over the place instead of instead of using constructor injection) etc etc and every codebase is quickly completely ruined vs if it had been implemented in literally any other framework.
But! Fortunately for you, the Java community has made their choice, and it's not going to change - Spring is the default and correct option, and anyone who uses any other framework is just stubborn and wrong.
> Spring documentation is and has always been poor and the sheer volume of outdated documentation
Spring documentation is excellent. I had to learn Spring as a PHP developer, so I put the documentation onto a Kindle and read it. It's also versioned, so you don't need to read out of date versions:
> This is different to eg DropWizard where you actually boot the app (no different to how it does in a real env ie no "test application context") and make real http requests to it. (not some watered down fake Spring HTTP test requests)
Spring Boot allows you to write full application tests that will boot it up on a random port with the @SpringBootTest annotation, as is covered by the excellent documentation
> Add in the horribly, horribly ingrained, unidiomatic ways people use Spring (eg sprinkling field autowiring all over the place instead of instead of using constructor injection)
You can use whichever.
> anyone who uses any other framework is just stubborn and wrong.
Not at all. Spring Boot is just a great solution, that's all. It's got strong support from a company, lots of documentation and first class support for testing. It also allows you to easily swap out different underlying technology, eg. you can switch from Jetty or Tomcat, Liquibase to Flyway.
It's a disservice to persuade businesses to use smaller projects that don't have a comparable level of support, or flexibility.
If you're lucky and the exception happens in your code directly. If not you're gonna have about 30 lines of interceptors and generators and whatnot before you get to your class. If you call ClassA::foo from ClassB::bar you'll get about 5 lines of interceptors between foo and bar in your stack trace. Debugging is also a nightmare in IntelliJ as step-into and step-out will go through all those interceptors.
Debugging bothered me too. But in the end I have configured IntelliJ to skip all the interceptor classes while stepping into. Had to add a whole bunch of classes and packages for that though
I used Spring Boot and just set debug breakpoints, that way you don't have to step into and out-of, you just press "play" and it moves to the next breakpoint.
Another big difficulty is the handling of depedencies, as spring boot is bringing in gprc, jpa, jdbc and countless other libraries. One really needs a dedicated team to figure out all these issues!
Very true! But management is sold on "best practices" from VMWare suits. So any practical difficulty is just an excuse for not learning the latest, Next generation technologies.
It brings in whatever you use. Also, it has a goddamn webpage where you can click together what do you want to use and it will create an initial project for you with the chosen build tool and what not. It hardly gets easier than that.
This isn't true. Spring Boot by itself brings in very little, you can however _add_ GRPC, JPA and JDBC support by adding a library and Spring Boot will even autoconfigure it for you.
IBM WebSphere Application Server took several minutes to start or stop. Deploying war file took another 10-30 seconds. And you had to restart application server sometimes.
Spring Boot application with few controllers starts in 2 seconds on my outdated laptop.
Spring is lightweight, compared to old tech.
Not the most lightweight, that's for sure. Simple Java web server which uses socket API to server requests, starts in few milliseconds. That's the bar.
Spring Boot is not the same thing as Spring, and is indeed recapitulating all of the mistakes of EJB (I guess it's been long enough that the new generation of developers doesn't know about the problems). You can still use vanilla Spring though.
> Spring Boot is an opinionated way to configure Spring applications.
If by "configure" you mean "make arbitrary changes to the behaviour of". Spring Boot adds a bunch of spring-boot-specific stuff that can't be replicated in vanilla Spring and isn't supported for use outside Spring Boot (e.g. @ConditionalOnMissingBean and friends are explicitly not supposed to be used in non-boot Spring configurations). This is a long way away from just sugar for an ordinary Spring configuration.
> Which mistakes is it repeating?
- Huge and incomprehensible
- Components can refer to other components in ways that are completely invisible in the code
- No way to understand your application's behaviour by just looking at your code, because it can vary drastically depending on the things that are instantiated by the container at runtime. (In EJB this was container-provided services, in Spring Boot it's configurations that are automatically instantiated if they're present on the classpath, without the application ever referring to them at all)
- In practice applications depend on implementation details of the framework and cannot safely upgrade or migrate
Well, Spring has multiple fundamental problems. They've chosen wrong language and wrong techniques. Runtime metaprogramming is sick and slow.
Though that doesn't mean that anything is wrong with JVM as a platofrm.
spring-core can be replaced by, essentially, several hundred lines of LoC: https://izumi.7mind.io/distage/index.html And in fact these lines can do lot more than Spring.
Annotations are a band aid. They easily move what otherwise were compile time errors into runtime errors. The advantage of using them is that you have to write less (repetitive) code.
I prefer code without them. They add magic. I dont like magic in my code.
I honestly think the big issue here is using Java for these use-cases. I know that sounds flame-baity, but I'm being sincere.
Java is a very primitive language. For the vast majority of its life, it's basically been C + basic classes + garbage collection.
As a result, it's very verbose, which is totally fine for a low-level language. But, when building large, high-level, business apps, it's just a weird fit. I think that's why we see all of these annotation-heavy band-aids on top of Java (Lombok, Spring, JPA, etc)- it's because Java is actually not the right tool for the job, but instead of migrating (or inventing) a better tool, we just sunken-cost-fallacy ourselves to death.
I disagree here. Having GC, VM, streams, big stdlib, makes is quite highlevel.
It's not very terse (like Ruby maybe), but modern Java is terse enough.
To keep a language small is a good thing: less to remember, easier to join the team. Go, Elm, Reason/ReScript, LISPs all go that route.
Java misses some things badly. Like being able to have a reference to a method (Jodd has a library fix for this). Or like sum types and pattern matching.
But I'm more bitten by features that Java has than what it has not. Overuse of Exceptions (instead of sum types) and Annotations are my biggest pains.
You see a lot of Java's shortcomings properly being addressed in Kotlin. Like the getter/setter story. And "standards" like Bean and XML config have given Java a bad rep.
> I disagree here. Having GC, VM, streams, big stdlib, makes is quite highlevel.
I used to think that, too. I probably wont't convince you otherwise, and it really doesn't matter how you or I categorize the language, but I think a solid argument can be made that Java's abstraction power is almost zero, especially if you consider versions older than two or three years (before records, switch expressions, sealed classes, etc). I also think that the ability to differentiate between boxed and unboxed primitives, no concept of immutability/const, primitive synchronization tools like mutexes and raw threads, etc, make a compelling case that Java is not well-suited for thinking at a high level of abstraction.
Think about how much code it required in Java to create a value type with four fields before records. You needed to list all four fields and their types in the class body, then you need to list all four fields and their types in the constructor signature, then you need to write `this.foo = foo` four times in the constructor body. Then, depending on your conventions and preferences on mutability, etc, you'll need to write getters and/or setters for the four fields. Then you need to write a custom `equals()` implementation. Then you need to write a custom `hashCode()` implementation. Then you need to write a custom `toString()` implementation.
I hope you don't have to update that class, either, because forgetting to change your `equals`, `hashCode`, and `toString` will cause bugs.
There's basically no universe where you can convince me that this shouldn't be considered low-level programming.
> To keep a language small is a good thing: less to remember, easier to join the team. Go, Elm, Reason/ReScript, LISPs all go that route.
I agree! Small/simple is great. But look at how expressive Reason/ReScript/OCaml is/are compared to Java. Same with LISP. They aren't huge languages with endless features being added on all the time, but they allow for much more high-level programming than Java, IMO.
> Java misses some things badly. Like being able to have a reference to a method (Jodd has a library fix for this). Or like sum types and pattern matching.
To be fair, though, this is not what Java was designed for. Java was initially an object-oriented language. Sum types and pattern matching are not OO. Object-orientation was supposed to be about black-boxes sending "messages" to each other while maintaining their own internal state and invariants. In "true" OOP, you wouldn't have a sum type, because you'd have an object that would exhibit different behavior depending on the implementation.
Granted, we're moving away from hardcore OOP as an industry (thank goodness). But, I'd argue that the "problem" isn't Java's lack of sum types and pattern matching, but rather that we're trying to make Java into something it isn't. We should just use a different tool. I'm not in my garage trying to attach a weight to the end of my screwdriver to make it better at driving nails- I'm going to my toolbox to grab a hammer, instead.
Agreed with many points. So Java is then somewhat in the middle.
OTOH lets consider Rust. It is in my book a low-level lang, close to the metal (hence Rust?). It has a muuuuuuch better feature set compared to Java (IMHO). But it is geared at low-level, so no VM and certainly no GC out-of-the-box... In your def Rust'd be a high level lang: which is cool. I like your def :) But I still def'd high level slightly different: more in terms of the ability program close to the machine, or more in abstractions.
> Sum types and pattern matching are not OO.
Traditionally not often found in OO, but otherwise verrry much compatible with OO.
> In "true" OOP, you wouldn't have a sum type, because you'd have an object that would exhibit different behavior depending on the implementation.
I think this is more about tradition than "trueness". I cannot return an Either<Error, Result> from Java. That sucks. Many have used Exceptions to fix it, but that suck even more. I'd say OO is compatible with sum types.
> But, I'd argue that the "problem" isn't Java's lack of sum types and pattern matching, but rather that we're trying to make Java into something it isn't.
This always happens. And some langs are better suited for that than others. I work on a Java codebase currently and welcome those features, and actively consider moving the whole show over to Kotlin. Kotlin to me is like a typed Ruby. And in Ruby many libs are in C (in Kotlin then many libs'd be in Java).
I think OO and FP bite eachother. You cannot have both. See Scala. It becomes way too big as a language, and lack idiomatic ways of doing things. But one can have a lot of FP in an otherwise OO lang (see Kotlin for instance).
the pernicious thing about spring is there appears to be 15 different ways to do the same thing. Everyone's idea and enhancement request was thrown in. Plus things got left in that should have been deprecated after better ideas came along or the java language improved to allow new techniques.
I'm glad someone is working on a light weight replacement to spring. I had some ideas on a light weight DI framework but never got around to it.
I use http://sparkjava.com in my hobby project. It mostly does what I want, but I had to hack it a bit to be able to stream responses. It's also crazy fast and about as lightweight as these things get.
Spring is certainly a divisive topic, and I think it's hard for people on different sides to fully understand each other's experiences.
I have used Spring for years. Yes, there are some things I don't like about it, for instances Spring Boots overeager auto configuration, but it provides an unparalleled level of flexibility and productivity. I have never encountered a behavior in Spring that I have not been able to read the source and figure out what's going on and then change the behavior to be what I want. Spring is absurdly flexible and you only need to use the parts that you want.
A few years ago, I decided to try an alternative and wrote an app in Vert.x with no Spring. It worked fine, but it was a hell of a lot more work than leveraging the Spring ecosystem. I later rewrote it using Boot, and it works better, is easier to understand, and uses less code.
Have you seen Spring Data JDBC? It's such a good idea that saves so much boilerplate and I'm not aware of anything else like it. It threads the needle between rolling your own SQL and descending into the hell of a full on ORM.
Anyway, the closets I can come to understanding why people hate Spring so much is to consider my own opinion of Rails. I don't like Ruby and I don't like Rails. I hate all of the magic and I don't want to learn it. But, I'm sure, like Spring, it's enormously productive if you do understand what it's doing and how to use it.
I think you hit the nail on the head with your reflection on your attitude with respect to Ruby on Rails.
From my point of view, Java is an anemic language, and the "cure" appears to be to introduce a bunch of annotation-magic frameworks (Spring + JacksonXML + Hibernate/JPA/JDBC/whatever + Lombok?) that each have their own magic and inconsistencies, to the point that your Java code is more of a configuration file than actual logic (which sounds great), but with the downside that you don't actually know where anything is actually implemented and have little idea about what can fail and where.
As a "polyglot" dev, I just don't have the time or patience to learn all of the magic on top of the language itself.
On the topic of Vert.x, it's definitely a different philosophy than Spring, as you experienced. I'm honestly not sure what domains Vert.x would be superior in, but it seems like it's way overkill for your typical mostly-crud backend app. Vert.x is less of a framework and more like a "build-your-own-framework" toolkit.
Spring Data JDBC is, by default I believe, backed by a full on ORM, that being Hibernate.
I'm open to different opinions on this, but I dislike Hibernate because of the complexity and the pains it causes when trying to do simple things. Hibernate, and Spring's use of it, is a leaky abstraction. When running into bugs, just trying to use a flow like, read sql row to POJO -> update POJO -> Save POJO to DB, using Spring JPA repository interfaces, I find myself needing to know about Hibernate internals, like the persistence context, how it relates with transactions, when objects are merged vs saved vs are they already in the persistence context or not? Plus Hibernate docs suck in my opinion.
One time we hit a bug in Hibernate. This was within the last two years, using a newer version of Spring Boot. We read a row from SQL in a transaction. Later in time, in a whole different Transaction, we read the same row. We read it with an annotation on the query method, "@LockType(PESSIMISTIC_WRITE)". We were using MSSQL and this sends table hints like "(updlock, rowlock, holdlock)". So essentially we wanted exclusive access to this row for the length of the transaction. But the data we were getting in the row didn't make any sense? We could see the sql query with the table hints hitting the sql server, but Hibernate was giving us a cached POJO!? If we "evicted" the pojo before we queried then it worked right. Again, this was at the very beginning of a fresh transaction. Wtf.
I haven't really touched Java in a while but I don't get why you'd want a lightweight DI container.
You can just build your object graph and pass dependencies manually if you want a lightweight approach, no? That's just the way people do it in most languages.
I think there are a lot of Java developers, that have just never worked without a DI framework, and just don't have a grasp on just how simple it can be to write code without one.
As someone who hated Java, used it for a few years, and now occasionally misses it...
I only miss DI. I miss being able to say "this system depends on these external things" and having a consistent, convenient way of sharing/swapping/testing those components and dependencies.
The solution in other languages? Unstructured globals, deep argument passing, or monkey patching with mocks?!
Yea, I can write simpler code without DI... By ignoring a bunch of stuff.
When you have lots of things-that-create-things-that-create-things, this gets tedious really fast. DI frameworks exist because they result in a lot less code that does nothing but pass dependences along.
This reminds me of SQL/ORM debate. "Just use SQL!" Sure, until you get tired of typing the same SQL over and over and realize you can cut out most of that crap by adding an ORM.
But how do you handle configuration then ? At some point you want a user-facing UI where the available features (which are generally classes) are listed and the user can choose the feature, say which log backend is enabled, without having to change code - that's the whole point of it. (And the most tedious code to write by hand - a complete waste of time)
In the main method, then you can pass the configured values wherever you need to when new-ing classes.
> At some point you want a user-facing UI where the available features (which are generally classes) are listed and the user can choose the feature, say which log backend is enabled, without having to change code - that's the whole point of it. (And the most tedious code to write by hand - a complete waste of time)
I consider DI a valuable pattern, but I've never experienced anything close to this need.
Which is the standard way to do DI in Spring as well? It will be just called by reflection instead.
But frankly, how will you call that new if it depends on a class which is a singleton, another which has some more complicated scope so it may or may not have to be reused? DI is not only about calling new..
Is what you're thinking of equivalent to deep argument passing? I've seen it done where you pass around a global Factory object that can provide dependencies. It's basically rudimentary DIY DI.
It's really very simple, no you don't need to pass around a factory object.
You just have a class/classes that construct/wire all of your singleton objects and passes the required dependencies into their respective constructors as necessary.
Here is a contrived example of what the wiring code might look like for a web app that uses a database.
public static void main(String[] args) {
MyConfig config = readConfigFile();
DatabaseConnection dbConn = new DatabaseConnection(config.dbHost(), config.dbPort());
UserDao userDao = new UserDao(dbConn);
UserController userController = new UserController(userDao);
List<Controller> controllers = List.of(userController);
WebServer webServer = new WebServer(config.listenPort(), controllers);
webServer.runAndBlock();
}
Yep. Once you get too many arguments what you do is usually to create some kind of Context class that bundles all of them and just pass that on everywhere.
I'd say that the only one of your listed solutions-in-other-languages that is actually a valid solution is deep argument passing.
And I fail to see why it's a problem. If your FooService depends on a BarService, which depends on a BazService, and BazService needs a database connection, then that means your FooService really does also depend on a database connection. Hiding that information, to me, seems like a mistake. Can you articulate why one would prefer not to have FooService explicitly require that database connection, or am I inadvertently arguing against a straw man? If so, please correct me, because I'm asking sincerely.
Of all the time I spend thinking about my code and writing code, I truly can't say that adding a dependency and having the compiler complain until I fix a bunch of constructors has really caused me that much grief. And I'm not going to pretend that it has never been the case that I've had to fix 20 constructors.
Ultimately, I think thisnis going to come down to preference.
I would prefer not to have to fix 20 constructors.
It's tedious and time consuming. The intermediate classes that _do technically depend on FooService because BarService does_ - the intermediate classes don't care! It clutters the code everywhere else for minimal benefit.
Manually, you see all your dependencies just shy of main where the binary initializes them all and starts passing things down. In DI, you have a module file somewhere with them all.
(As a clarification, in case it's needed: I obviously didn't LOVE it when I had to update 20 ctors after changing a somewhat fundamental "service" to need a new dep. My point was that, even as painful as that was, it wasn't that bad and it's usually much less bad than that.)
I guess the (philosophical) difference comes to this statement:
> The intermediate classes that _do technically depend on FooService because BarService does_ - the intermediate classes don't care!
I can definitely understand what you're saying there, but it's interesting to me that I don't see it that way. I think I'm just less pragmatic and more... "academic" (?) about how I read and understand my own code. If X depends on Y and Y depends on Z, I'm comfortable with X explicitly depending on Z because I imagine "inlining" Y's functionality in X. Either that or you turn Y into an interface and then X only depends on IY. But, my brain just likes the explicit continuity I guess.
The solution in other languages is to use a DI framework written for them. Which one doesn't have any? In .NET, the basic DI interface (imports/exports etc) is even part the standard library as System.Composition.
You say that, and I usually agree, I mean, constructor args are the simplest form of DI.
But then, working in a complex codebase, I introduce a new dependency that is instantiated early in the tree, used two disparate classes rather deep in the tree, suddenly I'm changing 10 different constructors just to get the new dependency where it needs to be.
The tree of constructors is where DI shines as an alternative.
That REALLY depends on the size of your codebase. When it’s small, no need for a DI framework. But when it grows large, it becomes quite a pain, and a DI framework is nice, eliminates a bunch of boilerplate with every code change.
A good DI framework just saves you from having to spell out all the glue code; or at least minimize that. DIY dependency injection is indeed a useful skill to have with other languages. Unfortunately, it's not what a lot of people do with other languages because they simply don't know that it would help them.
Particularly in the javascript world there seem to be a lot of people struggling to write good, testable code mainly because they make the rookie mistake of not separating their glue code from their business logic. Basically they have bits of code that initialize whatever and they need to put it somewhere and it ends up in the wrong place and before you know it, it becomes impossible to isolate any functionality such that you can actually test it easily without booting up the entire application. Add global variables to the mix and you have basically an untestable mess.
I still use Spring (but very selectively). They've added multiple styles of doing DI over the years, which is confusing. The latest incarnation of that uses neither reflection nor annotations and is very similar to the type of code you'd write manually if you had the time to clean it up and make it nice to use. Another benefit is that it enables native compilation, which with the recent release of spring-native is now a thing people do. Spring is large and confusing but the DI part is actually pretty easy to use. If you've used Koin or Dagger on Android, it's similar to how that works.
I've used Spring DI. I understand the argument for it, when building bigger applications, though it invariably brings its own complexity too.
What you say about compile-time DI to allow native images makes me feel like we've almost come full circle. I'm still not convinced you need automatic DI at all for smaller services.
Why do "static references become a tangled mess"? In my (limited) experience with runtime DI libraries (albeit in Go) they turn clear, IDE- and debugging-friendly code where the compiler tells you at compile time if you got it wrong ... into a hard-to-debug magical soup.
With static, using-the-language dependency injection, isn't the question of "how does ABC component get access to DEF?" answerable with the normal IDE/language tooling, rather than some magical library's way of doing it? You can just find the calls to a constructor and look at the arguments.
My experience is based on my bad experience with runtime DI libraries, and is definitely biased against them, but I must be missing something here.
There are lots of reasons why static references are undesirable, but some of the more serious are:
* Static dependencies make testing harder, no question about it. This is mediated in dynamic languages like Ruby by mocking statics. While you can actually do this in Java with Powermock, avoiding mocks entirely is even better. If you can't use a real object, use a fake that implements the relevant interface.
* Statics mean singleton, and that invariant often changes as a product matures. It's very easy to go from "the database" to "a database", and when you have 500 places getting "the database" it's very hard to make that evolution.
* Statics make it very hard to maintain module boundaries, because every static is its own exported interface. In a long-running project, binding tends to get tighter and tighter as every module reaches out for the statics of other modules.
Sure, folks can write bad code with DI systems too. And I'm no fan of Spring - not because of the DI, which is fine, but because of the need to wrap everything else in the universe and now you have to understand both how the underlying thing works and the way Spring changes it. But something like Guice or Dagger is just the right amount of glue to hold a system together, without getting in your way.
Just a note: I overloaded (excuse the pun) the word "static": I didn't mean the "static" keyword, but "statically compiled/typed". So it doesn't mean singletons, just that you pass dependencies as explicit arguments to constructors and functions.
I do not understand what distinction you're making. In the world of DI, you still have typed constructors and factory methods. It's not like Guice turns Java into Ruby. The only difference is that you don't have to chain together constructor boilerplate - in fact, the static types determine the injections.
Do you object to passing interfaces vs concrete types? That is a wholly orthogonal concern; you make the choice to extract interfaces with or without DI.
As a Java developer for all my career here is my take. In Java world there is this cultish cottage industry of "frameworks" for all sorts of work. Most Java developers are not expected to write plain code with JDK standard + some external libraries. Creating an object via "new Obj()" might cause programing universe to collapse so DI framework is must for enterprise Java developers.
If I were to tell at work that Go has inbuilt http server where we could implement a few handlers and have a basic service running. They would not be shocked that a http listener could be this simple but rather ask "Does Go bundles "weblogic/websphere/tomcat/netty" server with it or else how can it work? Same with testing, no understanding on how, what is to be tested but everything about "JUNIT/Mockito/Mockster/SpringUnit" or whatever.
There is no requirement for understanding basic concepts for testing, client/server, dependency, error management etc. So even basic functionalities are understood in terms of a branded framework. This is their main frame of reference.
Just to echo this is similar to my experience. Java development culture that I have known in the work place is extremely coddled by their frameworks.
It is hard for them to open the terminal and execute their application JAR from the command line--only ever from the IDE. Oh wait--they need Tomcat/Apache & a few hours of dealing with classpath issues.
That's just a problem with developers who do Java as their 'nine to five' job and don't have any interest or passion to really find out how stuff works. I've met a lot of those people and there's no reason they can't contribute if the project is set up to accommodate it.
On the other hand there are the enthousiasts (like you I presume) who like tinkering and using the language to the fullest. Any successful project needs at least a few of these people, but they can also go overboard by building a lot of custom functionality where any standard library could have been used.
While I'm also an advocate for increasing knowledge for the systems you're working with it's no 'sin' to use some libraries. For instance: for your HTTP server example, it's quite easy to just listen on a socket and respond to a request. But you want parallelism, so you need a thread pool. And queues, configuration and error handling. That will escalate quickly so why not pick whatever Java servlet implementation which has most of the complexity and - more important - is already production tested so it won't fall over when you deploy it live. And then there's stuff like OpenID connect or SOAP (yes, still exists) where you can 'plug in' an implementation on some servers so you can get work done instead of worrying about getting all the implementation details right for some complex protocol.
> but they can also go overboard by building a lot of custom functionality where any standard library could have been used.
Well I am kind of recommending using standard libraries. And servlet implementation I am using embedded tomcat as I mentioned in other comment. What I am not doing is generating gratuitous scaffolding of dozen packages and innumerable classes because that is the "best practice".
Just to clarify it is not my opinion. It is the groupthink of enterprise Java programing where reading Java tutorial itself would be obscure thing. Everything has to be looked from "framework" perspective. Framework says 'new' is bad so it is bad, dependency has to be constructor/setter injected by DI container so that's how it has to be.
In my experience most DI just interferes with being able to use the IDE to track down instantiations. Ive worked on these projects that basically have these fancy runtime things to answer questions that could be answered by the IDE if it werent so obscured. I remember one project we had a fancy thing to generate a graphviz graph, and it was like neat, but we could just use find all references if we just called new.
The dumb thing is most of the time only one type is ever injected. Its all hypothetical flexibility which has a cost but no benefit
> I remember one project we had a fancy thing to generate a graphviz graph, and it was like neat, but we could just use find all references if we just called new.
Ha. Calling `new` would either be an absolute enterprise Java sin or an obscure aracana. Some people are quite proud of the fact of converting compile time errors to runtime exceptions. Because you know "best practices" and all.
It definitely has a benefit at scale. I’m not sure what application were you developing, but the amount of time a single instance was changed into an interface because the client wanted the n+234th little change in this special star constellation.. with DI you don’t have to write any more code, you can even use different implementations per environment (@Profile), so this is not accidental complexity in most cases. Sure, if you need a 100 lines web server that prints hello world it is an overkill, but the correct tool for the job..
"static" in java DI can refer to setting global variables with singleton instances. E.g. java logging libraries usually do this so that you don't have to DI everywhere you want to log. In Go, some packages do this like flag and log. In Rails, this is so common that it replaces DI entirely, but I usually didn't feel like rails suffered from it.
I think what you are referring to is just manually doing DI. I.e. you defined constructors that accept dependencies and then call them all in a main function. I think this is tolerable if your codebase is structured for it. In typical java codebases, it gets ugly really fast. IMO this is caused by a general proliferation in the number of classes (due to class-per-file among other reasons), as well as a tendency to never use "static" DI. As an extreme example, if you needed to inject a logging dependency, then almost all code would need to be part of the DI graph. In a typical web backend, you might DI the sql connection pool. This causes basically all code to need DI since it either uses sql or has a transitive dependency that uses sql. IMO injecting the connection pool is not useful since it's not useful to write tests where you inject anything other than a real sql connection.
Ah, that explains the confusion. Yeah, I didn't mean static as in the "static" keyword in Java / C++, but as in specified in the statically-typed code. Defining constructors that accept dependencies -- exactly. Ah yeah, I can see how Java exacerbates things here with the one-class-per-file rule -- ugh.
Go doesn't require one class (well, type or struct in Go) per file, and has much more flexibility in how you build packages as a result. I think it's a good thing that dependencies like the logger and the database are passed around explicitly: I've learned the hard way that "explicit is better than implicit" even when it means a bit more boilerplate.
This, it’s really exhausting to read this never ending wheel reinvention. Sure any one can use simpler non-spring frameworks, and other “non standard” frameworks and libraries for 1/10 or 1/100 of the functionality, and get 10-100x the bugs and much less or zero support. But we need netty! And then when you add thread pools, jdbc, logging, etc? Yep you’ve reimplemented spring. Just use spring, spend the time to learn it and reap the rewards.
As someone who dealt with a ton of Spring in the recent past, I completely disagree.
First of all, thread pools are part of the standard library. Spring adds little to no value on top of it.
Second, reinventing some of that stuff is absolutely worthwhile, because Spring's library design/implementation is not very good.
Finally, when I had the opportunity to start a new Java project, I opted to not use Spring. I finally had a server that started up fast, took less code than a Spring project, was easily navigable in an IDE, and whose code was generally easier to follow. It was also easier to write tests for.
One thing I learned is that people seem to underestimate just how thin Spring's abstractions are over stuff in the library, servlets, etc. Most of what Spring does is wrap things in a bean interface so they can be used with DI (which is something I’ve never found any value in).
Well you are missing one of the great feature of Spring framework: Converting compile time errors in to runtime exceptions.
Jokes apart you are absolutely right about non-spring based services. I did same using plain Java + embedded tomcat for some services. No cargo-cult like endless decorative packages and classes. Exactly same result as you observed. Less code, fast to start and vastly improved error management.
Same here. I've gotten rid of all that stuff, it's just layers and layers of indirection that contribute nothing.
One rule that has also helped me a lot to keep my code clean and make it easier to debug is to fail as much as possible in the constructor. So when you call new MyThing(), you will either get a usable object or it'll throw an exception. Further method calls are expected to work. Of course this is not doable for everything, but it sure helps keeping the methods clean and not have them throw various exceptions.
Could you share your Spring/Spring Boot alternatives? Are they Java based? I'm doing backend stuff with Spring Boot and I would like to test alternatives. Spring boot is not that difficult to work with, but I would like to test a "simpler" solution.
I've had similar experiences. A few years ago, I wrote a small service in plain Java, no frameworks as part of a quick change to improve performance. It worked and we all moved on. Later it was converted to Spring Boot and it slowed way down.
> But we need netty! And then when you add thread pools, jdbc, logging, et
java.util.concurrent has threadpools and pretty damn decent at that; jdbc is a part of very standard jdk, logging is part of java.util.logging. Why do you need netty (which is not a part of spring either way)?
In over 23y of working with Java, I have never needed spring.
Agreed. Stuff like this feels like magic for magic’s sake, and as someone who has had to operate services that use these DI frameworks, they are a big pain.
I read all of the documentation for the service that I operate--per my other comment (https://news.ycombinator.com/item?id=29973282), often times things aren't well-documented and it's crucial to be able to look at the source code to figure out what something does (e.g., how is a configuration parameter used? what are its valid permutations?); however, when the source code is obscured by gratuitous complexity then it imposes a high cost on the user and in the case of DI frameworks, that gratuitous complexity comes with no discernible benefit (a car offers me something of value to justify its learning curve). Personally I'm of the opinion that a person shouldn't have to be a seasoned Java developer to use so many tools that are implemented in Java (or any other language, for that matter).
Operate means “run the service”. If you need to configure things which aren’t well documented, it’s nice to be able to look at the code, but the DI frameworks obscure the code path. This is pretty straightforward; no idea why this would seem like flame bait—I didn’t even realize this was something people held deep emotional attachments to.
Plumbing the construction of your object graph manually does not have a particularly high cost/benefit - most of your services are singletons that depend on each other, and it's already clear enough which ones depend on which others without repeating yourself. A very basic "here's a bag of classes that depend on each other, wire them all together and then let me pull out the instances by type" is often worthwhile for avoiding all that boilerplate, even if it does break the rules of the language a little. Something like Picocontainer or even Guice is pretty good IME.
Not using Java but generally in OO languages I ended up passing forward dependencies in grouped and themed classes like LoginDependencies, InboxDependencies etcetera. Everything under an Interface so you just mock whatever you need. Never ran into serious issues.
Of course logging might be static but “true” dependencies like networking classes never are.
I want lightweight, and compile time. But I'll take compile time only if need be.
In terms of lightweight, I have never needed to use the @Alternative binding [0]. Nearly all of my needs are met by being able to define "this is a singleton, this is a dependency that you should always inject a new instance of, and this is a property."
But it's surprisingly hard to find DI that limits itself like that. The DI in Micronaut and Quarkus are probably the closest to my ideal. Compile time, and only implement a subset of CDI etc.
I really like the Go-like simplicity of these libraries, without the cursed architecture astronomy from the 2000s.
In general it's interesting times for Java. With all of language improvements from Kotlin/Scala, and upcoming Go-like concurrency it really feels like a renaissance for the language.
Project Loom’s virtual threads (without dedicated OS threads and stacks), which will hopefully relieve devs from manually doing a CPS transform of procedural code into chains of futures for thread pool workers to complete.
I'd say that first Java renaissance is Java 5 with generics. Second Java renaissance is Java 8 with lambdas. IMO third Java renaissance will be with re-introduction of green threads.
I wonder if someone can recommend a lightweight http server library? I like Javalin but it's based on Jetty which is a fully JavaEE compliant framework and includes support for things like OSGI which I don't need. With the whole Log4j situation, I'm re-evaluating some the libraries I've previously relied on.
Netty copies the response body when sending to each client, so it's not as lightweight as I've found. For streaming large response bodies, it does not work well. I haven't found a good Java alternative yet (probably will switch to C++ and uWS...)
Netty core is about as close to the metal as networking gets on the JVM.
It's abstractions are built over a zero-copy capable byte buffer, and there is generally a lot of care taken to avoid copying where possible.
I haven't used the websocket codec, but I'm sure the maintainers would welcome a patch that removes unnecessary copying.
Quote:
"But how does Netty do things so fast ? One of the reasons is that it is using native memory pool to store network buffers. If you did some file reading or network action with Vert.x you probably used io.vertx.core.buffer.Buffer class. This class is actually a wrapper around Netty io.netty.buffer.ByteBuf class. Why am I telling you all this ? Let assume that you have a service where clients are downloading 20Mbyte files. Netty will have to allocate at least 20Mbyte for every connected client."
Although this may be an issue with how Vert.x is using Netty. I have to dig into it more.
Looks nice and clean. It does seem to be maintained by a single person (at least the JSON subproject [1]) which will be a major turn off for adoption by an "enterprise"
First thoughts: the JSON subproject seems to be very unprincipled. The documentation documents general usage through a few examples, but it doesn't really give you a good idea of the semantics of the library. It appears to scan your objects using reflection for things that it determines to be fields (what are the criteria?), but for some reason does not serialize collection types by default because "This plays well with some 3rd party libraries (like ORM) where collections represent lazy relationships". The library is configured by modifying the state of global objects which is just a disaster waiting to happen.
This is great. Java BADLY needs to shed weight and verbosity and in general just catch up with the times.
Having used not only traditional Java and Spring (including "modern" Spring boot) but also alternatives, like eg DropWizard, I MUCH prefer the alternatives.
DropWizard in particular seems to me a more neutral collection of some of the best tools for each job, and it's both simple and easy.
Spring is just Spring, Spring and more Spring, and while it's "easy", it's not simple- there's a lot of magic.
I'm glad to finally be in a team where people are open minded enough to look outside the Spring bubble. TBH these days, we don't even use Java anymore, we use Kotlin + Arrow which is amazing.
Java’s verbosity/abstraction problem is unfortunately not due to the language or libraries at this point as much as it is the programmers - the hardest thing to change. You need only to look around this thread to see Java programmers who can’t imagine writing a useful application without a DI framework that supports runtime implementation swapping, or aspect oriented programming.
Agreed! I lost patience with the backwards Java community long ago, there's no arguing with them, they refuse to even consider trying anything other than what they're used to, so what's the point. Better to move on and leave them to it.
One thing that gives me hope is that the actual language designers have the right view on it, and I think are guiding the community in the right direction without explicitly condemning the way a lot of things are currently done (which would be a political nightmare).
For instance, records are a step away from mindless getters and setters - but rather than just add the syntactic sugar of properties, they introduced immutability as well.
For sure, it's great that people like Josh Bloch, Brian Goetz (and many others) have been very aware of and trying to address all the problems and endorse (and enforce) solutions to them (for decades at this point)
but as much as I hate to say it it feels like it's a bit too little too late :/
and there's still this bizarre situation where seemingly most of the Java community is still living in the 90s
Is there a "Getting Started" guide or a list of examples anywhere? I'm on mobile so may have missed them. All I could see were links to the separate component docs.
A lot of this looks like functionality offered by other, more popular libraries. Jodd JSON looks functionally (and syntactically!) similar to Jackson, but Jackson has a lot more users:
Literally every common enterprise problem has a java library over a decade old. Jodd seems to be aiming to be lightweight and fast, not solve new problems necessarily.
Why exactly? I think the two concept is very meaningfully merged. For simple programs you don’t need multiple namespaces so you have a single folder, for more complex one, tree hierarchies are good for both namespaces and folders.
the `<Book>` generic type doesn't translate to anything at run time, so you cannot actually parse the json out as a book class, unless you already knew it was going to be a Book. The parse() method cannot be generic over all possible inputs as is - unless the user also pass in the `Book.class` parameter!
Parent just missed the new keyword, and generics can work based on return type as well with the above syntax. It has nothing to do with erasure, we are at compile time.
To cope with all this, i wrote this little project: https://github.com/MoserMichael/ls-annotations
It's a decompiler that is listing all annotations, so it becomes easier to grep a text file in order to detect the dependencies between annotations.
it is using the asm library https://asm.ow2.io/ to inspect the bytecode files, so as to extract the class signature, along with the reference and declaration of annotations included in a classpath, or class files included within a directory structure. A limitation/feature is, that it is inspecting already compiled bytecode files.