Develop Reference

Java tests: Massively generate mock objects by running your code

Hello all :) In the JVM debug mode you can inspect the objects that are present when you run your code.
This means one can create a utility that can generate a dump of those objects as ready to use mocks (or close enough, hopefully). Those mocks would span the entire scope of the program run, and this would help greatly in building an extensive test coverage.
Because lazy is good, I was wondering if such a utility is currently available.
Best regards

I don't know of a way to do this from a memory/heap dump or from debug mode but...
If you want to serialize arbitrary java objects to and from files for use in tests then you can use XStream to do so. You could then use them in your unit tests with ease.
You can also use standard Java serialization if your objects are all serializable.
To collect the data in the first place you can create an aspect using AspectJ or Spring-AOP or similar. I've done something similar in the past and it worked really well.
One word of caution though: If you are doing this then any refactoring of your objects require refactoring of the test data. This is easier with XStream as it's XML files you are dealing with.

How to mock a static call on a class from a third-party library

I am wondering whether it is possible with PowerMock or any other library to mock out a static call in a class from a library. The class in that third-party library makes a call to one of the classes in the rt.jar and I want a return a custom implementation of that returned Type. I am trying to do this outside of test code.
Otherwise, I had to extend a few classes from that library and replace some implementation. Has someone done anything like this before?

Yes it is possible, e.g. using PowerMock.mockStatic() or PowerMock.mockStaticPartial() if you want to mock one method, only.
There is a quite good tutorial on the homepage of PowerMock.
I posted an example on SO.
[EDIT] IF you want to do such magic in production code, however, I would recommend NOT to use a Testing-Framework. Maybe Groovy can help you with that - it is possible with Groovy to manipulate classes (even JDK classes) at runtime, and it is (I think) a thinner layer on top of the JVM.

Generally speaking it's really bad idea to do such hardcore stubbing (it's not mocking what you describe). I'd go with building tiny abstraction over this library so that you can have full control on what you want to return. It is possible to use some features of PowerMock outside tests but this not piece of cake. Here you have rough description that can help if you really want: https://groups.google.com/d/msg/powermock/SMDMe-y6fLg/1HF0TsGOqTIJ
Anyway I would not recommend doing that.

Is there a way to listen to another class' method execution?

Is it possible to listen to a method execution of an instance or all instances of a class, without modifying their code ?
Something like:
someInstance.addMethodExecutionListener('methodName', handler);
SomeClass.addMethodExecutionListener('methodName', handler);
It would be for logging purposes...

What you're asking about is a small subset of what you can do with Aspect Oriented Programming. It's not supported in plain Java and its implementations, but it's the central reason for AspectJ.

Depending on the environment you could use different technologies. Spring provides Aspects that you can bind to certain events (e.g. method execution).
If you are in a Java EE container managed environment you can use Interceptors for EJBs or SoapHandlers for Web Services.

One approach is to use the tooling API, JVMTI (replaces the separate debugging and profiling APIs).
Otherwise, you could rewrite the class files to insert your code before the method code. It's not necessarily easy. ASM is good for bytecode manipulation at a low level, but you might want to use some library (or write your own) or possibly use some "aspect" tool.
Bytecode can easily be rewritten "on disc" before loading, or at runtime using the instrumentation API and -javaagent: on the command line.

Java: Locate reflection code usage

We have huge codebase and some classes are often used via reflection all over the code. We can safely remove classes and compiler is happy, but some of them are used dynamically using reflection so I can't locate them otherwise than searching strings ...
Is there some reflection explorer for Java code?

No simple tool to do this. However you can use code coverage instead. What this does is give you a report of all the line of code executed. This can be even more useful in either improving test code or removing dead code.
Reflections is by definition very dynamic and you have to run the right code to see what it would do. i.e. you have to have reasonable tests. You can add logging to everything Reflection does if you can access this code, or perhaps you can use instrumentation of these libraries (or change them directly)

I suggest, using appropriately licensed source for your JRE, modifying the reflection classes to log when classes are used by reflection (use a map/WeakHashMap to ignore duplicates). Your modified system classes can replace those in rt.jar with -Xbootclasspath/p: on the command line (on Oracle "Sun" JRE, others will presumably have something similar). Run your program and tests and see what comes up.
(Possibly you might have to hack around issues with class loading order in the system classes.)

I doubt any such utility is readily available, but I could be wrong.
This is quite complex, considering that dynamically loaded classes (via reflection) can themselves load other classes dynamically and that the names of loaded classes may come from variables or some runtime input.
Your codebase probably does neither of these. If this a one time effort searching strings might be a good option. Or you look for calls to reflection methods.

As the other posters have mentioned, this cannot be done with static analysis due to the dynamic nature of Reflection. If you are using Eclipse, you might find this coverage tool to be useful, and it's very easy to work with. It's called EclEmma

Why the RetentionPolicy for #deprecated is RUNTIME?

Why at runtime is anyone interested in knowing that a method is deprecated? Can some provide me with some examples?

There are some frameworks and tools that instantiate objects to work with them.
For example, many JavaBean UI editors create instances of the beans and interact with them as the user manipulates the UI they're designing.
Having the #Deprecated annotation available at runtime allows tools such as this to flag deprecated methods, events, properties for the user.

You're assuming that #deprecated is only of interest in the compile phase (IDE, compiler), but its not a stretch to imaging instrumentation scenarios where you require that information.
For example, an IDE can inform you of the number of call sites for a deprecated method, but how would you go about determining the percentage of time your application spends in deprecated methods?

One's runtime is another one's design time, e.g. when writing code that uses an API.

Good question, and I'm stretching to come up with a convincing scenario. All I've got is that I could imagine a application which used a classloader which didn't allow the use of deprecated code. This would require RetentionPolicy.RUNTIME.
That's all I've got...

Couple practical uses that come to mind:
With Velocity you can have a custom Uberspector which logs the actual calls from Velocity templates to any deprecated method and then just by reading the log you can see where the method is used and you can go and edit it out.
With Wicket you can have a security policy which disallows instantiating any class based on the .class contents so it could be possible to make a system which prevents the instantiation of #Deprecated classes if you're not an admin.

Imagine you compile MyClass.class with deprecated methods. If your #Deprecated annotations got lost, your IDE or compiler couldn't warn you when you call those methods from another class.