Hacker News Reader

Comment by pmcollins | Hacker News Reader

Possibly unpopular opinion: Java's biggest mistake, by far, was annotations that define behavior at runtime.

So now we have consultingware like Spring where if something isn't working, it could because you missed an annotation somewhere, or put the right annotation in the wrong place. Which annotation? Where? Maybe you'll find out a week from now that you made a mistake, when a customer finds a bug in production.

This took all of the compile-time checking goodness that you got from Java and threw it in the garbage. Now you either have to call an expensive consultancy, read books/manuals about your gigantic framework (fun!), go on forums, etc. You can't just use your coding skills.

I still often use Java for my side projects because I love it without runtime annotations, but thank god for the rise of Golang. I'd rather deliver pizza than go back to the misery that is annotation-driven development in Java.

View on HN

Worth noting that Go has this too in the form of struct tags on fields, which people use to define behaviour like reading from a db or json, and which have similar pseudo-languages stuffed into strings - people are even trying to extend them into structured data now. Madness.

It's quite possible to avoid them of course and I prefer just to use code to instantiate objects rather than learning yet another configuration language attached to fields.

> Possibly unpopular opinion: Java's biggest mistake, by far, was annotations that define behavior at runtime.

Now add to that the fact that if the runtime can't load the annotation class via the classloader, it just silently pretends the annotation isn't there.

That's as demonic as "assert" silently doing nothing by default.

I believe you're right, though I think it's Spring's inversion of control rather than the annotations themselves.

The problem with inversion of control is that if you get it wrong, there is no feedback. All you get is "nothing happened". When it works, it just works, which is great. When it doesn't work, it doesn't work, and "it doesn't work" is practically impossible to Google. Spring had the same problems, worse, with XML configuration.

The solution is exactly as you say: let programmers program. Solve the problem with debugging tools that you already know, rather than introducing a whole new meta-meta-programming environment without any debugging support. (If you attach a Java debugger to a running Spring program to step through the point where it's failing to find your annotation, you will regret it.)

I actually miss this in C# and wish the .net community had gone in with bytecode rewriting the way the Java community did.

The new source generators in C# 9 seem like a good compromise. Rather than rewriting code they can only add code but that ensures some amount of predictability.

https://github.com/dotnet/roslyn/blob/master/docs/features/s...

The alternative is heaps of XML or JSON configuration, detached from the code where it’s used. Consider that if you wanted to inject a bean in Spring XML it requires creating a bean definition that in turn defines all the beans injected into it, which in turn require their own bean definitions, etc. Then you have to declare exactly which field/method the bean is injected into. If you were developing software in the pre-annotations day you’d understand how much that sucks. The annotation approach is much better in comparison.

Is turning Java into a dynamic programming language really the way to go to fix this, though?

Java was already that. The grandparent is just noting what was there before annotations arrived.

Well they're actually being kind, XML was a step up from having the annotations in docstrings. That was infuriatingly bad.

Consider that people to this day still dog Java for being overly verbose, and then consider how much boilerplate (code and XML) is required to make something like a Spring REST controller that includes dependency injection. You can boil that down to basically one small class with a couple of annotations these days. The old way is absolutely dreadful in comparison.

Annotations are great as long as the consuming framework reflects the annotations exactly once for JIT/bookkeeping. Often the people I see who hate annotations are invoking reflection (explicitly or implicitly) in critical code paths.

Is it though?

Why not just use code (generated if required) to read xml or json for each class? That way it is clear, in the source code and can perform other transformations as required.

> Is it though?

Yes. It's what the Java world was before annotations became a thing.

> Why not just use code (generated if required) to read xml or json for each class?

Because it didn't happen that way, because Java is way too verbose for that, and because "imperative declarations" are a horrible thing.

You're describing what was, not what could have been. There's nothing to preclude just having a function on your classes to read from json or db data.

Perhaps the culture is stronger than the language though.

> inject

I see the problem.

The whole point of spring XML was so you didn't have to "write code" to wire things up. Now we're using annotations to replace XML - we're writing code so we don't have to write code. It makes no fucking sense.

Annotation injections are a completely ridiculous turn of events.

> Now we're using annotations to replace XML - we're writing code so we don't have to write code. It makes no fucking sense.

It does though. Turns out that writing XML configuration means you don’t get to take advantage of the context associated with an annotation. I.e., if I put @Inject on method something(X value) in class A, all the context of what type to inject and where comes along for the ride. In XML I have to explicitly specify every single bit of context, and oh yeah, if I rename “A”, “X”, or “something” I better fix that in the XML or my program will blow up. Not a good look for a programming language that already gets grief about being overly verbose! Annotations just flat out make the configuration part of the equation easier.

> I have to explicitly specify every single bit of context,

You still are doing that, just in a less clear way and a less debuggable way. Most other languages get along without meta-languages (there are some frameworks that are spring-like) because being explicit is better than being implicit.

> You still are doing that, just in a less clear way and a less debuggable way.

That’s debatable to a degree. If I put @Inject on a field it’s pretty clear what’s going on just from a quick glance of the source code. By contrast, I don’t know injection of some field happened _unless_ I take a gander at the XML config. And the debuggability of both approaches is the same, the injection manager is doing the same magic under the covers, only the configuration is different.

Wiring up dependencies via XML is indeed a bad idea for the reasons you specify. But if you're going to wire up dependencies in code, you don't need annotations. Java already has a method for declaring and providing dependencies for a class: writing and calling constructors, which is clearer and checked by the compiler.

It's important to understand that spring gets around the wiring problem by being a system for declaring and using global variables. This turns out to be a fundamental waste of time, as the whole point of making things dependency-injectable in the first place was to avoid global variables.

However, every spring bean is a global variable, and every bean reference, whether explicit or implicit via autowiring, is a reference to a global variable. Spring results in bad, un-modular, hard-to-debug, and hard-to-maintain wiring code. Just say "no" to runtime dependency injection frameworks.

You can easily and correctly summarize Spring as follows. Spring tries to solve the problem of "applying parameters to function is boilerplatey" by creating a DSL for declaring and using global variables, because, global variables don't have to be passed around! And yet, ironically the reason we do parameter passing to functions (constructors factory methods, etc) is to avoid global variables.

Spring is a fundamentally flawed waste of time, and it represents one of the biggest mistakes of the Java community.

Reply on news.ycombinator.com