Community
Participate
Working Groups
Created attachment 161546 [details] Screenshot showing the problem In p2 we have generated our .class files with the jsr14 target. However, if we use some of these classes (from code which is set to 1.4 source / target), we get strange errors. The errors are strange because they do not show up in the compile error view, nor do they show up as markers on the file itself. However, if you look in the .java file, you see a marker. The particular error is: The method toArray(Class) from the type IQueryResult refers to the missing type T I've attached a screenshot to show you what I mean.
> In p2 we have generated our .class files with the jsr14 target. However, if we > use some of these classes (from code which is set to 1.4 source / target), we > get strange errors. The errors are strange because they do not show up in the > compile error view, nor do they show up as markers on the file itself. However, > if you look in the .java file, you see a marker. This is not a marker, but rather a wrong highlighting. The problem comes from the reconciler. I'll what I can do to fix this case, but since this is not a supported target, it is not a high priority.
> The problem comes from the reconciler. I'll what I can do to fix this case, but > since this is not a supported target, it is not a high priority. Re: not a supported target, that may explain my other bug (bug 305255) :-) No rush, I just wanted to log these bugs so they didn't get lost. However, now that p2 is using this target, is there something we can do to make it supported target (obviously not for 3.6)?
Ian, when we started using this feature in p2, there was a tacit agreement between Olivier and I (and even discussed during the eclipse team meeting) that we would not ask to make that support full fledged because this could require a lot of work and would not be useful to a majority of ppl (like support for Java 7 would).
We can keep the bug open but currently there are no plans to invest into jsr14 target.
Created attachment 171656 [details] Test projects I don't think this has anything to do with jsr14. Attached are two plain old Java projects that show the issue without the use of jsr14. The key is the client (where the error is) is using compile setting of J2SE-1.4 and compiling against another project that is using the compile settings of Java 5 and has generics in the API.
As far as I know this is only a reconciler issue. I'll debug it. It is not directly related to jsr14, but it is related to the fact that 1.5 API are referenced inside a project set as 1.4. So this is the kind of settings that you get a lot when using the jsr14. If you disable the report of problem as you type, the error is gone. I'll investigate it.
This is why we have a problem. In the reconciler, the BundleContext unit is retrieved as a source type, but it is "read" with the compiler options from the caller site (1.4). So all its 1.5 information is lost and when the getService() method is resolved, its return type name is S. It is resolved as a 1.4 method with a return type S that is not found. During the compilation, the type is retrieved as a binary type that preserves all its generic information. So the way to fix this would be to retrieve dependent types using their own compiler options. I'll make some experiment in this direction.
In order to fix this, we would need to store the compiler options of each unit inside its compilation scope. Right now the scope gets the global options from the lookup environment which doesn't work well when some types should be read using 1.4 level and some types should be read using 1.5 level. This is an issue only with source types.
*** Bug 318573 has been marked as a duplicate of this bug. ***
This bug is going to cause a bit of grief when the patch in bug 322007 is released. The OSGi APIs will have generics. Any project using J2SE 1.4 project settings will see these strange errors in their editor for calls to the OSGi API that has generics. This appears to only be an issue if the project containing generics in their API is in the workspace, so perhaps it is not as big of an issue. To me it is rather annoying because I ALWAYS have org.eclipse.osgi in my workspace ;-)
Olivier is away all of this month, I'll take a look and see what is involved.
(In reply to comment #7) > During the compilation, the type is retrieved as a binary type that preserves > all its generic information. The type is retrieved as a binary type where all the generic information is erased. So instead of attempting to resolve a return type of S where S is a type variable, we attempt to resolve java.lang.Object and we have nothing to complain about.
Created attachment 176764 [details] Patch under consideration.
All JDT/Core tests pass, I'll add a regression test and test some more. Ian, Thomas: Are you in a position to apply the source patch (3.7 HEAD) and test ? TIA.
(In reply to comment #14) > Ian, Thomas: > > Are you in a position to apply the source patch (3.7 HEAD) and > test ? TIA. Yes, and it seems to have fixed up the errors I was seeing in the Java editor. Thanks.
I think the patch posted earlier is step in the right direction, but full solution may need some more work. This is under investigation.
Created attachment 176892 [details] Revised patch under test This patch addresses three issues: (1) With the earlier patch, the reconciler was aborting with an NPE. The current patch addresses this issue. (2) Added regression tests. (3) With 1.5 projects with generics being added to the class path of a 1.4 project, the reconciler starts producing several unchecked warnings in 1.4 code. This ix fixed, so the behavior is the same as the compiler (i.e no generics warnings in 1.4 code even though generic entities are references in their raw (only possible) form from 1.4 code. Under test.
Created attachment 176907 [details] Proposed patch Same patch as before, with a few typo's inside comments taken care of. Passes all JDT/Core tests.
Frederic, please review. TIA.
Patch looks good to me
Released in HEAD for 3.7 M2.
Verified for 3.7M2 using I20100914-0100. I could no longer get reconcile errors using this build.
*** Bug 179195 has been marked as a duplicate of this bug. ***
