[aspectj-dev] Weaving with Unresolvable Types in LTW

["Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx>]

I'm running into an unpleasant old problem in a new context: the greedy
AspectJ weaver. What do I mean? I mean the requirement for the weaver to
resolve any type referenced in a woven class (whether indirectly or just to
resolve a type hierarchy). Here's an example: I'm doing load-time weaving
against an application that bundles a standard Struts 1.1 jar. It turns out
there's a deprecated type, org.apache.struts.legacy.GenericDataSource, that
Struts distributes separately. However, a central class in Struts, its
ActionServlet, has a bytecode reference to a type that extends this type.
For compiling against the class with javac, this is sufficient. However,
when the AspectJ weaver sees this, it emits an error. In a load-time weaving
context, here's an example output:

error can't determine superclass of missing type
org.apache.struts.legacy.GenericDataSource
when matching pointcut (((call(* javax.sql.DataSource.getConnection(..)) &&
target(javax.sql.DataSource)) || (call(* java.sql.Driver
.connect(..)) && args(java.lang.String, ..))) || (call(*
java.sql.DriverManager.getConnection(..)) && args(java.lang.String, ..)))
when matching shadow method-call(void
org.apache.struts.util.GenericDataSource.close())
when weaving type org.apache.struts.action.ActionServlet
when weaving classes
when weaving

Now, in a build-time weaving environment this kind of error can be
frustrating to resolve (e.g., mocking out calls to third party libraries
that you don't own). In a load-time weaving environment, this error is hard
to address, for a library aspect that should apply in unknown environments.
In this example, it would be a rare application using Struts that would have
the legacy jar visible on its classpath, and it would be onerous to ask
library users to include this and other deprecated jars to suppress these
errors.

I do believe the weaver is still emitting woven bytecode output but is not
counting these "unknown types" matching against the shadows. Could someone
clarify this?

I think it's going to be very important for reusable AspectJ libraries to
have allow load-time weaving to work even in the absence of a type like
this. I would like to see this become a warning that is Xlint suppressable
warning. Basically, I think AspectJ load-time weaving should not impose
tighter type resolution requirements than Java does.

I think it shouldn't much matter whether the weaver would count a pointcut
as matching a join point shadow with such an unknown type in the picture. If
the rule were that unknown types were treated as never matching anything but
Object+ and naming patterns, I think the behavior would be correct (is this
what the weaver already does?). I don't think negation affects this since if
you ever have a join point where the unresolvable type appears, you will
already have a ClassNotFoundException at runtime.

I think for build-time weaving it's probably still right to make this an
error, because it's important that the woven class works as expected in an
environment where these unknown-at-build-time types are resolvable...

Thanks,
Ron

Ron Bodkin
Chief Technology Officer
New Aspects of Software
w: (415) 824-4690