Thank you, Konstantinos Marinos, Jacques for sharing your thoughts.
Hello Gaetan,
I tried the HotSwap option available in IntelliJ IDEA.
Enable HotSwap Settings + DCEVM Plugin
File Watcher Plugin setup
CronJob setup so that it could manage your login information.
But it's trickier, confusing, and more lengthy to set up.
I dropped the idea of continuing with IntelliJ settings instead, and
continued with creating an independent plugin "devreload" for OFBiz.
Sharing more details below.
Hello Dev Community,
Wanted to share an update on the Java hot-reload tooling for OFBiz
development (the devreload plugin) that removes the restart-and-wait cycle
when iterating on services, events, and services.xml files.
https://github.com/apache/ofbiz-plugins/pull/316
https://github.com/ashishvijaywargiya/ofbiz-plugins/tree/add-devreload/devreload
Based on the community feedback around not wanting framework-level code
changes, I have moved everything into the devreload plugin itself — there
are now zero changes required in ofbiz-framework.
Now the plugin is entirely self-contained: dropping plugins/devreload into
a checkout (or removing it) has zero effect on the rest of OFBiz either
way, since it hooks in purely through the standard component/container
discovery mechanism and the JVM's own Instrumentation API, with no
reflective bridge or hook anywhere in framework code.
The plugin provides two Gradle commands, both drop-in replacements for the
normal ofbiz start command.
The two devreload commands
1. ./gradlew ofbizDev
What it does: Starts OFBiz normally (stock JDK), with hot-reload active.
Java method-body edits and services.xml changes go live within ~300ms of
saving, no restart. It cannot hot-swap structural changes (a brand-new
method, a removed method/field, a changed signature) — those still require
a restart on a plain JDK.
2. ./gradlew ofbizDevEnhanced --no-watch-fs
What it does: Starts OFBiz on a JVM with enhanced class redefinition
support, instead of a stock JDK. On top of everything ofbizDev does, it
additionally hot-swaps structural changes — a brand-new method, a removed
method or field, a changed signature — live as well, with no restart. The
--no-watch-fs flag is recommended on a full checkout to avoid a
directory-watch resource ceiling we found and root-caused during testing.
Both commands also support optional component scoping via
-Photreload.components=compA,compB for a faster, narrower startup while
working on a couple of components.
Both commands have been tested end to end, including editing existing
methods, editing services.xml, and adding brand-new methods and services,
with all changes verified to take effect live without a restart.
I will be merging this "devreload" plugin sometime in the next week.
Please share your feedback on this whenever you can.
--
Kind Regards,
Ashish Vijaywargiya
Vice President of Operations
*HotWax Systems*
*Enterprise open source experts*
http://www.hotwaxsystems.com
On Thu, Jul 2, 2026 at 7:53 PM Konstantinos Marinos <[email protected]>
wrote:
Hello Ashish,
thank you for your work on this feature. I personally find the approach
very interesting.
Although I can see the point of view and the concerns raised by Geatan,
offering extensive hot-reload capabilities directly from the
framework/tooling without relying on the IDE is for me a nice addition.
After all, it is an extra option for developers that don't use eclipse or
Intellij - although I imagine they are a very small minority.
To the concern regarding "plugin" code residing inside the main project,
I was wondering if there was an option for some "creative" refactoring
where you bind your new classloader through properties or a similar
mechanism. Of course if any additional configuration is absent, it should
default to the current implementation. In that case even your DevReloadHook
class could live in the plugin and be picked up through a more generalised
Interface that just provides the appropriate classloader.
This way no changes in the main project hint to the existence of the dev
container plugin, but anyone can provide their own implementation of a
"classloader provider" that modifies the standard classloading behaviour
for java.
This is only an idea I had after looking at the modifications in trunk. I
hope I was able to get my point across and that it addresses the concerns
in this thread.
Best of luck with further development and the future adoption of this
functionality.
Konstantinos Marinos
On 2026/07/02 12:24:07 Ashish Vijaywargiya wrote:
Hello Jacques and Geatan,
Thank you for sharing your thoughts. They were very helpful. 👍
I thought about my implementation again and updated it a bit. The
implementation (WatchService + in-process compiler + a child-first
classloader) lives entirely in a small plugin, published separately at
https://github.com/ashishvijaywargiya/devreload. This plugin is
available
to anyone, and anyone can clone it if required.
I can also move it to the ofbiz-plugins folder if the community members
agree to put the "devreload" component codebase there.
To make the framework pick up hot-reloaded classes when that plugin is
present, I need a small footprint in ofbiz-framework itself: a
reflective
bridge, a small file DevReloadHook.java, plus one gated classloader
check
each in StandardJavaEngine and JavaEventHandler.
Branch for reference:
https://github.com/apache/ofbiz-framework/compare/trunk...ashishvijaywargiya:ofbiz-framework:dev-reload-container-support
Hopefully, now the changes in the "dev-reload-container-support" branch
can
be merged into the OFBiz trunk code.
To demonstrate the feature, I have added a new field "comments2" on the
form, and then made the changes in services.xml, and then made the
changes
in OfbizDemoServices.java file. The changes in services.xml and java
files
are reflected without restarting OFBiz.
https://drive.google.com/drive/folders/1W5ILWVOSBD956GcDT50-GmZkV_seMNRv?usp=sharing
I have made the changes in a demo component -
https://github.com/ashishvijaywargiya/ofbizDemo.
Please let me know your thoughts on this.
I will also explore the HotSwap plugin in IntelliJ IDEA and get back
with
my thoughts.
Thank you.
--
Kind Regards,
Ashish Vijaywargiya
Vice President of Operations
*HotWax Systems*
*Enterprise open source experts*
http://www.hotwaxsystems.com
On Wed, Jul 1, 2026 at 9:49 PM Jacques Le Roux via dev <
[email protected]>
wrote:
Hi,
I tend to agree with Gaetan.
Jacques
Le 01/07/2026 à 09:18, gaetan.chaboussie via dev a écrit :
Hello Ashish, hello all.
First, thanks for the effort put into this. Seems like a lot of work
(even if it looks like there has been some AI help on the code).
This being said, I'm not sure how i feel seeing a 'developer only'
intended feature in the project code.
I think that it's the IDE's job to provide this kind of feature. In
my
experience, Eclipse handles it natively pretty well, and Intellij is
making
great progress (and has a Hotsawp plugin that i personally use).
Also, i believe that it's precisely the point of GroovyScripts to
allow
editing without recompiling.
Although I understand the idea, I would personnaly not advise this
change, that creates low level code changes, and looks tricky to
maintain.
Gaetan.
On 6/30/26 18:03, Ashish Vijaywargiya wrote:
Hello OFBiz Dev Community,
I would like to share a prototype that removes the need to restart
OFBiz
when developing Java services, events and service
definitions(services.xml).
Many years ago I came across Tomcat's reloadable="true" context
attribute.
When enabled, Tomcat's application deployer watches for class file
changes
and
automatically reloads the web application — no server restart, no
manual
step. I always thought that was a great developer experience, and
at the
back of my mind I wondered whether something similar could be done
in
OFBiz.
The standard Java change cycle in OFBiz today is:
edit .java → ./gradlew classes → kill OFBiz → wait 30-60 s →
restart →
test
Groovy scripts and Freemarker templates already pick up changes
without
a
restart; Java does not. This prototype brings the same convenience
to
Java
development, specifically targeting *Services.java and *Events.java
files
which are the ones developers touch most during active feature
work.
--- What it does ---
A new class called DevReloadContainer is added to framework/base.
It is
activated by passing -Dofbiz.hotreload=true on startup and does
three
things:
1. Watches build/classes/java/main/ for changed .class files and
hot-swaps them into a fresh class loader without restarting
OFBiz.
In practice this means saving a *Services.java or
*Events.java
file
is enough — the change is live in under a second.
2. Watches all component servicedef/ directories and clears the
service
model cache when any *services.xml file changes, so new or
modified
service definitions are picked up immediately.
3. Watches all component src/main/java/ directories and compiles
changed
.java files in-process (using javax.tools.JavaCompiler), so
you
do not
need a second terminal running ./gradlew -t classes.
A 300 ms debounce window batches a burst of file-save events into a
single
reload, so rapid edits do not cause multiple reloads.
--- The new dev workflow ---
A new Gradle task wraps everything into one command:
./gradlew ofbizDev
Start OFBiz with that command, then edit any *Services.java,
*Events.java,
or *services.xml file and save — changes are live without any
restart.
The working code is on branch dev-reload-container-support.
https://github.com/ashishvijaywargiya/ofbiz-framework/tree/dev-reload-container-support
https://github.com/apache/ofbiz-framework/compare/trunk...ashishvijaywargiya:ofbiz-framework:dev-reload-container-support
The implementation went through several rounds of debugging and
covers 32 test cases including child-first class loading,
multi-cycle
reload correctness,
inner and anonymous class reloading, concurrent class loading,
malformed-bytecode handling, shutdown races, and the macOS
spurious-event
suppression.
Please review this feature and let me know your thoughts/feedback.
And please report any issues you find.
Very soon, I will be creating a pull request for this feature.
I am hopeful that this feature will be helpful to all developers
who are
building enterprise applications using the Apache OFBiz project. 👍
Thank you.
--
Kind Regards,
Ashish Vijaywargiya
Vice President of Operations
*HotWax Systems*
*Enterprise open source experts*
http://www.hotwaxsystems.com
