5 ms·

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 re

by 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

by xienze 6y ago

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