Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] aspectjrt.jar name

> To have a version class, embedded in aspectjrt.jar ...

I remember something like that coming up before:

  http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/aspectj-home/doc/faq.html#q:versioninfo

It's a good question.

Right now both jars support the Java standard
mechanism for getting version information from
Package (in Java 1.3), and aspectjtools.jar also
has org.aspectj.bridge.Version.  ajc now requires
1.3, but still does what a 1.2 client would (read
the version directly) because it checks before
setting up the user classpath.  So there are
already ways to discover the version.

It's worth proposing as an enhancement request
that the runtime classes include a version class
for those who embed the classes in their own jars.
This could be used (1) by ajc in embedded form,
(2) as an automatic check generated into aspects,
or (3) by user code.

(1) Applications that embed forms of ajc - e.g.,
classloaders - will be directly monitoring the
messages emitted using an IMessageHandler, so they
can filter out the warning about the missing
aspectjrt.jar.  It's not clear whether emitting
the warning only when the types are not found
would help these clients.  And I prefer to leave
it to the compiler/weaver to decide what versions
warrant warnings. So this isn't a strong driver, imho.

(2) It might avoid errors if aspects, when they were
loaded, verified that they could access a version
that is the same or greater than the one they were
compiled with.  (Depending on how well we understood
false positives, this early warning could be enabled
or disabled by a compiler flag or a runtime
environment variable.)  This could work with a
version in aspectjrt.jar but not in the official
public runtime API.  (For the check, there's no
need for a class; it could be implemented as a static
method on JoinPoint.)

This might be a good code contribution: a -X
compiler option that generated a check for a
version at aspect load time (and emitted only
one warning or error on failure).

(3) Before we surface a version API in the
runtime that's accessible to aspect clients,
I'd want to see a compelling use case.  The
best I can think of is to log the version
of the runtime classes in use.  (I'd discourage
users from varying code at runtime based on
versions.)


Wes

a@xxxxxxxxxxxxxxx wrote:

Following proposal:
To have a version class, embedded in aspectjrt.jar and aspectjtools.jar.
The you can simply try to load that class, compare the version number,
and if that fails you can emmit a warning etc. ...
This approach has IMHO a big advantage, if aspectj.rt is embedded in an
other jar file, extracted on the file systems, etc. this approach does
still work. (Or is this not permitted by the license?)

If that proposal is fine, I think I can submit a patch.

regards
   Arno


Wes Isberg <wes@xxxxxxxxxxxxxx> schrieb am 29.07.2003, 19:52:36:

> Why does it check for
> a JAR named aspectjrt.jar?

ajc checks for aspectjrt.jar both to ensure the
org.aspectj.lang..* classes are available and to
verify that the version of the runtime classes is
the same as that of the compiler.  Both being
common mistakes, it saved a lot of support time to
provide the warnings.  However, ajc will emit an
error only if it can't find a runtime type the code
uses (e.g., JoinPoint).

When renamed, the jar and version check is failing,
but the types are being found.  You could end up
using the wrong version of runtime classes without
being warned about it, but it should work fine.

We debated sealing the runtime classes or emitting
an error if the aspectjrt.jar were not on the
classpath, but both seemed too inflexible for
some of the applications we anticipate.  It would
be nice if we inspected the jar containing the
runtime types for its version rather than seeking
a particular named jar, or if we searched for
reasonable variants of the name (see, e.g., the
Ant taskdef search for aspectjtools.jar variants,
which could be generalized in a ..util.Lang method);
a patch from a contributor would be welcome here!

(That's more than you ever wanted to know about...)

Wes


Volkmann, Mark wrote:

Interestingly it seems to work even if we rename the JAR.  It just prints
out a warning message that it couldn't find the JAR.  Why does it check for
a JAR named aspectjrt.jar?



-----Original Message-----
From: Wes Isberg [mailto:wes@xxxxxxxxxxxxxx]
Sent: Monday, July 28, 2003 5:10 PM
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] aspectjrt.jar name


Right now, we do check for that name.

There can be only one version of the AspectJ runtime classes in a
namespace, so you couldn't run with a different version in any case.
But the later version is upwards-binary-compatible with the earlier
version, so you might be able to replace the Cactus library with
the one from the AspectJ 1.1 distribution.

Wes

Volkmann, Mark wrote:



Does aspectjrt.jar have to be named that?  I'd like to rename it to
aspectjrt1.1.jar to avoid conflict with the version that

Cactus uses, but


when I do that, ajc reports that it can't find the JAR.




**************************************************************
*********************


WARNING: All e-mail sent to and from this address will be

received or


otherwise recorded by the A.G. Edwards corporate e-mail

system and is


subject to archival, monitoring or review by, and/or disclosure to,
someone other than the recipient.


**************************************************************
**********************

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users




***********************************************************************************
WARNING:  All e-mail sent to and from this address will be received or
otherwise recorded by the A.G. Edwards corporate e-mail system and is
subject to archival, monitoring or review by, and/or disclosure to,
someone other than the recipient.
************************************************************************************


_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users




Back to the top