Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VerifyError ascribing Java annotations to scala.annotation.Annotation #9644

Closed
scabug opened this issue Feb 4, 2016 · 2 comments · Fixed by scala/scala#6869
Closed

VerifyError ascribing Java annotations to scala.annotation.Annotation #9644

scabug opened this issue Feb 4, 2016 · 2 comments · Fixed by scala/scala#6869

Comments

@scabug
Copy link

scabug commented Feb 4, 2016

Scala says Java annotations extend scala.annotation.Annotation, but generates invalid bytecode trying to perform this cast:

scala> import scala.annotation.Annotation
scala> import java.lang.Deprecated
scala> val x: Deprecated = null
x: Deprecated = null
​
scala> x: Annotation
java.lang.VerifyError: Bad type on operand stack

This happens for all Java annotations, Deprecated isn't special.

This was mentioned in a comment of #9400, but is a separate issue. Also reported here.

@scabug
Copy link
Author

scabug commented Feb 4, 2016

Imported From: https://issues.scala-lang.org/browse/SI-9644?orig=1
Reporter: Daniel Armak (danarmak)
Affected Versions: 2.11.7
See #9400

@hrhino
Copy link

hrhino commented Jun 25, 2018

In recent 2.12, assigning Deprecated to ClassfileAnnotation causes a crash in jvm.

hrhino added a commit to hrhino/scala that referenced this issue Jun 29, 2018
Previously, `JavaParsers` and `ClassfileParser` would "fix-up"
Java annotations to be non-abstract classes with `Annotation`
and `StaticAnnotation` as parents. This caused all manner of
strangeness and invalid classfiles (see linked tickets) and
was surprising, to say the least.

Now, the only special dispensation given to Java annotations
is that they get a public, no-args class constructor, because
that's what it takes to get `typedAnnotation` to be able to
look up the type. This means that `new Foo`, where `Foo` is
a Java annotation, still compiles (as it does right now,
actually). Part of the reason for this commit is to provoke
a discussion about how to fix that.

Fixes scala/bug#8778.
Fixes scala/bug#9400.
Fixes scala/bug#9644.
hrhino added a commit to hrhino/scala that referenced this issue Jul 1, 2018
Previously, `JavaParsers` and `ClassfileParser` would "fix-up"
Java annotations to be non-abstract classes with `Annotation`
and `StaticAnnotation` as parents. This caused all manner of
strangeness and invalid classfiles (see linked tickets) and
was surprising, to say the least.

Now, the only special dispensation given to Java annotations
is that they get a public, no-args class constructor, because
that's what it takes to get `typedAnnotation` to be able to
look up the type. This means that `new Foo`, where `Foo` is
a Java annotation, still compiles (as it does right now,
actually). Part of the reason for this commit is to provoke
a discussion about how to fix that.

Fixes scala/bug#8778.
Fixes scala/bug#9400.
Fixes scala/bug#9644.
hrhino added a commit to hrhino/scala that referenced this issue Jul 1, 2018
Previously, `JavaParsers` and `ClassfileParser` would "fix-up"
Java annotations to be non-abstract classes with `Annotation`
and `StaticAnnotation` as parents. This caused all manner of
strangeness and invalid classfiles (see linked tickets) and
was surprising, to say the least.

Now, the only special dispensation given to Java annotations
is that they get a public, no-args class constructor, because
that's what it takes to get `typedAnnotation` to be able to
look up the type. This means that `new Foo`, where `Foo` is
a Java annotation, still compiles (as it does right now,
actually). Part of the reason for this commit is to provoke
a discussion about how to fix that.

Fixes scala/bug#8778.
Fixes scala/bug#9400.
Fixes scala/bug#9644.
hrhino added a commit to hrhino/scala that referenced this issue Jul 2, 2018
Previously, `JavaParsers` and `ClassfileParser` would "fix-up"
Java annotations to be non-abstract classes with `Annotation`
and `StaticAnnotation` as parents. This caused all manner of
strangeness and invalid classfiles (see linked tickets) and
was surprising, to say the least.

Now, the only special dispensation given to Java annotations
is that they get a public, no-args class constructor, because
that's what it takes to get `typedAnnotation` to be able to
look up the type. This means that `new Foo`, where `Foo` is
a Java annotation, still compiles (as it does right now,
actually). Part of the reason for this commit is to provoke
a discussion about how to fix that.

Fixes scala/bug#8778.
Fixes scala/bug#9400.
Fixes scala/bug#9644.
hrhino added a commit to hrhino/scala that referenced this issue Jul 2, 2018
Previously, `JavaParsers` and `ClassfileParser` would "fix-up"
Java annotations to be non-abstract classes with `Annotation`
and `StaticAnnotation` as parents. This caused all manner of
strangeness and invalid classfiles (see linked tickets) and
was surprising, to say the least.

Now, the only special dispensation given to Java annotations
is that they get a public, no-args class constructor, because
that's what it takes to get `typedAnnotation` to be able to
look up the type. This means that `new Foo`, where `Foo` is
a Java annotation, still compiles (as it does right now,
actually). Part of the reason for this commit is to provoke
a discussion about how to fix that.

Fixes scala/bug#8778.
Fixes scala/bug#9400.
Fixes scala/bug#9644.
@SethTisue SethTisue modified the milestones: Backlog, 2.13.0-M5 Aug 7, 2018
@SethTisue SethTisue assigned hrhino and unassigned lrytz Aug 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants