Bug 197271 - [compiler] Compile in Eclipse works as expected, but not with JVM 1.6.1
Summary: [compiler] Compile in Eclipse works as expected, but not with JVM 1.6.1
Status: VERIFIED WORKSFORME
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2.1   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.5 M4   Edit
Assignee: Kent Johnson CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-20 05:11 EDT by Daniel Migowski CLA
Modified: 2008-12-08 21:45 EST (History)
2 users (show)

See Also:


Attachments
Source file that shows up the bug. (693 bytes, application/octet-stream)
2007-07-20 05:12 EDT, Daniel Migowski CLA
no flags Details
Proposed patch with testcase (3.54 KB, patch)
2008-12-03 15:08 EST, Kent Johnson CLA
no flags Details | Diff
Proposed patch with testcase for 3.4.2 (3.85 KB, patch)
2008-12-04 11:43 EST, Kent Johnson CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Migowski CLA 2007-07-20 05:11:20 EDT
Build ID: M20070212-1330

Steps To Reproduce:
1. Take the attached class file.
2. See how eclipse compiles it without problems.
3. Compile with the Sun JVM at the command line at receive the following error:
de\ikoffice\EclipseBug.java:28: hello() in de.ikoffice.EclipseBug cannot be appl
ied to (java.lang.String)
             hello("static Class!");
             ^
1 error

More information:
It can be solved by calling hello() with EclipseBug.hello(), but Eclipse should either throw an exception, too, to be comform with the JVM, or forward his bug to sun.
Comment 1 Daniel Migowski CLA 2007-07-20 05:12:47 EDT
Created attachment 74243 [details]
Source file that shows up the bug.
Comment 2 Kent Johnson CLA 2007-08-09 14:05:12 EDT
The example code compiles fine with javac prior to 1.5

Need to investigate why javac changed their behaviour
Comment 3 Kent Johnson CLA 2008-04-22 15:31:42 EDT
Its not an issue of private static fields/methods no longer being visible. Both of these cases compile fine.

class EclipseBug {
	//void hello() { System.out.println("Hello Instance!"); }
	private static void hello(String who) {
		System.out.println("Hello "+who+"!");
	}
	static class EclipseBugInnerClass extends EclipseBug {
		public void innerHello() { hello("static Class!"); }
	}
}

class EclipseBug2 {
	private static String foo = "static Class!";

	static class EclipseBugInnerClass extends EclipseBug {
		public void test() { System.out.println(foo); }
	}
	public static void main(String[] s) {
		new EclipseBugInnerClass().test();
	}
}
Comment 4 Brian Southey CLA 2008-06-11 08:22:31 EDT
Ive just downloaded eclipse-cpp-europa-winter-win32, mingw

I compiled and ran the intro."Hello World" prog. ok.
 
   However, when I try to build and run it again as the helloworld program, 
  I get the following error :

  **** Internal Builder is used for build ****
  gcc -O0 -g3 -Wall -c -fmessage-length=0 -osrc\helloworld.o .\src\helloworld.c
  gcc: installation problem, cannot exec `cc1': No such file or directory
  Build error occurred, build is stopped
  Time consumed: 125 ms.

Also as I try and work thro. other projects they seem to get mixed up with each other, and the runs fail.
Error messages are launch failed no binaries etc.

Is there a way of clearing failed projects from the platform completely?
I have printed out several tutorials but they dont ans. this.

I may say that eclipse came as a breath of fresh air after the useless Borland C++ compiler and the worse Microsoft .Net framework 3.5 and vis C++ x 86!

However there are still problems.
Comment 5 Kent Johnson CLA 2008-06-11 10:11:45 EDT
Brian - I don't think this bug has anything to do with your example. This is a specific problem with the Java compiler spec (Not C++).


I suggest you join the Eclipse/C++ newsgroup & ask your question there.
Comment 6 Brian Southey CLA 2008-06-12 02:08:55 EDT
(In reply to comment #5)
> Brian - I don't think this bug has anything to do with your example. This is a
> specific problem with the Java compiler spec (Not C++).
> I suggest you join the Eclipse/C++ newsgroup & ask your question there.

Please tell me how to join Eclipse/C++ thro. bugzilla?

Thanks

Brian
Comment 7 Kent Johnson CLA 2008-12-02 14:27:38 EST
In addition to the cases in comment #3, this case also compiles fine in javac 1.5 & above

class EclipseBug {
        private void hello() { System.out.println(1); }
        private static void hello(String who) { System.out.println(2); }
        static class EclipseBugInnerClass extends EclipseBug {
                public void innerHello() { hello(""); }
        }
}


So its only the case when the instance method is NOT private but the matching static method IS private.
Comment 8 Kent Johnson CLA 2008-12-02 15:37:19 EST
class EclipseBug {
  void hello() { System.out.println(1); }
  private static void hello(String who) { System.out.println(2); }

  static class E1 extends EclipseBug {
    public void x() { hello(null); } // fails in 1.5 & above, succeeds in 1.4
    public void y(E1 e) { e.hello(null); } // fails
  }
  static class E2 {
    public void x() { hello(null); } // succeeds
    public void y(E1 e) { e.hello(null); } // fails
  }
}

class E3 extends EclipseBug {
  public void x() { hello(null); } // fails
  public void y(E3  e) { e.hello(null); } // fails
}


So between 1.4 & 1.5, E1.x() compiles differently. The visible inherited method hello() found by walking the superclass chain takes precedence over the private static method found in the outer class scope.
Comment 9 Kent Johnson CLA 2008-12-03 15:08:54 EST
Created attachment 119423 [details]
Proposed patch with testcase
Comment 10 Kent Johnson CLA 2008-12-04 11:43:16 EST
Created attachment 119525 [details]
Proposed patch with testcase for 3.4.2

If we need it
Comment 11 Kent Johnson CLA 2008-12-04 12:00:38 EST
Just before I released the fix, I tried with the latest JDK7 build (1.7.0-ea-b40) and javac has changed their behaviour back to what it was in 1.4 & now accept a matching private static method again.

So we will keep our current behaviour.

Test released for 3.5M4
Comment 12 Olivier Thomann CLA 2008-12-08 21:45:25 EST
Verified for 3.5M4 using I20081208-1800