Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] no match for this type name...

Michael,

A belated reply/clarification:

The reason that this could potentially be a legal situation is this:

call(public * *Facade.*(..))

Here you would not want an error simply because you had no Facade's in your system. This I agree with.*

However, I am temporarily at a loss to explain why an absolute type name needs an import when a wildcarded type name does not. Obviously an absolute type name demands a stricter level of checking--which I approve of. But again, I never really understood why the warning wasn't an error. I remember it had something to do with load time weaving, but I can't recall exactly what.

I'll put a really fine point on the question:

If the lack of a wildcard combined with the lack of an import makes a type invisible to an aspect, why is this not an error? When is this correct? Can anyone give an example?

I've encountered this warning a number of times during development, and it has never signaled anything but an error.

Cheers,
Nick

P.S. If you do add a bug, post to the list and tell us its number. I'd like to follow the discussion.

* Though I think that it would be nice if you could tell ajc to warn you if a specific pointcut matched nothing.

On Jun 3, 2004, at 9:54 AM, Ramnivas Laddad wrote:

Michael,

AspectJ developer have tried to improve error/warning messages
to make them clearer and user friendly. However, it is upto
us -- aspectj users -- to point out areas for improvement
and help by suggesting better messages. In fact, these
XLint warnings are a result of combination of user feedback
and developer initiative; in pre-1.1 version, there were no
warnings at all and you would be wondering why program compiled
fine, but did not execute as expected.

For those who are seasoned to seeing this error message,
it is "once you know, you know" kind of situation. It is,
therefore, importnant that you, as a representive of
newcomers to AspectJ, help by narrating your experience
and suggesting what would have been useful to you (which
you are already doing).

Okay, now onto the error message itself. It is a little
complex to come with a simple error message. You could see
error message for one of the following reason:
1. Misspelled type name: In this case, the type won't exist
   anywhere in the system. This also includes case of fully
   specified type name with missed/misspelled packages.
2. Correctly spelled type name but missed package statement
   (and type not in the same package as the aspect): In
   essense the type isn't visible to the aspect.
3. Type name specified as wildcarded package: This would be
   case when pointcut say something like call(com..MyTypeName.*(..)).
   In this case, you don't even need a package statement and
   the program will still compile fine.
   (This situation is actually covered by a different XLint
    warning, which is turned off by default).

I think perhaps it will be best if you file this as a bug so that
it can be tracked and resolved in a new version of AspectJ.
I will add my input as a comment to that bug.

-Ramnivas

--- Michael McConnell <mcconnellem@xxxxxxxxx> wrote:
Ramnivas -- At first I thought you were being sarcastic when you
wrote:

For the error message, how about something like:
"Unknown type MessageCommunicator. Please ensure correct
 spelling and/or the type is visible to the source file
 (check your import statements or use the fully-qualified
  type name)".

And then I saw the following:
The downside I see is sheer verbosity of the message.
Perhaps a better alternative is to point to document
that elaborates on "Xlint:invalidAbsoluteTypeName".

I think the latter is much more preferable than the former. But I
think *BOTH* miss the
point that I was trying to make earlier, which is: if I were using
standard Java
(with/without Eclipse), and I had forgotten the package statement, I
would have gotten
the following message: "The declared package does not match the
expected package xxxxx".

NOT the statement:  "no match for this type name: XXXX
[Xlint:invalidAbsoluteTypeName]".

I mean --- this is almost as good as a 1970's ABEND NNNN statement.

In your book, you state that ajc is a superset of javac. Which is
fine as far as it goes,
but (I wish the AJC developers had decided to) add in the syntax and
semantics that AOP
requires, but *don't mess with standard java*, especially the error
messages and warnings
that you would expect to see if *writing standard Java*. If the
package and import
statements are valid within an aspect, treat them as they would a
standard Java
statement, and issue the standard messages we have all grown to know
and love.

NONE of this is YOUR FAULT. However, there was a suggestion on this
forum to start
documenting errors like as to probable causes. As much as it would
have helped me, I
would prefer that aspect users get together and start demanding tools
from ajc developers
that build upon the knowledge that they already know, and do not
require
learning/generating differential diagnoses for symptoms they have
never seen.

FWTW,
Michael


=====



	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users



	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users


Nicholas Lesiecki
Software Craftsman, specializing in J2EE,
Agile Methods, and aspect-oriented programming

Books:
* Mastering AspectJ: http://tinyurl.com/66vf
* Java Tools for Extreme Programming: http://tinyurl.com/66vt

Articles on AspectJ:
* http://tinyurl.com/66vu and http://tinyurl.com/66vv



Back to the top