> (I could open another can of worms which is the NB profiler > https://github.com/apache/netbeans/issues/7323)
Indeed; I use the NetBeans profiler quite a lot. I see a worrying line of argument in these discussions: Some contributors say, quoting from the PR above, "I don't use [feature X] at all personally", another one says "me neither", and then "either we need someone to work on it ... or we drop it". I disagree with this: Dropping a feature is permanent, whereas leaving it in avoids disrupting existing users, and allows occasional fixes to be accepted over time. For a huge piece of software such as NetBeans, different users are going to use different features, and bugs are a fact of life. Doing big workflow changes such as "switch from maven to gradle" will not eliminate bugs, but rather replace them with another set of bugs. Over time, each user picks a workflow, and learns about the relevant bugs and how to work around them. If a particular bug is particularly egregious, the user might find it worthwhile to develop a patch, and perhaps submit a PR. (In the profiler's case, as an example, Peter Hull and Lars Bruun-Hansen contributed a big patch in 2021; see https://github.com/apache/netbeans/pull/2700 .) In the case of https://github.com/apache/netbeans/issues/7323 and similar issues, ideally we would figure out how to encourage the original issue submitter to develop a fix... after all, all NetBeans users are also software developers themselves! -- Eirik From: Michael Bien <mbie...@gmail.com> Date: Thursday, August 22, 2024 at 1:57 AM To: "dev@netbeans.apache.org" <dev@netbeans.apache.org>, Eirik Bakke <eba...@ultorg.com> Subject: Re: [DISCUSS] Projects, Builds and IDE magic On 19.08.24 05:38, Eirik Bakke wrote: When did you see the last CoS bug fix? Is there empirical evidence that this is still maintained? There was this one: https://github.com/apache/netbeans/pull/504 ("Option to skip CoS copying of class files when the target is already newer, such as from an external compilation") right, the last fixes I could find were around the 12.x time frame. The fix linked above was 15 releases ago for example. First, I would like to take a step back and ask what's the purpose of an IDE. I'd like to be able to edit my code, hit "Run", and have the code run. Preferably both quickly and accurately. But speed is _really_ important, as slow operations tend to change the user's entire workflow. So I often prefer speed over full fidelity wrt. what a clean build would produce. That was always a known tradeoff with Compile-on-Save, in both NetBeans and Eclipse; that's OK! I too would like that everything happens with minimal delay after hitting a key - but correctness comes first. If I press a button and it works only sometimes or only for a badly defined subset of projects, I would question every button press during debugging sessions from now on. This in turn also breaks the workflow since recovering from cos problems requires essentially a clean+rebuild. There are also users who reported that they couldn't run tests which was fixed by turning CoS off etc. CoS not relevant for small projects that build instantly, though, such as when starting a new project from scratch. So CoS should definitively stay off by default, and have some big warnings/caveats on it. But I'd hate to see it deprecated or removed; it's a really valuable piece of technology. On a high level, this thread is about agreeing to focus our time on tool integration instead of IDE specific tricks. While looking through the issues and PRs I realized this probably already happened. (I could open another can of worms which is the NB profiler https://github.com/apache/netbeans/issues/7323) When we literally have to disable a feature by default because it causes so many problems (https://github.com/apache/netbeans/pull/5826). It already is de facto deprecated, just not in UI or doc. -mbien -- Eirik
