Community
Participate
Working Groups
In JDK1.5, StringBuffer have been refactored and now inherits from AbstractStringBuilder. The AbstractStringBuilder have a lot method append that return an AbstractStringBuilder. In the class, StringBuffer all this methods have their counterparts that return a StringBuffer. The problems comes when you try to use one of this append method. example new StringBuffer().append(1); The eclipse compiler returns an error "The type AbstractStringBuilder is not visible". I think its an error in compiler method lookup that prefers AbstractStringBuilder.append(int) to StringBuffer.append(int). I think this is a major bug 'cause programmer cannot test jdk1.5 api.
The problem comes from the fact our compiler isn't 1.5 yet. StringBuffer defines alternate methods with distinct return types. These are bridge methods used to perform mapping at runtime (which cares about return types in signature). --> java.lang.AbstractStringBuilder append(java.lang.String) java.lang.StringBuffer append(java.lang.String) --> java.lang.Appendable append(char) throws java.io.IOException java.lang.StringBuffer append(char[]) The 1.4 compiler doesn't expect this scenario, and thus incorrectly pick the wrong method (due to ordering of methods in classfile). Extra checks are necessary so as to select the proper method.
*** Bug 51864 has been marked as a duplicate of this bug. ***
Fix is to filter out bridge methods (as synthetics) from binary bindings. This could be applied to HEAD stream independently from 1.5 branch, since it will not impact existing code.
One thing which is troublesome is that the 1.5 spec seems to have changed the value of ACC_SYNTHETIC from 0x20000 to 0x1000, which will render all libraries compiled with <1.5 compilers obsolete (as <1.5 generated synthetics are no longer recognized as such by 1.5 standards). We may want to consider both values as synthetic for backward compatibility...
Actually, ACC_SYNTHETIC does not cause grief. It was not a public flag in the past, only an attribute. We can make it reflect the new value, and convert attribute to modifiers from 1.5 on. No need to check for bridge methods, as these are also marked as synthetics. Fixed by simply setting AccSynthetic to 0x1000.
Fixed
*** Bug 51707 has been marked as a duplicate of this bug. ***
*** Bug 52979 has been marked as a duplicate of this bug. ***
*** Bug 54673 has been marked as a duplicate of this bug. ***
Verified in build I200403240800.
*** Bug 56277 has been marked as a duplicate of this bug. ***
This bug seems to have reappeared in 3.2 M5 release. I upgraded from M4 to M5 (Version: 3.2.0 Build id: I20060217-1115) and get both: "The type AbstractStringBuilder is not visible" and "Unhandled exception type IOException" wherever I use StringBuffer.append() methods. I am using: "java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)" If I swap to: "java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2)" the errors disappear.
This is likely a consequence of fixing bug 124943. Kent - pls have a look, and file a new bug report if needed.
Trevor, can you provide a testcase? When I try a simple case with new StringBuffer().append(1), it works fine in 1.4 & 5.0 modes.
I cannot reproduce this in a standalone test case. The following is code that fails in my large project. public class Testm5a { public String test() { char ch = 'a'; StringBuffer addressStr = new StringBuffer(); // This causes The type AbstractStringBuilder is not visible addressStr.append("AAAA").append("AAAAA"); // This gives unhandled exception IO exception addressStr.append(ch); return addressStr.toString(); } } From my testing in my large project the error only seems to occur when I use buff.append().append();. If I break the code to use buff.append(); buff.append(); the error does not occur. And the IO Exception only seems to come from the append(char ch) method. My project giving the error is part of a set of about 15 related projects that I created under M4 release. I have now also taken a copy of my source and created a new single project and the errors disappear, but when I recreated the set of original projects the errors remained.
Cannot reproduce with 3.2 RC1 and comment 15 test case... I've also verified all duplicate and everything is fine => close as WORKSFORME
Sorry, WORKSFORME is not a correct resolution
It should be FIXED, as this issue is still considered as fixed...
(In reply to comment #18) > It should be FIXED, as this issue is still considered as fixed... From above discussions, it's not clear if the issue is resolved in eclipse 1.5. In my J2EE-project, I've lots of StringBuffers for holding the SQL-query constants. So, if the issue is not fixed, it will be mammoth task to break the stringBuffer.append().append(). Please suggest something useful. Thanks much.
Our understanding is that the problem got fixed, and last raised issues were not reproducible. If you believe you have found an issue, then please open another defect, since this one has long lived. Remember to add steps to reproduce, since this was the lack of steps which made the last raised issues useless.
Created attachment 83216 [details] ..
Created attachment 83217 [details] ..
Created attachment 83218 [details] ...
What's going on hoya ?
