Why isn't scala.annotation.Annotation sealed?

[Eugene Burmako]

As experience with https://issues.scala-lang.org/browse/SI-6325 shows,
in order to persist an annotation in Scala pickles, it has to subclass
either ClassfileAnnotation or StaticAnnotation - just Annotation isn't
enough.

Therefore I have a question. Why do we even allow users to subclass
Annotation directly, if such subclasses aren't going to make much
sense anyways?

[Paul Phillips]

On Sat, Sep 15, 2012 at 11:26 AM, Eugene Burmako <eugene....@epfl.ch> wrote:

Therefore I have a question. Why do we even allow users to subclass
Annotation directly, if such subclasses aren't going to make much
sense anyways?

There are internal things which subclass Annotation directly.  A few of the more obscure capabilities of scala capabilities of scala can be seen in this test case:

  https://github.com/scala/scala/blob/master/test/files/run/constrained-types.scala

(Look for "keepOnlyTypeConstraints" in the compiler source.) Whether any of this is a good idea, I don't know.

[Simon Ochsenreither]

Hi,

I just dug this thread up, because I had exactly the same question.

Is there any reason why TypeConstraint needs to extend Annotation and not StaticAnnotation?

If there are reasons for not inheriting from StaticAnnotation, we could at least put a @deprecatedInheritance annotation on Annotation itself.

Btw, can we get rid of this “Implementation restriction: subclassing Classfile does not make your annotation visible at runtime.” non-sense?
A) The class is called ClassfileAnnotation and not Classfile.
B) Of course it doesn't make the annotation visible at runtime, that's the whole point of a ClassfileAnnotation. If we had a non-functional RuntimeAnnotation, then I'd understand an error message like that, but we don't.

Thanks and bye,

Simon

[Simon Ochsenreither]

Hi,

Is there any reason why TypeConstraint needs to extend Annotation and not StaticAnnotation?

If there are reasons for not inheriting from StaticAnnotation, we could at least put a @deprecatedInheritance annotation on Annotation itself.

 

I'd like to retract that part. I've looked a bit closer and it seems to make sense. I assumed that those annotations were structured like a GADT, not in the hierarchy they actually were when I wrote the comment above.

• Annotation is basically something like SourceAnnotation
• StaticAnnotation inherits from Annotation and keeps the annotations available during compilation, even with separate compilation
• ClassfileAnnotation inherits from StaticAnnotation and adds the information to the classfile's attribute section as a RuntimeInvisibleAnnotation

This is all reasonable.

So what's basically missing is some kind of RuntimeAnnotation extending ClassfileAnnotation, which writes to the attribute section as a RuntimeVisibleAnnotation.

Btw, is there a reason why the proper flags are not set for annotations? For instance ...

class FooAnnotation extends annotation.ClassfileAnnotation
val fa = classOf[FooAnnotation]
println(fa.isAnnotation)

... prints false!

 

Btw, can we get rid of this “Implementation restriction: subclassing Classfile does not make your annotation visible at runtime.” non-sense?
A) The class is called ClassfileAnnotation and not Classfile.
B) Of course it doesn't make the annotation visible at runtime, that's the whole point of a ClassfileAnnotation. If we had a non-functional RuntimeAnnotation, then I'd understand an error message like that, but we don't.

https://issues.scala-lang.org/browse/SI-6991

Thanks and bye,

Simon

[Paul Phillips]

On Fri, Jan 18, 2013 at 9:12 AM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

Btw, is there a reason why the proper flags are not set for annotations? For instance ...

class FooAnnotation extends annotation.ClassfileAnnotation
val fa = classOf[FooAnnotation]
println(fa.isAnnotation)

... prints false!

Jvm spec mandates ACC_INTERFACE be set if ACC_ANNOTATION is set.

[Simon Ochsenreither]

As far as I see, currently none of them are set. (Only 0x1, but I guess that's something like ACC_PUBLIC).

Is there any reason, or is this just not implemented yet?

[Lukas Rytz]

On Fri, Jan 18, 2013 at 6:37 PM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

As far as I see, currently none of them are set. (Only 0x1, but I guess that's something like ACC_PUBLIC).

Is there any reason, or is this just not implemented yet?

Doing it might be misleading because they are not really annotations in the java sense. ClassfileAnnotations would be if the scala compiler would support writing them.

[Simon Ochsenreither]

Doing it might be misleading because they are not really annotations in the java sense. ClassfileAnnotations would be if the scala compiler would support writing them.

Considering that we are not involved in the low-level bytecode generation business anymore, wouldn't it be sufficient to put right arguments into ASM's API?

[Simon Ochsenreither]

Doing it might be misleading because they are not really annotations in the java sense. ClassfileAnnotations would be if the scala compiler would support writing them.

Btw, having looked at the spec, it would be a bit more work than for enums (where it is really only ACC_ENUM + extends Enum), but setting the right flags would probably be a huge step forward.

[Paul Phillips]

On Friday, January 18, 2013, Simon Ochsenreither wrote:

Btw, having looked at the spec, it would be a bit more work than for enums (where it is really only ACC_ENUM + extends Enum), but setting the right flags would probably be a huge step forward.

Did my email get lost somewhere? You can't set ACC_ANNOTATION without setting ACC_INTERFACE. You can't set ACC_INTERFACE without setting ACC_ABSTRACT. If you are ACC_ABSTRACT you cannot be instantiated. What are the right flags?

[Simon Ochsenreither]

Did my email get lost somewhere? You can't set ACC_ANNOTATION without setting ACC_INTERFACE. You can't set ACC_INTERFACE without setting ACC_ABSTRACT. If you are ACC_ABSTRACT you cannot be instantiated. What are the right flags?

Sorry, maybe I didn't communicate properly. I meant to say that the amount of work left, once the right flags are set, is a bit higher for annotations than for enums.

[Paul Phillips]

On Fri, Jan 18, 2013 at 1:39 PM, Simon Ochsenreither <simon.och...@gmail.com> wrote:

Sorry, maybe I didn't communicate properly. I meant to say that the amount of work left, once the right flags are set, is a bit higher for annotations than for enums.

I'm still trying to elicit your statement as to what are the "right flags" for annotations.

[Simon Ochsenreither]

I'm still trying to elicit your statement as to what are the "right flags" for annotations.

The ones you have mentioned, afaik, no disagreement here.