Whats your opinion on AspectJ for L2J 3rd party coders ?

[Sylar88]

With 3rd party coders i mean those that code customs in the core and dont like it getting messed up during sync.

[jurchiks]

http://en.wikipedia.org/wiki/AspectJ
Looks very interesting tbh. Thx!
I don't think this would be interesting to 3rd party coders only, could be used for retail stuff aswell.

[Sylar88]

Yap, the main thing i found fascinating is that i can hook anything in the core without changing its code. We can write our own aspects which hook themselves in the L2J classes and then compile with the AspectJ compiler instead of javac.

AspectJ compiler does his magic importing the aspects in the l2j code and produce the class files bytecode. And from then on there's no aspectj element since the jar can run normally in any VM.

[jurchiks]

Yeah, it's something that might even be used for theone's event listeners, wouldn't you agree?

[Sylar88]

+1.

Though i got no clue on the code's optimization level when using jvc instead of javacc. I did run some tests though but i didnt see any significant difference between javac vs jvc generated class files.

[theone]

The concept is very interesting, it's a more complete way to make what I was calling the "Interface engine" in another post. My idea was to simply use simple template interfaces for most of the more important classes in the core and extend those with each a "base template" which would contain the "L2J-approved" methods, then if you want to mod these methods, you can do this in the dp by extending one(or many) of these and register it in the proper class.
Both methods could work, AspectJ and mine, however remember that there are alot of newbies around and make sure that the "prefered" method wont bring too much "How can I do this?", "Please explain to me...", "Can you do this for me? It's too complicated :S ", etc...
Just make sure you keep the KISS (keep it simple stupid) rule in mind
I'm not sure which approach is best... that remains to be determined. Although your idea would save me alot of hours of work

[Sylar88]

Judging from yours and my signature, we both adore the lazy " make it for me " kids

Anyway some things that i found out so far and might be useful to those wishing to experiment:

1)Instead of writing new ant tasks to integrate AspectJ in L2J, you can use the AspectJ Adapter. Find the javac task in your build.xml and add

compiler="org.aspectj.tools.ant.taskdefs.Ajc11CompilerAdapter"

Be sure to add the aspectjtools.jar in your ant classpath ( windows --> preferences --> ant ... ).

2)Based on 1) if Aspect files are not ending in .java extension javac will filter them out and wont allow aspectj weaver to integrate the aspect's code. So be sure to name them .java instead of the default .aj

3)Each time an aspect's pointcut is changed, the aspect IDE plugin recompiles the classes searching classes matching the signature. If the signature doesnt specify a specific object it may crash eclipse due to huge recompilation.

4)Change the builder of eclipse java l2j project ( .project .classpath files ) so as the project becomes an AspectJ instead of Java project.

[jurchiks]

It says that AspectJ is very easy to learn bcuz it's very similar to Java. As far as the samples I've seen go I concur.

[theone]

The only thing I'm wondering about still about AspectJ is... will most devs be able to use it?
Lets remember that this is an open source project with alot of people who have scarce at best fundamental knowledge of programming. Although I agree that your solution would be best for projects involving mainly experienced or well trained devs, in this case I'm worried about the outcome... i.e.: will it be too complex for most to understand? (even if for some of us it seems rather easy, lets not forget that most of them are not some of us )
I still think it's a very valid suggestion, especially since it goes in the same line of thought as what I was proposing, but just thought I'd point this out.

[jurchiks]

TBH I wouldn't care; you don't have to (and you must not) feed the knowledge with a spoon, people can aways just read the existing code or use the "old ways" (or GTFO if they're stupid and not willing to learn). In any case, they would need to learn java and so I don't see what would change apart from the approach to the code.

[Stake]

I always make my codes as close to AOP as I can nowadays. This is called kinda an API programming. Anyway, AspectJ is great. I guess it uses only preprocessor patterns, because hooking is just about replacing some instructions, like inserting a call before another call, like exception handling, or wrap calls in one call, etc. It is a great tool for change one application's code without much modification, but intended only for this. If you write a Java app implementing an API, you don't need to care about more AOP.

[theone]

After documenting myself a bit more about AspectJ, it seems to be a very promising idea I must say

[Sylar88]

hehe nice, what i haven't figure out yet, is how to divert the control flow. For example :

public void foo()
{
action1();

if(action2())
action3();

}

I want for example this to return after executing action1(). The only way i can think so far is to use an advice with around() rule on foo() and rewrite foo myself with the if {} excluted.

Any other ideas ?

[poltomb]

I have played with AspectJ and it is a cool technology indeed. I was first attempting to create an event listener framework using annotations, interface injection, and reflection (so it would work kinda like how C# delegates work). I was in the middle of making it, then got distracted by work :/ I haven't done much with AJ since then, but I would be happy to help you guys with any questions you might have or give ideas on implementation. Feel free to PM me here.

Also, you might want to look into using the new invokedynamic features of JSR-292. Dynamic invocation is many times faster than reflection.