Summary: | AJDT AspectJ Internal Compiler Error | ||
---|---|---|---|
Product: | [Tools] AspectJ | Reporter: | Macneil Shonle <mshonle> |
Component: | Compiler | Assignee: | aspectj inbox <aspectj-inbox> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | c.nappin |
Version: | 1.5.0 | ||
Target Milestone: | 1.5.1 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Macneil Shonle
2006-01-18 16:59:18 EST
hmmm. I added a testcase for this to the harness we have for exercising incremental compilation - works for me :( I created the version without the printf pointcut then added that and performed an inc-compile. The test is commented out for now (even though it works) until someone gets more time to play around and investigate this bug. I believe we don't have any test programs that use printf() so wouldnt be surprised if there was some kind of problem... I've spent some time trying to recreate this problem and so far have had no success... In the output it says that it's building two files - is it possible to attach the other file to this bug? (As a note the failing line number is 1230 in the latest codebase in HEAD). Here's the other file, which is a pure .java file: package edu.ucsd.aosd; import java.util.Arrays; import java.util.List; import java.util.ListIterator; public class GenericsMapTest { public interface BinaryFunction<T> { T apply(T x, T y); } public interface UnaryFunction<T> { T apply(T x); } // main public static void main(String[] args) { List<Integer> list = Arrays.asList(new Integer[]{1,2,3,4,5}); Integer sum = reduce(list, 0, new BinaryFunction<Integer>() { public Integer apply(Integer x, Integer y) { return x + y; } }); applyAll(list, new UnaryFunction<Integer>() { public Integer apply(Integer x) { return x * x; } }); System.out.printf("sum = %d\n", sum); for (Integer i: list) { System.out.printf("%d ", i); } } static <T> T reduce(List<T> list, T identity, BinaryFunction<T> fun) { T result = identity; for (T item: list) { result = fun.apply(result, item); } return result; } static <T> void applyAll(List<T> list, UnaryFunction<T> fun) { ListIterator<T> it = list.listIterator(); while (it.hasNext()) { it.set(fun.apply(it.next())); } } } #### Unfortunately I don't recall the order in which I typed in things, made errors, resaved/recompiled, changed the other .java file to .aj, et cetera... I assume order is important for this. I'll add anything else if it happens again. I've still not had any success reproducing this bug, although as a note the reason for the BCExcpetion is that the LazyMethodGen associated with the around advice is no longer in the list of methodGens for the aspect....how or why this happened I don't know and can't investigate further until I reproduce it. However, since the changes entitled "go 'back to source' on incremental aspect change" were checked in to HEAD, the testcase for this bug which Andy checked in and commented out (mentioned in comment #1) is now failing because the changes now force a full build rather than an incremental one. Therefore, I don't believe that the failing scenario described in this bug can be reproduced since any change to the aspect or class within MyApplication now results in a full build and the problem is an incremental one. *** Bug 130720 has been marked as a duplicate of this bug. *** Closing this bug as fixed as per the comment #4. The scenario described in this bug can no longer happen as any changes made to aspects now results in us going back to the source and doing a full build, whereas this bug was seen on an incremental build after changes to an aspect. This is available in the latest AJDT 1.3.1 dev build and will be available in the next AJDT 1.4 dev build. |