Bug 33843 - Compiler incorrectly generating static method calls
Summary: Compiler incorrectly generating static method calls
Status: RESOLVED WONTFIX
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 2.1   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 2.1 RC2   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-03-05 10:37 EST by Jon Skeet CLA
Modified: 2003-03-07 13:23 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jon Skeet CLA 2003-03-05 10:37:52 EST
I believe according to JLS, that the call from Main in the following code should
compile to Derived.foo() even though only Base.foo() gets called. Eclipse
compiles  directly to Base.foo.

public class Main
{
    public static void main(String[] args)
    {
         Derived.foo();
    }
}

public class Base
{
    public static void foo()
    {
    }
}

public class Derived extends Base
{
}

It would only cause a problem if a classloader really needed the information
that Derived is loaded, even though Derived is *not* initialised by the above.
Comment 1 Jon Skeet CLA 2003-03-05 10:38:13 EST
(Sorry, should have said: reported against RC1)
Comment 2 Jerome Lanneluc CLA 2003-03-05 10:44:42 EST
Were you using the 1.3 or the 1.4 compliance setting?
Comment 3 Philipe Mulet CLA 2003-03-05 10:54:30 EST
A static method invocation is still to be performed, however in between 1.3 and 
1.4 a small nuance was made.

The declaring type of the reference to #foo() in Main is 'Base' in 1.3, 
and 'Derived' in 1.4 (the declaring type is the receiver type from 1.4 on).

This can actually make a difference when playing with binary compatibility, and 
adding a definition of #foo() on Derived without recompiling Main.

Comment 4 Philipe Mulet CLA 2003-03-05 12:24:28 EST
Olivier - pls check javac behavior, I believe we have the same.
Comment 5 Jon Skeet CLA 2003-03-05 12:48:16 EST
JDK1.3.1 does indeed exhibit the 1.3 behaviour - but I would argue that that's
just a bug in the 1.3.1 compiler, which shouldn't be emulated here. No doubt 1.3
had other bugs - do you wish to emulate all of them? There's a difference (IMO)
between compliance to varying standards, and emulation of bugs in prior
implementations of those standards.
Comment 6 Olivier Thomann CLA 2003-03-05 13:18:59 EST
The 1.3 and 1.4 compliance mode follows exactly the same behavior than 
respectively javac 1.3.1 and javac 1.4.1. I am not sure we can actually change 
this behavior in our 1.3 compliance mode and still pass all JCK 1.3 tests.

Philippe, what do you think?
Comment 7 Jon Skeet CLA 2003-03-06 03:09:24 EST
One note of potential interest: when you compile with javac -target 1.3 where
javac is from JDK1.4.1, it doesn't revert to the 1.3 behaviour. If javac isn't
going to emulate its previous bugs, why should Eclipse? ;)
Comment 8 Philipe Mulet CLA 2003-03-06 05:26:56 EST
Javac from jdk1.4 is matching Eclipse Java compiler 1.4 compliant mode.
Javac from jdk1.3 is matching Eclipse Java compiler 1.3 compliant mode.

The target setting is irrelevant, it denotes the version tagged into classfiles 
(major/minor). The source setting level is also irrelevant, it enables/disables 
assertion.

So toggling the compliance mode is the way to go to get the proper behavior. 
There are many more differences in our 1.3 and 1.4 compliant mode, most of them 
account for clarifications of the specs which occurred since 1.3 went out.

One thing to keep in mind is that there isn't a global JCK, but rather a JCK1.3 
and a JCK1.4 which makes some assumption on the respective compiler behaviors...

Closing, working as designed. Toggling compliance level is the proper way to 
match expectation.
Comment 9 Philipe Mulet CLA 2003-03-07 06:23:54 EST
*** Bug 34000 has been marked as a duplicate of this bug. ***
Comment 10 Philipe Mulet CLA 2003-03-07 13:21:41 EST
One small nuance to this is that if target >= 1.2, then the receiver type is 
used (as opposed to declaring type), also see bug 34078.
Comment 11 Philipe Mulet CLA 2003-03-07 13:23:26 EST
Related bug is rather bug 34000