In general, I find that NetBeans alone works nicely for my debugging sessions. There are certainly some nice features which I believe makes it a very practical tool.
I have used JRebel in the past but I must say the company (sold twice I think) has made things a bit less friendly with respect to licensing. (We have cases for which a license file is needed but we have only been provided ones that expire in about 30 days despite the fact that our licenses are for one year) I have been working with the dcevm <https://github.com/TravaOpenJDK/trava-jdk-11-dcevm> and NetBeans a bit lately and hotswapping classes works nicely in some current use cases (remote web applications for example). The one issue I am seeing is that resources, such as JSF files, are not automatically reloaded (remotely). Carl On Tue, Aug 25, 2020 at 4:34 AM Jean-Marc Borer <[email protected]> wrote: > I also kind of disagree with Tim about it un-usefulness of a debugger. You > can achieve way more that just stepping through the code. You can even > dynamically add debugging traces without needing to touch the code and this > he forgets: you cannot add logging statements for code you cannot compile > yourself such as the JVM for example or other Maven artifacts. Have a look > as well at tools such JRebel and Yourkit. They are use cases where they > help you to save a lot of time. > > Cheers, > > JM > > > > On Thu, Aug 6, 2020 at 7:50 PM Matthias Bläsing <[email protected] > > > wrote: > > > Hi, > > > > I don't think debugging with logging/println statements and debugging > > are either or. Both are approach that can be taken. > > > > HOWEVER, if you are new to programming, learn to use a debugger. While > > there is learning involved and it is not always the right tool, having > > it available is a great help. > > > > In a past job we had a central staging JavaEE server, that was used to > > do QS testing with the end users. That server had the jpdw agent loaded > > and at times it was invaluable to be able to just debug in the testing > > system with the user reproducing his problem. > > > > With a debugger it is much easier to explorer the current runtime > > environment and in contrast to logging statements, you don't need to > > know what you want to know before it happens. > > > > Contrary to Tims reply a debugger does not require you to single step > > through code. Line break points are pretty fast, method break points > > are slower, but can be helpful to get to the offending code quickly. > > > > In the end the same advise as in many other cases in IT applies: > > > > - Know your tools (also the ones you may not like) > > - Know when to use which tool > > > > Just a second perspective > > > > Matthias > > > > Am Donnerstag, den 06.08.2020, 03:12 -0400 schrieb Tim Boudreau: > > > I've been developing NetBeans itself and plugins for it for 21 years > now. > > > In that time I have run a debugger against NetBeans maybe ONCE, to see > if > > > it worked. > > > > > > The startup time penalty, and the odds of winding up stepping through > > code > > > you actually need to see, rather than marching endlessly through > > > java.util.Logger's source code and other irrelevant stuff, are > > > infinitesimal. Debuggers are a great tool for debugging algorithms you > > can > > > isolate in a test or tiny application, or for learning how programs > work > > > when you're learning to program. As a tool for fixing things in huge > > > applications with deep stacks, they're pretty much useless - way too > much > > > distracting noise and way to little signal. > > > > > > My suggestion is, learn to love logging statements and > > > System.out.println(). You can isolate problems quite fast if you do a > > sort > > > of logging-binary-search - add a logging statement entering the code > > where > > > something goes wrong, and one at a point where that thing probably has > > > already gone wrong. If that works as expected, add logging at the > > midpoint > > > between those two points. Still okay at the midpoint? Add one between > > the > > > middle and end - and so forth until you're on the line where things > > really > > > do go wrong (usually just narrowing down the scope lets you see it). > > > > > > Sorry to be a downer on debuggers, but I can count on one hand the > number > > > of times I have learned anything useful from a debugger, and all of > those > > > times I could have probably found it faster if I'd just read the code. > > > > > > -Tim > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > For further information about the NetBeans mailing lists, visit: > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > > > > -- Carl J. Mosca
