Thoughts: Versioning, Class Reloading, ClassLoaders

Recently on Ted Neward's weblog there was a discussion about the limitations of the ClassLoader architecture: http://neward.net/ted/weblog/index.jsp?date=20030215 Ted offers some suggestion for improving the architecture, and it got me to thinking about a few related changes that I think might make the classloading more powerful and allow for quicker, cleaner updates of Java while giving you more control over how the updates affect your existing code. Now bear with me on this, it's not too well thought out, but I figured I'd start it and see what you guys all think.
(There are Three Changes)
The first change would be to build version-checking/loading directly into the classloader architecture. With version-checked loading, Sun (and developers) can deploy incremental updates without the need for delivery of an entirely new jdk/jre (e.g. rt.jar).
The second change is what could come out of using a version-checked loading method: You could set your code to use specific versions.
Example:
In the new Isolate API, it will be necessary to update java.lang.System to work differently than the current version. Let's say I want to run old apps as I always did, and some new apps using the new version of System. Simply start the JVM with -Djava.runtime.version=1.3 (or whatever) for runtime packages and -Djava.version.package=com.mycompany.data[1.3+] for third party packages. With this information the classloader automatically loads the proper version.
The third change (again drawing from the previous two):
Allow the System ClassLoader to redefine classes (not just arbitrarily, bear with me here). To fully realize the power of byte-code engineering, and dynamic runtime classes/decisions, I believe classes need to be able to be redefined. HOWEVER, I think this would HAVE to be coordinated with the versioning system. Let me explain:
When a class is defined it would automatically be given a version (whether or not you specify one) within the VM - maybe considered a "Runtime version number." When you redefine a class, you would have to specify a new version (there would be a required syntax for this that Java "forces" you to follow so we all would do it the same). CodeSources would then (in the jar?) specify whether they can use that new version, maybe like this:
compatibility:
package com.me.data.* + //ANY VERSION
package com.me.io.* 1.2+ //1.2 OR LATER As well, it would be done on a major/minor version system, so any minor versions would be assumed to be compatible with anything taking the major version of that (So if I can use 1.3, then any 1.3.1 has to be compatible with my code) Otherwise, these classes continue to use the earlier version.
One thing that might also be added (not sure if nec), is some extra methods (similar to Serialization methods?) to facilitate the reloading. So if my class uses a package that can be updated, then I have the ability to implement the method public void packageReloaded(String packageName, String version)? (Not sure this would be needed) but even if I do not implement that method, the JVM could still update the class, in a default manner. This is not well thought out and would need more time, but I think this could make Java VERY powerful in terms of ability to handle dynamic systems and architectures. (What issues are raised by something like this?)
As well, it would need security to be better thought out. I'm thinking that CodeSource-based permissioning is a poor concept when you're dealing with dynamically created classes that have no file (they're generated at runtime). So there would need to be an update of the security architecture for this - and a maybe way to ensure that only Sun/and/or the owner of this particular JVM installation updates the package java.* for example.

I don't know enough about class loading and such to really critique your suggestions, but I know the ability to upgrade only certain packages would definitely be nice. The only non-technical drawback that comes to mind is vendor support. Right now, an application server has a set of Java versions that it supports. With this change now maybe it supports Java 1.5 plus the NIO package version 1.6 plus javax.servlet 1.7, etc you get the idea. But that's just an inconvenience, not a roadblock.

Similar Messages

Dynamic class reloading in modular web application

Hi.
My web application has these requirements:
A. Functional modularization (like plug-ins). Modules will be simple jars containing application logic classes: dto beans, business logic services, dao (jpa), framework stuff (Struts2), etc...
B. At runtime and without restarting the application "class loading" must be aware of classes inside new, changed and removed modules.
C. Some of these jars will be outside the web application folder (WEB-INF/lib), possibly outside the container itself too.
My question:
1. Can I achieve all or some of my requirements with a Java web application?
2. How should I manage the modules?
3. Do I need some special web container feature (maybe osgi)?
4. Can I use a custom class loader in my application?
The architecture objectives are:
I. Provide scalability.
II. Efficient development process (independent deployment and no application restart required).
III. Better production support (no application restart required for changes).
More on the architecture:
a). Functional scalability, meaning this that my application may functionally grow up to an indeterminate number of small functional modules.
b). Modules will be developed, deployed and maintained independently so the application discovers and loads classes on demand.
c). Avoid a big .war file containing all the small modules because a small change in one module would involves deploying all the other modules (possibly hundreds o even thousands of them) and restarting the application.
d). Above point involves dynamic class reloading.
I guess this is addressed by OSGI (looks like heavy to deal with), Jigsaw (still under development) and maybe others. I think the key point is the class loader. I will develop a custom class loader but maybe you have some advice for me before starting to develop.
Thanks and regards.

