|
Replies:
14
-
Last Post:
May 16, 2005 6:14 AM
by: greggwon
|
|
|
|
|
|
|
Redefine Classes
Posted:
Mar 12, 2005 7:46 AM
|
|
|
I would like to be able to redefine classes at runtime. I know that it is currently possible to redefine the body of mothods, but I think I can't add / remove methods and fields.
The use case I have in mind is RMI-based systems and Java-based systems that run for a long time. These systems currently need to be restarted when new versions of a class become available.
Is there some work going on (inside Sun) to make unrestricted class redefinition possible and to research the problems that class evolution creates?
Thanks.
Sebastian
|
|
|
|
|
|
|
Re: Redefine Classes
Posted:
Mar 14, 2005 6:26 AM
in response to: slohmeier
|
|
|
Java already has the hotswap functionality.
|
|
|
|
|
|
|
|
|
Re: Redefine Classes
Posted:
Mar 14, 2005 6:40 AM
in response to: regexguy
|
|
|
You mean HotSpot? I thought this is just-in-time optimizing compiler that is also able to de-optimize when new classes are loaded or perhaps the body of an optimized method is changed.
How can I use it to e.g. add a method to one of the loaded classes?
|
|
|
|
|
|
|
|
|
Re: Redefine Classes
Posted:
Mar 14, 2005 7:01 AM
in response to: slohmeier
|
|
|
Here's how to use it in Ant for debugging:
https://hotswap.dev.java.net/
Not sure of how the details work, but if you look thru the info at the above link you can probably figure it out.
|
|
|
|
|
|
|
|
|
Re: Redefine Classes
Posted:
Mar 14, 2005 7:06 AM
in response to: regexguy
|
|
|
@regexguy:
Then try removing/adding fields and methods and then Hotswap the class. Good luck.
The Hotswap functionality has been in Java for years; Java 5.0 brought the instrumentation API that allows Java agents to modify method bodies at runtime.
Neither of these allow to change the class layout (There are basic problems; what if you add a field to a class... what happens to the existing objects of that class? They won't have the field, and code accessing it will fail or produce undefined results; touching all objects and updating them to the new layout might work, but can cause inconsitancies with classes... for instance, a field that is set to a value in a constructor... what should this be set to in the updated object?)
Message was edited by: murphee
|
|
|
|
|
|
|
|
|
Re: Redefine Classes
Posted:
Mar 14, 2005 7:42 AM
in response to: murphee
|
|
|
Yep that's the kind of things I'm interested in.
One way to circumvent the problem with the new field that is initialized in the constructor may be to add a
private void <reinit>(long serialVerUID) {
switch() {
case 1L: // init the field added in the second version
case 2L: // init the field added in the third version
}
}
method that is generated by the IDE and invoked when the class is redefined.
Of course there are much more questions (e.g. when to update classes in a running application?). What I would like to know if there is anybody at Sun or outside who is working on these questions.
|
|
|
|
|
|
|
|
|
Re: Redefine Classes
Posted:
Mar 14, 2005 8:26 AM
in response to: slohmeier
|
|
|
Might be a good question for the Hotspot VM Chat tomorrow (15th March).
Smalltalk or other dynamic environments might already have solutions, as they've allowed to redefine and enhance classes of existing classes for some time. I tried to find something on this but haven't really found anything good.
Any pointers to ideas/papers on this are greatly appreciated (hint, hint).
|
|
|
|
|
|
|
|
|
Re: Redefine Classes
Posted:
Mar 14, 2005 8:49 AM
in response to: murphee
|
|
|
Good idea. I added the question to the forum gathering questions for the chat.
I've searched for papers on this and found an number of papers that include info about this topic:
Class and Data Evolution Support in the PJama Persistent Platform by Misha Dmitriev;
Safe Class and Data Evolution in Large and Long-Lived Java Applications by Mikhail Dmitriev
Both of these papers were created during research using the PJama JVM that resulted from the Forest project at Sun which is still accessible at http://research.sun.com/forest/. PJama was a project that implemented Orthogonal Persistence with Java (e.g. save the state of the VM and restart with this state the next time instead of starting from scratch again).
The existence of the papers indicates that they indeed thought about the problems that class evolution creates in long-running applications. (Didn't have the time to read them yet).
|
|
|
|
|
|
|
|
|
Re: Redefine Classes
Posted:
Mar 18, 2005 6:28 PM
in response to: slohmeier
|
|
|
The short answer is to use interfaces and class loaders to load different implementations behind the interface.
The definitive paper on this is
--------------------------------
Sheng Liang, Gilad Bracha
October 1998
ACM SIGPLAN Notices,
Proceedings of the 13th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications,
Volume 33 Issue 10
Abstract
Class loaders are a powerful mechanism for dynamically loading software components on the Java platform. They are unusual in supporting all of the following features: laziness, type-safe linkage, user-defined extensibility, and multiple communicating namespaces. We present the notion of class loaders and demonstrate some of their interesting uses. In addition, we discuss how to maintain type safety in the presence of user-defined dynamic class loading.
--------------------------------
For a longer answer, it would help to know what you were trying to do. That is, what's the problem you are trying to solve; not just replacing methods for the fun of it.
|
|
|
|
|
|
|
|
|
Re: Redefine Classes
Posted:
Mar 20, 2005 3:57 AM
in response to: peterkessler
|
|
|
The paper you point to is a good example what I want to avoid. They write that they don't address the problems that arise from schema evolution. They show how the problems can by bypassed using multiple classloaders.
One use case I have in mind is a Jini Message Board (available on http://conferences.jini.org  ) on the internet. This system consists of a Jini service that is accessed by numerous Java clients that I can't control. The clients ask the server for new messages and can add messages to the server. Now I want to change the message class i.e. all clients need to download this class and update all instances of this class to the new schema. This could be done by restarting parts of the client when multiple classloaders are used. But it would be more elegant if the class would simply by redefined.
Please note that I'm not saying 'I want to be able to add methods to already-loaded classes in Mustang'. I want to explore unrestricted class redefinition to find a way to safely redefine classes (and instances!) at runtime to avoid having to handle mulitple classloaders etc.
How to redefine the class and which rules to follow when redefining a class is of course still to be found out (and not part of this topic).
So to answer my original question you might tell me about any efforts in- or outside of Sun that you know try to tackle the problems associated with unrestricted class redefinition, or any person you know who might be in a better position to answer the orginal question.
Sebastian
|
|
|
|
|
|
|
|
|
Re: Redefine Classes
Posted:
Mar 31, 2005 9:08 AM
in response to: slohmeier
|
|
|
Ok, given the missing answer I conclude that there are no projects working on this topic.
I think I will take some time to read the papers from the PJama project I mentioned earlier before continuing to think about this topic.
Sebastian
|
|
|
|
|
|
|
|
|
Re: Redefine Classes
Posted:
May 16, 2005 6:14 AM
in response to: slohmeier
|
|
|
Hi Sebastian!
> One use case I have in mind is a Jini Message Board
> (available on http://conferences.jini.org ) on
> the internet. This system consists of a Jini service
> that is accessed by numerous Java clients that I
> can't control. The clients ask the server for new
> messages and can add messages to the server. Now I
> want to change the message class i.e. all clients
> need to download this class and update all instances
> of this class to the new schema. This could be done
> by restarting parts of the client when multiple
> classloaders are used. But it would be more elegant
> if the class would simply by redefined.
In this case, it seems to me that the messages could be created by a factory object that comes from the server.
public interface MessageFactory {
public Message getInstance( User to[], User from,
String text );
}
There might be methods on Message that allow you to set subject if that concept is supported etc. If you use interfaces for each of the features that you want the message to be able to support, then the user of the message will have access to the features it supports from a receive perspective. The factory allows the versioning to be managed centrally. And, the codebase, comes from the factory service so that classloading automatically versions the new objects and maintains compatibility with the old objects. You would want to use Marshalling to transport the messages away from the clients so that the original codebase stays with the messages.
It could be that the generic features of messaging would be encapsulated in an interface such as
public interface MessageBase {
public Message getContent();
public List<User> getTo();
public boolean isTo( User u );
public User getFrom();
}
As you evolve the uses of the messaging, you can version this interface in the implementations. Can you give some specific types of evolution which you are having problems dealing with?
|
|
|
|
|
|
|
|
|
Re: Redefine Classes
Posted:
Mar 18, 2005 12:45 AM
in response to: slohmeier
|
|
|
And replace some secure version of a class at runtime with a viral one that sends the creditcard information your victims type in to your machine?
|
|
|
|
|
|
|
|
|
Re: Redefine Classes
Posted:
Mar 18, 2005 3:06 AM
in response to: jwenting
|
|
|
Like with every aspect of the Java platform it would of course also be neccessary to think about the security implications. E.g. the API might check if a special RedefinePermission has been granted. Another possibility would be to make the API used to trigger redefinition available to an agent only (like it is currently done in the java.lang.intrument case).
|
|
|
|
|
|
|
|
|
Re: Redefine Classes
Posted:
Mar 21, 2005 2:50 PM
in response to: jwenting
|
|
|
> And replace some secure version of a class at runtime
> with a viral one that sends the creditcard
> information your victims type in to your machine?
Erm....... so... how is an attacker going to get the JVM with that credit-card processing class to load his malicious class? If an application allows some attacker to load arbitrary code (the one doing the changing of the class), then you have bigger problems...
BTW: look at the current instrumentation implementation: the Agent that is allowed to change code (or intercept code when it's loaded) has to be defined at startup time as an JVM argument. This is already possible with Java 5.0, it's just that the functionality is limited to changing method bodies.
|
|
|
|
|
java.net RSS
