3

The scalac Java parser is taking objection to my Java code

imported `Entity' is permanently hidden by definition of object Entity in package domain    Asset.java

This seems to be a collision between an import and a class with the same name in the package being compiled.

In my package I have a class

package iMP2020.domain;

public interface Entity {
    public Serializable getId();
}

with the same name as an imported class from a different package

package iMP2020.domain;
import javax.persistence.Entity; // compiler warning

@Entity
public class Asset {

where it is complaining about the import. Javac is quite happy. Note that I don't have to reference my version of the class- just its existence is enough to trigger the warning on the import.

I can fix this by removing the import and explicitly referencing @Entity, but is it a bug in the compiler?

Duncan McGregor
  • 17,665
  • 12
  • 64
  • 118
  • 1
    Whether or not it's a bug, why are you using the Scala compiler to compile Java code instead of the Java compiler? Regardless of whether javac or scalac is not living up to the Java spec (or whether the behavior is not covered by a spec), if you want the javac behavior, use javac? – Rex Kerr May 30 '11 at 17:09
  • Because scalac parses Java source in order to deduce the type signatures so that we can have circular dependancies between Java and Scala - http://www.codecommit.com/blog/scala/joint-compilation-of-scala-and-java-sources – Duncan McGregor May 30 '11 at 17:26
  • In other words, "I have an unresolvable circular dependency between Java and Scala, but somehow I can compile this successfully with javac anyway, which is how I know that javac doesn't complain?" I don't know whether it's a bug or not, but either way, it's good that you have a workaround. – Rex Kerr May 30 '11 at 17:42
  • Don't know if it is a bug, but given that it is a warning and not an error, the Scala compiler does not violate Java specification. – notnoop May 30 '11 at 17:49
  • @Rex Actually I don't have any unresolvable dependencies, so that javac compiles this just fine. – Duncan McGregor May 30 '11 at 18:53
  • Then there isn't any reason to have scalac parse it, which is probably the best workaround (since you get bytecode as well as a symbol table out of javac). – Rex Kerr May 30 '11 at 19:08
  • @Rex - I didn't ask how to get rid of the warning, I asked if it is a bug! It arose adding the Scala nature to an Eclipse project - which evidently sets scalac to work on all my .java sources. – Duncan McGregor May 30 '11 at 19:39
  • Even if it's a bug in (Sun's) javac, you probably want scalac to work exactly the same way, so you could file a bug report. I'd guess that it's a pretty low priority, however. – Rex Kerr May 30 '11 at 20:43
  • It emphatically isn't a bug in javac - it understands that there is no conflict. But scalac doesn't. I'll take it off to the scala mailing list. – Duncan McGregor May 30 '11 at 20:47

3 Answers3

1

You have two Entity references, one for your interface, and another one for javax.persistence.Entity.

Try to replace the second one with the full qualified name, removing the import:

package iMP2020.domain;

public interface Entity {
    public Serializable getId();
}

and

package iMP2020.domain;

@javax.persistence.Entity
public class Asset {
greuze
  • 4,250
  • 5
  • 43
  • 62
1

I don't seem to be able to reproduce this except with the Scala Eclipse plugin, so I'm going to wait for that to stabilise before coming to a conclusion.

Anthony Pegram
  • 123,721
  • 27
  • 225
  • 246
Duncan McGregor
  • 17,665
  • 12
  • 64
  • 118
  • try to "import javax.persistence" then use it as javax.persistence.Entity in your code. – Dan Jan 24 '12 at 15:24
0

I don't think it is a bug. It doesn't make sense for an import to have the same name as a package member.

astay13
  • 6,857
  • 10
  • 41
  • 56
  • Well it does make sense if I have a class in another package with the same name as a class in my package. Surely javac should be the arbiter here, and it doesn't issue a warning. – Duncan McGregor May 30 '11 at 12:23
  • @Duncan, Sorry, what I meant is that it doesn't make sense for the compiler to allow you to use 2 classes with the same name. It could be that javac expects you to use the fully qualified class name to reference the import. – astay13 May 30 '11 at 12:32
  • Note that I don't have to reference the class in the current package. Just its existence is enough to trigger the warning on the import. In the case of the code above, javac only considers the explicit import and does not give a warning. Scalac complains. – Duncan McGregor May 30 '11 at 12:56