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 >> > > >> >> > > >> > >> >
