Bug 275215 - org.eclipse.jdt.internal.core.util.KeyToSignature#consumeType() uses a method not available in J2SE-1.4 EE
Summary: org.eclipse.jdt.internal.core.util.KeyToSignature#consumeType() uses a method...
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.5   Edit
Hardware: PC Windows XP
: P3 trivial (vote)
Target Milestone: 3.5 RC1   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-06 16:08 EDT by Benjamin Cabé CLA
Modified: 2011-01-10 09:47 EST (History)
5 users (show)

See Also:
david_audel: review+


Attachments
fix (912 bytes, patch)
2009-05-06 16:09 EDT, Benjamin Cabé CLA
john.arthorne: iplog+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Benjamin Cabé CLA 2009-05-06 16:08:16 EDT
Description	Resource	Path	Location	Type
The method StringBuffer.insert(int, CharSequence) referenced in org.eclipse.jdt.internal.core.util.KeyToSignature.consumeType() is not defined in bundle's required execution environment: J2SE-1.4 	KeyToSignature.java	/org.eclipse.jdt.core/model/org/eclipse/jdt/internal/core/util	line 261	API Usage Problem
Comment 1 Benjamin Cabé CLA 2009-05-06 16:09:12 EDT
Created attachment 134689 [details]
fix
Comment 2 Olivier Thomann CLA 2009-05-06 17:09:51 EDT
This problem only occurs if JDT/Core is compiled using a 1.5 library. This is not supposed to be the case.
JDT/Core should always be built using 1.4 libraries.
Comment 3 Olivier Thomann CLA 2009-05-07 11:20:30 EDT
For safety (people that are building JDT/Core on a 1.5 libraries), we could release that patch.
David, please review.
Comment 4 David Audel CLA 2009-05-07 11:21:34 EDT
+1. patch looks good and would avoid problems with this uncommon configuration.
Comment 5 Olivier Thomann CLA 2009-05-07 11:23:36 EDT
Released for 3.5RC1.
Code review is required for verification.
Comment 6 Benjamin Cabé CLA 2009-05-07 14:13:50 EDT
Olivier, I'm afraid I'm missing a point here: when I enabled API Tooling on o.e.jdt.core, I had the error in comment 0 because J2SE1.4 (the EE of this bundle), does *NOT* contain an insert(int, xxx) method taking a CharSequence parameter as its second argument. So in fact I am wondering how this code was supposed to compile against a JRE 1.4 before! But as already said, I must be missing something, and I don't really understand why we are talking about JRE 1.5 here
Comment 7 Olivier Thomann CLA 2009-05-07 14:15:51 EDT
Check the JRE used on the JDT/Core project classpath. I am sure this is a JRE 1.5.
You don't resolve to the insert(int, CharSequence) if the libraries on the classpath are 1.4 libraries. If you have 1.4 libraries, this call is resolved to insert(int, Object).
Comment 8 Olivier Thomann CLA 2009-05-07 15:33:26 EDT
Can you confirm that you have a 1.5 JRE or above on the project's classpath ?
Comment 9 Benjamin Cabé CLA 2009-05-07 15:59:34 EDT
Olivier you're right: now that I added the configuration for a JRE 1.4 in my workspace, it looks good!
Is it because of a bug in API tools that I had sort of a false report for this "missing" insert(int, CharSequence) method in J2SE1.4?
Changing the code to 
   this.signature.insert(this.typeSigStart, (Object)typeParametersSig);
makes API tools happy again (when I have a JRE>1.4, of course :))
Comment 10 Olivier Thomann CLA 2009-05-07 16:25:57 EDT
(In reply to comment #9)
> Is it because of a bug in API tools that I had sort of a false report for this
> "missing" insert(int, CharSequence) method in J2SE1.4?
This is not a bug, it is a feature :-).
When you are building with a 1.5 JRE on the classpath, the call is resolved to a different signature than when you are using a 1.4 JRE on the classpath.
API Tooling is using resolved signatures and finds that the resolved signature for this call would not be available with a 1.4 JRE.
So we "fix" the code to avoid this method invocation to resolve to a different signature according to the libraries used on the classpath.

Comment 11 Benjamin Cabé CLA 2009-05-07 16:36:58 EDT
(In reply to comment #10)
> This is not a bug, it is a feature :-).
> [...]

Thank you very much for this explanation Olivier, everything is much clearer now! :)
Comment 12 Kent Johnson CLA 2009-05-14 11:04:34 EDT
Verified for 3.5RC1 using I20090513-2000
Comment 13 John Arthorne CLA 2009-06-01 11:07:23 EDT
Moving iplog+ flag from bug itself to the contributed patch.