Community
Participate
Working Groups
AIM Issue Tracker is HD100125. This problem does not happen in Eclipse 1.0, only in WSWB 1.0. Using a fully qualified class name breaks the visiblity of the superclass. If you don't use the fully qualified name, it is fine. Is the compiler different in WSWB 1.0 and Eclipse 1.0? Try to build the following 2 classes in a package called problem1 in WSWB: ================== package problem1; class B { } ================== package problem1; class A extends problem1.B { } ================== You will see an error in the Tasks List saying: Superclass problem 1.B is not visible
It should not make a difference, even in 2.0 we should compile it clear. Should investigate.
There is no error in 2.0. It compiles fine. Where can I get a copy of WSWB 1.0. I need it in order to reproduce this problem.
You can get WSWB 1.0 from the jumpstart page. This is where our customers are downloading the product: http://jumpstart.raleigh.ibm.com/Workbench_Drivers/WSWB_1_0/wswb_1_0.html
I reproduced the problem in both eclipse 1.0 and wswb 1.0. So it makes sense that the two behaviors are consistent. Should we investigate a fix or is it fine to say this is fixed in 2.0?
The customer has been told that it is fixed in 2.0, but they are still requesting a fix. They claim they have too many errors to use a workaround of not using fully qualified class names.
Fix proposal: Instead of: if (checkVisibility && n == size) { // if we're finished and know the final superinterface then check visibility SourceTypeBinding enclosingSourceType = enclosingSourceType(); if (enclosingSourceType == null ? !superType.canBeSeenBy(sourceType.fPackage) : !superType.canBeSeenBy(sourceType, enclosingSourceType)) return new ProblemReferenceBinding (CharOperation.subarray(compoundName, 0, n), NotVisible); } I would put: if (checkVisibility && n == size) { // if we're finished and know the final superinterface then check visibility if (!superType.canBeSeenBy(sourceType.fPackage)) return new ProblemReferenceBinding(CharOperation.subarray(compoundName, 0, n), NotVisible); } According to the existing code in 2.0. Could you please, Philippe, double check it? Thanks.
Olivier - did you check other occurrences of usage of #checkVisibility ? Have they all evolved in the same way ?
This seems to be the only occurrence of checkVisibility with a condition on the enclosing type.
Backporting 2.0 behavior, and issuing a patch for this one, see details on the JDT/Core page (plug-in version for it will be 1.0.6) : http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt-core- home/patches/org.eclipse.jdt.core_1.0.6.zip
Sent fix to customer
Can we closed this defect ?
Actually, was closed already.
