--
Kind Regards,
Ashish Vijaywargiya
Vice President of Operations
*HotWax Systems*
/Enterprise open source experts/
http://www.hotwaxsystems.com
On Tue, Jul 7, 2026 at 12:19 PM gaetan.chaboussie via dev
<[email protected]> wrote:
Hi Ashish, Hi all.
I am still not ok with the idea of this code being merged in plugins
repo, i'm refering to this line you wrote :
I will be merging this "devreload" plugin sometime in the next week.
Again, IMO it shouldn't be the community's job to maintain this
feature
considering the gain / work ratio.
Even if the code has been refactored and streamlined, it doesn't
changes
my opinion.
Regards,
Gaetan.
On 7/6/26 16:06, Ashish Vijaywargiya wrote:
> Hello All,
>
> Here is the quick update on the "*devreload*" hot-reload plugin:
the two
> separate Gradle commands have been merged into a single one.
>
> Previously, there were two tasks, ./gradlew ofbizDev for stock-JDK
> hot-reload and ./gradlew ofbizDevEnhanced for DCEVM-backed
structural
> hot-reload. Now there is just one task, ofbizDev, and enhanced
mode is a
> flag on it.
>
> ./gradlew ofbizDev still starts OFBiz normally on a stock JDK,
> hot-reloading method body edits and services.xml changes live,
exactly as
> before.
>
> ./gradlew ofbizDev -Photreload.enhanced=true --no-watch-fs runs
the same
> task on a DCEVM-patched JVM instead (JetBrains Runtime is
auto-detected
> from a local IntelliJ IDEA install, or point at one explicitly with
> -PdcevmHome or DCEVM_HOME), additionally hot-swapping structural
changes
> like new or removed methods live, with no restart.
>
> Both modes still support component scoping via
> -Photreload.components=compA,compB for a faster, narrower
startup on large
> checkouts.
>
> Under the hood, this is now a single JavaExec task rather than
two separate
> task types, so enhanced mode also picks up JavaExec's built-in
safety nets,
> like automatic classpath-argfile handling on Windows and --debug-jvm
> support, which the old separate Exec-based task did not have.
>
> No other behavior has changed. Full details are in
> plugins/devreload/README.md.
>
https://github.com/ashishvijaywargiya/ofbiz-plugins/blob/add-devreload/devreload/README.md
>
> And here is the PR that I created over the weekend.
> https://github.com/apache/ofbiz-plugins/pull/316
>
> --
> Kind Regards,
> Ashish Vijaywargiya
> Vice President of Operations
> *HotWax Systems*
> *Enterprise open source experts*
> http://www.hotwaxsystems.com
>
>
>
> On Sat, Jul 4, 2026 at 6:34 PM Ashish Vijaywargiya <
> [email protected]> wrote:
>
>> 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
>>>>>>>