Classes maintained by the container should not be loaded by an application. You want the container to read those classes and react accordingly. Most of those classes are read when the container starts up a container restart will be required. Trying to leverage another container within a container does not sound like it will be worth (if you can get it to work).
Perhaps you should state the problem that you are trying to solve with these modules so that others may suggest more feasible solutions to achieve your target goals.

Dynamic Class Reloading

As I know that setting has to be made to the application server to enable the class reloading features, so that the changes to the components (such as enterprise beans, servlets, and JSP files) to a running server can be deployed without having to stop the application server process and start it again.
I'm just wondering, for those Web Hosting Company that offer JSP-compatible Web Servers services, are they forced to have the Class Reloading Feature enabled for their Web Server?? else how they can provided 7 x 24 service, as no downtime are allowed, please advise?

"... else how they can provided 7 x 24 service, as no downtime are allowed, please advise?"
Most large organisations wishing to redeploy an application but maintain service would not use class reloading (which would be a path to chaos!) but would use their load balancers or clustering software to disable connections to some (half?) of their servers. They'd then load the updated software onto the out-of-service servers, swich the live traffic onto them and then update the remaining servers before bringing them back into service.
This kind of redeployment can also be achieved by running more than one instance of the app server on each box, with only one instance 'live' at any one time. Updates are made to the off-line instances and then connections redirected to them. This has the advantage that the old code is still in place so fall-back is easy if there's a problem with the redeployed code.

Guru question, class reloading, resolved symbols

How can I determine all of the class symbols that get
resolved in a java class file? I want this from java, the
utility javap doesn't really fit the bill since it doesn't
give me the information I want.
BACKGROUND
I'm creating a class reloader which loads many packages. In order to get the reloading effect, a new
class loader must be instantiated...which is fine. The usual approach is to reload every class on the class path, but this is too time consuming. I would like to
be more elegant and only reload the minimum set of class files and delegate appropriately.
In order to do this I need need to know all of the symbols used by a particular class. For example,
if a class ABC has a method that uses class XYZ, and
XYZ gets modified to be XYZ'. I need to reload ABC if
I reload XYZ', otherwise ABC will use XYZ. This is
behavior spec'ed in JVM class loader spec (5.3).
The JVM spec also outlines the format of the
class file, but I really don't want to parse this myself.
Are there any utilities to facilitate inspecting class
files and getting this kind of information.

The usual approach is to reload every class on the class path...Huh? I was rather certain that classes were loaded as needed, not as found.
I need to reload ABC if I reload XYZ', otherwise ABC will use XYZ.
This is behavior spec'ed in JVM class loader spec (5.3).I don't understand this either. You can't 'reload' XYZ. You can load a different class. Or you can use a different class loader and load the a class with the same name (although the jvm will treat it as a different class.) Or you can wait for the jvm to collect the class loader (which means no instances of XYZ at a minimum) and then load what ever you want. Reloading to me suggests that you are some how replacing the existing class and that can't happen.
If the only reference in ABC is a method (local and not static) then I don't believe the class will be loaded until the method is called.
Whatever class loader loaded ABC and XYZ will not be gc'd until there are no instances of the classes it loaded. So if both use the same class loader then by definition when you load ABC, when you get a chance to load XYZ you can do whatever you want.
So, given the above, I am not sure I understand the question.

Clarification needed on servlet class reloading

          I have a question about servlet reloading in WLS6.0
          Let's assume i have version 1.0 of a SomeServlet.class loaded in WLS.
          Client are accessing it currently.
          Now let's say i create version 1.1 of SomeServlet.class and i want to deploy it in WLS.
          I have the "servlet reloading" turned ON.
          So that means that version 1.1 will be immediately loaded by WLS right?
          Question: Will WLS first unload version1.0? If so, what happens to the clients who are using version 1.0?
          Will they get a ClassCastException? Or will they be abruptly switched from 1.0 to 1.1? Will they see any any error at all?
          Thanks.
          PS: If i had deployed the servlet in a WAR file, will the same rules apply? In other words, if i replace the WAR file will a newer version, what will happen to the classes from the previous WAR file that are being used by clients.
          Is there a document explaining "how WLS reloads/hot-deploys servlets/ejb"? I understand that WLS6.0 uses a new "classloader architecture" that is different from WLS5.1.0. Some document to explain the differences would be helpful. Thanks.


