eclipse 3.4 (ganymede) package collision with type

Question

We have a package that ends with exception e.g.

package a.b.c.exception;

Our code base had no issues up till eclipse 3.3, however when we shifted to eclipse 3.4, it started giving errors related to this package:

"The package a.b.c.exception collides with a type"

When I refactor the package name to a.b.c.exceptions, there are no issues. Is this due to a bug in eclipse 3.4 or is there some setting to rectify this behavior?

Featureless

What type does it collide with? – Bluegreen

that's what I don't know and eclipse doesn't outlines any specific type – Featureless

Thanks Nate and VonC for responding to the question and going in the right direction as it seemed to be a Java related issue, however as I said we've been working on this workspace since 3 years on eclipse 3.2, 3.3 but this issue cropped up only when we upgraded to 3.4. – Featureless

Answer 1

I changed one of the compilation option in eclipse and the problem disappeared. Under workspace properties: Java Compiler -> Errors/Warnings -> Change 'Unused import' from 'Warning' to 'Ignore'.

Featureless

although this solved the issue I was facing but i'm not able to determine why only this particular package gave the error in the first place. There were many other packages which do not have immediate classes. – Featureless

Answer 2

It's because you have a class named exception (with a lower case "e") in the a.b.c package and a package named a.b.c.exception.

It causes a name collision because if you have the code a.b.c.exception.doSomething(); - does that mean you want to call the static doSomething() method in the a.b.c.exception class? Or does it mean there's a class called a.b.c.exception.doSomething that you're trying to invoke the constructor of?

Stick with the Java naming conventions - packages all lowercase, classes starting with an uppercase and camel-case after - and you'll never see this problem.

==========EDIT==========

This is the only legitimate reason this error should be showing up...

It doesn't have to be in your project directly, it could be in another project or library that your project depends on. This should show you any occurrences of the class anywhere on the build path or your project : Hit the Flashlight looking button in the Eclipse toolbar -> Choose 'Java Search' -> enter a.b.c.exception in search field -> select 'Case sensitive' -> select 'Type' in 'Search For' -> make sure all options are selected for 'Search In'.

Are you using any tools that generate classes? Could they be putting them into the build directory of your project? When you see the error, if you go to the project's build directory, and go down into the a/b/c/ directory do you see a .class file for 'exception'?

Of course Eclipse in general could have a bug (though I'd expect there would be a bug report in Eclipse 3.4 and you'd be able to find more complaints if it was...), your Eclipse install could be broken in some way (Can anyone else open your project in Eclipse 3.4? Could you do a clean Eclipse 3.4 install in another directory? Does the error appear there?), or your project could be messed up in some way (Create a new project with no dependencies other than the JDK, create the a.b.c.exception package in your new project, create a class in your project to import a.b.c.exception.*; and see if the error occurs.).

Zecchino

nops, no class named exception or Exception in the package or anywhere else. We are quite strictly sticking to the Java conventions :) – Featureless

After seeing your comment, (and this answer), I agree. Much more accurate. +1 – Extortion

Nate/VonC do you still think that this theory explains the problem I'm stating? – Featureless

Nate, thanks for explaining the possibilities. I couldn't find the type that this package is colliding with. However, when I created package with the same name in another workspace, it worked without issues. Also, in this case too when I start clean-building my workspace the error vanishes and in the end when building completes, the error crops up again. Do you think there is any way I can find the location of the type that's colliding with my package? – Featureless

Answer 3

In Java you can not have a class name that is the same as a package name.

That means the JDT package must have enforced that rule only in 3.4

See bug 63668 for instance.

---

As Nate comments:

A class named Exception won't prevent you from creating package exception.
Case matters.

Also remember the full name of a class includes the package it's in.
So a.b.SomeClass (class name) is different from x.y.SomeClass (package name).
There would be no name collision here.

The class name and the package name have to match in both case and package to cause this error.

See his more accurate answer.

Extortion

The classes in this package have different names. Package name is a.b.c.exception Classes in this package: ABCException, DEFException, GHIException Or are you saying because Java has a class/type Exception, therefore I cannot create a package named 'exception'? – Featureless

@Monis: the latter: class Exception in Java should prevent you to create a package exception. – Extortion

I would disagree b/c I have another package x.y.exception which does not give this collision with type issue. – Featureless

A class named Exception won't prevent you from creating package exception. Case matters. Also remember the full name of a class includes the package it's in. So a.b.SomeClass (class name) is different from x.y.SomeClass (package name). There would be no name collision here. The class name and the package name have to match in both case and package to cause this error. – Zecchino

right, agreed. Any pointers to what the issue is then? To me it looks related to 3.4. – Featureless

Answer 4

I know this will sound silly, and possibly too simple to be true, but I solved this exact same error message by:

• Deleting the entire line of the package name causing the error message.
• Saving the .java file(this triggers a new error on the same line stating "The declared package "" does not match the expected package"), which it should do.
• Re-typing the original package name onto the same line.
• Saving the .java file.

Could not tell you why this worked, but it did, and Eclipse stopped throwing a tantrum on the spot.

Safe typing and speedy coding.

-Goodge

Girgenti

This seems to be an eclipse bug, and the mentioned has fixed the error. Atcually, althoug the error was showing there, the compiler worked correctly. – Incendiarism

Answer 5

I encountered a similar problem in a huge code base that I inherited. It turns out that the clash was caused by an partially qualified class name in a JavaDoc link.

To paraphrase, Eclipse was telling me that I had a package/type clash for a.b.c.d. when compiling a.b.c.d.London. Doing a java search on the code for a.b.c.d revealed that Eclipse thought that a JavaDoc comment in a.b.c.Paris was a match. The JavaDoc comment contained {@ link d.NewYork}. When I changed the it to read {@link a.b.c.d.NewYork} the compilation error was resolved.

It should also be noted that NewYork was not imported into the Paris class as it only appeared in the JavaDoc comment. This also made it un-resolved in its abbreviated form and clicking on the link in the comment did not work. Making it an absolute reference also makes the JavaDoc link work.

Pindling

Answer 6

If you have a class Foo, you cannot have a package that ends with Foo, such as com.my.Foo.
Also if you are using maven style, you have resources in your project under something like src/main/resources
The folders in your resources also have a package style and there, also, you cannot have a folder that contains the name of your class.

you will definitely encounter this problem when developing a Jenkins plugin according to the recommended conventions.
if you follow the Jenkins conventions, and you create a builder in a class named MyBuilder in package x.y then you are also supposed to place your .jelly in a resource folder named x.y.MyBuilder. This will result in the above problem.
However, if you name your resource folder x.y.myBuilder (notice lower case 'm' in myBuilder), unlike the recommended convention, the plugin will still work as you intended

Rutharuthann