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 a mistake, I'm not calling it useless. Just like e.g. null isn't useless, it's considered by some as being a mistake. Nor am I advocating for more keywords, I don't know where you get that idea from? My point is something like a transaction (just picking one from your list here) can just as easily be achieved by code if a language supports the proper constructs (like Kotlin does). e.g.:
fun someMethod() {
withTransaction {
//do within transaction
}
}
This reads clearly, and most importantly, doesn't break. Unlike annotations where you have to rely on proper setup for the method to be proxied and be performed within a transaction. Same goes for validation, security, etc.. Forgetting to properly jam your class through an annotation preprocessor leads to code actually performed without the proper transaction, security measures or validation. Do you understand the problem I'm trying to describe that plain old code doesn't have?
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.
That's exactly what I mean. Annotations like `data` differ because it instructs the compiler to emit extra (byte)code. That code is just code and won't behave differently from whatever (jvm) language you use it. It are instructions for the compiler to do some extra work. Those are really helpfull because it makes our lives easier without the chance of being misused of not run with the appropiate accompanied framework.
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.
Yes I know what your take on it would be, but this is a discussion forum on which I'm offering a different perspective. :) So don't get me wrong here, I'm also a big proponent of consistency. I just think the two types of annotations are simply 2 different things and shouldn't both be considered/called an 'annotation`