4 ms·

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

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.

xienze 6y ago
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.
- doliveira 6y ago
  Is turning Java into a dynamic programming language really the way to go to fix this, though?
  - masklinn 6y ago
    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.
  - xienze 6y ago
    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.
- optimiz3 6y ago
  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.
- grey-area 6y ago
  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.
  - masklinn 6y ago
    > 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.
    - grey-area 6y ago
      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.
- bcrosby95 6y ago
  > 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.
  - xienze 6y ago
    > 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.
    - Supermancho 6y ago
      > 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.
      - xienze 6y ago
        > 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.
    - 6y ago
peeters 6y ago
> 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.
- ben509 6y ago
  That's as demonic as "assert" silently doing nothing by default.
grey-area 6y ago
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.
RandoHolmes 6y ago
I actually miss this in C# and wish the .net community had gone in with bytecode rewriting the way the Java community did.
- voxic11 6y ago
  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/source-generators.cookbook.md https://github.com/dotnet/roslyn/blob/master/docs/features/s...
jfengel 6y ago
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.)

xienze 6y ago

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.

doliveira 6y ago
Is turning Java into a dynamic programming language really the way to go to fix this, though?
- masklinn 6y ago
  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.
- xienze 6y ago
  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.
optimiz3 6y ago
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.
grey-area 6y ago
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.
- masklinn 6y ago
  > 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.
  - grey-area 6y ago
    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.
bcrosby95 6y ago
> 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.
- xienze 6y ago
  > 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.
  - Supermancho 6y ago
    > 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.
    - xienze 6y ago
      > 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.
  - 6y ago

peeters 6y ago

> 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.

ben509 6y ago
That's as demonic as "assert" silently doing nothing by default.

grey-area 6y ago

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.

RandoHolmes 6y ago

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

voxic11 6y ago
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/source-generators.cookbook.md https://github.com/dotnet/roslyn/blob/master/docs/features/s...

jfengel 6y ago

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.)