Comment by willtim | Hacker News Reader

Comment by willtim | Hacker News Reader

Parent Full thread

> if you see Spring as existing to correct issues with the underlying Java language, then I'm highly skeptical that you've ever had meaningful experience with either one.

Let's please avoid personal attacks if at all possible. Spring started out with the dependency injection framework and "aspect-oriented programming". It was marketed as an alternative to EJB. Web frameworks and other add-ons came later. If you don't see DI and AspectJ as working around Java's weaknesses, then I encourage you to try a more expressive language.

In an expressive language (e.g. Clojure or Haskell), DI and AspectJ could be, for example, replaced by reifying a program as data and using modular interpreters. One interpreter using mock data, another talks to the database, uses transaction boundaries and logs. This sort of solution is unfortunately just not very practical in Java.

DI is just another name for "passing values to functions". We did it in Java just fine before Spring became so popular and Spring doesn't add that much for this particular way of writing Java code. Of course Spring is nice as a whole, even if huge and much more than DI, but the benefits of using it just to specify lazy proxy singletons using annotations are overblown. Autowiring becomes seductive so you get situations when you still need to test and some devs now have a component class with 10 private autowired dependencies and ask questions on how to test it that lead to in order of awfulness using reflection in the test to bypass 'private' and assign dummy values to the dependencies, using Spring's JUnit test runner and mock beans, rewriting the class a bit to use constructor or setter-method autowires that you can set without bringing in all the spring machinery, or break up the test so it depends on less and individual parts may not even need to be Spring components at all.

In another expressive language like Common Lisp, it has generic functions which 1) let you dispatch on more than just the class type of the first argument (implicitly in Java, explicitly 'self' in Python) which is a feature that by itself removes a lot of Java back-bending and 2) you can specify :before and :after and :around methods to provide the benefits of aspects with the built-in function compute-applicable-methods available to help see everything that might apply when invoking a method with specific arguments. There's also metaclasses which open other doors. There's just a whole lot of built-in expressiveness in the languages beyond the Java and JavaScript ecosystems.

Reply on news.ycombinator.com