<p>Consider an object-oriented language like Java. Typically, when a class is modified and recompiled, the software which uses that class must be closed and restarted, and the program state may need to be saved to disk in order to be restored.</p>
<p>However, it is theoretically possible that an implementation could allow &quot;hot reloading&quot; of classes at runtime. This would be beneficial for availability in long-running software such as a networked servers, and also potentially useful for interactive debugging ─ you would not have to restart the program to try out changes.</p>
<p>To be clear, the idea here is not just that new instances created after the update will use the new class. The idea is that when the class is updated, existing instances of the old class are migrated to become instances of the new class, including any changes required to their memory layouts. For example, new fields added to existing objects could be initialised with some default value, or perhaps the language could have a mechanism allowing the user to control how existing objects are re-initialised.</p>
<p>How could hot reloading of classes work in practice, and what would its limitations be?</p>

<object-oriented>
How can an object-oriented language support hot reloading of classes?
CC BY-SA 4.0
2023-05-24T17:00:13.083Z
Dart is one language I know that supports this
mousetail 'he-him'
CC BY-SA 4.0
2023-05-24T17:01:05.540Z
@mousetail I'd definitely be interested in an answer about how Dart handles this.
kaya3
CC BY-SA 4.0
2023-05-24T17:04:46.130Z
Java allows dynamic loading of classes at runtime; i use that in the unit tests for my Vyxal to JVM compiler
Seggan
CC BY-SA 4.0
2023-05-24T17:07:17.477Z
@Seggan Yes, but as far as I know, existing objects would still be associated with the old version of the class. Perhaps there is some way to do it in Java by replacing the class pointer in the object's header? If there is an example of this being done in practice (perhaps using `sun.misc.unsafe`?) it would make for a good answer.
kaya3
CC BY-SA 4.0
2023-05-24T18:13:36.493Z
you can `putInt` (at address 8, for the klass word) but all your code will still think that the values are of the old type. note that even if you just change the implementation of a method that already existed, calling it without a cast will return garbage. `unsafe.putInt(obj, 8, newKM); (NewClass)obj` *should* work fine though.
RubenVerg
CC BY-SA 4.0
2023-05-24T18:53:58.000Z
Objective-C lets you mess with the dtable at runtime, and it works because literally every method call is dynamic. This is a surprisingly well-documented thing, though I’ve only seen it used for DI.
Bbrk24
CC BY-SA 4.0
2023-05-24T21:33:08.647Z
Is this asking about this in the *debugger* or as a language-level feature? Production IDEs do have this in the debugger already and it works moderately ok sometimes.
Michael Homer
CC BY-SA 4.0
2023-05-24T21:35:18.780Z
@MichaelHomer As a language-level feature is more interesting, but answers about debuggers which support this are fine too (particularly if there is a shortage of practical examples from real languages that support it as a language-level feature).
kaya3
CC BY-SA 4.0
2023-05-25T10:27:17.810Z
What about setting implicit conversions and being lazy about the conversion, only when the old type is used would you need to change it, so you might update them lazily, you'd need strong runtime reflection capabilities though. Shortly you might save the old class and each of its iterations and set up an implicit conversion pipeline made possible by storing migrations (setting default fields etc.). The limitations to this would be that you would have to type check at runtime every single call which would probably have a sizeable impact to performance and the load would increase every iteration
kaiserthe13th
CC BY-SA 4.0
2024-06-18T07:31:47.313Z
Suppose the data layout for the class has changed, for example to add a field. When the instance is "hot reloaded", how should the runtime know what the new field value should be?
Karl Knechtel
CC BY-SA 4.0
2024-06-18T11:55:29.073Z
@KarlKnechtel That is part of the question. *"For example, new fields added to existing objects could be initialised with some default value, or perhaps the language could have a mechanism allowing the user to control how existing objects are re-initialised."* But since the question asks how it could work in practice, I would like to see this kind of thing discussed in answers.
kaya3
CC BY-SA 4.0
2024-06-19T14:13:00.080Z
What happens if you remove a field from the "updated" version of a class?
CoffeeTableEspresso
CC BY-SA 4.0
2024-06-19T14:14:30.093Z
@CoffeeTableEspresso The fields would be removed from the existing instances.
kaya3
<p>This is a feature of the language Erlang and the library functions known as OTP. The combination allows classes written following certain guidelines to be upgraded on the fly. During the upgrade process existing calls to the classes use the &quot;old&quot; code, while new invocations use the &quot;current&quot; code. Over time all old calls run to the return point and the system will be able to accept further upgrades. It is a bit of convoluted reading, but you may start here <a href="https://www.erlang.org/doc/system/release_handling.html" rel="nofollow noreferrer">Erlang/OTP documentation</a></p>
<p>I will try to describe the most important ways a class has to be adapted to handle this update. But first, it is not really for the rapid software debug process but mainly for the deployment of software updates to a distributed system with many processors and extremely high demands on availability. Erlang/OTP was developed for telephone exchanges that preferrably should run for many years between reboots.</p>
<p>The support is part of the OTP &quot;framework&quot; as only classes deriving from this framework are supported. A class has a specific procedure that is called when a new version is installed. This procedure will do any changes needed. In addition a number of tools on the developement system creates &quot;update&quot; files that describe the update. These are copied to the target system and the update is initiated.</p>
<p>The Erlang runtime knows about the difference between &quot;old&quot; and &quot;current&quot; code as well. Note that Erlang is compiled into a type of byte-code that is interpreted on the target system (similar to how java originally worked).</p>

