Bug 132314 - [comp-upgrade] AspectJ compiler requires dependencies the JDT compiler doesnt
Summary: [comp-upgrade] AspectJ compiler requires dependencies the JDT compiler doesnt
Status: NEW
Alias: None
Product: AspectJ
Classification: Tools
Component: Compiler (show other bugs)
Version: 1.5.0   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: aspectj inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-17 06:50 EST by Matt Chapman CLA
Modified: 2008-08-22 16:07 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Chapman CLA 2006-03-17 06:50:49 EST
This problem occurs in both 1.5.0 final and the latest dev build.

I have a plugin project in Eclipse and if I perform the "Find unused dependencies" option it tells me org.eclipse.search is not used. So I then remove this, but then everything goes horribly south. Compilation is aborted half-way through the project, and no exception, error, or any other indication is given that something has gone wrong - you just don't get all the class files you expect. This occurs without any aspects in the project, and JDT can compile the project without any problems (this is on Eclipse 3.2).

There are two problems here - the compiler is issuing a compilation error for something that shouldn't be a problem, and for the affected file it does not report that compilation of the file has even been attempted, so AJDT doesn't add the error marker for it.

The project has some dependencies on other projects, but I can make these available as required. It also requires Eclipse 3.2M5.
Comment 1 Oliver CLA 2006-04-22 08:46:53 EDT
I had a similar problem with a "declare precedence" statement in one of my examples. During a talk with my students I tried to provocate an error message with the statement

    declare precedence : *, CopAspect, *;

But no error message appears. Next I tried to reproduce the bug, export the project and import it as new project into a new workspace. Here AJDT marks the declare statement correct as error.

I tried different other things but did not succeed in reproducing this behaviour so at last I deleted all my other projects and puts the problematic example together with the workspace to

    http://www.javatux.de/aj/examples_with_workspace.tgz (ca. 2 MB)

I looked also in .classpath and .project if there are strange entries because it's an older project but can't find any anomalies.
Comment 2 Matt Chapman CLA 2006-05-10 06:27:05 EDT
Still occurs with AJDT 1.4.0.20060509123512 on Eclipse 3.2RC3.
My test project is org.eclipse.ajdt.ui.tests from AJDT.
Comment 3 Andrew Clement CLA 2006-05-11 10:55:37 EDT
As Matt says - there are two problems here.

1. compilation error never gets reported by AJDT as the compiler never reported that it had compiled the file
2. why does the compiler require that type when the JDT compiler does not.

The first one (the really serious one...) is now fixed.  There are a class of errors in the compiler that occur at a point so far from the logic that knows what source file is being processed that they just get attached as an error to an AbortException that is thrown - because the compiler can't attach them to the compilationresult for what it is processing at the time.  There is some logic that runs after processing a unit and before ending compilation of the units that repairs the damage, attaching the problem from the abortexception to the unit that was being processed at the time.  In order to fix this problem a few things got changed:

a. changed the 'after() returning: process()' advice in the CompilerAdapter aspect to 'after(): process()' advice which ensures we put out the 'compiled:' message indicating compilation was attempted (to keep AJDT happy).  This causes the error to appear in the problems view.
b. added some extra code in the code that runs after compilation to double check whether errors exist against the units compilation result.  This double checking logic is required because of the code that takes the problem attached to the exception and puts it on the compilation result - previously we only checked for errors in the after process logic.  Now that we also check for errors at the end of compilation we correctly *stop* and *dont weave* in the case where this kind of error has occurred.

I am half convinced that the fact that AJ thinks we need this type whereas the JDT says we dont (problem 2) is due to an Eclipse compiler difference between 3.1 (what AJ is based on) and 3.2 - so I'll mark this bug as one to double check when the 3.2 compiler is integrated.
Comment 4 Andrew Clement CLA 2008-01-22 12:24:02 EST
needs checking, might be fixed now we are a 1.6 compiler