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 source parser does not follow Java rules for shadowing. #7232

Closed
scabug opened this issue Mar 8, 2013 · 8 comments
Closed

Java source parser does not follow Java rules for shadowing. #7232

scabug opened this issue Mar 8, 2013 · 8 comments

Comments

@scabug
Copy link

@scabug scabug commented Mar 8, 2013

It's easiest to just look at the attachment in order to understand the problem.

The Java class my.test.bl.bo.CashDrawer.getDrawer() is returning a type of my.test.bl.bo.location.Drawer. Scala thinks it's returning a type of my.test.bl.bo.Drawer even though CashDrawer specifically imports my.test.bl.bo.location.Drawer.

// CashDrawer.java
package my.test.bl.bo;

import my.test.bl.bo.location.Drawer;

public class CashDrawer {
    public static Drawer getDrawer() {
        return new Drawer();
    }
}

Scala will interpret it correctly only if the type names are all fully qualified.

CashDrawer.java
package my.test.bl.bo;

public class CashDrawer {
    public static my.test.bl.bo.location.Drawer getDrawer() {
        return new my.test.bl.bo.location.Drawer();
    }
}
@scabug
Copy link
Author

@scabug scabug commented Mar 8, 2013

Imported From: https://issues.scala-lang.org/browse/SI-7232?orig=1
Reporter: Joseph Freeman (jfree143)
Affected Versions: 2.10.0
Attachments:

@scabug
Copy link
Author

@scabug scabug commented Mar 11, 2013

@adriaanm said:
Are we talking about scalac parsing java source code? If you're not in the IDE, the best thing to do would be to first compile your Java to class files and then compile with scalac against the class files. It would still be good to fix this, though, of course!

@scabug
Copy link
Author

@scabug scabug commented Mar 11, 2013

Joseph Freeman (jfree143) said (edited on Mar 11, 2013 5:56:29 PM UTC):
As far as I know, scalac parses the Java code as well as the Scala code...so I guess it would be scalac that's at fault here.

It does seem to work if you run the code from within the Eclipse. However, doing 'mvn clean install' in a separate terminal will fail unless the type names are fully qualified every time.

Also, if I have Java calling Scala and Scala calling Java, then I don't think your suggestion would work. Right?

@scabug
Copy link
Author

@scabug scabug commented Mar 11, 2013

@scabug
Copy link
Author

@scabug scabug commented Mar 11, 2013

@retronym said:
This bug is a consequence of scalac reusing the Scala typechecker to analyze Java source files, given the difference binding precedence rules:

Java Spec:

A single-type-import declaration d in a compilation unit c of package p that imports
a type named n shadows, throughout c, the declarations of:
• any top level type named n declared in another compilation unit of p
• any type named n imported by a type-import-on-demand declaration in c
• any type named n imported by a static-import-on-demand declaration in c

Scala Spec:

Bindings of different kinds have a precedence defined on them:
1. Definitions and declarations that are local, inherited, or made available by a
package clause in the same compilation unit where the definition occurs have
highest precedence.
2. Explicit imports have next highest precedence.

@scabug
Copy link
Author

@scabug scabug commented Mar 11, 2013

@scabug
Copy link
Author

@scabug scabug commented Mar 11, 2013

@retronym said:
Oh, I just realised the Eugene picked up this ticket earlier today. @eugene: Let me know if you want me to take it, otherwise feel free to use my branch as a reference. It definitely needs additional test variations.

@scabug
Copy link
Author

@scabug scabug commented Mar 13, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants