Bug 129553 - Can not compile java project (not aspectj project) with aspectj files (*.aj)
Summary: Can not compile java project (not aspectj project) with aspectj files (*.aj)
Status: RESOLVED FIXED
Alias: None
Product: AJDT
Classification: Tools
Component: UI (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: 1.4.0 M1   Edit
Assignee: Matt Chapman CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-02-27 07:18 EST by Urs Frei CLA
Modified: 2006-03-06 08:55 EST (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 Urs Frei CLA 2006-02-27 07:18:19 EST
I can not compile a java project (not aspectj project) with aspectj files (*.aj).

If I compile the follow source:
*****
public aspect testAspect {

}
*****
Eclipse get me a error. The message is:
Syntax error on token "aspect", interface expected

In the past we worked with Eclipse 3.2M4. With this Milestone, it worked correctly. But not with the Eclipse 3.2M5.
Comment 1 Philipe Mulet CLA 2006-02-27 09:22:52 EST
This indicates that a Java file syntax is expected. "aspect" is not a Java keyword.
The current behavior is thus expected. Forwarding to AspectJ component.
Comment 2 Andrew Clement CLA 2006-02-27 10:10:59 EST
and over the fence to AJDT for comment.
Comment 3 Matt Chapman CLA 2006-02-28 12:40:36 EST
Yes, the change has occurred in 3.2M5, because we have defined a "AspectJ source file" content type associated with .aj files, derived from the Java source file content type. The new JDT support in 3.2M5 allows for compilation units with non-.java extensions, so in this case the Java project is trying to interpret the .aj files as containing Java source code. So this is a change in behaviour, but it is no more or less correct than the previous behaviour. It is working as per the current design. Bug 36939 discusses further possible enhancements towards supporting Java-like source files.

Why do you want to store AspectJ source in a Java project anyway? What is the use-case here? Could you not just exclude the files from the build path, or
move them to somewhere outside of a source folder?
Comment 4 Urs Frei CLA 2006-03-01 01:33:40 EST
The behaviour of Milestone 4 was very useful for us. We are new in the Aspect Oriented Programming. At time we only use the aspects to make the quality oft the code better. We use it for example in Unittests or add additional asserts to the code. With the M4 we have the possibility to compile the code without Aspect and run it on product runtime without aspects.
An other case is: Compiling with AspectJ is very slow. So we decided that not all developer have to change the Project to AspectJ. It was in the past no Problem, because we use AspectJ at this time only for the code quality.
It is possible to add the aj files in a separately source folder. But I would prefer it to have the same things together, in the same source package. 

Thanks for your work
Comment 5 Adrian Colyer CLA 2006-03-01 04:23:33 EST
Especially on larger projects (and until we release all the memory improvements in 1.5.1 etc.), for certain classes of aspects it's reasonably common to switch forwards and backwards between the java and aspectj project nature (we have to do it when we build shadows in AspectJ for example, because of the requirements of our swizzling ant script). Also, consider a team scenario where the majority of developers work with the JDT, but a few "aspect-aware" ones work with and check-in .aj files (these might be just decws for example). Some built in support when in Java nature to easily say "exclude all .aj files" would be a big help here.
Comment 6 Matt Chapman CLA 2006-03-01 05:18:58 EST
Performance improvements to the compiler should help with the one use-case, but I agree we should do what we can for the adoption scenario. There were many advantages to making the changes that caused this issue, and one of those was to make JDT's build path exclusion work for .aj files, which I think we can make use of here. I propose that when you remove the AspectJ capability from a project, we automatically exclude all .aj files from the build path. That will result in behaviour as close as possible to previously. Going the other way is a little tricky - if we automatically include all .aj files, we may be including something that was excluded last time the project was an AspectJ project. So when converting to an AspectJ project if we detect any excluded .aj files, we could prompt the user to ask them whether to include all .aj files. How does that sound?
Comment 7 Adrian Colyer CLA 2006-03-02 03:40:43 EST
That's the kind of thing I was thinking of. An auto-exclude on conversion to a .java project seems entirely reasonable as I can't think of a scenario where you would legitimately want the JDT compiler to try and compile .aj files (perhaps @AspectJ aspects in files with a .aj extension, but that's a real corner case). 
Prompting on conversion back to an AspectJ project also seems perfectly reasonable, so all-in-all this looks to be a good solution. thks.
Comment 8 Matt Chapman CLA 2006-03-06 08:55:42 EST
Implemented as described above. Tests added.

AJDT1.4 build.59 Build Fixed
BUILD COMPLETE -  build.59
Date of build:	03/05/2006 05:52:24
Time to build:	18 minutes 17 seconds
Last changed:	03/05/2006 05:37:02
Last log entry:	129553: Can not compile java project (not aspectj project) with aspectj file