For example new object allocated, after then it throw to different place, where it is used by a lot of methods. So I want to track all read operations on it to understand in which places this object is used. Something like "go to breakpoint" but "go to next read operation with this object".
There does not seem to be such a shortcut available with IDEA. I am not aware of such shortcuts in any other IDE either.
Below is a resource with list of all available shortcuts and no such facility is listed.
https://resources.jetbrains.com/storage/products/idea/docs/IntelliJIDEA_ReferenceCard.pdf
Communities grow with contribution. You're always welcome to submit a request with below link so that it can be considered if feasible.
https://intellij-support.jetbrains.com/hc/en-us/requests/new?ticket_form_id=66731
If you're talking about seeing where the variable is used (which is what I make from your question), you can just Ctrl-Click on the variable name.
Alternatively, you can right-click on the variable name and click on "Find Usages".
If you want to observe the variable's state and how it changes throughout a debugging session, you can attach a variable "watch" to it.
See https://www.jetbrains.com/help/idea/2016.3/debug-tool-window-variables.html for more information on that.
Related
There is a possibility to add a watchpoint in the Eclipse, like mentioned e.g. here How to detect when a variable changes value
After invoking the watchpoint, the class which contains watched field is displayed and I am able to see that a setter was called. What I would like to know, is where exactly, in which place in the code, the setter(or constructor) was called.
This existing answer suggests that there is no such feature.
But beyond that, there is a simply workaround: use eclipse to find all usages of the method/ctor that sets the thing you are interested in, and then put break points on each of those.
Alternatively, you could put a test in your code under test, to throw exceptions in certain cases, delivering you a nice stack trace containing the call chain.
Is there a way that I can configure properties of my JPA(I am using hibernate as implementation) entity such that no one can see its value while debugging?
The property is transient and I don't want anyone to see it while debugging due to security reasons. The jar/war of my application will be used by third party.
Assuming you're running your program on an Oracle JVM, and allowing people to attach to that JVM via a debugger -- no, you can't hide certain fields.
The interface that the debuggers will use to talk to the Java process is JDI 1, and it gives pretty much all of the information that the JVM has about your code. Specifically:
If a person has an ObjectReference to the object that contains your sensitive data, they can get its ReferenceType.
They can call ReferenceType::allFields to list all of the fields, including transient ones, in the class:
All declared and inherited fields are included, regardless of whether they are hidden or multiply inherited.
Back on the ObjectReference, they can call ObjectReference::getValue(Field) to get the field's value. Note that the documentation doesn't say anything about an IllegalAccessException, or anything like that.
Even if you could lock down certain fields, it wouldn't do you much good; the debugger would be able to see the value when it's in a local variable (either when you read the field, or when you're about to write to it). What you really want is to lock down certain values, not fields. And that's also not in the JDI.
1 Actually JDWP under the hood, but JDI is built on top of that and easier to discuss here.
I have the following problem, we might even call it a classic one:
public void myMethod(Map<Object, Object> parameter){
someOtherObject.method(parameter);
.
.
.
someOtherThirdPartyObject.method(parameter);
}
And suddenly, in the end some method touched the input parameter Map, and I don't know where and how. Now, I know it would be desirable to make the parameter immutable, but it is not and that is the root of the problem. For instance, the methods inside myMethod are intended to perform some validations, but they do some more as well, which is wrong by design.
So, the question is how to create a breakpoint in this method where the execution pauses if an attribute of this parameter Map changes? It might be a good idea to put a conditional breakpoint after each method call, but if you have 20-odd methods, it's rather painful.
How can I debug when this input parameter is changing?
What you want appears to be called a "watchpoint". I actually didn't know this functionality existed and I used to work on the Eclipse Project!
http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.cdt.doc.user%2Ftasks%2Fcdt_t_add_watch.htm
It looks like you'll have to figure out what fields are being editted and then set a "Write" watchpoint using the help document above.
Additionally, Eclipse highlights variables which are modified, so if you step over your method calls one by one you will be able to see which one is modifying the value (and which field is being modified) because it will be highlighted (bright yellow, by default) in the "variables" tab in the "debug" perspective. Once you know which method if modifying the data you can run debug again, but this time debug the method that changes the value and just keep repeating until you find the problem.
This is a classic problem solving scenario where you start with a very large search space and systematically and methodologically narrow it down until the search space is small enough for you to locate the problem.
If you're trying to locate a spot where your map is being modified incorrectly, you might want to first start at the higher levels of the myMethod. Put breakpoints around the methods called inside the myMethod method. At each breakpoint, look at the contents of the Map. Eclipse has a variable watch panel where you can see the contents of every variable at a specific moment in time.
When you hit the breakpoint where you notice something is wrong. Stop. You now know to dig into someOtherObject.method(parameter); assuming the data was changed at it's breakpoint.
Now, someotherObject.method will likely have other methods inside it. Put your breakpoints inside this method around all of it's function calls and repeat the process. Continue repeating until there are no more methods left. Eventually, you will narrow down the problem and have the answer.
Unfortunately, there is no magic "fix my code" button for these types of problems. It just takes good, old fashioned Sherlock Holmes style investigative skills and reasoning to eliminate areas of the code that you know aren't the problem until you're left with a smaller section that allows you to get at the root cause.
If no code modification is allowed, you can
use the watchpoints method described by acattle to watch changes at this specific map instance or
have breakpoints in the Map methods modifying its state (if you want to do that for multiple instances). It does not matter that the Map code is binary only, you can still open it using Ctrl-Shift-T (Open Type), select the methods like put(...) or remove(...) in the outline view and add breakpoints using the context menu in the outline view.
I want to store debug variables while using a breakpoint and restore them regardless of the application. I probably need some plugin to let me serialize variables and restore them anytime.
To be more specific I want:
breakpoint
see variables, store them
let the flow go further
restore variables and view them in a convenient way (maybe in debug, but not while debugging) and compare variables with my application's view tier
ps. I was trying to find some plugin, but without results.
thanks
I completetly agree with stacker, to answer for your next question about expand all it's very hard to implement for eclipse guys - regarding to this
One risk is the difficulty of dealing
with self-referencing structures,
because application have to expand
them only one time. There may be
variable A which has a reference to B;
and there may be a variable B which
has a reference to A. This kind of
problems -seem- can easily solve by a
set, however this isn't the best
approach. Another risk may be the
quantity of the features I proposed. I
think it would be better to withdraw
some of these. I published them here,
because I couldn't determine which.
The only thing you can do (using the standard debugger) is, to copy the textual information from the variables view into the clipboard (Ctrl-C) and store (Ctrl-V) it in a texteditor for later reference. Please note that only expanded nodes, from the variables view, will be copied.
I'm developing a swing based application where I'm using many FileDialogs? So I say why not to make just one FileDialog object instead all of these instances and use it in the whole project? Is this a good assumption? does this have any performance improvement?
Thanks
This is a great example of a use case where application performance doesn't really matter and the question actually falls into the premature optimization class of problem solving. Why? Using FileDialog means that you are interacting with the user who, even if skilled beyond skilled with shortcut key Kung Fu, will be many orders of magnitude slower than the application. How many FileDialogs could a speedy user open, use and close in one minute? Say a dozen. You should not need to care about a dozen objects coming and going in one minute. Shouldn't even appear on your radar. Use your energies elsewhere. In fact, you should create a new object every time and avoid any caching headaches.
I would make a static FileDialog class that generates a new instance of the FileDialog each time a new one needs open rather than sharing a Singleton instance across the application.
That'll save you the headache of trying to figure out if you're reading the correct path from the dialog box or if somebody has opened the dialog and picked a new path and now you're referencing that new path rather than the originally selected path, etc...
Why implement is as a Singleton? Can you actually verify that displaying two file dialogs will never occur?
Better to have it as a regular class; you don't want to build in limitations which could become pain points later.
It isn't like your application is going to be critically overloaded by millions of calls to the file dialog, and who knows, perhaps someday it will be the right solution to have two file dialogs. Even if you don't display them both at the same time, perhaps holding the history in a "source" dialog and having a separate history in the "destination" dialog would be a blessing in a file transfer program.
Forget performance/speedyness. It doesn't matter here. Semantics matter. Reusing the same file dialog may give you things for free. Will the dialog start in the same directory every time? It will if it is the same instance. If you are creating new dialogs you will have to set startup dir your self.
Also why make it impossible to create more than one instance? Just make an instance member in your frame and be done with it.