About security, I guess that if the customer is smart enough to
understand your code (either looking at the bytecode or decompiling it),
then he may inject his own code that inhibits your checks. But I think
this is not related to the AOP-way of doing this, i.e. if the customer
understands that every <init> method starts with

if (invalidLicense) return;

then he can inject "invalidLicense=true" at the beginning of every <init>.
No matter if your check was inserted statically or at run-time or whatever.
Obfuscation should make harder to find your check, but maybe you can
"hide" it enough to make the task quite difficult (maybe you could
insert some checks in random locations too).

Otherwise, I think it's a good idea, you could do it "statically"
(writing a tool that modifies every class - then you distribute the
modified package) or "dynamically" (writing an agent -see
java.lang.instrument- that modifies your methods when each class is loaded).
In your case I think that the "dynamic" way may slow down a bit your app
and the end user could just disable it to inhibit your licence check.

Francesco

On Wed, 21 Dec 2005 18:21:17 +0800, "Ravi Shankar Nair"
<sujashankar@pacific.net.sg> wrote, quoted or indirectly quoted
someone who said :

What do you mean by AOP (Aspect Oriented Programming?) Have you an URL
for the product/technique you are considering?

License programs only stop lazy or ignorant users.  If you want to
stop hackers even obfuscation won't stop them. Using AOT compilation
will probably will make it not worth their while.

see http://mindprod.com/jgloss/obfuscator.html
http://mindprod.com/jgloss/aot.html
http://mindprod.com/jgloss/installer.html

[...]

You're writing a J2EE application, and yet you aren't willing to trust
your customers enough to avoid blatantly illegal actions?  That would
make sense for a computer game, but typically J2EE customers are
businesses.

AOP, in general, needs to be used very carefully to avoid serious
maintenance hassles.  You have to think REALLY hard about whether you
really do want EVERY situation that matches your pointcut to result in
the specified behavior.

Many of the common AOP examples are extremely worrying.  You see code
telling excited people how to define join points that match patterns of
method names, or insert code when exceptions are thrown, or otherwise
assign special significance to a not-necessarily-significant programming
action.  The problem is that reasonable Java programmers make
assumptions about their environment.  Everyone in the project now needs
to internalize language elements; things that mean one thing in Java,
but mean something completely different in this project.

I talked to someone recently about a project where someone had
"helpfully" defined a join point to roll back the current transaction if
an exception got thrown anywhere.  The problem was that eventually,
someone wrote some code that tried to perform an optional operation that
could fail in an unimportant way.  This poor programmer banged his head
against the wall for a long time before realizing that even if he caught
the exception, throwing it in the first place caused a rollback of the
current transaction.  He had to go modify the pointcut to exclude his
code.

Every join point you define that co-opts a normal Java construct is
another thing that programmers have to remember ALL THE TIME when they
are working on this project.  Really competent software developer
understand that their job is to manage complexity -- essentially, to
find ways to ignore (and help others ignore) anything that's not
relevant to the immediate problem at hand.  Possibly the MOST
destructive thing you can do for maintaining code is to add things that
have to be remembered EVERYWHERE.  Unfortunately, AOP is often used to
do exactly that.

This is not a caution against using AOP.  It's a caution against using
it without understanding and avoiding the potential nightmare you ight
be creating.  If you use a modern AOP compiler with JDK 1.5 annotations
and use annotations in your join points, that disadvantage of AOP is
substantially reduced (in fact, practically eliminated, though there
remains the risk that some exhuberant programmer reads an online
tutorial that tells them how to screw you over with AOP, and does it).

Aside from that, make sure this doesn't add too much complexity to your
deployment process.  If not, you're golden!