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

Java transient flag is not translated to Scala annotation #10042

Closed
scabug opened this issue Nov 10, 2016 · 7 comments
Closed

Java transient flag is not translated to Scala annotation #10042

scabug opened this issue Nov 10, 2016 · 7 comments
Assignees
Milestone

Comments

@scabug
Copy link

scabug commented Nov 10, 2016

There is currently no way to check if a Java symbol is transient or not.

This is the case because scala.reflect.internal.ClassfileConstants does not translate the JAVA_ACC_TRANSIENT flag to a Scala flag. Therefore, checks with hasFlag(Flags.TRANS_FLAG) in symbols are negative for transitive variables in Java classes.

There is a hack through reflection that can be used to check this, but the fact that this case is not handled is bad for java interop and Serialization-intensive code.

@scabug
Copy link
Author

scabug commented Nov 10, 2016

Imported From: https://issues.scala-lang.org/browse/SI-10042?orig=1
Reporter: @jvican
Affected Versions: 2.11.0, 2.12.0

@scabug
Copy link
Author

scabug commented Nov 11, 2016

@lrytz said:
TRANS_FLAG does not (and should not) correspond to JAVA_ACC_TRANSIENT: it is a special flag that can be used within a phase to pass information from one traversal to another. By convention, it should always be reset at the end of the phase.

In fact, there is no Scala flag that corresponds to JAVA_ACC_TRANSIENT. The same is also true for JAVA_ACC_VOLATILE, JAVA_ACC_NATIVE, probably others. The actual Scala equivalent for these is an annotation, so I think the classfile parser should add the corresponding annotation to the symbol. I don't think there's an existing example where this is being done.

@scabug
Copy link
Author

scabug commented Nov 11, 2016

@jvican said (edited on Nov 11, 2016 10:22:18 AM UTC):
I'm happy to implement this, since it's a blocker for me. Would you accept these changes for 2.12.1 if I make a PR?

@scabug
Copy link
Author

scabug commented Nov 11, 2016

@lrytz said:
For 2.12.1, it depends on the size / risk of the patch and how quickly it would be available for review. Also cc @retronym, @adriaanm, do you think what I outlined above makes sense?

@scabug
Copy link
Author

scabug commented Nov 23, 2016

@adriaanm said (edited on Nov 23, 2016 6:27:42 PM UTC):
I agree with Lukas that these Java classfile flags should be turned into Scala annotations. We could consider this for 2.12.2.

@scabug
Copy link
Author

scabug commented Dec 1, 2016

@retronym said:
{quote}I don't think there's an existing example where this is being done.{quote}

Probably the most similar is the way we parse the Throws attribute and add the @throws annotation to Java method symbols.

@scabug
Copy link
Author

scabug commented Dec 1, 2016

@retronym said (edited on Dec 1, 2016 7:24:30 AM UTC):
For consistency, we'll also have populate this annotation in our Java source file compiler, and in runtime reflection.

Looks like we forgot to create the @throwable annotation for runtime reflection Java method symbols, we should have added:

diff --git a/src/reflect/scala/reflect/runtime/JavaMirrors.scala b/src/reflect/scala/reflect/runtime/JavaMirrors.scala
index 95440ebc00..eabaa6b389 100644
--- a/src/reflect/scala/reflect/runtime/JavaMirrors.scala
+++ b/src/reflect/scala/reflect/runtime/JavaMirrors.scala
@@ -1162,6 +1162,7 @@ private[scala] trait JavaMirrors extends internal.SymbolTable with api.JavaUnive
       copyAnnotations(meth, jmeth)
       if (jmeth.javaFlags.isVarargs) meth modifyInfo arrayToRepeated
       if (jmeth.getDefaultValue != null) meth.addAnnotation(AnnotationDefaultAttr)
+      jmeth.getExceptionTypes.foreach(cls => meth.addThrowsAnnotation(classToScala(cls)))
       markAllCompleted(meth)
       meth
     }

@scabug scabug added this to the Backlog milestone Apr 7, 2017
@hrhino hrhino self-assigned this Jul 2, 2017
hrhino added a commit to hrhino/scala that referenced this issue Jul 13, 2017
a.k.a., once more into the ClassfileParser fray.

In `JavaMirrors`, add these synthetic annotations along with
the real ones (and the `@throws` annotation which we already
synthesize in the same place). In `ClassfileParser`, inspect
the access flags and apply the appropriate annotations then.
Happily, we were already doing The Right Thing[tm] for these
classes if we loaded their symbols via `JavaParsers`, so for
today that file escapes unscathed.

Fixes scala/bug#10042.
hrhino added a commit to hrhino/scala that referenced this issue Jul 14, 2017
a.k.a., once more into the ClassfileParser fray.

In `JavaMirrors`, add these synthetic annotations along with
the real ones (and the `@throws` annotation which we already
synthesize in the same place). In `ClassfileParser`, inspect
the access flags and apply the appropriate annotations then.
Happily, we were already doing The Right Thing[tm] for these
classes if we loaded their symbols via `JavaParsers`, so for
today that file escapes unscathed.

Fixes scala/bug#10042.
@hrhino hrhino modified the milestones: 2.12.4, Backlog Jul 14, 2017
@hrhino hrhino changed the title Java transient flag is not translated to Scala flag Java transient flag is not translated to Scala annotation Jul 17, 2017
hrhino added a commit to hrhino/scala that referenced this issue Jul 17, 2017
a.k.a., once more into the ClassfileParser fray.

In `JavaMirrors`, add these synthetic annotations along with
the real ones (and the `@throws` annotation which we already
synthesize in the same place). In `ClassfileParser`, inspect
the access flags and apply the appropriate annotations then.
Happily, we were already doing The Right Thing[tm] for these
classes if we loaded their symbols via `JavaParsers`, so for
today that file escapes unscathed.

Fixes scala/bug#10042.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants