Imported From: https://issues.scala-lang.org/browse/SI-2764?orig=1
Reporter: Alex (alex.savitsky)
Attachments:

• CreationTimestamp.scala (created on Dec 4, 2009 4:53:07 PM UTC, 382 bytes)

Alex (alex.savitsky) said:
Scala file with a reported error

@milessabin said:
I can reproduce the problem with the following minimized example,

Enum.java

public enum Enum {
  VALUE;
}

Ann.java

public @interface Ann {
  Enum value();
}

Use.scala

class Use {
  @Ann(Enum.VALUE)
  def foo {}
}

And in this case an error is reported by command line scalac,

src/bug2764/Use.scala:4: error: annotation argument needs to be a constant; found: Enum.VALUE
  @Ann(Enum.VALUE)
            ^
one error found

So it looks like the Eclipse vs. command-line build issue might be a red-herring.

In both cases scalac is seeing a UniqueConstantType in a context where it's expecting to see a Literal (in Typer.typedAnnotation).

@lrytz said:
The problem is that java enum values don't have a constant type when being parsed from java source (it works when compiling against the compiled java files). Not sure where to fix this, probably some special case in the typer.

The classfile parser does it:

sym.setInfo(if ((jflags & JAVA_ACC_ENUM) == 0) info else mkConstantType(Constant(sym)))

@milessabin said:
My hunch is that the original reporter was working with Java source for the incremental build, but Java binaries for the command-line build, hence the apparent Eclipse vs. command-line difference.

Anyhow, reassigning to the the compiler.

Thomas Scheiblauer (tom) said:
I get this error only when annotating "var" or "val". On "def" it behaves correctly.

Thomas Scheiblauer (tom) said:
ok... after updating my Eclipse Scala IDE to the latest snapshot tonight it stopped working on "def"

Thomas Scheiblauer (tom) said:
Hmmm, strange behavior. Magically it works again even on "var".. at least in one project. The other one in the same Eclipse workspace shows the errors in the editor sidebar but compiles non the less. Seems pretty non deterministic to me but obviously only affects the Eclipse IDE code validation (momentarily) as vaguely stated in a previous comment.

Galder (galderz) said:
This issue is also present when trying to use java static constants in Scala annotations.

Any idea if this will be fixed for next Scala 2.8 beta?

@lrytz said:
@tom: I don't think this issue is related in any way to the eclipse IDE.

@galderz: Yes, that's right, I'm aware that the issue also applies to java static final constants.

The problem is that I really don't know an easy way to fix this.

For enumerations, the java source parser would need to add some additional modifier to the trees of the enum constants (fields) to mark them as enum values. That way the type checker could assign a constant type.

For static constants, it's even worse: our current java parser does not look at definitions at all, it only parses declarations. So the value of the static final field is just skipped by the parser. It's not possible to know the value of the static final field when type checking an annotation that uses it.

Thomas Scheiblauer (tom) said:
@rytz: my observation is that the error only shows up in the eclipse code(text) editor sidebar and not(!) in the "Markers" view. Further it gets already displayed during editing and not after saving the resource. I don't know too much about the eclipse "code validation while editing" internals but it seems to me that the error marker is generated before compiling the resource.
...and the compiled code runs as expected.
???

@milessabin said:
@tom The problem this ticket relates to isn't Eclipse-specific. You might be seeing a side-effect of it which affects only the presentation compiler, but equally you might be seeing a different problem altogether.

Please try and put together a minimal self-contained non-mavenized Eclipse project which illustrates the problem. If you can verify that you only see the report in the Eclipse Scala editor (ie. a command line build succeeds, and nothing shows in the Eclipse Problems view), then please open a new ticket, assigned to the IDE with the project attached.

Bram Bouwens (bbouwens) said:
Also observed with 2.8.0 final and IntelliJ IDEA 9.0.3

dubby said:
Any news here? This issue is a real problem for my project.
I have a lot of Annotations with Enum parameters.
The project can be compiled without errors (using Maven-Scala-Plugin).

