IntelliJ IDEA. Debugger Professional

so let's begin this is the third and the last uh presentation about the debugger this is the most kind of smart and useful features of the intellij debugger which we have so far um i call it professional but it doesn't mean that these features are hard to use or somewhat um for professionals only no not really but for some reasons they are not that widely used which we are trying to solve at the moment but let's start with some things which i forgot to tell you about on the previous talk and number one is the color filter which is a special filter right here in the breakpoint so the example we had from last time uh we had some work being done in the warm-up section and in the real work section and we were interested in the real work so we set a breakpoint in the work method and we can see that this it is triggered in the from the warm up so last time i showed you how to filter this using the dependent breakpoints so you set a breakpoint somewhere here and you set this breakpoint as a dependent from that breakpoint so with the color filter there's an easier way to do this so if you see the breakpoint and you have some easy way to specify the color for it you can call the intentions menu and say that you don't want to stop if it is called from the warm-up or stop only if it is called from the warm-up and in this case we don't want to stop it uh when it is called from the warm-up because the warm-up is the caller frame and we say it we continue and now you can see that we stop only in in the real kind of part of the application which we are mostly interested in also if you go to the breakpoint settings from here you can see that you can specify not only the exact method with the signature and so on but also you can specify the uh wildcard so for example like any method uh warm-up with any signature will be used as a filter in this case or you can say that you want like any method from this class and if you use a filter like this we will for sure not stop anymore because well real work is is a method from this class as well but i think you get the point another thing is that um renders can be created not only for the objects but also for the primitive types and arrays let me show you so here we have the integer value and for integer value we have some built-in renderers like uh hex presentation or a binary presentation and you can quickly switch them but what if for example you want them both at the same time for any integer value this is possible using the custom renderers so you can create it for a primitive type and you specify something like this so you want it to start with the uh kek string and you reference the value as this even though it is not a an object but anyway we can do that in the debugger and then you create the binary presentation as well so this way it will create a renderer and every integer in any place in the program will be presented using this renderer so for example here and if we go inside the print line method you will see that any number integer value will be presented like this um let's find it somewhere here knock it here so anywhere and also it is possible to do that for um arrays so for example let's pass some parameters here to the application and restart it and uh you can see that the arcs array is presented in this nice and convenient way and that is because i already created the renderer for this which is implemented this simple and easy way because we have a special method for this in the erase class also i forgot to tell you that we have special built-in renderers for images and if you do some like swing programming or something like that you can quickly see the content of the image in right in the debugger oops i forgot to remove the breakpoint so here you can see the image icon which contains an icon and it is loaded from the image on the disk and we can click on this show icon link and see the image and this is a really nice viewer in the editor itself so you can quickly see what's inside the image objects in the debugger but more than that um if you set a breakpoint inside the paint method of the components so in our case let me show you this application shows a big button and uh this button contains the simple text it is small and here and a huge icon which is a jetbrains logo so we can put a breakpoint inside the paint component for this and step by step debug how the component is painted so this one is a jpanel we are not really interested in and this one is a j button which is what we want to debug actually and you can see that the image icon here is what we have and you can also see the real image from here so let's step by step see what's happening inside and we step into and step over until we see that something interesting is happening here so let's skip this until we paint the border so right now in the graphics object there's also the show image link and if you click there you will see that the graphics buffer is empty right now because nothing has been yet painted to that after we paint a border so we can step over here we can show the image again and see that now we have if you can see that and we have the border like this rounded squares painted here and then we can skip to the icon painting so this line here paints the icon so we can step over show image again and we can see that now we have not only the border but also the icon and there's some space here left for the text so we can skip to the text painting somewhere here and you can see that now we have the button fully painted so this way you can debug how the components are painted on the user screen let's get back to the demo oops another nice thing is the lambdas so in streams in java and in some other places users can write several lambdas on one line and it is really hard it was really hard to debug such things because debugger knows about a line and if there's a lot of things happening on one line it's really tricky for that to be debugged well not in idea because we have some special things for this so if you try to set a breakpoint on a line with several lambdas you will be asked about where exactly you want to stop so every lambda is highlighted in this situation and also you can set a breakpoint on the line itself and it will stop only once uh when you first enter the line and you can set a breakpoint on every lambda and also all is really the like any location on the line so every lambda on the line and also the line itself so let's see how it works this one is the line breakpoint so we only stop here when we start the application once and if we kind of continue we will exit the application for sure and if we stop somewhere inside the lambda we will really stop on this line but only when we proceed up to the stream processing so you can see that we enter here with the i equals two and if we resume it also four and six and so on also if you really really interested in any location on the line this is also possible now you can resume and you will stop in every lambda or anything else on this line also if you haven't set the breakpoint in advance but you appeared on such line and you do the step into debugger will ask you what where exactly you want to step into and you can see that it's not only about method calls here like off a filter and of course you will enter these exact methods but also there are several lambda expressions here so you can click on this lambda and you will stop when this lambda will be executed on this line so this is really useful and and easy way to debug streams and another funny thing about deleted breakpoints so uh if you have a breakpoint uh fully set up with a condition with the some filters with the evaluate and log field and then you accidentally click on that and delete it so what do you do well actually there's in there are two ways to to fix this and one of them is there's a special action called restore breakpoint and what it does is um basically restore the last deleted breakpoint so voila we have it back another way to do that so i deleted it again well not accidentally but anyway another way to restore the breakpoint is to set a breakpoint back and of course it doesn't have any setup but it has this nicely link like restore previous breakpoint because it knows that you have just deleted a breakpoint on this line so you can click here and you can restore your breakpoint and later in the presentation i will show you another way how to handle this which is more proficient okay so now let's start with the real nice professional features and the first one of them is the mark object so if in the program you are interested in a specific object so for example here we have a string object and for some reason we want to um remember this exact object and and if we uh see it in any other context we want to make sure that this is the exact object we had before so you can mark it this is called the mark object and you can specify the i don't know the label for this and also you can specify the color for this if you have several of them you can distinguish them by the color so i don't know which one i like orange okay so now the object is marked with this label and if we proceed inside the print line method you will see that any occurrence of this object will be highlighted with this nice label so if we go inside the for example value off and then inside the tostring you will see that not only this is marked with this label but also the frame itself because uh well tostring is called for the marked object um so this is really kind of useful to be able to detect the objects you are interested in but there is one more kind of really useful feature of the labeled object and this is that labeled objects could be accessed from anywhere actually so for example if you have appeared in another thread from where you of course you cannot access that object anyhow it's another thread it doesn't have anything kind of even close to that context here but we had marked we have marked the object already so in any context where we can evaluate an expression we can type uh the name of the label and then underscore the debug label and the completion will help you here and this expression will evaluate to the object which we have marked before so in any context where you can evaluate so you can create a watch from this and this watch will be available in any frame anywhere in any thread you can create a condition for a breakpoint checking for example that this object is the same as that object that we have marked already this is also possible you can create a column method for this or you can kind of make an expression from that for example you can call a method from i don't know from current context using the object that you have labeled before this is really useful sometimes as you can access it from some places where before that you will you were not able to to see the object anyhow so this is about the mark objects now um now you saw so that we have some uh things uh we can use used to see what's happening in the program even if we don't have the exact objects in the context where we are right now but the debugger is actually provides you much more so don't think that when you debug an application you are kind of uh only in the place where you are right now like you have a thread you have a stack you have a frame so you can access only what's there in the frame or like local variables or referenced variables from there it's not true so debugger knows everything about your program and to provide you with this information we have a memory view so memory view think about it as a snapshot of your memory but it's not a snapshot it's a real kind of access to the memory of the application so you you have a list of all classes and all objects in the java hip of the application that is being debugged so for example um we have 4 000 plus strings in the application right now even though we don't have any of them in the current context so we can double click there and see the all the objects here and also we have a filter here so you can specify a condition written in in a regular language well in programming language in java in this case and you can filter that so for example we are interested in strings uh with the length uh more than 100 so it will apply this expression to every string object in the java heap and provide you with the strings which which are longer than a hundred symbols so what about a thousand symbols yeah there are some so what can you do with this information because now you know that there is a nice string ada and d and so on so from here you can show the referring objects so really what objects reference this particular object so this is almost the same as you you can do in the memory profiler or when you open a memory snapshot in in any memory analysis tool so you can see that it's a local object from java which for some reason reference this super huge line uh what else from here so for example you want to find a string which starts with a special prefix [Music] actually any expression which you can apply in the application you can apply in in the filter in the memory view this way you can find any object in the hip and also then you can mark it and provide it with a nice name i don't know string one and then as i have shown you before you can um reference it from any context so for example if you have several objects of the type you are interested in so let's uh continue to the next breakpoint so now we have three objects of memory type like memory is a class so of course we have them here in the context right now but it doesn't mean that this is always be like this so for example if we step into the print line method now we don't have any of them here but we can quickly filter this uh in the memory view and now we have all of them here so uh if you know that you have some interesting objects in the hip you can quickly find them from the memory view reference them or use them from the your current context or you can change them so um once again it is of course possible to do any modifications to that objects in the memory the same way you do that with the objects in the current context also in the memory view the ns there are some nice features like the diff column so when you do steps you can see how the number of object changes so for example since the previous stop there appeared like three more memory uh class objects and two uh classes were probably loaded and created one more string and so on and so forth so you can step in your program and see how the memory changes and you can even call the garbage collection from the evaluator and also see how the number of objects changes in the java hip um from here you can also track uh new instances of the objects so if we say ask it to track new instances from here and we restart it and we skip to the next breakpoint you can see that now it has the link here so if we click uh you can see for every object that was created since our last stop the creation stack so this one well in this context it of course it's not that interesting but for some objects sometimes it's really interesting to see where the the constructors were called for them and you can do that from the memory view so let's un-track them um okay uh some nice settings of the debugger which you may be interested to change uh when you um at some pro level uh of debugger knowledge so as i said before uh it is really easy to delete a breakpoint if you simply click on that and it's gone so uh you may be interested in changing that and there's a special settings for this here in the debugger settings which is called remove breakpoint so by default you click and also you can drag or click with the middle mouse button i usually use this just because i i tend to delete breakpoints a lot and i don't want to restore them so on the first click i create a breakpoint under the second click i disable the breakpoint so if i want to get back to that breakpoint i enable it again and so on so no more deletion by click and to delete it i either click it with the middle mouse button or drag it to the editor this is for me much useful also we have the confirm removal of conditional logging breakpoints so if you don't want to be that radical and change the behavior you can enable this and if you have a breakpoint with the condition oops it will ask you every time you want to remove this breakpoint i don't know for some people it is useful but i find this radical way of removing breakpoint for more useful also the default delay for the tooltips in the debugger is 700 milliseconds which for me is too too big too long so you can uh set it to something like a hundred milliseconds or maybe zero but zero is once again to to to radical um also if you're a keyboard lover and you don't want to use the quick evaluate shortcut you can enable the show value tooltip on code selection and this way to evaluate something you just need to select it so you can just enlarge the selection like here oops i i use mouse so i don't yeah like this so for people really who really don't like mouse this could be useful and one last thing is the null elements in the collection and arrays and by default we don't show them and even though we are showing a special hint for this [Music] many people don't understand why there is no nulls there so if you don't like this oops if you don't like this behavior you can go here to the data view settings and unselect this setting and now objects will be there in the collection for some people this is more useful than not having them so let's continue the hot swap the jvm has the ability to change the bodies of the methods on the fly and in the debugger you can easily use this using the reload or the hot swap functionality so for example we appeared in this nice method which is printing the integer parameter plus a hundred and for some reason we would like it to print plus thousands for example so of course we can stop it we can recompile it restart it and then see what happened what's happened but there's an easier way we change the code we call a special action called compile and reload file and it will recompile this one particular file and reload it in the debugger and you will see that the current method is now obsolete with a nice red icon and obsolete doesn't mean anything dangerous it it only means that the new version of the method will be in effect only on the next entry to the method because jvm jvm doesn't want anything to be broken so in the process of uh execution of the method it will not uh kind of replace the code so when you exit the method and stop there on the next iteration uh the new code will be in effect so you can see that now it prints the plus thousand uh also if you don't want uh to skip the current kind of call of the method and you want it to be processed with the same parameter value so let's change it to back to 100 and compile and reload again and what if we want it to be executed with the i equals to zero uh we can do a trick using the drop frame so we drop this frame and we enter it again and now the method will be executed with the same parameters and with the new bytecode changed so we can step over and see that it it produced the new result which we expect this is the easy way to change the body of the method you are already in currently and please don't try to change the main method on the fly because you will not be able to see the difference because you will not be able to drop the mainframe and step into that again uh so only on restart you will be you will see the difference what else can you do with the hot swap so other than changing the application on the fly so you can check your fix of the bug right there without restarting the application also there's another use case uh so check this code so it does a lot of iterations and for example you are interested in one of them with a special i equals to i don't know a hundred thousand hundred thousand so if you start this application uh even though this condition is really simple but the number of condition checks is so huge that you will probably not be able to wait until it triggers so there's a way to work around this so one of them is to hard code this condition right into the application so you can easily do this here and then set a breakpoint here and this would be usual breakpoint and you can recompile restart it and then immediately stop right there where you want it to so we have a plus thousand here so it's it's okay that it's a different number here uh so but you can do the same using the hot swap so for example if you want to be stopped here so let's let's delete it and restart the application and for example stop on the first iteration but we wanted uh to stop on the iteration number a hundred thousand so i haven't yet recompiled and reloaded the code so you can see that the breakpoint is is invalid but when i compile and reload the file and it will be reloaded the breakpoint will become checked so now it will work yes so let's skip this back yes so this way you can work around the conditional breakpoints which are really really frequently used and you are not able to wait until the condition is uh is true uh what else in the debugger so last time we discussed the remote connection of the debugger but actually for the debugger any connection is remote so even processes on the local machine is is attached the same way you attach the process on a different machine so it's a socket so uh for local processes you can attach to them using the attach to process action let's do this and you can see that now it far it finds only one java process and it states that it can do read-only attach so what is that so if we haven't provided the vm vm option for the process which we discussed before uh with that debug agent and so on you can still attach the debugger using this read-only mode and this mode is um is like this you suspend the application altogether and you can see the threads you can see the frames you can see the local variables and the content of the memory but you cannot do the stepping so you can suspend all the applications see what's happening inside and then resume everything at once so no break points no evaluation but you will be able to see what's happening at the moment so let's try this this launcher is the uh on mac it requires this super user privileges so this this process is actually the compile server of this idea so you can check the processes it has you can see what's happening inside every process with every value of every variable and you can also see the memory view for this this is much more useful than the regular thread dumps because well thread dumps does not provide you with any information about variable values and here you can see you can check whatever you want of like for every frame you have the values um this is sometimes much more useful than regular thread dumps but also you can use this for different thing so consider this a simple application which runs the oops i already have which runs the uh jdb jdb is a command line debugger for from the jdk so i just use it as an example of the process which waits for the user input here so we have this process right now running and we can see that it is in the list of the java processes in the system here it is so we can do the read-only attach and observe what's happening inside um let's type the password so you can see the that it starts from the main and the main is actually a constant tools example debug so if you didn't know the jdb is an example inside the jdk is an example application of how you can write a command line tool for the the apis okay so in read-only mode there's not it's not that interesting so what if we want to debug it uh [Music] with the debug agent so where do we provide this debug agent so jdb does not accept the vm options from the command line because it has its own starter jdb as an executable in the system uh well actually there is a way uh there is a special environment variable called java tool options uh if the virtual machine java virtual machine is started and it sees that this variable is set it adds the value to the vm option of the virtual machine so how we can use this we can provide this variable and we can set the value of this variable to the debug agent line so this is exactly the same line we used for remote debugging before with one difference is that we don't specify the address because uh well if the address is like fixed number it will be used for every virtual machine and so a second invocation of the virtual machine will have the same address and will not be able to start so we don't provide it so that the virtual machine is able to auto [Music] detect any available address and use it so now let's provide this environmental variable to the process and let's run it instead of debug because this environmental variable uh interfere with the regular debugger from the idea so we run it uh it has detected um the option so this is from the jvm it's it's not our output the jvm on startup detected that this environmental variable is set and it used it and you can see that it assigned the port to this process but also if we go to the attach to process list you will see that it assigned a port to the jdb process as well so this is uh this one and this is the jdb process from uh from the uh from the the sub process which started from here so now we can attach it uh using the regular debugger attach not the read only so what do we do here so we can pause it and we can see well almost the same picture we had in the read-only attach so how do we proceed with this so let's set a breakpoint here for example so after the redline is completed we will be able to stop here but how do we provide input to the process which we started from another process and we actually don't assign and we haven't assigned anyhow streams so um let's attach to this process as well so now we attach to this process and we let's stop on the breakpoint here let's get the process stream and let's write something there like hello and i know that we also need to flush the stream you can see that the hello is now available on the breakpoint in that another process and we can step by step debug that and see what's happening inside the another process even though we haven't anyhow affected the startup line using this environmental variable we are able to debug it now so sometimes it is useful so using this technique you don't have to rely on some debug options for the sub processes inside another kind of process you can use it to debug like anything anywhere okay um what else ah also i forgot to tell you that if you have a running process already and you have a tool window for that there's a special button here called attach debugger so you don't have to go to the attach to process list you can attach the debugger to this exact process right from the tool window and also for read-only attach this is also available so instead of doing a thread dump from the tool window you can attach a read-only debugger and have much more information ah debug decompiled code what if you want to debug an application and you don't have source code for that application at all consider this example i have a toolbox here and i have installed the release version of the idea ultimate 19.3.3 so i can go to the settings if you can see that i can go to the vm options and add the line for the debugger agent then i can start this idea and go to the attach the process you can see this idea in the list and i can attach so now i can debug this application but i don't have sources for this and uh one way to to find the sources is to well get to the github and then fetch them and for idea repository takes like some time quite some time and another way i will show you right now so you can pause here and you can see some frames from jdk and some frames from the comment lj ide but there's no sources there are no sources so if you click you you can see the local variables but no source there is a way to work around this so if you go to the project settings and before that let's go to the toolbox and copy the install location now let's and this project which we are currently in it has nothing inside so it's it's an empty module just some dependencies for the demo like uh jetbrains annotations and so on but no no source code for the idea of course so and this is also the annotations artifact so let's add a java library to the project and from here i know the extra strange mug shortcut to go directly to the path i i copied from there it's a secret so from the from here let's add the whole lip folder of the installed idea and we will add it as a dependency and it will take some time to index this but after that if you kill if you click on the intellij source or the frame from the intelligent sources you will see that now we have something and it looks like so the source code well basically it is the source code but it's not the real source code it is the decompiled class file as as it states here on the top so what it does uh is it takes the class file from the jar from that lib folder we have provided and it decompiles that because the idea has the decompiler built in and it provides you with the decompile source code but the debugger is fully integrated with the decompiler so now you can step by step uh go through the code you can do this step into step over everything else so sometimes the decompilation process is not that absolutely correct but the code will look almost as the real source code for the application so we don't have the source code but we can debug it and we can see the local variables and also of course because it is a real debugger we can do things like this so let's uh oops we have a lot of breakpoints so let's open something in this idea and i know that there's a nice class inside the idea which is the editor impul my favorite let's go there and once again it is decompiled so we have the paint method which is the main method doing the painting inside the idea code so let's get back and now immediately we have it painted and we have stopped on the breakpoint so let's see what we have here in the editor a lot of fields and i am interested in the background field so we have this nice field here let's change it to something like color green oops and let's resume it yeah you can see we we we didn't have sources for this idea but we were able to debug it stop somewhere in a real position and change the value so this way actually even without sources you can debug almost any application uh the things you need for this is the bytecode so you need to have the access to the class files and there may be some tricks to to make it harder like stripping of the debug symbols from the class files or the obfuscation of of the byte code but in in many many situations this approach works really nice so let's get back and please don't use this for illegal things uh when you first use the decompiler there's a special uh kind of agreement that you're stepping to the really dark territory so we are not responsible for anything you are doing with this super technology uh okay async stack traces so in modern world with many many threads and cores and when people are really interested in making their hardware working really hard hardware hard working sometimes it's really hard to debug the code written in the async way so consider this example we have the getline which is called inside the run async completable future which what it does it basically calls this get line on a separate thread and then waits for the result so if we debug this um and i will disable async stack traces for now if you debug it in any other debugger not the intellij you will see the picture like this so this stack trace of this uh getline invocation does not contain anything even close to the main method so it is the insights of the executor which is used for the completable future and async and uh if you stop somewhere inside the getline method you will not be able to find out where you came from so where this getline was kind of scheduled for execution and here we do that again so inside this async kind of processing we do this again so if you stop here you don't know anything about the getline method and of course you don't know anything about the main method which was kind of the root cause of all this processing but not in idea so i enable back the async stack traces and they are enabled by default so if we filter out the uninteresting stuff you can see that now you can see the logical async stack trace so first frame is the kind of second schedule and the last frame here is the main thread oh main method so this way it is really easy to see how the work chunks are processed and where they are scheduled and where the uh kind of real processing is happening there are some limitations to this so for example in the so-called captured stack frames or stack traces here you will not be able to see the local variables but that's the limitation it takes too much time to record that information as well so by default uh this uh technology uh is kind of used for most common executors from the jdk so invocator from swing and some some other things uh also if you have your own executors in the in your application there is a way to to make async traces available for you as well so this is a really simple example of the custom scheduler or the executor so we have a queue and we have a thread which process the elements in the queue and we have a schedule method which kind of adds the element to the queue and we have the process method which kind of done which doing the processing so without the sync stack traces if you uh stop inside the process method you will see the stack well almost like we had before so nothing that looks like the schedule method well we are interested in the information about where the schedule method was called for this piece of work so we have a special annotation in the jetbrains annotation annotations package especially for this and the annotation is called the async schedule and the async execute and the schedule is for the place where you schedule the work so you mark the key which will be used for matching the execute part later and then the execute annotation is used in the process method so you set the annotations like this and you don't need anything else in your application let's restart it and now you can see that inside the stack trace you can see the async stack trace and it shows you the exact schedule position so for the first process invocation it is the first schedule for the second it is the second and for the third it is the third so in the idea project we have annotated several we have already annotated several custom schedulers we have in the code like later invocator or alarm and some other so if you have more examples please annotate them or contact me and i will help you and doing this uh stream debugger we have already checked some examples of these streams and saw how complicated it may be to debug them but there is a solution and nice solution which is called stream debugger so if you have a stream and it's really hard to understand what's happening inside so it calls some factorized method and other stream operations after that and also the input is rather complicated there's a special action for analyzing what's happening inside which is called the trace stream chain and you click on that it will evaluate the stream and provide you with the [Music] image of the transitions which is happening inside the stream so you can see that every uh oh my god let's let's disable that renderer it is so strange yes so every input in the stream you can see how it is processed in the [Music] in the stream processing so for example this flat map uh uh obviously calls that factorize so for every input you can have more than one output and then the distinct will remove duplicates and you can see how it's happening visually and then it sorts that and then to array basically puts everything to array so it is very easy to see visually what's happening inside the stream and it's not necessarily have to be integers here you you can have any type of objects also the flat mode produce this nice picture of what's happening from the beginning to the end and if you click anywhere it will show you the path uh of uh of the element through the stream processing sometimes it's really easier to understand what's happening here than doing the real debug what if you have a breakpoint and as we have seen before you may have a breakpoint with the condition doing some hard work uh checking something but uh as you can see here nothing is happening so the application is doing something but we don't know what so for us it looks like the application hang or something like that but the problem is that we forgot the breakpoint with the condition so how do we uh figure this out so in this case it's obvious but in an application with the huge code base it may not be that obvious so there's a special view for this called the overhead view and it records and shows you the overhead of different elements in the object different processes happening inside the debugger so now you can see that the breakpoint was hit was never hit but it takes a lot of time for processing and you can disable it right from here so let's let's set a breakpoint somewhere else if we can now yes and we can disable it and and uh this way we can quickly find some breakpoints uh possibly with conditions which slows down your application and if you don't need them you can disable them from there at once and also it shows some more nice things there so it shows you the renderers so this is the [Music] array renderer and if you step you can see that it takes sometimes well not much but some renderers may take a lot of time to evaluate so if you see that your stepping is slow uh and some of your renderers consume a lot of time you can disable these renders and step a little bit faster and also you can see the show method return values is here uh though we don't show the exact time it took but on every step it takes some time to to provide you with the last return value of the last method also i don't think i i was talking about this feature maybe yes but it shows you the last return value of the method so if you don't have it somewhere anywhere recorded sometimes it's really useful to have it here but it consumes some cycles so if you don't need it please disable it to be able to do the stepping faster so this view is the first place to go if you see that the application in the debugger is working slower than it is expected first open the overhead view maybe you have forgotten something and it consumes the cpu uh some things uh to say about watches so usually watch a watch is a an expression which will be evaluated in every context uh so if you have uh something specific there in most contexts you will have the unable to evaluate everywhere so for example if we add this kind of a here so strange case but anyway if we go to another thread of course there will be no such variable here as a so for some cases there is a solution called class level watches if you are interested in a special specific expression for a specific type only so for example we have a string here and maybe for a string we are interested in having the length available inside so you can add a class level watch to this type of object so in this case it's string and you will be able to see this uh for every string object and let's add anything something else so for example we would like to see if it starts with a and you can see it's true so let's go to the memory view and see what we have for other strings so you can see that we have these class level watches here because we edit them for the string object and you can quickly see the values for any string objects now also if you're interested in a particular field so if you have a lot of fields in the class you may be interested in some of them first so you can add them as a class level watch but there's an easier solution you can click on this flag or call the pin to top action and it will just move this field to the top of the list also class level watches are implemented using the renderers so if you go here well in presentation mode you cannot see this let me show you like this if you go to the settings you can see that these expressions are added to the list of the fields and you can make them on demand so if for example this uh expression is uh kind of uh may take uh long to evaluate and you don't want it to be evaluated for everything you can make it on demand and it will be evaluated only when you click here so for example you can add some hardcore processing there make it on demand and evaluate it only when you need it for this particular method also you can unpin of course if you don't need that so let's see if it works for any yes it works for any method or any string object now and of course this is not only for strings you can use it for any type of objects uh another question which people usually ask is when you stop when you not stop when you suspend your application using the suspend button or pause uh you cannot evaluate so you can see this uh message here that the vm is not post uh by the breakpoint request so you cannot evaluate so even if you want to get something as easy as system get properties you cannot do that because it's a limitation of the jvm so what can you do in this case um well the solution is actually easy you can do a step and usually in in many many situations after the suspend you can do this step so if it's not the endless weight in in this thread if it does some like processing uh like event dispatch threat or something like that you will be able to do a step and then in this context you can easily do the evaluation so this way you can work around this limitation of the jvm in many many cases if not all actually this is it now you can debug much better maybe like a professional thank you and your questions any questions there's a microphone right there munich oh my god two people there any questions no have a question give him the microphone really can your debugger download class files can your debugger download for class files uh download from where or you mean the source code it can download it could possibly download this for a community version but probably not for the ultimate microphone doesn't work it seems hello oh ah now it works well i can repeat it the question was why can't the debugger download the source code or the classes for the application being debugged yes yes uh and my answer was that it probably can do that for the ah you mean automatically added to as a library or or what you uh you can do step you can do uh show frame ah i understand so get it from the debugger like the byte code yes and if debugger can do all these things can't uh it should know the yes yes it knows so uh [Music] the debugger can get the byte code from the application itself it's true uh it can get the bytecode of the method so there is a request to do that even without the operations i showed you with the leap folder and so on so it is technically possible to do this yes but it's it is not yet done because there are some limitations to the uh bytecode provided by the debugger so for example it does not provide you with the exceptions table so the compilation of this is is tricky so we don't do that now but maybe we'll do that in future no questions thank you that's it then thank you is there a question munich no okay thank you bye bye you

Channel: IntelliJ IDEA by JetBrains

Views: 13,817

Keywords: debugging java, java, debugging in intellij, intellij java, intellij idea tutorial, intellij idea, debugger

Id: JPR3w3Qtwzw

Length: 68min 40sec (4120 seconds)

Published: Thu Sep 09 2021