CC BY-SA 4.0
2024-06-18T22:20:48.880Z
2024-06-19T13:19:19.830Z
2024-06-19T13:19:19.830Z
ghellquist
<p>I made some experiments, about recompiling classes at runtime, within Ike (that is my pet OO programming language, built on top of Lua).</p>
<p>There are two classes of implementations of OO langs: those where recompiling... just does nothing, and the ones where the action is supported.
Just for an example: when you recompile a class in Python, nothing happens. The object already instanciated continue to use the old definition. Only new objects will inherit the new behaviors.
Ruby is different, because Ruby had been designed with the same concepts of late-binding borrowed from Smalltalk.
When you recompile dynamically a class (in Ruby) the new behaviors are immediately effective even for the already instantiated objects.
The same thing happens in Smalltalk.</p>
<p>Well: if you want this feature you must code it.
The first behavior (the one of Python, for example) is the simplest one. It is a byproduct of the simple design of the system.
Instead, if you want the second one (the immediate propagation of a new behavior) you have to face a more complex design.</p>
<p>As a first thing: after recompiled the class you must be able to cycle all the existing objects that directly inherit from that class and send them the &quot;become&quot; message. That is: you must inform them about the new class which will be their reference from now.
Obviously this should take place in a protected time-segment.
For many simple classes there are not problems, but the recompilation of some particular system classes may corrupt the integrity of the whole system (if the replacement does not take place correctly).</p>
<p>A problem you may consider secondary is this: what do you want to do with the old class? When you recompile a class you are not &quot;replacing&quot; it. You are just adding another object to the system. If the old class is not completely removed, you risk to have a system that is a timer-bomb. The old class <strong>MUST</strong> be removed. But you can not remove it until the last instance of that class had been updated.</p>
<p>Another not obvious (at least for me) problem is about the source.
Many debugging features use to connect bad behaviors or exceptions occurred to a line within the source which defined the objects involved.
When you recompile dynamically the references to the new source should replace the original ones.
You can not point user to a line of source witch is not a real source...</p>
<p>The problem here is that the user (the one responsible of the recompilation) is probably working within a big file of source code, the original file from which the system had been initialized.
But she is changing just one method of a given class, or maybe a whole class. She does not recompile the whole module, but just a piece.</p>
<p>In any case: the references the VM knows about the new object recompiled will be no connected to the source file, but to a string that feed the compiler.
All next signals of errors occurred within that class will have that string, and not the original file, as reference.
Hence you have to implement a &quot;reconciliation&quot; strategy to give user useful feedbacks, in case of exceptions.</p>
<p>...this is my cent to the whole question.</p>