The new version will be loaded immediately into a new classloader.
          The old version will remain (in its old classloader) until there are no
          longer any references to it (which will happen when clients that were
          using the old version have completed their operations).
          mark
          Jeff Mathers wrote:
          > Did you ever get clarification on this point?
          >
          > I am trying to figure out how to force WLS 6 to reload servlets following a
          > re-compile. Your message hinted at a way to do this. Can you fill me in?
          >
          > Jeff Mathers
          > IT R&D
          > RWJPRI - Johnson & Johnson
          >
          > "R" <[email protected]> wrote in message
          > news:[email protected]...
          > >
          > > I have a question about servlet reloading in WLS6.0
          > >
          > > Let's assume i have version 1.0 of a SomeServlet.class loaded in WLS.
          > > Client are accessing it currently.
          > > Now let's say i create version 1.1 of SomeServlet.class and i want to
          > deploy it in WLS.
          > > I have the "servlet reloading" turned ON.
          > > So that means that version 1.1 will be immediately loaded by WLS right?
          > >
          > > Question: Will WLS first unload version1.0? If so, what happens to the
          > clients who are using version 1.0?
          > > Will they get a ClassCastException? Or will they be abruptly switched from
          > 1.0 to 1.1? Will they see any any error at all?
          > >
          > > Thanks.
          > >
          > > PS: If i had deployed the servlet in a WAR file, will the same rules
          > apply? In other words, if i replace the WAR file will a newer version, what
          > will happen to the classes from the previous WAR file that are being used by
          > clients.
          > >
          > > Is there a document explaining "how WLS reloads/hot-deploys servlets/ejb"?
          > I understand that WLS6.0 uses a new "classloader architecture" that is
          > different from WLS5.1.0. Some document to explain the differences would be
          > helpful. Thanks.

Package versioning (class)

Hi@all
I have a big problem.
I want to store a version number and a build number. I know that I can save the build number in the manifest but I don't know how I can store the version number of every class.
But I don't mean the class versioning. It must be possible to change the version number manually.
The solution to write the versions in a text file which is stored in a jar file is very bad and so I need a good solution for my problem.
Can help anybody???
Thanks,
bastlwastl

Hi
Interesting qn, but AFAIK, Java doesnt provide this functionality.
Understand where u r coming from, e.g. Person.java has version 1 and version1.1, difference is that 1.1 has different methods or just a different implementation. This is also perhaps driven by data, which maybe different.
A few thoughts...
1. Have methods getMajorVersion, getMinorVersion and u can invoke them dynamically via reflection. If it doesnt have the methods, so be it. Some may think implement an interface might help, e.g. Versionable or something but with reflection, it doesnt matter and sounds too draconian to get all developers to implement it :)
2. Use BCEL or JavaAssist to store the version numbers somewhere in the class file.

ClassCastException when classes (and classloaders) match. Confused.

Hi,
I am callng a method on an object using reflection. I then cast the resultant object. This cast gives me a ClassCastException. However I have added some debugging code as I suspected the Class of the object being cast was the same as the target cast too.
The class being cast to is called es.shared.ESData and when I try
object instanceof es.shared.ESData I get True.
So the object is of the correct Class (and is not null) so why would the cast fail ? I thought maybe they have different ClassLoaders so I got my code to print the following
object.getClass().getClassLoader() ;
ESData.class.getClassLoader();and the classlaoders are the same. So I have object of the type es.shared.ESData that when I try and cast it to es.shared.ESData a ClassCastException is thrown.
Can anyone help me understand why this would happen ? I have googled and found nothing of help, but then it is a very hard query to raise for google.
Regards
Russell
PS the code looks a little like this
Method method = serviceObject.getClass().getMethod("doESRequest", new Class[] { esData.getClass() });
Object result = method.invoke(serviceObject, new Object[] { esData });
System.out.println((result instanceof es.shared.ESData));//this always prints True
System.out.println((result == null));//this is false!
System.out.println(ESData.class.getClassLoader() + " = " +result.getClass().getClassLoader()); //these always match!
ESdata esDataResult = (ESData)result;//ClassCastException!

I noticed you ahve different spelling on the class name. Is that the problem? See ESdata vs ESData!
ESdata esDataResult = (ESData)result;//ClassCastException!

WEB-INF/lib class reloading

Are the jar/zip files placed in the WEB-INF/lib directory
of the web app reloadable i.e. if the classes in the jar file
are changed would they be reloaded by the webapp
class loader just like the classes in the WEB-INF/classes
directory?

1ro que nada te aconsejo que respondas en ingles... este es un foro en esa lengua.
si tu ingles es malo te sugiero que uses http://babelfish.altavista.com
2) do you have include the Reports library in yours projects.

