Community
Participate
Working Groups
This has been a problem since AspectJ5 when support was first added for this kind of construct: interface I<T> { } aspect X { public void I<Z>.foo(Z z) {} } where the ITD is defined to share type variables with the target type. In these cases we create a generic signature for the member in the class X that uses the type variable but that type variable cannot be resolved according to regular java rules (foo is not a generic method and the containing type for foo does not define a type variable). The eclipse compiler considers this an inconsistent class file and any thorough verifier of the contents of the .class file would report this as a problem. We ought to be doing something smarter and making the type variable either resolvable in some way or not using the standard generic signature attribute to record it (maybe an AspectJ generic signature attribute in this case). The problem was highlighted in some of the work on bug 242797. Currently the fix under that bug for this (which has been made in the Eclipse compiler BinaryTypeBinding class) recognizes the situation and resolves the type variable correctly - but that doesn't change the fact that the .class file on disk is inconsistent.
complex bit o work
I'm not sure if I understand the state of this correctly. Is the current dev build supposed to have solved the reporting of the inconsistent class file error? If so, I'm still getting one as of 1.6.1.200810061956. It also seem odd to me that the error marker shows up on a non-advised class file, the first one in the eclipse source tree, which has nothing to do with the ITD.
Just to clarify, this is only happening on ITDs that contain generic fields. For example the following aspect will cause the error when applied, while I have a number of similar aspects that don't introduce fields and work ok. If it'll help I can put together a test case. private T CreateAction<T>.newObject; public void CreateAction<T>.cancelCreate() { setNew(null); } public void CreateAction<T>.create() { T newObject = getNew(); if (newObject == null) throw new NullPointerException("New object is null"); H2Lookup.em().persist(newObject); } public T CreateAction<T>.getNew() { if (newObject == null) newObject = instantiate(); return newObject; } public void CreateAction<T>.setNew(T newObject) { this.newObject = null; } }
AspectJ still creates inconsistent class files - and so this bug is still valid. However, what I did in 242797 was allow the JDT compiler to cope with them, rather than fix their creation (since that is a much more complicated piece of work). Under 242797, with your help, we found two situations where JDT would detect inconsistency. So, we either have another scenario that detects inconsistency or there was a problem getting the change into AJDT that covers: https://bugs.eclipse.org/bugs/show_bug.cgi?id=242797#c41 Are you seeing it failing for exactly the same code (242797 comment 41) as before or are you doing something slightly different?
Created attachment 115188 [details] Replicates inconsistent classfile error It's easier to describe with a test case. This should cause the inconsistent class file marker on Eclipse 3.4 with the most recent AspectJ on the dev update site last week. I'm updating to the most recent now to confirm that it's still a problem.
OK. Earlier today I checked the latest build with the most recent testcase (the one from 242797 comment 41) and that works fine, so this must be a new manifestation of the problem. I'll try the new testcase, thanks.
Dave - one thing... there is a bug in the latest AJDT where it erroneously turns on an option. Can you try disabling it and see what it does for you? Open Window>Preferences then select 'AspectJ Compiler' and on the right hand side, turn OFF suppress autobuilds. then kick off a full build. Now try and recreate - any difference for you?
I've got the latest AJDT from the dev update site installed, suppress autobuilds is unchecked (it doesn't seem to have been checked) and I'm still seeing the error. The testcase should be pretty easy to test out though. I created 2 projects, one contains the interface and ITD, the other contains a class the ITD implementing the interface, and then I zipped them up. You should be able to just unzip, import into your workspace and see the error occur. It seems to have something to do with the generic field introduced, so maybe the previous fix just took care of methods?
First fix was for generic methods, latter fix was for generic fields. I've imported your code from comment 5 and it works fine for me. Can you tell me which file you change to trigger the inconsistent message or does it just happen every time for you? Open the AJDT Event Trace view (Window>ShowView>AspectJ>AJDT Event Trace) and check that it is actually doing builds. I am on AJDT 1.6.1.200810122153 which includes AspectJ 1.6.2.20081004054700
That's strange. I'm on the same version of AJDT you are and still seeing the error. It happens whenever my ITD is on the aspect path. If I remove the project "bug" from the aspect path of "bug2" the error is replaced with a message stating that the method getGenericField must be implemented, then I add it back, rebuild, and get the inconsistent class file error. Any ideas what else in my config could be different?
With that AJDT build I've just now seen some wierdness related to aspectpath. Not sure if that is what you are seeing. Anyway, I've committed a brand new AspectJ into AJDT (it includes your other fix for bridge methods too). This will be in the next AJDT dev build. Hopefully upgrading to that will get you over this glitch. If the marker just kept persisting I'd claim it was just a stale marker in the workspace that wasn't being cleaned up properly but the fact that it goes when you remove the aspectpath dependency and then returns when you readd it, hmmm. I will also retry your test scenario on my eclipse when the new dev build is available. Actually I am on windows, so I will try your scenario on my Mac when I get home too.
I just got a chance to update to the new AJDT (ends with 2052) and I'm still seeing the inconsistent class file error. Have you been able to test it on a mac?
Hmmm... I had a coworker try it out with the latest dev build and he is on a mac as well and not seeing the marker. I also just noticed that although "Software Updates" shows me on the latest version, Eclipse > About Eclipse Platform > Configuration Details shows the feature version as 1.6.1.200809182225. I can't figure out how that came to be as I can't find that string in any config file, but regardless it seems to be an eclipse issue rather than an aspectj one.
can you remove some of those older versions you have installed? I didn't see it on my Mac when I tried. We are getting close to a release candidate for 1.6.1 so I'd like to be sure we have your problem all fixed in this forthcoming release.
Ok, all fixed. Somehow a space had gotten introduced at the end of the name of my eclipse folder and it seems that the update manager was adding all new plugins to a folder with no space at the end, that only it could see. Weird. I'm now on the latest ajdt and the marker is gone. Sorry about that.
Created attachment 116348 [details] Java app to strip attributes In this jar is an application that can strip the signature attribute for methods starting ajc$interMethod in a target class. It is easier to do it this way for now (to check the approach) rather than rework the compiler not to include it. Once downloaded, ensure the jar and aspectjweaver.jar are on your classpath (and the .class for the aspect that needs to be stripped). Run java Stripper a.b.c.Code And it will tell you what it is doing: Attempting to strip Signature atttribute from method ajc$interMethod$a_b_c_Code$a_b_c_I$foo Removing signature (La/b/c/I<TT;>;TT;)V Attempting to strip Signature atttribute from method ajc$interMethodDispatch1$a_b_c_Code$a_b_c_I$foo Removing signature (La/b/c/I<TT;>;TT;)V Writing out new .class to C:\asc\ws\aspectj16_2\tests\bugs163\pr244619\.\a\b\c\Code.class Complete
unsetting the target field which is currently set for something already released
