Eclipse Community Forums: Java Development Tools (JDT) » Generic Name Clash in one workspace but not other

Home » Language IDEs » Java Development Tools (JDT) » Generic Name Clash in one workspace but not other(I have one workspace reporting a name clash but another that does not.)

Show: Today's Messages :: Show Polls :: Message Navigator

Generic Name Clash in one workspace but not other [message #653385]

Wed, 09 February 2011 15:36

No real name

Messages: 7
Registered: February 2011

Junior Member

Hi all,

I have seen many posts in the bug repository regarding type name clashes and it seems some are attributable to the JDK others to Eclipse. I'm not sure which situation my scenario falls into but it does seem that the issue I am encountering may be related to my workspace.

I have a class which extends HashSet which in turn overrides the the addAll(...) method of AbstractCollection. When the project is built in one workspace the compiler reports the following error:

Type Name clash: The method addAll(Collection<SuperContent>) of type ExtendedSet has the same erasure as addAll(Collection<? extends E>) of type AbstractCollection<E> but does not override it.

Another workspace on my machine and those of coworkers using the same source and project settings from our repository do not report this issue. We are using JDK 1.6.0_23 in all workspaces. I am running Helios build 20100917-0705 while my coworker is running Galileo, Version: 3.5.2
Build id: M20100211-1343.

For reference:
SomeContent extends SuperContent

public class ExtendedSet extends HashSet<SomeContent>{
    public void addAll( Collection<SuperContent> items )    {
        ...
    }
}

and from the JDK AbstractCollection defines:

public boolean addAll(Collection<? extends E> c) {
    ...
}

As I understand, after erasure the return type becomes irrelevant. Regardless, I have modified the overidden addAll(...) to return a boolean and I saw no change to the errors being reported.

If the error being reported is valid, that's fine and I can look to correct the issue. My main concern is the inconsistency of the IDE in reporting the issue. It leads me to believe that there may be an issue in the workspace that needs to be resolved.

It may be interesting to note that I was able to compile the project briefly without making changes to anything. After restarting Eclipse(reluctantly, because I was worried this would happen...) , the issue came back.

Anyone have ideas regarding the reason this one workspace would be reporting this issue and how I might be able to get rid of the errors?

Thanks.

Report message to a moderator

Re: Generic Name Clash in one workspace but not other [message #653518 is a reply to message #653385]

Thu, 10 February 2011 05:15

Srikanth Sankaran

Messages: 5
Registered: July 2009

Junior Member

The error is due to eclipse adjusting its behavior
to match JDK7 javac compiler. If I compile the code
using Javac 7b127, I get the same error:

C:\jtests> C:\jdk-7-ea-bin-b127-windows-i586-27_jan_2011\jdk7\jdk1.7.0\ bin\javac
-Xlint:unchecked -Xlint:rawtypes -Xlint:deprecation -sourcepath c:\jtests Extend
edSet.java
ExtendedSet.java:5: name clash: addAll(Collection<SuperContent>) in ExtendedSet
and addAll(Collection<? extends E>) in AbstractCollection have the same erasure,
yet neither overrides the other
public boolean addAll( Collection<SuperContent> items ) {
^
where E is a type-variable:
E extends Object declared in class AbstractCollection
1 error

See:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=289247
http://bugs.sun.com/view_bug.do?bug_id=6182950

Report message to a moderator

Re: Generic Name Clash in one workspace but not other [message #653520 is a reply to message #653518]

Thu, 10 February 2011 05:25

Srikanth Sankaran

Messages: 5
Registered: July 2009

Junior Member

I think you had noticed the part of return types
not being a part of signature already.

So the erasures of the methods are the same
(since return type should not be considered
when computing the erasure of method signature),
but ExtendedSet.addAll( Collection<SuperContent> items )
does not override java.util.AbstractCollection.addAll(Collection<? extends E>).
For it to override the super's method properly, its signature
should have been declared as ExtendedSet.addAll(Collection<? extends SomeContent>)
(accouting for proper substitution of type variables)

So, that javac5 & 6 compile this code is a bug.

In fact if you change the return type to boolean,
evan javac5 & 6 will reject the code.

Report message to a moderator

Re: Generic Name Clash in one workspace but not other [message #653633 is a reply to message #653385]

Thu, 10 February 2011 13:43

No real name

Messages: 7
Registered: February 2011

Junior Member

Excellent! Thanks for that. Nice to see some validation on what I thought should be the correct way to override the method.

I did previously make the signature change so the method was defined as ExtendedSet.addAll(Collection<? extends SomeContent>) but I still seem to get the name clash, as I am seeing now after making the change again.

Are you saying this should build now that the method is defined as ExtendedSet.addAll(Collection<? extends SomeContent>) and still pointing to jdk 1.6.0_23?

The thing that bothers me is I have three environments (plus automated build scripts) all pointing to the same Java 6 version and only one shows this error. In fact, all environments were compiling this at one time until I had to restart Eclipse after which the problem returned. That's why I am wondering if I have a problem in my workspace.

Thanks again for your insight. It is greatly appreciated.

Report message to a moderator

Re: Generic Name Clash in one workspace but not other [message #653647 is a reply to message #653633]

Thu, 10 February 2011 14:27

No real name

Messages: 7
Registered: February 2011

Junior Member

Alright, now I'm confused...

If I build the modified code against 1.7.0-ea-b128, as I understood, it should compile. What I find instead is the modified code as presented below compiles in 1.6.0_23 but not in 1.7.0-ea-b128.

In fact, the original (incorrect?) and modified signatures are building at the command line for 1.6, but neither build for 1.7ea.

I hope that I am doing something so obviously wrong that I am just seeing past it.

/*
ExtendedSet.java
*/
import java.util.Collection;
import java.util.HashSet;

public class ExtendedSet extends HashSet<SomeContent>
{
    public void addAll(Collection<? extends SuperContent> items)
    {
        
    }
}

/*
SuperContent.java
*/
public class SuperContent
{

}

/*
SomeContent.java
*/

public class SomeContent extends SuperContent
{

}

Report message to a moderator

Re: Generic Name Clash in one workspace but not other [message #653809 is a reply to message #653647]

Fri, 11 February 2011 10:40

Satyam Kandula

Messages: 444
Registered: July 2009

Senior Member

It should be

public boolean addAll(Collection<? extends SomeContent> items)

Note two changes: the return type should be boolean and '? extends SuperContent' should be '? extends SomeContent'.

Report message to a moderator

Re: Generic Name Clash in one workspace but not other [message #653861 is a reply to message #653809]

Fri, 11 February 2011 15:42

No real name

Messages: 7
Registered: February 2011

Junior Member

Hmmm, everything I've read indicates the return type is not part of the erasure (see also srikanth's post below), regardless, adding the return type does not resolve the compilation error anyway.

I am still confused over the fact that this does compile in another project and on other machines pointing to the same jdk, although using a different Eclipse version (Galileo).

I'll try to find that version of Eclipse and see if it helps.

Report message to a moderator

Re: Generic Name Clash in one workspace but not other [message #654100 is a reply to message #653861]

Mon, 14 February 2011 08:26

Satyam Kandula

Messages: 444
Registered: July 2009

Senior Member

Submitting the following detailed description from Srikanth
######
The reason the following code compiles with javac5 & 6
but not with javac7 is that, the return type of a method
is not to be treated as a part of the method's signature
but javac5 & 6 incorrectly do so. In effect they treat the
void method as being distinctly different from the boolean
method of the super class. Since these are (incorrectly)
deduced to be different methods, the clash is not reported.

On the contrary, javac 7 correctly ignores the return type
while computing erasure and complains of a name clash
since the erasures are identical, but the subclass method
is not overriding to the superclass method.

/*
ExtendedSet.java
*/
import java.util.Collection;
import java.util.HashSet;

public class ExtendedSet extends HashSet<SomeContent>
{
    public void addAll(Collection<? extends SuperContent> items)
    {

    }
}

/*
SuperContent.java
*/
public class SuperContent
{

}

/*
SomeContent.java
*/

public class SomeContent extends SuperContent
{

}

In one of my earlier comment I had mentioned:

"In fact if you change the return type to boolean,
evan javac5 & 6 will reject the code."

i.e

public class ExtendedSet extends HashSet<SomeContent>
{
    public boolean addAll(Collection<SuperContent> items)
    {
	    return false;
    }
}

would fail to compile with javac 5,6. This is because
since the return type is now identical, the method is
not mistakenly treated as an altogether different method
by the compiler. Now since the erasure is the same
but the subclass method does not override the super
class method even javac 5 & 6 complains.

See that eclipse Galileo had a buggy behavior analahous
to javac 5,6. This was fixed in 3.6 M2 via
https://bugs.eclipse.org/bugs/show_bug.cgi?id=289247

Hope this helps.
########

Report message to a moderator

Re: Generic Name Clash in one workspace but not other [message #654169 is a reply to message #654100]

Mon, 14 February 2011 13:29

No real name

Messages: 7
Registered: February 2011

Junior Member

I suppose I should reiterate that the problem is not with the error itself it's that no matter how I write the method, no matter the jdk I compile against, I get the name clash compile error. This happens regardless of the eclipse version I am using (Eurpoa, Galileo, Helios).

Identical code checked out from the same repository on a coworkers machine compiles fine (even with the incorrectly overridden method). Our Java 6 build script correctly compiles the incorrect method declaration as well.

Incorrect declaration:

public void addAll(Collection<SuperContent> items)

In fact, I even have a plugin project using this incorrectly declared method without issue.

Also, the 'correct' declaration as provided in the last posted example does not build.

To me, this seems like a problem in my workspace. The fact that I can not get this to build in any environment regardless of how I declare the addAll() method is what really bothers me. I really can't change to Java7 without a huge procedural effort. I can use whatever Eclipse version I can get this to work in but I would just like to see it work somewhere, with some degree of consistency across different machines and in some cases different projects.

Is there some obscure "Eclipse-ism" that I need to perform to get one of the method declarations to compile?

Thanks again.

Report message to a moderator

Re: Generic Name Clash in one workspace but not other [message #654219 is a reply to message #654169]

Mon, 14 February 2011 15:58

Satyam Kandula

Messages: 444
Registered: July 2009

Senior Member

May be there is a different problem with your workspace, but let me reiterate our point to you. javac 6 and Eclipse 3.5 is doing wrong. The behavior in Eclipse 3.6 should be good. Saying that, we are not asking you to move to Java7, we are just telling that using proper code should fix errors from any Javac versions or Eclipse versions.

As I understand you are getting errors even with the correct code. To avoid any further confusion, let us talk about only the correct code. Please answer the following questions (some of them may be lame, but will probably rule out any doubts, sorry for that).
1. Did you try a full clean and build?
2. Did you try your sample (correct) code given as under as it is and do you still see errors? I have tried across 3.6.1, 3.6.2 and 3.7M5 and in all it works good. What errors do you see -- Is it Name clash?
3. If it works good for not the sample and not your original test case, is there a way you can give that to us.
4. Does your java build scripts work good with this new code?

Report message to a moderator

Re: Generic Name Clash in one workspace but not other [message #654235 is a reply to message #654219]

Mon, 14 February 2011 17:17

No real name

Messages: 7
Registered: February 2011

Junior Member

Satyam Kandula wrote on Mon, 14 February 2011 10:58

(some of them may be lame, but will probably rule out any doubts,
sorry for that).

No need to apologize. I suspect this is an environment issue and any question may help to shed light on the root off it.
Answers below...

1. Did you try a full clean and build?
Yes. I have several closed projects, not sure if that matters but two open projects including the production source and the example that was built using the source.

2. Did you try your sample (correct) code given as under as it is and do you still see errors? I have tried across 3.6.1, 3.6.2 and 3.7M5 and in all it works good. What errors do you see -- Is it Name clash?
The error I see is the name clash in all of the problem environments.
Name clash: The method addAll(Collection<? extends SuperContent>) of type ExtendedSet has the same erasure as addAll(Collection<? extends E>) of type AbstractCollection<E> but does not override it ExtendedSet.java /GenericsTest/src line 6 Java Problem

3. If it works good for not the sample and not your original test case, is there a way you can give that to us.
The example does not work and is really no different than the source from which it was taken except for the method body.

4. Does your java build scripts work good with this new code?
In answering this I see that my local environment does not build this line at all. It does not matter which method signature I provide leading me to believe my setup is questionable.

Would you mind letting me know which JDK you built against please? My suspicion is that there is confusion over which version of java is being referenced. I believe I have verified all of the settings in the workspace but it seems as though I have missed something.

Perhaps a quick recommendation of where to look in the IDE for common java configuration issues would help?

Thanks again,
Pat.

Report message to a moderator

Re: Generic Name Clash in one workspace but not other [message #654243 is a reply to message #654235]

Mon, 14 February 2011 17:35

Satyam Kandula

Messages: 444
Registered: July 2009

Senior Member

Thanks for your detailed answers.
Are you using <? extends SuperContent> or <? extends SomeContent>? It should be SomeContent and not SuperContent! Just to be clear, here is the correct code. Copy the testcase as it is and just paste it in your package explorer and please try out.

/*
ExtendedSet.java
*/
import java.util.Collection;
import java.util.HashSet;
public class ExtendedSet extends HashSet<SomeContent>
{
    public boolean addAll(Collection<? extends SomeContent> items)
    {
         return true;
    }
}

/*
SuperContent.java
*/
public class SuperContent
{

}

/*
SomeContent.java
*/
public class SomeContent extends SuperContent
{

}

I am not sure if you are clear, but Eclipse has its own compiler and it doesn't need a JDK. Only thing that matters here is the compliance. However, as you have asked, I have tried with Sun JDKs 1.5.0.22 and Sun JDKs 1.6.0_23 javacs on this particular file.
Let me know how it goes.

Report message to a moderator

Re: Generic Name Clash in one workspace but not other [message #654255 is a reply to message #654243]

Mon, 14 February 2011 19:00

No real name

Messages: 7
Registered: February 2011

Junior Member

Yes, that does fix the issue in my environment!

I still have no idea why this builds on other machines but I can't really take those over to fix what is NOT being indicated as broken.

Thank you for being a great second set of eyes and letting me know the right way to declare this class\method.

Pat.

Report message to a moderator

Previous Topic:	integration of JDT with Editor
Next Topic:	Run class file without source .java files

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Apr 23 10:36:39 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter