I am attempting to write Java code that will walk the stack and print not only the method names/line numbers, but also the values that were passed in as parameters to those methods. I was able to get at StackTraceElement objects (http://docs.oracle.com/javase/7/docs/api/java/lang/StackTraceElement.html) for each frame as returned by Thread.getStackTrace() (http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#getStackTrace%28%29), but this class doesn't expose the detail that I need.
Is there another approach to getting access to the stack frames / activation records that would give me the details on what was passed to each method?
You may be able to do this if you implement the JPDA (debugger API) but I doubt that you want to do that. (The performance implications could be significant, apart from anything else.)
As far as I'm aware, without that level of invasiveness, you won't be able to get at parameter values (or any other local variable values within a particular stack frame) via reflection.
Sorry for the answer to be negative, but without either that or something like AOP which you've already said you can't use, you're out of luck.
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.
First of all I must say I'm new to both Android dev and Java.
I'm trying to find a list of the tags that are used for logging in Android studio.
The examples I've been researching include using:
Log.i(tag:"Info","message");
Log.i(tag:"Values","another message");
Log.i(tag:"Seekbar changed", "and another message");
I tried for the past couple of hours to find a document online, that has a table to describe the reserved tags for View objects, any help will be appreciated.
There is no fixed list of "reserved tags" one can use for logging in Android. You decide for yourself which tags you want to use and what additional information about the state of your objects or primitive types you want to display.
The Log class has six different log levels (debug, error, info, verbose, warn and wtf [What a Terrible Failure]) and corresponding (static) methods (Log.d, Log.e, Log.i, Log.v, Log.w and Log.wtf) each of which you call with two string parameters, one string parameter and one Throwable or two string parameters and one Throwable.
The most commonly used is probably the variant with two string parameters, one parameter for a tag (chosen by you) and one parameter for a message (also chosen by you). See this post for information about which level to choose.
During debugging I often use commands like this one:
Log.e(String.valueOf(myIntVariable), String.valueOf(myOtherVariable));
Let me explain the reason for using the Log class like this. I use the error level because it will give you red entries in the LogCat output (inside an IDE, e.g. Android Studio), and the same IDE will also let you filter out all logs below the error level. However, this is for debugging only; make sure to get rid of those log commands before your app enters production.
Instead of using logs in the way I do, you can also use breakpoints in the debug mode. I guess it is mainly a question of taste if you prefer one or the other. Toasts would be third option (with more boilerplate though).
If you use logs a lot in your code, it makes sense to use real tags. Either you define a string called TAG (or something else) in your class, or you put the name of the containing method as the first parameter. This will give you a sense of the order by which your methods are being called. You can also use other tags as well, and it doesn't have to follow a specific convention either (though you should have a system for it to make sense of it).
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 a requirement, where support in my application a lot of processing is happening, at some point of time an exception occrured, due to an object. Now I would like to know the whole history of that object. I mean whatever happened with that object over the period of time since the application has started.
Is this peeping into this history of Object possible thru anyway using JMX or anything else ?
Thanks
In one word: No
With a few more words:
The JVM does not keep any history on any object past its current state, except for very little information related to garbage collection and perhaps some method call metrics needed for the HotSpot optimizer. Doing otherwise would imply a huge processing and memory overhead. There is also the question of granularity; do you log field changes only? Every method call? Every CPU instruction during a method call? The JVM simply takes the easy way out and does none of the above.
You have to isolate the class and/or specific instance of that object and log any operation that you need on your own. You will probably have to do that manually - I have yet to find a bytecode instrumentation library that would allow me to insert logging code at runtime...
Alternatively, you might be able to use an instrumenting profiler, but be prepared for a huge performance drop when doing that.
That's not possible with standard Java (or any other programming language I'm aware of). You should add sufficient logging to your application, which will allow you to get some idea of what's happened. Also, learn to use your IDE's debugger if you don't already know how.
I generally agree with #thkala and #artbristol (+1 for both).
But you have a requirement and have no choice: you need a solution.
I'd recommend you to try to wrap your objects with dynamic proxies that perform auditing, i.e. write all changes that happen to object.
You can probably use AspectJ for this. The aspect will note what method was called and what are the parameters that were sent. You can also use other, lower level tools, e.g. Javasist or CgLib.
Answer is No.JVM doesn't mainatain the history of object's state.Maximum what you can do you can keep track of states of your object that could be some where in-memory and when you get exception you can serialize that in-memory object and then i think you can do analysis.
I just had an idea that I wonder whether is possible in java. Let's say when doing debugging using eclipse or netbeans, you could record an object and save it. Then when going through the second round of debugging, save the object again. Now you could compare the first object recorded with the second object for all properties and find out any differences. Is this possible?
You can do this in plain Java code (assuming your objects are Serializable), but I don't think any debuggers have this feature built-in.
It would simply be a case of serialising the first object during the debugging run (which if you had a static method to do so, you could generally call from the debugger) and saving it somewhere. Then, during the second run, call another method to reconstitute the object from it's serialised form - and then compare the objects (either with their equals() methods, or some more bespoke comparison method).
In practice though I find that whenever I want to do this I just scribble down the relevant properties on a piece of paper and compare them manually. Rarely am I looking at thousands and thousands of properties that might change between a run; if you think about the symptoms you're seeing and the behaviour of your object, you can normally have a very good idea of what might be changing before you even fire up the debugger, and then use the latter to confirm your hypothesis and backtrack to see where the value "went wrong".
Give your object a useful toString() method and then use unit tests to compare the result with what you expect.
But I agree: The wire protocol for remote debugging can serialize any object, so it should be possible to write a program that does this automatically.
OTOH, objects which aren't meant to be serialized can be dangerous. If you accidentally use this on a classloader, you'll get all objects and classes and everything back as one big lump. So you need a way to stop the serialization to make sure it can't run havoc in a deep object tree.
On top of that, I'd like a feature to save the current state of the app and be able to go back in time.
I don't think any debugger can save object to compare them later. What you can do though is to create a watch variable on the variable, but wrap it with the ToStringBuilder() of the apache commons and dump it in the console, like so:
System.out.println(ToStringBuilder.reflectionToString(object));
Each time the breakpoint is reached, the content of the object will be shown in the console. You can even see the private data.
Therefore, you do not need to modify the toString() method of the object directly (this is useful for library object for example). You can then compare the output of your two passes.