Community
Participate
Working Groups
Created attachment 181779 [details] test.casting projects I20101025-1800 Attached are two plug-in projects with identical code, except one uses 1.4 compiler settings (test.casting1) and the other uses 1.5 compiler settings (test.casting2). Both use the following block of code: public void start(BundleContext context) throws Exception { System.out.println("Hello World!!"); Bundle b = context.getBundle().adapt(BundleWiring.class); System.out.println("What I can assign BundleWirning to Bundle!! " + b); } The following line should cause a compilation error in both cases: Bundle b = context.getBundle().adapt(BundleWiring.class); It only is causing a compilation error for the 1.5 project. In the 1.4 project the compiler seems to add an implicit cast to (Bundle). But that will fail with a cast exception at runtime.
This is caused by the fix for bug 324850. Srikanth, I think we now need to "filter" some generic information where we didn't need to in the past. If we cannot "fix" this, we might want to revert bug 324850 for M3 as this is causing grief to OSGI users.
(In reply to comment #1) > This is caused by the fix for bug 324850. > Srikanth, I think we now need to "filter" some generic information where we > didn't need to in the past. On the contrary, at least per initial investigation, it looks like we need to admit more generic information from the binary type when referenced in the context of a 1.4 project. > If we cannot "fix" this, we might want to revert bug 324850 for M3 as this is > causing grief to OSGI users. I'll see what is involved. FWIW, see that in this scenario we compile code that shouldn't be compiled rather than the other way about.
(In reply to comment #1) > This is caused by the fix for bug 324850. > Srikanth, I think we now need to "filter" some generic information where we > didn't need to in the past. > If we cannot "fix" this, we might want to revert bug 324850 for M3 as this is > causing grief to OSGI users. Jay has volunteered (Thanks!) to prepare a patch after unrolling these changes and testing them. In parallel I am working on a fix for the two issues that have resulted since the fix for bug 324850.
Created attachment 181923 [details] Patch This is the rollback patch of the fix for bug 324850. This fixes both this bug and 328827. The patch has been tested for both the bugs and all other regression tests.
Created attachment 181936 [details] Patch that fixes the problem No regression test yet,
(In reply to comment #5) > Created an attachment (id=181936) [details] > Patch that fixes the problem Basically in 1.4 mode, we resolve BundleWiring.class to have a type of Class as opposed to Class<BundleWiring> since we see the class Class to be a plain old (non-generic) reference type. This causes problems in type inference during method selection. Now similar to argument munging done for boxed types and primitive we special case Class literal expressions, these being the only ones that carry full parameterization information even in 1.4 source code mode.
Created attachment 182019 [details] Patch with test
Olivier, please review - Passes all JDT/Core tests. (You may have to back out the back out of the fix for bug 324850 first)
Just verified that build I20101028-1441 does not have this bug.
(In reply to comment #9) > Just verified that build I20101028-1441 does not have this bug. Thanks, Jay.
Looks good.
Released in HEAD for 3.7 M4
(In reply to comment #12) > Released in HEAD for 3.7 M4 In the above projects attached by Thomas, in the 1.4 project if I use this line: Bundle b = (Bundle) context.getBundle().adapt(int.class); (int.class instead of BundleWiring.class) it compiles fine, but i guess it will fail at runtime because we can't cast from Integer to Bundle. In 1.5 project it gives me the correct error. Srikanth, i'm not too sure about this though. Can you say whether this is just a false alarm or some legit bug?
(In reply to comment #13) > In the above projects attached by Thomas, in the 1.4 project if I use this > line: > > Bundle b = (Bundle) context.getBundle().adapt(int.class); > > (int.class instead of BundleWiring.class) > > it compiles fine, but i guess it will fail at runtime because we can't cast > from Integer to Bundle. In 1.5 project it gives me the correct error. Srikanth, > i'm not too sure about this though. Can you say whether this is just a false > alarm or some legit bug? I get: Description Resource Path Location Type Type mismatch: cannot convert from Integer to Bundle Activator.java /test.casting2/src/test/casting2 line 17 Java Problem Which looks good.
(In reply to comment #14) > [..] > I get: > Description Resource Path Location Type > Type mismatch: cannot convert from Integer to Bundle Activator.java > /test.casting2/src/test/casting2 line 17 Java Problem > Which looks good. But you only get this error on the 1.5 project and not on the 1.4 project, right? Thats the main contention. The cast from Integer to Bundle will fail in 1.4 as well, but there's no error there.
I got a different error in 1.4. It reports Object instead of Integer. I do have an error in both projects.
(In reply to comment #16) > I got a different error in 1.4. It reports Object instead of Integer. > I do have an error in both projects. Olivier got the error when not using the cast to Bundle. We've cross checked that there's no error in 1.4 project, but its fine since in 1.4 it effectively boils down to a cast from Object to Bundle (and not Integer to Bundle as in 1.5). Verified for 3.7M4 using build I20101205-2000.
