Community
Participate
Working Groups
The compiler does compile import my.package.*; without an error only because the directory "my/package" exists, but that's different from the behaviour of sun's javac. javac checks, that there are java-classes (and not just images for example) in the package. Eclipse's compiler should be modified in a way, that the behaviour matches the one of javac. This actually happen's with 3.1M1 too.
I don't see why we would change this. Nothing is wrong with this code. It tells to import all public types from the package q. It doesn't require q to contain any public types. Jikes doesn't complain on such code. If you try to use a single import declaration, then you will get an invalid import error because the corresponding type doesn't exist. Do you have a link in the JLS that would confirm that javac has the right behavior?
I will have a closer look to the JLS, and perhaps i find something that justifies javac's behaviour. On the other hand, there's the philosophical question, when a package exists. For me, the fact that the package-directory exists isn't sufficient. Therefor i like javac's behaviour more than eclipse's. I know that users shouldn't *-imports, but one user in my project did, and the package only contained a picture, no classes. So javac complained about that, and Eclipse didn't. I can imagine, that the patch for Eclipse would be rather short, since the compiler has to enumerate all classes in the package anyway. If there were none, the compiler should simply throw an error.
We have two questions: 1) Should we complain according to the JLS? If yes, then we should definitely handle this case and this would not be an option. I didn't find anything that would say that our behavior is wrong. 2) if 1) is no, should we add an option? I don't really see what an error or a warning would add. We already report unused imports. So you can simply set unused imports to error and you would get an error for this case. Could this be an acceptable solution?
If i'd set "unsed import" to error, than ton's of java-files wouldn't be compilable anymore. This is not a sollution. The problem of the JLS may be, that it doesn't say anything about empty-packaged and when exactly a package exists. That would be bad, since that would lead to different behaviours from compiler to compiler - which is there case we have here.
I just took a look at http://java.sun.com/docs/books/jls/second_edition/html/packages.doc.html#70209 Some quotes: - A package consists of a number of compilation units - It is a compile-time error for a type-import-on-demand declaration to name a type or package that is not accessible Both statement are <ironic>_very_ precise</ironic>.
So here we go: JLS 7.5.2: TypeImportOnDemandDeclaration: import PackageOrTypeName . * ; JLS 6.5.3.2: The package name Q.Id names a package that is the member named Id within the package named by Q. If Q does not name an observable package (§7.4.3), or Id is not the simple name an observable subpackage of that package, then a compile-time error occurs. JLS 7.4.3: A package is observable if and only if either: * A compilation unit containing a declaration of the package is observable. * A subpackage of the package is observable. JLS 7.3: CompilationUnit: PackageDeclarationopt ImportDeclarationsopt TypeDeclarationsopt According to 7.4.3, a package must contain a "compilation unit" which is equivalent to a java-file with the right package-declaration etc ... Thx go to Patrick Roemer in de.comp.lang.java for searching the JLS.
I created the following type in p1/p2/X.java & compiled it without error in javac (1.4.2 & 1.5.0): package p1.p2; import p1.*; class X {} So is p1 a package? Looks like it even though it doesn't contain any types itself. If I create a package foo.bar but have yet to add the first type to it, is it a package? If not, is foo a package since it has a subpackage? Our view is that any package created by the user is a package, regardless of when he gets around to adding the first type. We can debate the philosophical question forever, but JDT is a Java development environment & people will define things when they want... so we let them.
Yes, p1 is a package since it has an observable sub-package named p2. As i posted before: JLS 7.4.3: A package is observable if and only if either: * A compilation unit containing a declaration of the package is observable. * A subpackage of the package is observable.
a better testcase that matched the eclipse-situation would have been: create files: p1/test.png p2/test.java execute: javac -sourcepath . p2/test.java et voilà: p2/test.java:3: package p1 does not exist
I'll repeat: We can debate the philosophical question forever, but JDT is a Java development environment & people will define things when they want... so we let them. The user has defined the package. We take his word for it that its not a random directory. If he only wanted to create a folder then he would not have created a package.
forgot to close.
Eclipse treats a folder inside a source-folder like a package - is that correct? I cannot create a folder that won't be treated as a package inside a source or class-folder, and the JLS clearly handles this situation differntly.
