3 ms·

This is what happens when people try to add too much "magic." It's a side effect of many things, the most obvious being the lack of the language support for exp

This is what happens when people try to add too much "magic." It's a side effect of many things, the most obvious being the lack of the language support for expressing these types of things. It is the same sort of issue that plagued C++ with the ability to override operators while limiting which operators could be overridden. This kind of annotation hell is indicative of the inflexible and unextensible nature of Java. By the way, I'm not hating on JVM languages. Both Scala and Clojure have a means to handle this issue with grace and without sacrificing the readability of the code.

Morgawr 13y ago
I agree entirely and >This kind of annotation hell is indicative of the inflexible and unextensible nature of Java. This line made me think a lot, it reminded me of this amazing talk by Guy Steele[1], an absolute must for every language developer (or software developer in general, really). It's ironic that he's mostly referring to Java the language itself when he talks about "flexiblity" and "growing the language", where ~10 years later we all know that Java is becoming a messy inflexible deprecation hell. Still a solid talk nonetheless! [1] http://www.youtube.com/watch?v=_ahvzDzKdB0 http://www.youtube.com/watch?v=_ahvzDzKdB0
revetkn 13y ago
I don't know, annotations are what you make of them and can be abused like anything else. I miss being able to do things like this when I'm not working on Java code @GET @Path("/users/{userId}") public Page userPage(@PathParam("userId") UUID userId, @QueryParam("blub-filter") String filter) { ... }
spion 13y ago
To me, it looks like this happens when you can't easily build new things by reusing old ones (in this case annotations). If a developer was able to combine multiple annotations into one easily, they would be better able to express themselves in the typical cases sketchy example: @SerializableTo(name='orders', exclude='json'); @BelongsTo('customer') private List orders; then @BelongsTo is implemented using @ManyToMany, @Fetch, @JoinTable. Can you do that with annotations in Java without rewriting them from scratch?

Morgawr 13y ago

I agree entirely and >This kind of annotation hell is indicative of the inflexible and unextensible nature of Java. This line made me think a lot, it reminded me of this amazing talk by Guy Steele[1], an absolute must for every language developer (or software developer in general, really). It's ironic that he's mostly referring to Java the language itself when he talks about "flexiblity" and "growing the language", where ~10 years later we all know that Java is becoming a messy inflexible deprecation hell. Still a solid talk nonetheless! [1] http://www.youtube.com/watch?v=_ahvzDzKdB0 http://www.youtube.com/watch?v=_ahvzDzKdB0

revetkn 13y ago

I don't know, annotations are what you make of them and can be abused like anything else. I miss being able to do things like this when I'm not working on Java code @GET @Path("/users/{userId}") public Page userPage(@PathParam("userId") UUID userId, @QueryParam("blub-filter") String filter) { ... }

spion 13y ago

To me, it looks like this happens when you can't easily build new things by reusing old ones (in this case annotations). If a developer was able to combine multiple annotations into one easily, they would be better able to express themselves in the typical cases sketchy example: @SerializableTo(name='orders', exclude='json'); @BelongsTo('customer') private List orders; then @BelongsTo is implemented using @ManyToMany, @Fetch, @JoinTable. Can you do that with annotations in Java without rewriting them from scratch?