Tricks
•Download as PPTX, PDF•
0 likes•194 views
Slides with references to my JavaZone 2016 talk "Java Debugging Tricks". Slides on their own are not that informative, but contain references. Check out the video for actual demonstration: https://2016.javazone.no/program/java-debugging-tricks
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (14)
Similar to Tricks
Similar to Tricks (20)
More from Martin (高馬丁) Skarsaune
Recently uploaded
Recently uploaded (20)
Tricks
- 1. Martin Skarsaune Senior Developer and Co-Owner @MSkarsaune Debugging Tricks 高 馬 丁 We’re Hiring
- 2. Execution Order • Code evaluation • Controlling your steps and breaks • Manipulating code flow • Tracking classes and objects • Ensuring WYSIWYG • Debugging concurrent code • Customizing the debugger
- 3. Frames + threads Variables Watches ? Test Results? Console Display ? Code
- 4. Frames + threads Test Results? Variables + watchesConsole Code
- 5. 1. Should you always launch in debug mode?
- 6. IMHO: Always Launch in Debug Mode! • Ability to halt and troubleshoot • Threads • Hot code replacement • Consider launching externally
- 7. Excecution Order • Code evaluation • Controlling your steps and breaks • Manipulating code flow • Tracking classes and objects • Ensuring WYSIWYG • Debugging concurrent code • Customizing the debugger
- 9. Step Out- Code Evaluation • Both in Java editor and free form • Nothing is private • Watches • In breakpoints • Nested evaluations / breaks • Scrapbook
- 10. Execution Order • Code evaluation • Controlling your steps and breaks • Manipulating code flow • Tracking classes and objects • Ensuring WYSIWYG • Debugging concurrent code • Customizing the debugger
- 11. 3. Controlling your steps and Breaks
- 12. Step OUt- Controlling your steps and breaks • Step filters • Frame filters • Smart stepping • Lambda stepping and breakpoints • Exception breakpoints – Break after
- 13. Execution Order • Code evaluation • Controlling your steps and breaks • Manipulating code flow • Tracking classes and objects • Ensuring WYSIWYG • Debugging concurrent code • Customizing the debugger
- 15. Step Out- Manipulating Flow • Drop to frame • Modify values – nothing is really final • Force return
- 16. Execution Order • Code evaluation • Controlling your steps and breaks • Manipulating code flow • Tracking classes and objects • Ensuring WYSIWYG • Debugging concurrent code • Customizing the debugger
- 18. Step Out - Tracking Classes • Class load breakpoints • Static initializers • All instances and count – Requires ”JVM Memory Debugger View” plugin
- 20. SteP Out- Track Objects • Instance initializers + default constructor • Unique Id + Labelling objects • Watch points + instance filter • Tracking references
- 21. Execution Order • Code evaluation • Controlling your steps and breaks • Manipulating code flow • Tracking classes and objects • Ensuring WYSIWYG • Debugging concurrent code • Customizing the debugger
- 22. 7. Is What You See Real?
- 23. Step Out- Connection to code • Detecting erroneous source attachment – Editor Warning – Evaluate timestamp of class • Method breakpoints • Viewing actual code
- 24. Execution Order • Code evaluation • Controlling your steps and breaks • Manipulating code flow • Tracking classes and objects • Ensuring WYSIWYG • Debugging concurrent code • Customizing the debugger
- 26. Step Out- concurrency • Instance and thread filters on breakpoints • Step resume • Analyzing deadlocks
- 27. Execution Order • Code evaluation • Controlling your steps and breaks • Manipulating code flow • Tracking classes and objects • Ensuring WYSIWYG • Debugging concurrent code • Customizing the debugger
- 29. Quick Recap - Customizing the debugger • Detail Formatters / Data Type Renderers • Logical Structures
- 30. References
- 31. 10. REferences • IDE documentation • Debugging in IDEA 2016.1 https://www.youtube.com/watch?v=VdBsUv4lnm 4 • Decentipede Eclipse plugin update site: https://skarsaune.github.io/decentipede.update.s ite • JavaZone 2015: ”JVM Debugging under the hood”. https://vimeo.com/138957695
- 32. Questio ns ? Thank you for your time!
Editor's Notes
- Welcome everyone to this session where I will be focusing on debugging. My name is bla bla. I like to learn from other developers. Pick up some ideas. So what I plan to do is to demonstrate a few familiar scenarios, where we are in a debug session, and want to find out something or solve a problem. We will see what features and techniques can be used. Some of it may be known to you already, and in that case credit to you. Hopefully other things may be new or used in a different way than what you are used to. Hope show you something new today. Also some custom plugin functionality that is guaranteed to be new. I will also demonstrate some custom plugin functionality that is guaranteed to be new.
- I intend to look at the following topics. I have organized them according to what I myself found the most productive and rewarding from the top. That also solve quite common problems, and then more exotic tips towards the end. First I want to look at the debuggers ability to evaluate Java code on the fly. What it can be used for. Also in what way it is limited to normal code, but also cases where you can achieve things that you are not able to with normal code in your application. Then I would like to look at how the debugger can be used to manipulate the flow of an application. For instance if you want to test your application in a scenario, that may not be easily or consistently reproducable. Then I want to look at what tools there are to make stepping code and setting breakpoints as efficient and
- Some words on visual setup, which is not the same as I would normally use. These days I guess the trend is to concentrate on editing code as you work, with things like the distraction free mode in IntelliJ. When I debug however I prioritize differently. I normally do not have to see that many lines of code to troubleshoot, but I do want to have critical information at my fingertips. Normally you would have a large screen that allow you to arrange the different views at dedicated places. I guess many people have several large screens, so you can even distribute views over several windows or have floating views spread out. The moment you find a certain view not needed or a distraction, you can simply minimize it. If you find that your debug session takes you into a more active browsing and coding mode, you can simply maximize the editor, change perspective in Eclipse or go to distraction free mode in IntelliJ. What you really don’t want is to have to constantly change views in order to find the information you are looking for. If we look at this Eclipse example for instance. I normally like quite a lot of space for threads and frames, always have the variables visible. If I use watch expressions actively I would like to have them visible as well. If I’m debugging tests, I might want to keep track of the progress. Depending on the application I often want quite a lot of the console visible, also to keep track of what is going on. If I evaluate a lot of code on the fly, I might keep the Display view open, but most of the time it is sufficient to bring it up when I need it.
- If we take a similar look at IntelliJ.
- I intend to look at the following topics. I have organized them according to what I myself found the most productive and rewarding from the top. That also solve quite common problems, and then more exotic tips towards the end. First I want to look at the debuggers ability to evaluate Java code on the fly. What it can be used for. Also in what way it is limited to normal code, but also cases where you can achieve things that you are not able to with normal code in your application. Then I would like to look at how the debugger can be used to manipulate the flow of an application. For instance if you want to test your application in a scenario, that may not be easily or consistently reproducable. Then I want to look at what tools there are to make stepping code and setting breakpoints as efficient and
- Eclipse: Editor + Display + Scratch, breakpoint and evaluate, Log as part of conditional breakpoint. Terminate evaluation, Scratch: stream, regex, byte manipulation IntelliJ : Evaluate private, expression vs snippet, history, alt + operators, keep in scratch. Use appendable to log as part of conditional breakpoint. NB
- I intend to look at the following topics. I have organized them according to what I myself found the most productive and rewarding from the top. That also solve quite common problems, and then more exotic tips towards the end. First I want to look at the debuggers ability to evaluate Java code on the fly. What it can be used for. Also in what way it is limited to normal code, but also cases where you can achieve things that you are not able to with normal code in your application. Then I would like to look at how the debugger can be used to manipulate the flow of an application. For instance if you want to test your application in a scenario, that may not be easily or consistently reproducable. Then I want to look at what tools there are to make stepping code and setting breakpoints as efficient and
- Eclipse: Editor + Display + Scratch, breakpoint and evaluate IntelliJ : Evaluate private, expression vs snippet, history, alt + operators
- I intend to look at the following topics. I have organized them according to what I myself found the most productive and rewarding from the top. That also solve quite common problems, and then more exotic tips towards the end. First I want to look at the debuggers ability to evaluate Java code on the fly. What it can be used for. Also in what way it is limited to normal code, but also cases where you can achieve things that you are not able to with normal code in your application. Then I would like to look at how the debugger can be used to manipulate the flow of an application. For instance if you want to test your application in a scenario, that may not be easily or consistently reproducable. Then I want to look at what tools there are to make stepping code and setting breakpoints as efficient and
- Eclipse: Editor + Display + Scratch, breakpoint and evaluate IntelliJ : Evaluate private, expression vs snippet, history, alt + operators
- I intend to look at the following topics. I have organized them according to what I myself found the most productive and rewarding from the top. That also solve quite common problems, and then more exotic tips towards the end. First I want to look at the debuggers ability to evaluate Java code on the fly. What it can be used for. Also in what way it is limited to normal code, but also cases where you can achieve things that you are not able to with normal code in your application. Then I would like to look at how the debugger can be used to manipulate the flow of an application. For instance if you want to test your application in a scenario, that may not be easily or consistently reproducable. Then I want to look at what tools there are to make stepping code and setting breakpoints as efficient and
- I intend to look at the following topics. I have organized them according to what I myself found the most productive and rewarding from the top. That also solve quite common problems, and then more exotic tips towards the end. First I want to look at the debuggers ability to evaluate Java code on the fly. What it can be used for. Also in what way it is limited to normal code, but also cases where you can achieve things that you are not able to with normal code in your application. Then I would like to look at how the debugger can be used to manipulate the flow of an application. For instance if you want to test your application in a scenario, that may not be easily or consistently reproducable. Then I want to look at what tools there are to make stepping code and setting breakpoints as efficient and
- I intend to look at the following topics. I have organized them according to what I myself found the most productive and rewarding from the top. That also solve quite common problems, and then more exotic tips towards the end. First I want to look at the debuggers ability to evaluate Java code on the fly. What it can be used for. Also in what way it is limited to normal code, but also cases where you can achieve things that you are not able to with normal code in your application. Then I would like to look at how the debugger can be used to manipulate the flow of an application. For instance if you want to test your application in a scenario, that may not be easily or consistently reproducable. Then I want to look at what tools there are to make stepping code and setting breakpoints as efficient and
- I intend to look at the following topics. I have organized them according to what I myself found the most productive and rewarding from the top. That also solve quite common problems, and then more exotic tips towards the end. First I want to look at the debuggers ability to evaluate Java code on the fly. What it can be used for. Also in what way it is limited to normal code, but also cases where you can achieve things that you are not able to with normal code in your application. Then I would like to look at how the debugger can be used to manipulate the flow of an application. For instance if you want to test your application in a scenario, that may not be easily or consistently reproducable. Then I want to look at what tools there are to make stepping code and setting breakpoints as efficient and