[gf000]

Not really. It has a pretty bare bones OOP (single inheritance, interface), primitives and objects, generics and pretty much that's it.

Newer features fit very nicely and didn't increase the language surface (records are just a normal class with some methods auto-generated, while sealed types are just a restriction on who can subtype an interface -- and yet these give full ADT support for the language that improves readability and type safety).

[jimbokun]

Annotations add a seemingly infinite amount of new semantics. You can’t predict anything with confidence just looking at the code without also studying the annotation processors in depth, which regular Java tools don’t help you with.

[gf000]

Well, that's just metaprogramming.

Also, java annotation processors are strictly "append-only", they can't change code written as is. They may subclass it, or build new classes that make use of the annotations.

In my experience LLMs are more than happy with annotations, especially from the widely used ones (spring/jakarta ee, lombok though it's not an annotation processor, etc).

If you think about it, an annotation like @Path("/endpoint") is very informative for both humans and LLMs alike, being local to what it attaches to. Within an agent, the code serving the endpoint will be immediately visible in the context returned by a simple string search, no need to do another round of "find wherever this codebase registers routes".

[jim33442]

That metaprogramming is how a lot of places end up doing Java, because Java is a bad language that needs crutches like that. Or at least needed until whatever newer version fixed limitations of the old one, but all that old code is still around.

Biggest thing was lack of cooperative multitasking until virtual threads (Project Loom). And much older, lack of lambdas before Java 8.

[Orygin]

Annotations are a scourge. Automagic extensions you have to understand through years of usage.

Go has no such things and you have circled back exactly to the GP's point: "There's a ceiling on abstraction". There is no such ceiling in java ime

[jimbokun]

It’s even simpler to have a “register” method that takes the path specification, the HTTP verb, and a function to handle the request.

There is no case where annotations are superior to the meta programming facilities built into the language proper. Annotations only became popular because Java didn’t have easy syntax for function references or anonymous functions for a very long time.

[gf000]

Lambdas have been available for 10+ years.

Also, hard disagree on "register" method being simpler. A register method is code, while an annotation is a static declaration, ergo data. The former can happen in a helper function, renaming it from "register" to "path", changing/modifying the parameters, or putting it into some while loop dynamically generating endpoints.

At the very extreme it is Turing complete to figure out what endpoints are registered.

[jim33442]

10+ years of lambdas, but you can still tell from new code that the language used to not have lambdas. Plenty of code is older than that too.

The annotations are static, yeah. That's one advantage. I would still rather not do that. A lot of people were happy not to need that anymore in like NodeJS.

[gf000]

I mean, there are bad developers in every language.

And old code continuing to run 10 years later is a huge value of the platform.

[jimbokun]

Time again to learn the lesson of Lisp:

Code is data.

Data is code.

[cryptos]

Project Lombok rewrites code, however it misuses annotation processing.