Vitruvian Tux

Program very often feel the need to insert additional pieces of code in a system during its use (consider, for example the possibility of including plug in any one application, they must be used immediately after their "installation") we see how and within what limits, this is achievable with the language of the Sun

Compiling at runtime:

First, it is useful to know that from any Java application can invoke the compiler (javac) with the usual parameters (classpath and everything else) with a simple

  new String [ ] { Main. Compile (new String [] (
 , "-d", "bin /",
 filename + ".java" } ) ; "src / generatedCode /" + filename +. "java")); 

NB: for the various parameters (I left out many, including the options of compilation) I leave the documentation of APIs.

Loading:

Because you have the file. From class to load our application we have 2 roads, starting from the assumption that we know the name of the class:

1. If we do not have specific information about the class deduce through the mechanisms of reflection and instantiation methods;
2. If we have structured the "plugin" to implement a known interface to instantiate an object (as we shall see shortly) and call the methods of the interface.

2 I will consider the case because otherwise digress too much on a subject which is quite complicated and interesting reflection.

Consider the following case:

Class A (the one we want to load) B implements the interface.

  new ClassLoader ( ) ; ClassLoader loader = new ClassLoader ();
 gt ; cls = loader. loadClass ( "A" ) ; Class & lt;? & Gt; cls = loader. LoadClass ( "A");
 B ) cls. newInstance ( ) ; Istanza_di_A B = (B) cls. NewInstance ();
 ... ) ; istanza_di_A. metodoDiA (...); 

As you can see the process is very simple to implement, let's see now what is the main limitation.

UnloadingReloading:

Unfortunately, the JVM does not allow the unloading of classes loaded bytecode on.
Consider the idea of amending the code of the class once after instantiating an object of that type in our program. We would, as would seem natural that, once loaded bytecode of the class changed and recompiled, the new objects of type "A" are created according to the latest version available.

Unfortunately, this does not occur, we see why.
The classloader, which previously we used to "charge" in memory of our class bytecode at runtime, as we have said can not be (manually or automatically) to handle the unloading of classes instantiated by the application. At the time of the creation of an object is merely to follow the following algorithm (which carry a very simplified):

1. Check on a data structure (a hashtable) if there is an entry for the class that he was asked to load by going with the class name ( "class_name" -> "bytecode");
2. If you can not find matching entries in the name creates one and, after reading the file. Class, save the bytecode in such a structure then returns an instance of the program.
3. Alternatively, if you find an entry for the class name, is not concerned in any way to assess whether the bytecode is updated or not; instantiates an object from bytecode saved and returned to the program.

As you can imagine then the changes will take effect only when you reboot the program.
The only existing solution is to implement a custom ClassLoader which case we deal with caricareistanziare classes that we want to use as a plug-and that, once any change occurs, we can "throw away" (by placing all its references to null) reinstanziarene for a new application that takes care of managing the new code in its private data structure.

Cumbersome real solution? Well, if he does well to update the MENDMENTS Tomcat JSPs would say it is appropriate to adjust

Popularity: 19% [?]

Bookmark to:

Keywords: bytecode, ClassLoader, Compile, Dynamic Loading, HotSwap, Java, JSP, JVM, Loading, Reloading, Runtime, Tomcat, Unloading

leave a response , or trackback from your own site. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.