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
name mangling vs. java reflection #4316
Comments
@ingoem said: |
@gkossakowski said: |
@paulp said: |
@gkossakowski said: |
@paulp said: |
@gkossakowski said: It's quite likely that we'll be in luxury situation of having native Scala reflection that we can point folks at. |
@soc said: Does someone know the current javac behaviour is defined in the spec? If not, it would probably make sense to create a ticket in Oracle's bug tracker, even if we can sidestep the problem with Scala reflection, because huge optimizations efforts went into making reflection fast ... so if we can use Java reflection underneath instead of rolling things ourselves, we could benefit from that hard work. |
As of r24390 signatures appear to be in good shape with the exception of this, which I can only document for now. Actually this is not about signatures per se, but names which cause java -Xprint to fail.
Here is the java equivalent of the failing construct:
In an unsurprising twist, java creates the inner class java is looking for:
The successful output from the lazy val and def cases:
The failing output from the val case:
The text was updated successfully, but these errors were encountered: