[Collection] Links that help you to learn

[Xanderॐ]

For those that wanna implement Callbacks in java for better source control, or use bytecode manipulation for other ( evil ? ) purposes:

http://www.csg.is.titech.ac.jp/~chiba/javassist/tutorial/tutorial.html

 

For those that wanna learn code design and architecture to be able to make things like Phoenix-Engine easily:

http://www.javacamp.org/designPattern/

 

For those that wanna find or fix exploits in l2j based on race conditions and general thread synchronization issues:

http://www.javaworld.com/jw-10-1998/jw-10-toolbox.html

[Intrepid]

For those that wanna implement Callbacks in java for better source control, or use bytecode manipulation for other ( evil ? ) purposes:

http://www.csg.is.titech.ac.jp/~chiba/javassist/tutorial/tutorial.html

 

For those that wanna learn code design and architecture to be able to make things like Phoenix-Engine easily:

http://www.javacamp.org/designPattern/

 

callback is a highly not recommended thing to implement into l2j but anyway if someone wants to make web apps than its usefull... :)

[Xanderॐ]

callback is a highly not recommended thing to implement into l2j but anyway if someone wants to make web apps than its usefull... :)

 

If implemented correctly, they add absolutelly no overhead in the application. We are using them in our private svn and they work pretty well. Its a rework of the aionemu callback system, with the annotations removed. Saves you from applying 100 core patches and adds zero performance downgrade.

[Intrepid]

If implemented correctly, they add absolutelly no overhead in the application. We are using them in l2jsaver private svn and they work pretty well. Saves you from applying 100 core patches and adds zero performance downgrade.

 

Well it still creates a bunch of objects for nothing in many case(which increase the memory load), and on top of that it gives a really bad control over the source since you need to create an interface for most things separated.

 

The reason why people use callbacks are because they want an event notifier for web apps its not usefull for other things.

 

I know tho you picked to choose the callbacks from aion to the advice of a noob, but unless you want many many many small and useless objects for something that can be solved with a simple global task for example than you should not implement a callback. :)

[Xanderॐ]

We are probably talking about different things. I do not mean to hook interface lists inside functions in the source code and add objects that implement them. My callback system is based on javassist. It doesnt create any objects at all, it just applies the "patch" not in the source code, but on the bytecode when the JVM loads the class. For example.

 

public static void blabla()

{

 

System.out.println("hi1");

 

}

 

When the class containing that method gets loaded in the jvm, the jvm checks the javassist agent and if i have declared to do + testtest() inside blabla() , during class loading it manipulates and loads the following instead:

 

 

public static void blabla()

{

 

testtest();

System.out.println("hi1");

 

}

 

From then on, it juses the new class and voila, no extra objects, no extra memory, no extra cpu usage ;)

 

So the process of loading a class is :

 

New class requested ---> JVM gets the .class file in a byte[] array --> javassist agent transforms the class by patching --> ClassLoader loads the class and the application uses the patched one.

[Intrepid]

We are probably talking about different things. I do not mean to hook interface lists inside functions in the source code and add objects that implement them. My callback system is based on javassist. It doesnt create any objects at all, it just applies the "patch" not in the source code, but on the bytecode when the JVM loads the class. For example.

 

public static void blabla()

{

 

System.out.println("hi1");

 

}

 

When the class containing that method gets loaded in the jvm, the jvm checks the javassist agent and if i have declared to do + testtest() inside blabla() , during class loading it manipulates and loads the following instead:

 

 

public static void blabla()

{

 

testtest();

System.out.println("hi1");

 

}

 

From then on, it juses the new class and voila, no extra objects, no extra memory, no extra cpu usage ;)

 

 

But you know that a Java/Native call is in general 3 times slower than a Java/Java call right? :)

[Xanderॐ]

Its not a native call, why is it a native call ? o0 ? All it does is load a patched bytecode in the jvm. From then on JVM handles it like a normal class without knowing if its patched or not.

[Intrepid]

Its not a native call, why is it a native call ? o0 ? All it does is load a patched bytecode in the jvm.

 

Editing the byte code makes the code runs slower than if its in java and gets loaded into the jvm only without modifying.

 

This API allows you to read/write the bytecode on the fly which is not a good thing at all for l2j, not to mention its reflection based which is again a useless and really 1 of the worse ideas to ever use in l2j at high level. It makes understanding the code and coding harder and way more unfriendly.

 

There are high chance to get a really huge memory usage and even out of memory errors if the numbers of classes that needs to be loaded into the class pool even if the API try to reduce it.

 

it created instances "for ever" (imho until you replace the jar) so basically even if you use something rarely it leaves an instance there without allowing the garbage collector to get it since its blocked from it to keep the object for later usage.

 

The class loader of it is in general useless the current way of l2j is much better.

 

1 advantage i can say is you can modify the source on runtime but that can be done with other much better ways also(altho you would need a strong pc for it).

[Xanderॐ]

Editing the byte code makes the code runs slower than if its in java and gets loaded into the jvm only without modifying.

 

Where did you get that ? I tested two big loops of printing a string. One with the code in the class normally, the other way with an empty function that gets patched on runtime. The miliseconds that both loops took, to complete were approximatelly the same.

[Intrepid]

Where did you get that ?

 

Its a general fact a method call happens much faster if its a java/java call than if its a java from bytecode call ok thats not a real problem for you(i looked into other API not into what you use).

 

What i posted above at the reply 22 is what i found on your api so far.