Summary: | [compiler] visibility error for package private method | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Michael Chervil <michael.krkoska> | ||||||
Component: | Core | Assignee: | Srikanth Sankaran <srikanth_sankaran> | ||||||
Status: | VERIFIED FIXED | QA Contact: | |||||||
Severity: | normal | ||||||||
Priority: | P3 | CC: | jarthana, kent_johnson, Olivier_Thomann | ||||||
Version: | 3.5 | ||||||||
Target Milestone: | 3.6 M4 | ||||||||
Hardware: | PC | ||||||||
OS: | Windows XP | ||||||||
Whiteboard: | |||||||||
Attachments: |
|
This is the error I get from javac 7 and eclipse : CompilerBug.java:17: privateMethod() in CompilerBug is defined in an inaccessibl e class or interface getClass().newInstance().privateMethod(); ^ 1 error javac 1.5 & 6 compile it without error This is a result of the fix for bug 257434 Verified for 3.6M1 Reopening this defect to take a closer look. See that javac & eclipse are complaining about entirely different lines of code. // complained about by java 7, but not eclipse. getClass().newInstance().privateMethod(); // complained about by eclipse, but not java 7. getClass().newInstance().packagePrivateMethod(); Eclipse head behavior is at odds with java 7. Kent, can you comment on it ? Thanks. Yes - you're right. To be compatible with javac 7, we should find the private method not visible. I'll work on it today - we can talk about it tomorrow morning. Created attachment 150812 [details]
Potential patch
Kent, please take a look. I left the behavior about private member
access as it is (as I strongly suspect it is a javac7 bug) and fixed
only the access problems package private members.
The patch looks good. We just need to clarify whether the 'new' javac 7 behaviour is a bug or not (& I do agree with you that its likely a bug). Released in HEAD for 3.6M4 The open issue surrounding the private method access, which we believe is a bug in javac, has been reported to Sun compiler team. Thank you for reopening and fixing this. It actually even helps me :) I don't believe Sun will accept the disallowed access to private methods as a compiler bug. getClass() returns Class<MyClass>. An instance of Class<MyClass> could be any subclass (in my usecase it IS a subclass). The subclass might also have a private method of the same name. Now which one gets called? Doesn't seem easy to answer. I guess that's the reason why they changed it. (In reply to comment #9) > Thank you for reopening and fixing this. It actually even helps me :) You are welcome. (The recommendation from Sun is to leave the private method access as it is.) Verified for 3.6M4 using build I20091207-1800 |
Created attachment 142884 [details] java source showing the possible bug Using 3.5 I get the compiler error message "The method packagePrivateMethod() from the type CompilerBug" for the attached java source at line 18. JavaC doesn't have the problem with the source. Am I missing something, or is this a bug?