Community
Participate
Working Groups
HEAD, was OK in I20100928-1200 - enable compiler option for Unnecessary cast or 'instanceof' operation - set the system library to a 1.6 VM install, but set compiler compliance on the project to 1.4 - paste this class: package snippet; import java.util.Arrays; public class Snippet { String[] foo(Object[] args) { String[] a; a= (String[]) Arrays.asList(args).toArray(new String[0]); a= Arrays.asList(args).toArray(new String[0]); return a; } } In HEAD, I get a wrong warning on the first assignment to a. On the second assignment, the necessary compile error is missing. On the other hand, HEAD is better in resolving IMethods: Arrays.asList(..) and List.toArray(..) both resolve in HEAD (F3, Javadoc hovers), but they didn't resolve in I20100928-1200.
If you compile this code using javac 1.5 or above, it also compiles fine. If you use javac 1.4, it reports a problem of incompatible types. But if you run the 1.5 version, you end up with an ArrayStoreException. The problem is that since we have 1.5 libraries toArray(String[]) is resolved to return String[] and not Object[] as it does in 1.4 libraries. So when checking the assignment, we have String[] assigned to a String[] and there is no error to report. Note that if you remove the assignment, you don't have compile errors in 1.4, but you still get an ArrayStoreException at runtime. I don't know that part of the code well enough to know where we could convert the return type of toArray(..) back to Object[] as the return type in 1.4 libraries. > In HEAD, I get a wrong warning on the first assignment to a. On the second > assignment, the necessary compile error is missing. This is consistent in the way toArray(String[]) is resolved when 1.5 libraries are on the classpath. Srikanth, I'd like to discuss this with you to better understand that part of the code. Thanks.
Sorry, I forgot to mention the real-life examples that made me file this bug: When you compile org.eclipse.jdt.ui with only a 1.6 JRE available, you now get two of these problems in JarManifestWizardPage and GenerateHashCodeEqualsAction. Javac 1.6 agrees with our old behavior (I20100928-1200) when you compile with "-source 1.4".
This is what I meant. If using source 1.4, we need to do additional work to get back a Object[] for the return type of toArray(..) call.
Right now we use the compliance level to make different treatment between 1.5 or 1.4. According to what Markus reported, we should actually use the source level and not the compliance level.
Created attachment 183340 [details] Add disable regression test
I wonder if this is not the same issue as bug 330264.
(In reply to comment #6) > I wonder if this is not the same issue as bug 330264. Doesn't look like it - that bug has to do with unchecked method conversions, while this one has not. Under investigation.
See also bug 247307.
While compling in 1.4 mode, we should not perform inference of generic method type parameters and/or expected type. The code that performs the inference is keyed off of the presence or absence of type parameters, rather than the compliance settings. I think the same problem likely impacts bug 330264. As a matter of fact, it appears that bug 328775 was perhaps a very specific instance of the general problem and has perhaps been fixed in a point fix manner. If bug 330264 and bug bug 328775 are indeed related, I'll try to provide a general fix. that will subsume the fix done for bug 328775
(In reply to comment #8) > See also bug 247307. This has interesting and curious similarities, but is basically unconnected to the current bug.
1. Build Bundle.jar out of the following: public class Bundle { static <A> A adapt(Class<A> type) { return null; } } 2. Delete Bundle.java and Bundle.class 3. Compile the following in using a 1.5 javac compiler public class X { Bundle b = Bundle.adapt(BundleWiring.class); } class BundleWiring {} specifying the jar built in step 1 in the class path. You get an error of the form: X.java:2: incompatible types found : BundleWiring required: Bundle Bundle b = Bundle.adapt(BundleWiring.class); ^ 4. Now compile using -source 1.4 X.java:2: incompatible types found : java.lang.Object required: Bundle Bundle b = Bundle.adapt(BundleWiring.class); ^ 1 error See the morphed error message which is indicative of the fact that at 1.4 source level inference does not kick in.
Created attachment 183444 [details] Patch under test This patch fixes the current problem and also the one at bug 330264 and subsumes the bug 328775. The fix for bug 328775 which was too specific is no longer required as the current one is the general fix and is backed out by the current patch. (As a matter of fact that fix was actually facilitating type inference at 1.4 while the current patch completely precludes type inference at source < 1.5 and so is the more appropriate fix).
*** Bug 330264 has been marked as a duplicate of this bug. ***
Created attachment 183460 [details] Proposed patch This patch: - Arranges for generic type inference to trigger only at 1.5+ - Backs out the point fix done for bug 328775 and provides a broader, more general fix. (inhibiting inference at < 1.5 rather than facilitating ala the fix for bug 328775) - Adjusts some javadoc tests that depend on inference kicking in at < 1.5 - Bug 299384 which basically went away for free due to the fix for bug 328775 gets reintroduced as a result of backing out that particular fix. When the patch gets released, I'll reopen the code select defect (I have a potential fix for that too) - Disables the regression test for bug 299384 - Includes a regression test for bug 330264 - Passes all JDT/Core tests. I'll test it against OSGi projects, JDT/UI projects and PDE projects to make everything builds alright before releasing it.
(In reply to comment #14) > I'll test it against OSGi projects, JDT/UI projects and PDE projects > to make everything builds alright before releasing it. I didn't see any issues with building OSGi projects and all of eclipse. "All of eclipse" is really a workspace where all plugins from the platform are imported as source projects. So this may not include the test projects of various components. We are working on including test projects from JDT/UI and PDE as these seem to stress the 1.4/1.5 interoperability mode, but this validation infrastructure is work in progress.
Olivier, Please review. TIA.
Looks good even if this will cause some issues in the reconciler (see bug 299384).
Released for 3.7M4.
Verified using I20101207-0250 (4.1 I-build)
