Hot replaces classes in the JVM
This project provides a javaagent and a client to hot replace classes in the JVM over and above what is provided by standard JDK hotswap.
It does this using bytecode trickery to instrument both the classes to be replaced and the reflection API, which allows it to fake replacements that hotswap would not normally allow (For instance, if you remove a method the agent simply adds back a noop method and then hides it from the reflection API).
Being able to hot replace classes is one thing, but it is not very useful unless the framework you are using can also pickup on these changes and re-load its metadata. To this end Fakereplace integrates with the following frameworks:
It also provides Wildfly integration.
Download the latest release from https://mvnrepository.com/artifact/org.fakereplace/fakereplace-dist
To build it yourself simply run
mvn package --settings=.settings.xml
And then use the shaded jar that is build in the
dist\targetdirectory. Note that you only need to use the custom settings file if you do not already have the JBoss Nexus repositories in your personal settings file (as some tests are executed against Wildfly).
There is a single jar in the distribution,
fakereplace.jarto use it you need to set the JVM
-javaagentoption to point to this jar. If you are not using Wildfly you also need to specify the packages that you want to be able to hot replace.
For example, on Wildfly you would edit standalone.conf and add the following to
For other containers, you would need to add the following to the JVM options:
com.mycompany.myclassesis the top level package of the classes that you want to hot replace. All classes in this package or sub packages are instrumented to allow them to be replaced. If you are using Wildfly this step is not necessary, as the integration will just mark all user deployed classes as replaceable.
To set the JVM options you will probably need to modify your app servers startup script, or if you are using an IDE server plugin set the VM arguments in the launch configuration.
Start your application in DEBUG mode and attach a debugger to it.
There are currently 3 different ways to perform a hot deployment while debugging.
:information_source: After a successful hot deployment you should see outputs in the log like
INFO Fakereplace is replacing class com/mycompany/myclasses/MyService
Fakereplace will automatically enhance the normal IDE hot swapping capability. You should no longer get errors if you try and add/remove methods etc.
When you start your container specify the following system property
[test.war]with the actual name of your deployment. Fakereplace will then scan your source directory for changes, and attempt to automatically compile them. This is only triggered when a web request hits the container.
If you are using an exploded type deployment where the class files are on the file system rather than in a jar then Wildfly will automatically watch them for changes and attempt to replace them if they are modified.
In addition to the packages option mentioned above, the following options are also supported. They should be specified after the -javaagent command and comma separated, e.g.
If you run into a bug report it at:
For details on how if works see