> "Runtime annotations are simply a mistake..." There are many, many services that make sense to be applied at runtime such as validation, transactions, auditing, security etc. It's super useful to just annotate a class and get those services. I'm not sure DSLs or language-keywords would be useful for this. For UML, Deployment Diagrams (https://en.wikipedia.org/wiki/Deployment_diagram) may be used to clarifying assumptions about the runtime environment, among other things. So, no I don't agree w/ your comment that runtime annotations are useless or are there just to compensate for language flexibility. I don't think introducing a keyword for such services would be a good idea. It's much easier to evolve annotations than it is to evovle language keywords.
> “Then there are compile time annotations. These are the solid ones because they just lead to code. Code that can be used from any jvm language.”
I’m not sure what you mean here? The consumption of code b/w JVM languages is at the Byte code level, not source code level. Besides, by definition, compile-time annotations are removed by compilers before code is compiled into byte code.
> “So maybe a third option would be to clear about this distinction:
> Runtime annotations: upper cased with a required @ sign
> Compile annotations: lower cased with a optional @ sign”
If you see my recent comments, you know my take on it. I’m a proponent of consistency so just one way of annotating classes would do fine. Conventions to make certain things upper case (constant values largely) are anyways one of the reminents of Hungarian notation (https://en.wikipedia.org/wiki/Hungarian_notation) that, given our modern IDEs, should really die. Though I do make constant values upper case to be consistent w/ the generally accepted Java convention.