Community
Participate
Working Groups
On experimenting with aspectj I was suddenly asked politely by ajdt to log a bug here: steps: Take code snippet (rename classes, autogenerate code, i.e make it compile): @Aspect @SuppressWarnings("unchecked") public class DeliveryCallbackInterceptor { @Pointcut("execution(boolean org.springframework.integration.message.MessageHandler+.handleMessage(Message))&& args(message)") public void handleMethod(Message message){} @AfterThrowing(pointcut="handleMethod(message)", throwing="e") public void invokeDeliveryCallback(Message message, Throwable e){ ((DeliveryFailureCallback) message.getHeaders().get("errorcallback")).onDeliveryFailed(message, e); } } 1. place the cursor after 'pointcut="handleMethod(message' 2. type ', e' 3. save RESULT: org.aspectj.ajdt.internal.compiler.lookup.EclipseSourceType$MissingImplementationException at org.aspectj.ajdt.internal.compiler.lookup.EclipseSourceType.generateElementValue(EclipseSourceType.java:705) at org.aspectj.ajdt.internal.compiler.lookup.EclipseSourceType.generateAnnotation(EclipseSourceType.java:682) at org.aspectj.ajdt.internal.compiler.lookup.EclipseSourceType.convertEclipseAnnotation(EclipseSourceType.java:636) at org.aspectj.a ... urceType$MissingImplementationException thrown: Please raise an AspectJ bug. AspectJ does not know how to convert this annotation value ["unchecked"] I can reproduce this consistently by closing the error dialog and repeating the steps (saving after each change).
Seems related to Bug 255555
It isnt quite the same as 255555 - that was the problems of: - asking an EclipseType to hold an annotation, which should never be asked. - including extra parentheses around a declare annotation. This bug is similar to bug 238992, comment 11. Annotation conversion logic is not 100% fleshed out in some places - due to their being so many combinations. So the common ones are implemented and others are implemented as they come up. I am surprised that array annotation values are not behaving. I'll get on it.
Surprising, but the problem was due to it being unable to promote the string to an array (for SuppressWarnings). I'd have thought that would have been hit before - but I guess it does require a particular combination of files to be built on an incremental compile to trigger it, and I imagine @SuppressWarning(["abc"]) would work ok. Fixed for 1.6.4 - thanks for the testcase and recreation instructions. Still quite a few MissingImplementation exceptions in that code - glad I didn't flesh it out originally since some of these paths must be rather uncommon...
If only more bugs were as easy to report as this one...