How to tell what java version classes where compiled?

Is it possible to get the version of the Java SDK the classes were compiled with from within a Java application? I think about something like:
System.out.println("Application classes compiled/compatible with "+getClassCompilationVersion());

For the minimum check, the point is that i get the following exception when i try to run a application that was compiled with/for 1.4 is tried to be started with a 1.3 JRE:
Exception in thread "main" java.lang.UnsupportedClassVersionError: de/icomps/pro
totypes/Test (Unsupported major.minor version 48.0)
        at java.lang.ClassLoader.defineClass0(Native Method)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:488)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:10
6)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:243)
        at java.net.URLClassLoader.access$100(URLClassLoader.java:51)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:190)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:183)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:294)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:281)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:310)I hoped to somehow catch this and print a clean error message. But it seems, that the new classes can't be used ... even though the main() method doesn't use any 1.4 specific API. The JVM rejects the classes just because of the newer class file format versions.

NON-SERVLET, NON-EJB DYNAMIC CLASS RELOAD

hi,
          In weblogic 5.1, is there a way to reload a class from the clientclasses directory without restarting the server? it's just a class in the clientclasses used by the JSPs. a kind of hotdeploy for NON-EJB, NON-SERVLET CLASS. SPECIFIC guidance will be immensely appreciated..
          Thanks in advance
          Vijay


please show us the full error message.
it sounds like a classpath problem...

'Static' class reloading

OK - there are no static classses but. . .
For a class which provides no way to create an instance of itself, does the class loader ever remove the class from memory?
For instance, assume class Foo has a hugh static initializer. No other classes ever hold a reference to Foo, but they do occasionally call static methods of Foo. Will the class loader ever drop Foo from memory, then reload it (re-executing the static initializer and assigning the static fields) when another class calls one of Foo's static methods?
If not, do class definitions pile up endlessly in memory?
Thanks,
Eric Everman

do class definitions pile up endlessly in memory?Yes, if there are endless class definitions to load.
Maybe I should ask this one back to you:
does program have endless new class definitions to load?[b]
--lichu

IPlanet 4.1 & class reloading

Hi all,
i'm using iPlanet web server 4.1(FastTrack Ent. Edition) and just can't figure out how to automatically reload the user classes instantiated from my servlet. The latter is in /usr/netscape/server4/docs/servlet but the user classes are in a different location, /usr/test. I'd like to be able to make changes to these user classes w/o having to restart the webserver every time in order to reload these.
please help...

Hi,
1) stop the server
2) In the contexts.properties file, edit the following property: context.global.isModifiedCheckAggressive=true
3) start the server
(got this from http://knowledgebase.iplanet.com/ikb/kb/articles/4339.html )
Hope this helps,
Kurt.

One computer updated the other says up to date but they are the old version and reloading doesn't work.

I updated to the latest version on my desktop, then my credit card was hack so it was replaced and I had to reset my credit card info. When I tried to update my laptop the CC App said all were up to date - but trying to load a file from the updated Premiere app from my desktop onto my laptop fails with a "Newer version" error message. I unloaded and reloaded premiere but that did not work.

Alw51 what specific Newer Version error message are you referring too? Also which operating system are you using? Finally what version of Premiere Pro are you downloading and installing?

How to disable class reloading feature

Hi,
how can I disable the reloading of servlet classes in oc4j?
Thanks
GÃ¼nther

no answer?
Please help me!
Thanks
GÃ¼nther

Weird tomcat problem (class reloading)

i have very weird problem with tomcat 3.2.3.
for example i have html page which calls servlet.
everything is fine when i start tomcat. now when i
recompile servlet and try to call it again, this is
what i get:
Internal Servlet Error:
java.lang.IllegalStateException: Can't happen -
classname is null, who added this ?
at
org.apache.tomcat.core.ServletWrapper.loadServlet(ServletWrapper.java:261)what kind of error is this and what causes it? it
happens even if i try to refresh html page after
compiling.
is there any way to fix this because it is realy
tiring to restart tomcat each time i recompile
servlet.
thanx for help

Tomcat has to be restarted after recompiling any
servlet-class that was already invoked by tomcat.It's
the price you have to pay for a free server.
I think that this is not right. You can specify that an application context is "reloadable" in the server.xml file. This means that the servlet classes will be reloaded if the servlet has changed. This doesn't work for regular classes such as beans because they use a different class loader. (But Tomcat 4.0 is supposed to have something like this.) So just specify your servlets in web.xml and make sure reloadable="true" in the context in server.xml.

Thoughts: Versioning, Class Reloading, ClassLoaders

Similar Messages

Maybe you are looking for