Community
Participate
Working Groups
I have experienced situations where IAJC outputs a message like this at the end of compilation. [iajc] can't find type org.xxx.SomeTest In my case this was one time highly confusing since I did not expect the class in question to be referred anywhere in the project (I have to date still not located the reference). For such cases, it would be extremely nice if the error message would display WHY it need the class (i.e. the name of the refering class(es) or aspect(es) possibly with a reasonable cutoff as there is seldom need to list all referals). So I would like a message like this: [iajc] can't find type org.xxx.SomeTest referred by org.yyy.SomeClass,org.yy.SomeOtherClass ...
This is a good suggestion. Reassigning as such to compiler.
"can't find type" is displayed by World.resolve(TypeX,boolean). The boolean flag specifies if the caller of resolve() can handle the fact that a type is missing - if it can then 'cant find type' is not displayed and instead the caller gets a ResolvedTypeX.MISSING object. So the problem scenario where we would like more info is when the boolean is false. Currently there is only one route into this method where the boolean is false, that is through World.resolve(TypeX) where the caller hasn't specified whether they can handle a missing type. Unfortunately there are 63 callers of World.resolve(TypeX). The options seem to be: 1) Modify those 63 places to use the resolve(TypeX,boolean) variant and ensure they cope with ResolvedTypeX.MISSING correctly. 2) Pass some 'context' along as an extra parameter on every resolve() call so that 'cant find type' can give more information about what was happening when it attempted to find a type. Neither is ideal ... still thinking ... maybe there is a sensible subset of the 63 cases which are the most common and we can change them to 'resolve (TypeX,true)' and print better messages when ResolvedTypeX.MISSING is returned.
It's always hard to deal with 63 method calls. My quick pass reveals 5 kinds of uses that should be considered separately. 1. resolve(TypeX.OBJECT) or some other core runtime type. I'd suggest changing these either by adding specific methods to world, i.e. getObjectType () or a general getCoreType(TypeX.OBJECT). If one of these types is missing there's a basic configuration error. 2. resolve used in test cases. There are a fair number of these, and I don't think you need to worry about them. To simplify the analysis you might want to change these to use resolve(TypeX, true) followed by an assertion that ResolvedTypeX.MISSING wasn't returned. 3. A small number of cases where resolve is used where it doesn't really need to be. i.e. The API for Shadow.getEnclosingType() should probably return a ResolvedTypeX since this is what BcelShadow is already holding onto. These calls will never fail, but fixing them up will make it easier to see the other calls. 4. resolve used in implemention of actual weaving. These calls usually have an easy context to provide and would be useful to let the user know where the problem is, i.e. can't find type Foo while weaving around advice X into join point shadow Y. This is a great use of our multiple source locations support in 1.2. 5. Once you've done the ones above, there will still be a good number (~20?) remaining that are harder. These are probably the actual ones leading to the confusing error messages. These need to be looked at one by one to see where context can be easily supplied. Most of these calls are used to see if a given join point shadow matches a given pcd. This is a case where it would sometimes be nice to handle MISSING more carefully.
*** Bug 71045 has been marked as a duplicate of this bug. ***
I've finally gotten round to starting on this. I've removed the rogue calls in the testcases that confuse the situation and added a new method to world that should be used when looking for really important types like java.lang.Object which fails with an error other than 'cant find type' to let you know you are really in trouble. That seems to have taken me down to around 50 calls to resolve without a boolean. The quest continues ...
for the 1.2.1 release (or as many of the cases as we can)
I've fixed a bunch of cases of 'cant find type'. The rest that remain are hard to fix as they require a lot of state to be passed around in order to say why we cant find it. Adding all this state to the relevant methods would really complicate the implementation. I would rather target specific problematic 'cant find type' scenarios and fix them one-by-one. The reason I originally tried to fix them *all* is that we don't know which were the problematic ones, but now we have the AspectJ dump support. Here is a comment I put in another bug: ------------------ We have just built a version of AspectJ that includes some rudimentary dump support - this allows us to collect diagnostic information when things go wrong. I'd like to try it out for the first time on this bug. The version of AspectJ required is available here (the usual place): BUILD COMPLETE - build.356 Date of build: 08/23/2004 16:06:44 Time to build: 125 minutes 0 seconds Last changed: 08/23/2004 14:40:33 Latest good AspectJ jar available at: download.eclipse.org/technology/ajdt/dev/aspectj-DEVELOPMENT.jar Please can you retry your failing Java 1.5 scenario with this version. AND in order to cause it to dump on error (it normally just dumps on abort), you will need to set this property: org.aspectj.weaver.Dump.condition=error If that works then when the compiler finishes after reporting your 'Cant find type' message it will produce an ajcore.XXX file on the disk (XXX is a date/time stamp). Can you send me the ajcore file? That will enable me to tell which route to can't find type is having problems ------ So - in future - if anyone hits a really unhelpful 'cant find type' message, we should tell them to set org.aspectj.weaver.Dump.condition=error and re-run. If they then send us the ajcore.* file that comes out, we can target that particular path to 'cant find type' and fix it with better diagnostics.
Fix released as part of AspectJ 1.2.1
