Home » Language IDEs » Java Development Tools (JDT) » Duplicate conflicting class definitions in different files gives confusing error messages in client
| Duplicate conflicting class definitions in different files gives confusing error messages in client [message #258005] |
Fri, 09 January 2009 05:16  |
Eclipse User |
|
|
|
Hello,
Spent a confusing 10 minutes on this today, so I am wondering if others
have come across it and if they find it the error confusing as it did to me.
Say you have two files, Ext2.ext_1.java and Ext2.ext_2.java, both of
which declare class Ext2 with one method foo with different signatures.
You also have file Ext2Client.java that calls has code that call this
method.
Eclipse correctly gives "type Ext2 already defined" for one of the two
Ext2.* files, but for the client code is `ext2.foo(0)` it complains that
foo requires to parameters and if it is `ext2.foo(0, 0)` it complains
that foo requires one parameter.
The correct error message IMHO should be that Ext2.foo has multiple
conflicting declarations.
If you are curious why I have files with multiple dots with classes
defined like this: It is created by CCRC (clearcase remote client)
plug-in when I open older versions.
Comments?
****Ext2.ext_1.java****
class Ext2 {
void foo(int i, int j){}
}
****Ext2.ext_2.java****
class Ext2 {
void foo(int i){}
}
****Ext2Client.java****
class Ext2Client {
void foo(Ext2 ext2, int i, init j) {
ext2.foo(i, j);
// ERROR foo(int) is not applicable
ext2.foo(i);
// ERROR foo(int, int) is not applicable
}
|
|
|
| Re: Duplicate conflicting class definitions in different files gives confusing error messages in cli [message #258021 is a reply to message #258005] |
Fri, 09 January 2009 15:21  |
| Eclipse User |
|
|
|
"Hemal Pandya" <hemal.pandya@gmail.com> wrote in message
news:gk7858$gfr$1@build.eclipse.org...
> Hello,
>
> Spent a confusing 10 minutes on this today, so I am wondering if others
> have come across it and if they find it the error confusing as it did to
> me.
>
> Say you have two files, Ext2.ext_1.java and Ext2.ext_2.java, both of which
> declare class Ext2 with one method foo with different signatures. You also
> have file Ext2Client.java that calls has code that call this method.
>
> Eclipse correctly gives "type Ext2 already defined" for one of the two
> Ext2.* files, but for the client code is `ext2.foo(0)` it complains that
> foo requires to parameters and if it is `ext2.foo(0, 0)` it complains that
> foo requires one parameter.
>
> The correct error message IMHO should be that Ext2.foo has multiple
> conflicting declarations.
>
> If you are curious why I have files with multiple dots with classes
> defined like this: It is created by CCRC (clearcase remote client) plug-in
> when I open older versions.
>
> Comments?
Frankly, I think that CCRC is setting you up for failure. When you go
exploring weird corner cases (such as filenames that contain dots) it will
often be true that the compiler errors are counterintuitive. I'm actually
surprised the compiler can handle that at all. Are they really in the
unnamed (default) package, as you indicated in your example?
Compilers don't really have a lot of perspective on the big picture; they
just go about their business until they stumble over something that doesn't
make sense, and then they report it. It is not always possible for the
compiler to back up and figure out what the initial cause of the problem
was, especially in corner cases. In my experience it is a lot of work to
try to improve the error messaging in these cases, and it usually ends up
breaking something else instead.
Remember that Java has some odd rules about when conflicts need to be
resolved. A conflict itself is generally legal, the problem does not occur
until some client code has to resolve the conflict. (For one example, see
JLS 9.3.2.1, "Ambiguous Inherited Fields".)
|
|
|
| Re: Duplicate conflicting class definitions in different files gives confusing error messages in cli [message #258029 is a reply to message #258021] |
Fri, 09 January 2009 21:43 |
| Eclipse User |
|
|
|
Walter Harley wrote:
> "Hemal Pandya" <hemal.pandya@gmail.com> wrote in message
> news:gk7858$gfr$1@build.eclipse.org...
>> Hello,
>>
[....]
>> Comments?
>
>
> Frankly, I think that CCRC is setting you up for failure.
Yes, but perhaps not intentionally :-)
> When you go
> exploring weird corner cases (such as filenames that contain dots) it will
> often be true that the compiler errors are counterintuitive. I'm actually
> surprised the compiler can handle that at all. Are they really in the
> unnamed (default) package, as you indicated in your example?
No, they are in some package. Does that make a difference?
> Compilers don't really have a lot of perspective on the big picture; they
> just go about their business until they stumble over something that doesn't
> make sense, and then they report it. It is not always possible for the
> compiler to back up and figure out what the initial cause of the problem
> was, especially in corner cases. In my experience it is a lot of work to
> try to improve the error messaging in these cases, and it usually ends up
> breaking something else instead.
But Eclipse is not a compiler, it is an IDE.
I wondered what is happening in this case and can't figure it out. If
the call is being matched with the first Class found, the error should
not appear in all cases. If it is matched against all matching Classes
then apparently the IDE is making the assumption that user is going to
remove the duplicates nuking all but one. But that demonstrates that it
does recognize presence of multiple definitions, even at the call site,
and it should be able to alert the user of that.
> Remember that Java has some odd rules about when conflicts need to be
> resolved. A conflict itself is generally legal, the problem does not occur
> until some client code has to resolve the conflict. (For one example, see
> JLS 9.3.2.1, "Ambiguous Inherited Fields".)
I think Eclipse already goes beyond the stipulated rules. If I can
configure it to flag unused variables as an error, I don't see a reason
why it can not tell me that the method I am calling has conflicting
definitions in multiple files.t
Interestingly, Sun javac 1.6.0_11 compiles without complaints
Ext2.ext.java and creates Ext2.class. If I compile Ext2Client when
either of the two Ext2.ext.java and Ext2.ext2.java have been compiled,
then I get error for one of the two calls but not the other. If I
compile Ext2Client.java when neither have been compiled then it
complains "cannot find symbol". Note that this is different from the
Eclipse error, perhaps javac searches for the class, not finding it
searches for Ext2.java and complains that the class Ext2 is not found.
Indeed, if Ext2.java exists it goes by whatever is in that file,
ignoring the other two.
Eclipse, on the other hand, is aware of the double-dotted filenames and
conflicting definitions but forgets about them when I need it most.
|
|
|
| Re: Duplicate conflicting class definitions in different files gives confusing error messages in cli [message #258033 is a reply to message #258029] |
Sat, 10 January 2009 03:12 |
| Eclipse User |
|
|
|
"Hemal Pandya" <hemal.pandya@gmail.com> wrote in message
news:gk920o$lhu$1@build.eclipse.org...
> No, they are in some package. Does that make a difference?
It might. When you're talking about error messages, small differences make
a difference. It can even make a difference what order the two files were
compiled in.
> But Eclipse is not a compiler, it is an IDE.
I'm not sure what you mean by that. Eclipse includes its own Java compiler;
it doesn't use javac.
Maybe you mean that because it is an IDE, it should be more helpful than a
command-line compiler? I don't see how that's relevant; it still faces the
same issue.
> I think Eclipse already goes beyond the stipulated rules. If I can
> configure it to flag unused variables as an error, I don't see a reason
> why it can not tell me that the method I am calling has conflicting
> definitions in multiple files.
You're missing my point, I think. Having conflicting definitions in
multiple files is probably not in itself an error (although it seems to me
that one of your files is missing a primary type, which I thought would be
an error, but that's where we really need to get very precise about the
contents and location of the file). The error comes when you try to use the
definition. At that point, the compiler has to figure out how to report the
problem. But a problem of this sort means that the typesystem is broken:
the compiler no longer has any ground to stand on. It doesn't know what you
were trying to do, and it doesn't know what part of the typesystem is
"right", so it doesn't know which part of it is the problem, it just knows
that things are not lining up. From your perspective, you can see that the
problem was "caused" by having conflicting definitions.
If you're lucky, it'll report the problem in a way that makes sense to you.
But sometimes not. The compiler developers work really hard to try to get
it to be helpful most of the time, and they do a surprisingly good job, but
sometimes the necessary perspective is just not available at the time the
error is detected.
This is one reason why the Java Language Spec does not generally specify
what error messages should be produced in various error conditions. It
turns out that even defining particular error conditions is quite hard and
very implementation-dependent. The human brain, with its capacity for
introspection and awareness of purpose, is a very remarkable thing;
compilers are not nearly so self-aware, yet.
|
|
|
| Re: Duplicate conflicting class definitions in different files gives confusing error messages in cli [message #258037 is a reply to message #258033] |
Sat, 10 January 2009 08:46 |
| Eclipse User |
|
|
|
Walter Harley wrote:
> "Hemal Pandya" <hemal.pandya@gmail.com> wrote in message
> news:gk920o$lhu$1@build.eclipse.org...
>
>> But Eclipse is not a compiler, it is an IDE.
>
> I'm not sure what you mean by that. Eclipse includes its own Java compiler;
> it doesn't use javac.
>
> Maybe you mean that because it is an IDE, it should be more helpful than a
> command-line compiler? I don't see how that's relevant; it still faces the
> same issue.
Yes, that's what I mean.
>> I think Eclipse already goes beyond the stipulated rules. If I can
>> configure it to flag unused variables as an error, I don't see a reason
>> why it can not tell me that the method I am calling has conflicting
>> definitions in multiple files.
>
> You're missing my point, I think.
Perhaps. I think you are missing my point too :-)
> Having conflicting definitions in
> multiple files is probably not in itself an error (although it seems to me
> that one of your files is missing a primary type, which I thought would be
> an error, but that's where we really need to get very precise about the
> contents and location of the file). The error comes when you try to use the
> definition. At that point, the compiler has to figure out how to report the
> problem. But a problem of this sort means that the typesystem is broken:
> the compiler no longer has any ground to stand on. It doesn't know what you
> were trying to do, and it doesn't know what part of the typesystem is
> "right", so it doesn't know which part of it is the problem, it just knows
> that things are not lining up. From your perspective, you can see that the
> problem was "caused" by having conflicting definitions.
>
> If you're lucky, it'll report the problem in a way that makes sense to you.
> But sometimes not. The compiler developers work really hard to try to get
> it to be helpful most of the time, and they do a surprisingly good job, but
> sometimes the necessary perspective is just not available at the time the
> error is detected.
>
> This is one reason why the Java Language Spec does not generally specify
> what error messages should be produced in various error conditions. It
> turns out that even defining particular error conditions is quite hard and
> very implementation-dependent. The human brain, with its capacity for
> introspection and awareness of purpose, is a very remarkable thing;
> compilers are not nearly so self-aware, yet.
You are quite correct. And that is why Eclipse has "Potential
programming problems" section.
May be I am not able to see beyond my issue. Can you see any
circumstance when such a situation -- access to a class/member that has
conflicting definition in multiple resources -- can be resolved *only*
by eliminating that conflict. If there are many such situations, then my
suggestion is worthless otherwise I feel it holds some merit.
|
|
|
| Re: Duplicate conflicting class definitions in different files gives confusing error messages in cli [message #258041 is a reply to message #258037] |
Sat, 10 January 2009 12:28 |
| Eclipse User |
|
|
|
"Hemal Pandya" <hemal.pandya@gmail.com> wrote in message
news:gka8s2$2pf$1@build.eclipse.org...
> You are quite correct. And that is why Eclipse has "Potential programming
> problems" section.
Okay, I think I understand your point now. To paraphrase, you'd like to see
an optional warning for conflicting definitions.
Offhand I have a hunch that might be rather difficult to implement; it's
asking a subjunctive question, "are there any existing definitions such that
adding some hypothetical client definition would cause an unresolvable
conflict." Or, you could take it to only apply when some sort of typesystem
problem has already been detected - that is, "if a typesystem-related
warning or error is about to be produced, check to see whether there are any
unresolvable conflicts in the typesystem." Again, I'm not sure that the
compiler maintains enough perspective to actually answer that question, but
it does seem like a reasonable feature request. You might want to enter an
enhancement request in Bugzilla for that, including at least one complete
example of a failing case that currently generates a misleading error code.
> May be I am not able to see beyond my issue. Can you see any circumstance
> when such a situation -- access to a class/member that has conflicting
> definition in multiple resources -- can be resolved *only* by eliminating
> that conflict. If there are many such situations, then my suggestion is
> worthless otherwise I feel it holds some merit.
ISTR seeing some examples of that in the Java Puzzlers book just recently,
but I don't remember exactly where. Sometimes colliding definitions are not
a conflict at all, as when constants are defined with the same value in
multiply inherited interfaces. Sometimes the client can be rewritten to
disambiguate, for example by using a qualified name rather than a simple
name.
If it were me coming up with the set of Potential Programming Problems, i.e.
"things that shouldn't be legal even if they technically are", I would have
put "the file name contains a dot" high on that list :-) Does the
misleading error message occur in a case where that is not part of the
problem?
|
|
|
Goto Forum:
Current Time: Thu Apr 24 23:43:51 EDT 2025
Powered by FUDForum. Page generated in 0.03352 seconds |
Home