Bug 343001

Comment 1 Andrew Eisenberg 2011-04-15 13:43:53 EDT

This appears to be a problem with how the cross-cutting model is being generated.  All of the crosscutting relationships exist as expected, but the IProgramElement corresponding to the declare parents has an empty map for its kvpairs.  I would not expect that this would be empty, but it should contain the qualified type name of the parent being declared.

This explains why the gutter markers are correct and navigation works, but the parent type is not being recognized.

A simpler way to reproduce is to add this class to the project:

package org.springframework.data.neo4j.examples.hellograph;

import java.util.Set;

import org.springframework.data.graph.annotation.NodeEntity;
import org.springframework.data.graph.annotation.RelatedTo;
import org.springframework.data.graph.core.Direction;

@NodeEntity
public class BadClass {
    @RelatedTo(type = "", elementClass = BadClass.class, direction = Direction.BOTH)
    private Set<BadClass> reachableByRocket;
}


Because this class is annotated by @NodeEntity, the declare parents "declare parents : (@NodeEntity *) implements NodeBacked;" in Neo4jNodeBacking aspect should be applied in the editor, but it is not.  I'm guessing this is related to the fact that this is a binary asoect.

Comment 2 Andrew Eisenberg 2011-04-15 13:50:33 EDT

To see this in the debugger:

1. start a runtime workspace and add the Hello Worlds project to it.
2. Add the BadClass class shown above
2. Full build
3. in the base workspace, set a breakpoint at AJProjectModelFacade 899.
4. Add this condition to the breakpoint: relType == AJRelationshipManager.ASPECT_DECLARATIONS
5. In runtime workspace, right click on the gutter marker beside BadClass
6. Debugger should stop inside AJProjectModelFacade
7. In the expressions view or the display view inspect the expression "this.getProgramElement(handle)".  
8. You should see that kvparis is empty.

Comment 3 Andrew Clement 2011-04-26 12:27:04 EDT

Followed the debug in comment (2).  I've committed a new version of AspectJ where kvpairs is not null at that location, it is "{parentTypes=[org.springframework.data.graph.core.NodeBacked]}" but the underlining still occurs.

Comment 4 Andrew Eisenberg 2011-04-26 17:31:03 EDT

This has uncovered 2 AJDT problems:

1. AJDT was relying on the text of the IProgramElements.getDetails() method to determine if the target type is supposed to implement or extend the declared super type.  This is not a reliable way of getting the information since (among other problems) the getDetails() method returns null for binary aspects.
2. In order to find the erased type of a generic ITD method, AJDT needs to ask the World object for the erased type signature.  However, AJDT was passing in type signatures using '.' instead of '/'.  This was causing the target type not to be found.

Both problems have been fixed.  I am creating a few tests for this now before committing.

Comment 5 Andrew Eisenberg 2011-04-26 18:38:17 EDT

Urrrgh...this is turning into a bit more of a problem.

There are two problems with the following program now:

public class BadClass {
	void g() {
		List<String> b = persist();
		BadClass g = persist2();
	} 
}
 
aspect Foo {
	public <T extends List<String>>  T BadClass.persist() {
		return null;
	} 
	public <T>  T BadClass.persist2() {
		return null;
	} 
} 

The call to persist() is a warning because of an unchecked conversion from List to List<String>.  The reason is that for ITDs, we are erasing all type parameters and hence there is the warning.

Worse, the call to persist2() is an error since the type erasure of T is Object, which cannot be cast to BadClass directly.

I will need to do something more sophisticated here and not drop the type parameters when inserting ITDs.

Comment 6 Andrew Eisenberg 2011-04-26 22:01:50 EDT

*** Bug 332457 has been marked as a duplicate of this bug. ***

Comment 7 Andrew Eisenberg 2011-04-27 19:51:20 EDT

OK.  I have a solution in my workspace that appears to work.  The ITDInsert class is now being more careful to include type parameters with its inserted methods.  Similarly, IntertypeElement is including type parameters when it creates a mock method declaration.  These two things appear to make all editing issues go away.

The code is a little cleaner as well, so that's good.

However, I still need to create some tests for this, so I'll keep this bug open for now.

Comment 8 Andrew Eisenberg 2011-04-28 16:23:09 EDT

Fixed now and committed with regression tests.