Community
Participate
Working Groups
regression: the following test case compiles using AspectJ Compiler DEVELOPMENT built on Wednesday Aug 17, 2005 at 12:52:19 GMT but causes a compile error using AspectJ Compiler DEVELOPMENT built on Wednesday Aug 24, 2005 at 09:22:19 GMT class Bug_Provider { public void enable_bug(Object argument) {} } class Null_Provider<T> extends Bug_Provider { public T get_typed_null() { return null; } } public class Bug { public static void main(String[] args) { Null_Provider<Integer> null_provider = new Null_Provider<Integer>() {}; null_provider.enable_bug(null); Integer i = null_provider.get_typed_null(); // type mismatch } } note how a call to enable_bug(null) is required to exhibit the bug. this call is sensitive to the compile-time value of its argument: enable_bug(null) bug enabled enable_bug(new Object()) bug disabled enable_bug(new String()) bug enabled Object o = null; enable_bug(o); bug disabled String s = null; enable_bug(s); bug enabled if the definition of enable_bug is moved to Null_Provider, or if Null_Provider overrides it, then the bug is disabled. if null_provider is not an annonymous class, then enable_bug doesn't enable the bug. however, this call does _not_ have to be made on the same target. in fact, it can be made from a completely different method, class, or file; it will always enable the bug as long as the compiler sees the statement before get_typed_null(). well, this is the strangest aspectj bug i've reported yet!
we've been doing some work on anonymous types in the last two days, but I can confirm this bug is *not* related to the anonymous type registration changes we made for the Asm Builder bug. between the build dates that you mention, we upgraded from the eclipse 3.1 m6 jdt compiler level to eclipse 3.1 final level - given the nature of the report, I half wonder if this is a bug that JDT themselves have introduced.... I'm going to check it out in a plain java project...
nice try, but it's *not* a JDT bug, Eclipse 3.1 is quite happy with this program, so it's something that we've introduced...
found it! A bug introduced when sorting out generics and itds, whereby we failed to correctly parameterize a method binding found on a parameterized type binding. this test case now passes, just running the full suite to make sure there are no side effects, but that is extremely unlikely for such a localised fix.
fixed in latest published build. Thanks for the clear bug report, it must have taken a while to boil this one down to a simple reproduceable test case!
actually, there seems to be more to this bug. I have created a different bug report (Bug #108014), because the specific problem described here is indeed resolved.