CC BY-SA 4.0
2024-06-18T01:45:02.063Z
2024-06-18T01:45:02.063Z
pber
<p>Isn't this a regular feature of Java? As it's running &quot;bytecode&quot; with its &quot;VM&quot;/interpreter, Java offers reflection as an interpreter command can return the class metadata associated with the objects it's currently handling, including allowing to manipulate these during runtime. JIT (just-in-time compilation) can be a thing, Markus 'Notch' Persson using some hotloading while developing original Minecraft.</p>
<p>I'm not familiar with Java's particular features of this kind, I also don't know if there's migration strategies for existing objects vs. existing ones, but I do think the Java VM as well as the Java language front-end are a popular example for supporting such operations.</p>

CC BY-SA 4.0
2024-06-14T22:51:11.813Z
2024-06-14T22:51:11.813Z
skreutzer
CC BY-SA 4.0
2024-06-15T00:13:13.527Z
No, this simply isn't a feature of Java. Java reflection does not allow any way to change the class of an object which already exists.
kaya3
CC BY-SA 4.0
2024-06-15T00:31:12.157Z
Reflection implies looking from the outside at the metadata about objects and classes. But means 1. there is such metadata internally collected, 2. reflection exposes it to the programmer. A step 3. can be, based on the metadata being available (vs. not), consttructs can be provided to also change things at runtime. Indeed, reflection alone is not sufficient for hotloading. My point was that Java VM afaik can do some, Java lang maybe too (not sure). Same mechanisms that power reflection are a precondition, otherwise is harder to change things at what memory addresses happen to be.
skreutzer
CC BY-SA 4.0
2024-06-15T00:39:00.283Z
Hot reloading doesn't necessarily require a runtime mechanism for inspecting type members, for the same reason that database migrations don't need to inspect table columns at runtime. If the compiler has access to both versions of the class (or database table), it can generate code to update values (or rows) of that class (or table). As for Java, this definitely isn't a feature of the language, but if there is a VM which supports it then you should cite it ─ it's not useful to just say "maybe there is one", because the question is how it works in practice and what its limitations are.
kaya3
CC BY-SA 4.0
2024-06-15T02:02:01.813Z
I'm not really familiar with this, but the original question even less so (assumes this isn't a thing with Java). So OK: the typical way for a user would be to implement/derive-from `ClassLoader` to hot-reload the class instead of re-using the first loaded definition, then set it for the current thread. Loading a precompiled *.class source or otherwise compiling, but you relaxed that. May implement some object migration/copying even? Similar for other langs. Based on an interpreter/VM performing a lookup/dispatch for class names, method names, supply it code/bytecode to pass into execution.
skreutzer
CC BY-SA 4.0
2024-06-15T04:29:53.763Z
"I'm not really familiar with this" - in this case, it isn't necessary to post an answer. You've posted a lot of answers in short succession and a few of those, including this one, disclaim relevant knowledge of the topic. Those are unlikely to be strong answers, and it would probably be better to look for questions you know about and are able to answer. You might also like to go a little slower and build up familiarity with how things work well here.
Michael Homer
<h1>The Objective-C Runtime</h1>
<p>Objective-C has surprisingly strong runtime reflection capabilities, on par with that of JavaScript. Here's a couple ways you could do it with the Objective-C runtime library.</p>
<h2>Option 1: Register and deregister classes</h2>
<p>Objective-C lets you create new classes at runtime with <a href="https://developer.apple.com/documentation/objectivec/1418559-objc_allocateclasspair?language=objc" rel="nofollow noreferrer"><code>objc_allocateClassPair</code></a>, and deregister existing classes with <a href="https://developer.apple.com/documentation/objectivec/1418912-objc_disposeclasspair?language=objc" rel="nofollow noreferrer"><code>objc_disposeClassPair</code></a>. Whenever a class needs to be reloaded, you could register the new version as a new class and dispose the existing one. The problem with this approach is, as per the documentation for <code>objc_disposeClassPair</code>:</p>
<blockquote>
<p>Do not call this function if instances of the <code>cls</code> class or any subclass exist.</p>
</blockquote>
<p>However, you can change the class of an object at runtime with <a href="https://developer.apple.com/documentation/objectivec/1418905-object_setclass?language=objc" rel="nofollow noreferrer"><code>object_setClass</code></a>. Therefore, you could still use this approach with the following process:</p>
<ol>
<li>Allocate, configure, and register the new version of the class.</li>
<li>Iterate over all instances of the old version of the class, and change them to the new version. Objective-C doesn't have an &quot;all instances&quot; function in its runtime, so this would have to be a static property on the class.</li>
<li>Dispose the old version of the class.</li>
</ol>
<h2>Option 2: Mess with the class metadata</h2>
<p>This allows you to work without having to worry about subclasses or iterating over existing instances, but may be much more involved. You'd have to check each part of the definition individually.</p>
<h3>Methods</h3>
<p>To change the implementation of an existing method, use <a href="https://developer.apple.com/documentation/objectivec/1418707-method_setimplementation?language=objc" rel="nofollow noreferrer"><code>method_setImplementation</code></a> or <a href="https://developer.apple.com/documentation/objectivec/1418769-method_exchangeimplementations?language=objc" rel="nofollow noreferrer"><code>method_exchangeImplementations</code></a>. This is a well-supported pattern known as <em>method swizzling</em>; as I mentioned in a comment, this is usually used for dependency injection.</p>
<p>To add new methods, use <a href="https://developer.apple.com/documentation/objectivec/1418901-class_addmethod?language=objc" rel="nofollow noreferrer"><code>class_addMethod</code></a>.</p>
<p>Removing methods is actually not something that's not supported! If you're making a new language, you could probably add support for this in your language, but Objective-C doesn't have it. However, there is a way for an object to pretend like it doesn't have a method, even at compile time, so we can use the same technique here.</p>
<p>The first step is to write the method implementation as follows:</p>
<pre class="lang-objectivec prettyprint-override"><code>- (void)exampleMethod {
  [self doesNotRecognizeSelector:_cmd];
}
</code></pre>
<p><a href="https://developer.apple.com/documentation/objectivec/nsobject/1418637-doesnotrecognizeselector?language=objc" rel="nofollow noreferrer"><code>doesNotRecognizeSelector:</code></a> is the method invoked by the runtime when all attempts to find the implementation of a method have failed. <code>_cmd</code> is an implicit argument that all methods take, which is the method's <em>selector</em> (a representation of the method name).</p>
<p>The second step is to make <a href="https://developer.apple.com/documentation/objectivec/1418956-nsobject/1418583-respondstoselector?language=objc" rel="nofollow noreferrer"><code>respondsToSelector:</code></a> and <a href="https://developer.apple.com/documentation/objectivec/nsobject/1418555-instancesrespondtoselector?language=objc" rel="nofollow noreferrer"><code>instancesRespondToSelector:</code></a> also deny it:</p>
<pre class="lang-objectivec prettyprint-override"><code>- (BOOL)respondsToSelector:(SEL)aSelector {
  if (sel_isEqual(@selector(exampleMethod), aSelector)
    return NO;
  return [super respondsToSelector:aSelector];
}

+ (BOOL)instancesRespondToSelector:(SEL)aSelector {
  if (sel_isEqual(@selector(exampleMethod), aSelector)
    return NO;
  return class_respondsToSelector(self, aSelector);
}
</code></pre>
<p>Then, you can drop these in with the functions mentioned above.</p>
<h3>Properties</h3>
<p><em>Properties</em> are the public interface used to access instance members, while <em>ivars</em> are the underlying storage for them. Changing properties is fairly straightforward: <a href="https://developer.apple.com/documentation/objectivec/1418891-class_replaceproperty?language=objc" rel="nofollow noreferrer"><code>class_replaceProperty</code></a> to change an existing one and <a href="https://developer.apple.com/documentation/objectivec/1418946-class_addproperty?language=objc" rel="nofollow noreferrer"><code>class_addProperty</code></a> to add a new one, while deleting old ones is basically in the same boat as deleting methods. Each property corresponds to a pair of selectors (e.g. <code>foo</code> for the getter and <code>setFoo:</code> for the setter).</p>
<h3>Ivars</h3>
<p>This is where things get interesting. Messing with ivars means changing the actual memory layout of the class. Surprisingly, this is just supported: <a href="https://developer.apple.com/documentation/objectivec/1418749-class_setivarlayout?language=objc" rel="nofollow noreferrer"><code>class_setIvarLayout</code></a> for owned ivars and <a href="https://developer.apple.com/documentation/objectivec/1418852-class_setweakivarlayout?language=objc" rel="nofollow noreferrer"><code>class_setWeakIvarLayout</code></a> for weak ones. You may have to take care that existing instances don't become dangerous when you do this.</p>
<h3>Protocols</h3>
<p><em>Protocols</em> are Objective-C's equivalent of Java's interfaces. Once again, adding new ones is supported but removing existing ones is complicated. Adding a new one is just a call to <a href="https://developer.apple.com/documentation/objectivec/1418773-class_addprotocol?language=objc" rel="nofollow noreferrer"><code>class_addProtocol</code></a> plus implementing the necessary methods.</p>
<p>You can't remove the protocol from the class list, but you can make the class act like it's not there by overriding <a href="https://developer.apple.com/documentation/objectivec/nsobject/1418893-conformstoprotocol?language=objc" rel="nofollow noreferrer"><code>conformsToProtocol:</code></a></p>
<pre class="lang-objectivec prettyprint-override"><code>+ (BOOL)conformsToProtocol:(Protocol *)protocol {
  if ([protocol isEqual:@protocol(ProtocolToRemove)])
    return NO;
  return class_conformsToProtocol(self, protocol);
}
</code></pre>

CC BY-SA 4.0
2023-05-24T21:48:46.517Z
2023-05-29T14:14:21.310Z
2023-05-29T14:14:21.310Z
Bbrk24
# How can an object-oriented language support hot reloading of classes?
Posted by: username_0 on 2023-05-24
Consider an object-oriented language like Java. Typically, when a class is modified and recompiled, the software which uses that class must be closed and restarted, and the program state may need to be saved to disk in order to be restored.

However, it is theoretically possible that an implementation could allow "hot reloading" of classes at runtime. This would be beneficial for availability in long-running software such as a networked servers, and also potentially useful for interactive debugging ─ you would not have to restart the program to try out changes.

To be clear, the idea here is not just that new instances created after the update will use the new class. The idea is that when the class is updated, existing instances of the old class are migrated to become instances of the new class, including any changes required to their memory layouts. For example, new fields added to existing objects could be initialised with some default value, or perhaps the language could have a mechanism allowing the user to control how existing objects are re-initialised.

How could hot reloading of classes work in practice, and what would its limitations be?
**Tags:** object-oriented
> **Comments:**
> **username_1**: Dart is one language I know that supports this  
> **username_0**: @mousetail I'd definitely be interested in an answer about how Dart handles this.  
> **username_2**: Java allows dynamic loading of classes at runtime; i use that in the unit tests for my Vyxal to JVM compiler  
> **username_0**: @Seggan Yes, but as far as I know, existing objects would still be associated with the old version of the class. Perhaps there is some way to do it in Java by replacing the class pointer in the object's header? If there is an example of this being done in practice (perhaps using `sun.misc.unsafe`?) it would make for a good answer.  
> **username_3**: you can `putInt` (at address 8, for the klass word) but all your code will still think that the values are of the old type. note that even if you just change the implementation of a method that already existed, calling it without a cast will return garbage. `unsafe.putInt(obj, 8, newKM); (NewClass)obj` *should* work fine though.  
> **username_4**: Objective-C lets you mess with the dtable at runtime, and it works because literally every method call is dynamic. This is a surprisingly well-documented thing, though I’ve only seen it used for DI.  
> **username_5**: Is this asking about this in the *debugger* or as a language-level feature? Production IDEs do have this in the debugger already and it works moderately ok sometimes.  
> **username_0**: @MichaelHomer As a language-level feature is more interesting, but answers about debuggers which support this are fine too (particularly if there is a shortage of practical examples from real languages that support it as a language-level feature).  
> **username_6**: What about setting implicit conversions and being lazy about the conversion, only when the old type is used would you need to change it, so you might update them lazily, you'd need strong runtime reflection capabilities though. Shortly you might save the old class and each of its iterations and set up an implicit conversion pipeline made possible by storing migrations (setting default fields etc.). The limitations to this would be that you would have to type check at runtime every single call which would probably have a sizeable impact to performance and the load would increase every iteration  
> **username_7**: Suppose the data layout for the class has changed, for example to add a field. When the instance is "hot reloaded", how should the runtime know what the new field value should be?  
> **username_0**: @KarlKnechtel That is part of the question. *"For example, new fields added to existing objects could be initialised with some default value, or perhaps the language could have a mechanism allowing the user to control how existing objects are re-initialised."* But since the question asks how it could work in practice, I would like to see this kind of thing discussed in answers.  
> **username_8**: What happens if you remove a field from the "updated" version of a class?  
> **username_0**: @CoffeeTableEspresso The fields would be removed from the existing instances.  
---
## 4 answers
### Answer by username_4 on 2023-05-24. Score: 10
The Objective-C Runtime
Objective-C has surprisingly strong runtime reflection capabilities, on par with that of JavaScript. Here's a couple ways you could do it with the Objective-C runtime library.
Option 1: Register and deregister classes
Objective-C lets you create new classes at runtime with objc_allocateClassPair, and deregister existing classes with objc_disposeClassPair. Whenever a class needs to be reloaded, you could register the new version as a new class and dispose the existing one. The problem with this approach is, as per the documentation for objc_disposeClassPair:

Do not call this function if instances of the cls class or any subclass exist.

However, you can change the class of an object at runtime with object_setClass. Therefore, you could still use this approach with the following process:

Allocate, configure, and register the new version of the class.
Iterate over all instances of the old version of the class, and change them to the new version. Objective-C doesn't have an "all instances" function in its runtime, so this would have to be a static property on the class.
Dispose the old version of the class.

Option 2: Mess with the class metadata
This allows you to work without having to worry about subclasses or iterating over existing instances, but may be much more involved. You'd have to check each part of the definition individually.
Methods
To change the implementation of an existing method, use method_setImplementation or method_exchangeImplementations. This is a well-supported pattern known as method swizzling; as I mentioned in a comment, this is usually used for dependency injection.
To add new methods, use class_addMethod.
Removing methods is actually not something that's not supported! If you're making a new language, you could probably add support for this in your language, but Objective-C doesn't have it. However, there is a way for an object to pretend like it doesn't have a method, even at compile time, so we can use the same technique here.
The first step is to write the method implementation as follows:
- (void)exampleMethod {
  [self doesNotRecognizeSelector:_cmd];
}

doesNotRecognizeSelector: is the method invoked by the runtime when all attempts to find the implementation of a method have failed. _cmd is an implicit argument that all methods take, which is the method's selector (a representation of the method name).
The second step is to make respondsToSelector: and instancesRespondToSelector: also deny it:
- (BOOL)respondsToSelector:(SEL)aSelector {
  if (sel_isEqual(@selector(exampleMethod), aSelector)
    return NO;
  return [super respondsToSelector:aSelector];
}

+ (BOOL)instancesRespondToSelector:(SEL)aSelector {
  if (sel_isEqual(@selector(exampleMethod), aSelector)
    return NO;
  return class_respondsToSelector(self, aSelector);
}

Then, you can drop these in with the functions mentioned above.
Properties
Properties are the public interface used to access instance members, while ivars are the underlying storage for them. Changing properties is fairly straightforward: class_replaceProperty to change an existing one and class_addProperty to add a new one, while deleting old ones is basically in the same boat as deleting methods. Each property corresponds to a pair of selectors (e.g. foo for the getter and setFoo: for the setter).
Ivars
This is where things get interesting. Messing with ivars means changing the actual memory layout of the class. Surprisingly, this is just supported: class_setIvarLayout for owned ivars and class_setWeakIvarLayout for weak ones. You may have to take care that existing instances don't become dangerous when you do this.
Protocols
Protocols are Objective-C's equivalent of Java's interfaces. Once again, adding new ones is supported but removing existing ones is complicated. Adding a new one is just a call to class_addProtocol plus implementing the necessary methods.
You can't remove the protocol from the class list, but you can make the class act like it's not there by overriding conformsToProtocol:
+ (BOOL)conformsToProtocol:(Protocol *)protocol {
  if ([protocol isEqual:@protocol(ProtocolToRemove)])
    return NO;
  return class_conformsToProtocol(self, protocol);
}
---
### Answer by username_9 on 2024-06-18. Score: 2
This is a feature of the language Erlang and the library functions known as OTP. The combination allows classes written following certain guidelines to be upgraded on the fly. During the upgrade process existing calls to the classes use the "old" code, while new invocations use the "current" code. Over time all old calls run to the return point and the system will be able to accept further upgrades. It is a bit of convoluted reading, but you may start here [Erlang/OTP documentation](https://www.erlang.org/doc/system/release_handling.html)

I will try to describe the most important ways a class has to be adapted to handle this update. But first, it is not really for the rapid software debug process but mainly for the deployment of software updates to a distributed system with many processors and extremely high demands on availability. Erlang/OTP was developed for telephone exchanges that preferrably should run for many years between reboots.

The support is part of the OTP "framework" as only classes deriving from this framework are supported. A class has a specific procedure that is called when a new version is installed. This procedure will do any changes needed. In addition a number of tools on the developement system creates "update" files that describe the update. These are copied to the target system and the update is initiated.

The Erlang runtime knows about the difference between "old" and "current" code as well. Note that Erlang is compiled into a type of byte-code that is interpreted on the target system (similar to how java originally worked).
---
### Answer by username_10 on 2024-06-18. Score: 1
I made some experiments, about recompiling classes at runtime, within Ike (that is my pet OO programming language, built on top of Lua).

There are two classes of implementations of OO langs: those where recompiling... just does nothing, and the ones where the action is supported.
Just for an example: when you recompile a class in Python, nothing happens. The object already instanciated continue to use the old definition. Only new objects will inherit the new behaviors.
Ruby is different, because Ruby had been designed with the same concepts of late-binding borrowed from Smalltalk.
When you recompile dynamically a class (in Ruby) the new behaviors are immediately effective even for the already instantiated objects.
The same thing happens in Smalltalk.

Well: if you want this feature you must code it.
The first behavior (the one of Python, for example) is the simplest one. It is a byproduct of the simple design of the system.
Instead, if you want the second one (the immediate propagation of a new behavior) you have to face a more complex design.

As a first thing: after recompiled the class you must be able to cycle all the existing objects that directly inherit from that class and send them the "become" message. That is: you must inform them about the new class which will be their reference from now.
Obviously this should take place in a protected time-segment.
For many simple classes there are not problems, but the recompilation of some particular system classes may corrupt the integrity of the whole system (if the replacement does not take place correctly).

A problem you may consider secondary is this: what do you want to do with the old class? When you recompile a class you are not "replacing" it. You are just adding another object to the system. If the old class is not completely removed, you risk to have a system that is a timer-bomb. The old class **MUST** be removed. But you can not remove it until the last instance of that class had been updated.

Another not obvious (at least for me) problem is about the source.
Many debugging features use to connect bad behaviors or exceptions occurred to a line within the source which defined the objects involved.
When you recompile dynamically the references to the new source should replace the original ones.
You can not point user to a line of source witch is not a real source...

The problem here is that the user (the one responsible of the recompilation) is probably working within a big file of source code, the original file from which the system had been initialized.
But she is changing just one method of a given class, or maybe a whole class. She does not recompile the whole module, but just a piece.

In any case: the references the VM knows about the new object recompiled will be no connected to the source file, but to a string that feed the compiler.
All next signals of errors occurred within that class will have that string, and not the original file, as reference.
Hence you have to implement a "reconciliation" strategy to give user useful feedbacks, in case of exceptions.

...this is my cent to the whole question.
---
### Answer by username_11 on 2024-06-14. Score: -3
Isn't this a regular feature of Java? As it's running "bytecode" with its "VM"/interpreter, Java offers reflection as an interpreter command can return the class metadata associated with the objects it's currently handling, including allowing to manipulate these during runtime. JIT (just-in-time compilation) can be a thing, Markus 'Notch' Persson using some hotloading while developing original Minecraft.

I'm not familiar with Java's particular features of this kind, I also don't know if there's migration strategies for existing objects vs. existing ones, but I do think the Java VM as well as the Java language front-end are a popular example for supporting such operations.
> **Comments:**
> **username_0** (2024-06-15): No, this simply isn't a feature of Java. Java reflection does not allow any way to change the class of an object which already exists.  
> **username_11** (2024-06-15): Reflection implies looking from the outside at the metadata about objects and classes. But means 1. there is such metadata internally collected, 2. reflection exposes it to the programmer. A step 3. can be, based on the metadata being available (vs. not), consttructs can be provided to also change things at runtime. Indeed, reflection alone is not sufficient for hotloading. My point was that Java VM afaik can do some, Java lang maybe too (not sure). Same mechanisms that power reflection are a precondition, otherwise is harder to change things at what memory addresses happen to be.  
> **username_0** (2024-06-15): Hot reloading doesn't necessarily require a runtime mechanism for inspecting type members, for the same reason that database migrations don't need to inspect table columns at runtime. If the compiler has access to both versions of the class (or database table), it can generate code to update values (or rows) of that class (or table). As for Java, this definitely isn't a feature of the language, but if there is a VM which supports it then you should cite it ─ it's not useful to just say "maybe there is one", because the question is how it works in practice and what its limitations are.  
> **username_11** (2024-06-15): I'm not really familiar with this, but the original question even less so (assumes this isn't a thing with Java). So OK: the typical way for a user would be to implement/derive-from `ClassLoader` to hot-reload the class instead of re-using the first loaded definition, then set it for the current thread. Loading a precompiled *.class source or otherwise compiling, but you relaxed that. May implement some object migration/copying even? Similar for other langs. Based on an interpreter/VM performing a lookup/dispatch for class names, method names, supply it code/bytecode to pass into execution.  
> **username_5** (2024-06-15): "I'm not really familiar with this" - in this case, it isn't necessary to post an answer. You've posted a lot of answers in short succession and a few of those, including this one, disclaim relevant knowledge of the topic. Those are unlikely to be strong answers, and it would probably be better to look for questions you know about and are able to answer. You might also like to go a little slower and build up familiarity with how things work well here.  
---
