Thanks, Owen. A long time ago, I got tired of the bring-the-server-down, recompile, deploy, boot-the-server cycle every time a file changed. This is especially bad on a system with 9,000 files. I developed a system that, while a system is running, compiles a class in memory, loads, and caches it. After that process, it runs at full compiled speed. If the file changes, when it is called again, the system notices that it changed, recompiles, loads, and updates the cache. This means several things:
1. I can do all of my development without any bring-the-server-down, recompile, deploy, boot-the-server cycles. 2. A production system can be updated without disrupting existing users. 3. The recompile, load, cache process is negligible. Everything still runs at full compiled speed. I discovered years later that the world calls these microservices. Interestingly, not wanting to differ from standards, in general, I'd prefer to use standards over anything I custom-write. However, the industry's "standards" had significantly less functionality than what I had, and they required all sorts of configuration and registration. My system had greater flexibility and required zero configuration and registration. So I stick with my system. When originally developing this system, I had already switched to IntelliJ. Debugging my dynamically changing code just worked. I never gave debugging much of a thought. Later, when VSCode became popular, I thought I would give it a try. Although, right off the bat, I hated it immensely. For one thing, its minimalist design made it so that you essentially had to build your own IDE (plugins). It was a nightmare trying to do this with several competing plugins in most areas of my interest. Each plugin had its own configuration. I trudged through it, trying to give it a decent try. I eventually got everything to work. However, I soon noticed that their Java debugger couldn't handle my dynamically changing microservices. The debugger worked fine until I changed a class. After that, it was totally confused about line numbers. For that and several other issues, I dropped VSCode. After reporting the problem to a couple of sites, I discovered that this is a known shortcoming of the system. I suppose there is not enough interest in the problem for anyone to look at it. Interestingly, IntelliJ's debugger code is open-source. Others can easily see how they solved the problem. I later discovered that Eclipse and NetBeans have the same shortcoming. Since I have thousands of these microservices and do most of my development with them, an IDE that can't support this issue is of no value to me. My microservice system causes an additional problem. Typically, when you build a system, you compile all of your source files into another tree as executable class files. All of the build systems expect this. However, in my case, while there is a core that gets compiled in advance as normal, the microservices get distributed as source files since they get compiled at runtime. I've spent days working with Maven and Gradle trying to get them to do this. In the end, I was successful, but the build file was a convoluted, complex mess. No one could understand it or maintain it. And the fix depended on volatile plugins that caused no end of maintenance problems. I ended up writing my own build system that could trivially handle this sort of build process. It is utterly simple to understand and maintain, and it only executes the minimal processes to get a system up-to-date (you know, the main purpose of a build system). IntelliJ supported Ant, and it was trivial for me to build an Ant file that simply called my build system (bld). Thus, I have full IntelliJ integration! With each passing version of NetBeans, I have more and more trouble getting NetBeans to even recognize my system. NetBeans appears increasingly dependent on Maven to the point where, if your project is not a Maven project, NetBeans won't even work. The last big issue is source paths. I started using multiple source paths for two reasons: 1. My situation called for it. 2. IntelliJ trivially supported it. The thought that this would cause problems never occurred to me. I happily did this with IntelliJ for years. Now, when I try to use NetBeans, I have been utterly unable to get NetBeans to understand this. I spent about a day on this and just gave up. At this point, I am not going to restructure my entire system for NetBeans. I just can't use NetBeans. I tried reporting these issues, but there seems to be a general sense of "why don't you just use Maven?" Well, now you know. If NetBeans is essentially built on Maven, and Maven can't support anything but its one model, I will never be able to use NetBeans. Maven works wonderfully for typical Maven-structured applications. If you try to innovate and go outside Maven's box, you're SOL. Just some opinions. Blake On Sun, Jan 18, 2026 at 12:38 AM Owen Thomas <[email protected]> wrote: > Hi Blake. > > I thought I might just take the time to sing the praises of Netbeans. > > You seem to be a very intelligent man, who, as I do, loves to be creative > with software. Like you, I'm a bit of a woulda if I coulda type; I would > develop stuff for Netbeans if I had the time. The thing I've found so far > about Netbeans is that it is sufficient for my purposes, and doesn't try to > cajole me into appropriating anything fancy, unlike, say, IntelliJ which I > have found likes to usher me into a K-hole. :) When it comes to AI, > sometimes I just ask ChatGPT to generate some code for me... wonderful > stuff indeed! > > 看！我甚至會說中文！... wow! I might actually learn it for real some day too. > > I think you and I are two of many people who have a similar relationship > with Netbeans; I have a very high regard for those who make a contribution > and hence keep Netbeans sufficient for my purposes. Indeed, I hope my > anonymous usage stats (if indeed I send any - I would have elected to if > there is an option for this when I installed it) are helpful, and I hope > some of the prattle I publish on this mail list is received well by others. > > The best thing to happen in Java recently is flexible constructors, but > generally, Java has catered for my vicissitudes as my projects have grown > in complexity for about 20 years. Although I have been diverted for one > reason or another, Netbeans has been a reliable stalwart to which I have > returned time and again. > > Thanks again Netbeans for being sufficient and for not overburdening me > with expectation. I recon, among those gifted enough to give time they may > have to contribute to Netbeans's sufficiency, that there are many more > people among you who feel the same as me. > > Owen. > > On Sun, 18 Jan 2026 at 15:20, Blake McBride <[email protected]> wrote: > >> Greetings, >> >> I thought that sharing my experience with Claude Code might be useful, as >> it has dramatically increased my ability to repair bugs and implement >> features, and I believe it could do the same for NetBeans. >> >> I single-handedly maintain two primary systems. The first is Stack360 >> <https://stack360.io>, a large web-based system. The backend consists of >> roughly 9,000 Java and Groovy classes. The frontend is HTML and JavaScript >> and includes about 300 screens. The frontend and backend communicate over >> REST. The backend uses PostgreSQL with nearly 300 tables, and there are >> seven distinct frontends communicating with a single backend. >> >> The second system is my KISS web development framework, described at >> KissWeb.org. It is open source, so anyone can examine it in as much >> detail as they like. >> >> I began using Claude Code to help support, debug, and enhance these >> systems about six months ago. Early on, I invested significant time >> teaching Claude Code about my systems, architecture, and coding standards. >> >> Computers understand many languages, and to communicate with them you >> must learn one or more of those languages—Java, HTML, JavaScript, C, C#, >> Python, and so on. There is a different “language” used to work effectively >> with AI, and that language is English. Teaching Claude Code about my >> systems and standards is done entirely in plain English using plain text >> files. >> >> Before using Claude Code, I spent nearly all of my time supporting, >> debugging, and enhancing these systems. I worked seven days a week, roughly >> twelve hours a day. My only other concern was spending enough time with my >> wife to keep my marriage on track. >> >> Since training Claude Code on my systems, it now handles roughly 95% of >> my workload. Tasks that once took hours now take minutes. Does it make >> mistakes? Absolutely! But so has every employee I have ever worked with. >> When an employee makes a mistake, you must be careful how you present the >> issue—people get offended easily. Claude Code is always available and never >> gets an attitude. >> >> I pay $100 per month for Claude Code and have never hit a usage limit. I >> have defined several agents, each with expertise in a specific area. Claude >> Code uses these agents in parallel, with them communicating and >> collaborating to solve problems. >> >> Now to how this relates to NetBeans—I apologize in advance for being >> blunt. >> >> NetBeans was once my favorite IDE by far. It had the most intuitive >> interface I had ever used. Around the time NetBeans stopped functioning >> properly during the Apache transition, I switched to IntelliJ out of >> necessity. While IntelliJ is far better than IDEs like Eclipse, NetBeans >> was still the best, in my opinion. >> >> Unfortunately, NetBeans has remained unusable for serious work since the >> rework that was done as part of that transition. I would like to help, but >> I simply do not have the time. For me, that is not an option. >> >> For my purposes, the current version of NetBeans is far too restrictive >> and buggy for real-world use. That is a shame, because I genuinely like >> NetBeans. For a long time I assumed things would improve. Many years have >> passed, and in many areas the situation has worsened. >> >> I understand that progress depends on contributions. At present, there >> are not enough effective contributions to drive NetBeans forward in a >> meaningful way. Left as things are, I doubt NetBeans will ever regain >> anything close to its former level of use. >> >> This is where Claude Code becomes relevant. Tools like Claude Code can >> dramatically increase the amount of progress each contributor can deliver. >> Making a serious effort to integrate AI-assisted development into the >> NetBeans workflow could significantly accelerate development. I believe >> that a substantially more capable and useful version of NetBeans could be >> produced in a relatively short time. >> >> Like it or not, AI systems such as Claude Code are already replacing >> large portions of what we do. This is happening regardless of personal >> preference. My advice is simple: take maximum advantage of it while you can. >> >> Thanks, >> Blake McBride >> >