But i cannot create the Scaladoc of my project (using Scala 2.8.0) - getting the known "annotation argument needs to be a constant"-error , because Scaladoc also seems to be "too" strict.

Can i tell the Scaladoc to ignore this error, like the compiler does?

Alan (alanpog) said:
Also observed with 2.8.1 and ENSIME.

pdinklag said:
I want to stress this issue.

I can only second dubby, this is a real problem. It's basically impossible to use custom annotations with parameters, because not even constants can be used (as mentioned already).

You have to hardcode literal values at the moment, and that cannot be a solution.

Martin Krischik (krischik) said:
I too want to stress this issue.

Maven and IntelliJ IDEA work fine while ScalaDoc and NetBeans produce the mentioned error. In Netbeans I just ignore it but for ScalaDoc that is not possible

I tried to read the comments above but still fail to see how it can be that one compile technique (maven) produces good output while other don't.

@lrytz said:
Replying to [comment:28 krischik]:

Maven and IntelliJ IDEA work fine while ScalaDoc and NetBeans produce the mentioned error. In Netbeans I just ignore it but for ScalaDoc that is not possible

Maven / IDEA work because they happen to compile the Java files containing the enums (or constants) first, and then compile the Scala files against the bytecode. Try doing the same for !ScalaDoc (compile the Java files first and put the output folder in !ScalaDoc's classpath).

Concerning the fix, as I mentioned earlier, unfortunately I don't think there will be a solution anytime soon.

Martin Krischik (krischik) said:
But we are talking about javax.servlet.DispatcherType.REQUEST– a Java EE annotation. None of them should compile that enum. They should just use the one from javaee-api-6.0.jar

And let me check:

SET CLASSPATH=%[CLASSPATH];%[Repository]\javax\javaee-api\6.0\javaee-api-6.0.jar

Yep it is on the classpath as well.

@lrytz said:
Then you're seeing a different issue. Please open another ticket with the exact steps how to reproduce:

• minimal scala source file
• attach the jar file
• commands to reproduce

Florian Hars (florian) said:
Replying to [comment:31 rytz]:
That other issue is now #4607

heapifyman said (edited on May 23, 2011 11:09:57 AM UTC):
I get the error message mentioned in the issue description for javax.persistence annotations like {code}@GeneratedValue(strategy = GenerationType.AUTO){code} but only if I enable the experimental compiler extensions. This happens both in Eclipse and on the command line using sbt.

Without experimental extensions my test project compiles fine both in Eclipse and on the command line using sbt.

Jan Berkel (jberkel) said:
Just a heads up for everybody using sbt: you can specify the compile order like so:

class MyProject(info: ProjectInfo) extends DefaultProject(info) {
  override def compileOrder = CompileOrder.JavaThenScala
}

Doug Donohoe (donohoe) said:
I'm seeing this error in a mixed java/scala maven project using Intellij 10.5.1. It compiles fine on the command line (via mvn) but fails when compiling inside of IntelliJ.

What is odd is that IntelliJ is fine using annotations with enums compiled outside of the project.

However, it fails with an Annotation I have defined in the same project that is using that annotation. Based on the comments above, it seems that compile order matters and perhaps this could be an Intellij bug?

Dmitry Stropaloff (h8) said:
I've got such error message when trying to use RoboGuice injections in java/scala/android maven project. Something like this "@InjectView(R.id.textView) var view: TextView = _" will cause annotation error. "R" is a java, auto-generated (final) class and "id" is a static inner class with static int constants.

Andreas Joseph Krogh (andreak) said:
FWIW: The following works, using a scala object:

object F {
	final val a = ""
}

class A {
	@MyAnnotation(name = F.a)
	var name = "fish"
}

So having final val works

Andreas Joseph Krogh (andreak) said:
However, this doesn't:

object F {
	final val a: String = ""
}

class A {
	@MyAnnotation(name = F.a)
	var name = "fish"
}

results in:

error: annotation argument needs to be a constant; found: F.A
@MyAnnotation(name = F.a)

So the type-annotation :String breaks the whole thing, very strange...

@paulp said:

So the type-annotation :String breaks the whole thing, very strange...

...as specified in SLS 4.1, "Value Declarations and Definitions".

Andreas Joseph Krogh (andreak) said:
Yes, reading the spec (which I admit I hadn't), it clearly states "The final modifier must be present and no type annotation may be given".

But, to the average developer:

val a = "hi"

and

val a: String = "hi"

are the same thing, everything else is unexpected and comes as a surprise.

Taylor Leese (tleese22) said:
Andreas - Maybe I'm missing something here, but the original ticket is about using java enums in scala annotations -- not strings. I tried your workaround with an enum and there's still the same problem.

Tomer Gabel (holograph) said:
Christ, there's no working around it either, eh? Either turn your compilation model upside down or hardcode literals. I don't (yet) understand the internals of why this is hard to resolve, but three years and no working annotations... sigh

@paulp said:
It's possible that it's not that hard to resolve, but there aren't that many people who write actual code, and the people who do have hundreds (or thousands) of issues competing for their attention.

Philip Kster (phkoester) said:
This is very, very annoying. For some reason I never ran into this problem but now I do.

Now my projects don't compile any longer and I'm stuck.

This bug hasn't been resolved in years. Not knowing anything about the internal workings of the Scala compiler, this looks like a comparably easy thing to fix. This is a major problem, not a minor one!

I mean, if I can't use enums in annotations, then I cannot use this language. It's that simple. I'll put my Scala efforts on hold until this is fixed.

In theory Scala might be great and all, but in practice there are new problems every week. If everything works great in Eclipse, the Maven plugin would not work, or vice versa.

I want to code and not spend 90 % of my spare time maintaining my projects.

I'm really frustrated.

@paulp said:
Ok, I'm going to give this a look right now.

Philip Kster (phkoester) said (edited on May 11, 2012 4:29:55 PM UTC):
Thanks a lot, Paul. In case I sounded rude: I didn't mean to be rude, by no means. I'm still a Scala enthusiast. It's only that I can forget about my Scala weekend that I intended to have because this is a real blocker.

Maybe that's a good oppurtunity to visit my family then ... :)

@paulp said:
Don't worry about it; if I thought you were being unreasonable I wouldn't have picked up the ticket. I'm aware it's frustrating waiting for bugs to get fixed; that's why I do basically nothing but work on scala.

It's fixed in 8075672308 for trunk. I'll look at backporting it for 2.9.3.

G. Ralph Kuntz, MD (grkuntzmd) said:
Thank you.

I've been trying to use Scala in a JAX-RS project, but some of our custom annotations require Java enum values.

It's hard to convince other developers of how great Scala is if I can't use it in one of our major projects :-).

Alexey Aksenov (ezhik) said (edited on May 11, 2012 6:14:46 PM UTC):
This bug is very annoing, so I watch the thread and hope for fix.
I used annotations for AOP(aspectj) in one of my scala projects for android.
Here is workaround that working for me. Maybe, it will help you.

• declare annotation Cacheable in Java
  https://github.com/ezh/android-DigiLib/blob/master/src/main/java/org/digimead/digi/ctrl/lib/aop/Cacheable.java

There is no URL because this part of code is not public.

• use annotation Cacheable in Scala
  @Cacheable(namespace = Cache.web, examination = true)
  protected def httpGetFunc[T](force: Boolean, url: String)(implicit m: scala.reflect.Manifest[T]): Option[T] = try {

Cache.web as simple as

object Cache {
// pregenerated random
final val web = 123456
final val marketItem = 654321
object Period {
final val ever = -1
final val default = 0
}
}

King Regards

@paulp said:
I've tagged this for backporting, which is not a guarantee; I don't have time to do it right now but I expect to in the near future.

Philip Kster (phkoester) said:
Great job, Paul. Thanks a lot.

@lrytz said:
Great, thanks for the fix! For the second part of the ticket, there's a separate issue now (#5791).

@adriaanm said:
fixed for 2.10 in 8075672308 -- reopened for potential backport in 2.9.3-RC2

@adriaanm said:
too complex to backport to 2.9 -- please upgrade to 2.10