Using reflection you can get pretty much everything relating to a class. You can get all the declared methods, fields and classes (and possibly even more), but i couldn't find a way to reflect on a method so i could find out what classes that method might be using.
Essentially i would like to find out all dependencies to other classes that a given class has.
Example:
Given the following code:
import com.yada.yada.yada.SomeClass
public class MyClass
{
public MyClass
{
new SomeClass();
}
}
How can i find out that MyClass is using SomeClass in its constructor?
I was trying to think of a way to get all import statements defined in a class file but i couldn't find anything that way either. But, assuming there's a way to somehow dig up all import statements defined in a class file, how would one find out about classes defined in the same package, which do not require an import statement?
EDIT:
Scenario: The goal is to send the bytecode of this class (MyClass) to another process. This other process then takes in the bytecode and loads the class (MyClass) using class loaders, and so on. The problem is that when i try to create and run an instance of MyClass in the other process it fails because it cannot find a definition for SomeClass.
If SomeClass were a member of MyClass it wouldn't be a problem but since the only reference to it lies in a method, there's no way to get to it via reflection?
I think the closest you can come to getting all of a class's dependencies is by hooking into the class loader mechanism and recording what classes get loaded when the class you're examining is instantiated and its methods are called. Of yourse, you'd transitively also get all the classes that it indirectly depends on, but depending on what you want to do with the information, that may be what you actually need.
But it's impossible to do for all cases (just imagine a method that uses Class.forName() to ask for a random class name every time it's called).
how would one find out about classes defined in the same package
That's actually impossible to do in general, since the class loader concept really only allows asking for a fully qualified class name, and either getting that class or a ClassNotFoundException. Classes can be loaded from a webserver (in the case of applets) or generated on the fly, so you cannot know whether a specific class exists except by asking for it.
You can't (unless you decompile the bytecode). A local variable is not tied to any class instance, and it does not even exist for most of the lifetime of the class or its instances, so you can't access it via reflection.
What are you trying to achieve? Maybe if you tell us about your actual problem, rather than a perceived solution, we are better able to help.
Reflection does not help you here. The only way I can think of that you can achieve this is through a byte code tool like asm.
Create a ClassVisitor that gathers dependencies from
Class declarations
Annotations
Local variable declarations
Field declarations
Method declarations
Method invocations
(have I forgotten anything?)
Related
I am trying to write tests for a piece of code that uses the inner class of the following object as an input (I've generalized the names).
public class MockOuterClass implements OuterClass, Mock {
static class MockInnerClass implements InnerClass {
//fields and methods of the nested class
}
//methods of the outer class
}
Now since the inner class does not have a visibility tag, it defaults to "protected." Here lies my issue: since my tests and source code are in separate packages, how can I create an instance of this inner object? I attempted this:
MockOuterClass.MockInnerClass test = new MockOuterClass.MockInnerClass();
When I do this, Eclipse says that this line is unacceptable (which I assumed was the case, but it was wishful thinking) since MockInnerClass defaults to protected and thus cannot be used outside its package. Is there a way I can use this class somehow? I did not write the source code, so I am unsure if the lack of a "public" tag on the inner class was intentional or the programmer's mistake.
Thank you in advance.
A bit of an aside, not an actual answer, but I have always put my tests into the same package as the classes being tested. At least, as much as possible, there are a few very rare cases where this is impossible.
Why are you using a different package? Is there a good reason to do so?
Now, back to an answer, if you insist on testing from a separate package, unless MockOuterClass exposes some method to construct (or expose) the MockInnerClass, you are stuck. (I guess you could try using Reflection but that is getting desperate.) However, as several have commented, the author of the class "intended" for the inner class to be hidden, a. la. Kent Beck.
In other words, if you follow Kent Beck, you should be writing tests that target MockOuterClass, NOT MockInnerClass. The inner class is a "non public detail".
If this code wasn't written by you and declares a non-public static class (side-note: it defaults to package-protected, which is very different to protected), chances are the writer intends to hide the class from your use. In short, there is no way to access the class from outside the package, and you probably shouldn't be trying to.
I've just discovered about the existence of the Method class in Java.
Is an instance of this class equivalent to an instance of a Command class in the context of the Command design pattern?
If not, what are this class' practical uses?
Is an instance of this class equivalent to an instance of a Command class in the context of the Command design pattern?
No, absolutely not: Method class is part of reflection feature of Java. Command pattern, on the other hand, is language-agnostic, so it can be implemented in any language, including ones that lack reflection capabilities.
The practical use of the Method class is to access methods of classes to which you do not have access at compile time. You can load a class by name, grab its method object - also by name, and perform an invocation.
With this said, it does not mean that you couldn't implement something that behaves like the command pattern using reflection. In fact, you could make your implementation more flexible by eliminating compile-time dependency on your code. For example, you could build a system that take plugins, and requires that plugin classes implement a particular method. Rather than shipping to plugin writers an interface with the signature of the method, you could tell them that as long as their class implements the method that you need, the plugin is going to be accepted. At runtime you would be able to discover the proper method through reflection, and call user code without compile-time dependencies on either side.
This class, as well as the class Field, class Class, are all part of reflection API. This API is used to provide access to object in an indirect way.
The first idea behind reflection was to allow an object to describe itself. For instance an IDE could display all properties of an object for debugging, RAID development and so on.
If reflection is still used that way, it's also used today to discover dynamically the structure of an object or a class and "act on" it without explicitly knowing it : to change the values of its fields or invoke one its methods.
For instance, if you know class A, you can invoke the method m() of A this way :
A a = new A();
a.m();
With reflection, without knowing class A explicitly, you could :
Object a = A.getDeclaredConstructors()[0].newInstance();
Method m = a.getClass().getMethod("m");
m.invoke(a, null);
In the second case, you can imagine a more generic mechanism where you discover methods or fields and invoke them or change their values without knowing them in advance.
So, to answer directly your question, it has nothing to do with the Command design pattern.
I tried to instantiate a class that was declared with default access, in another package reflectively and received this error:
Class IOTest can not access a member of class com.BinspireD.core.model.DataNodeImpl with modifiers "public".
It this possible (to instantiate a class using reflection in a different package, with package private access)?
How would I properly go about it?
Thanks
The usual solution to these types of problems is as follows:
Think long and hard about what you're trying to do. Is it really necessary?
Chastise yourself with a small flail if you decide that it is.
Cheat. Check out the Javadoc for java.lang.reflect.AccessibleObject.
I have a tricky question and I'm not sure if it is even possible in Java. I'm in the following
situation:
I got a class A that uses another class, let's call it B. Now, I'm trying to write a third class (and I don't call it C), I call it B again (to be sure which class 'B' I mean, I will call it B1 and B2 in the rest of this post, ok?). All three classes resides in three different JAR-files. So far, so good.
Normaly, class A finds class B(1) on the classpath and will use it. But now I'm putting the JAR-file that contains B(2) at the very beginning of the classpath, so class A will find this class instead of the old one. So my class B(2) can act like the old class B(1) (which is a library in reality, that I can't customize in any other way. that's why I am doing that...).
And here comes my problem: In my class B(2) I want to load the real class B(1) and use it. I can do this so far by using reflection. I can even invoke methods via reflection, but I can't cast an instance of the loaded class to B reference. Here is the exception:
java.lang.ClassCastException: my.a.ClassB incompatible with my.a.ClassB
Has anybody an idea how I can use class B(1) in class B(2)? I am happy with any workarround...
Thanx, Thomas.
You can only do this through reflection.
As far as the runtime system is concerned, your two ClassB classes are complete separate entities and cannot be cast to each-other.
This sometimes happens in OSGi environments (which have complex classloader setups) or if you somehow manage to pass data between web application contexts.
If you want a common interface to call methods on both without reflection, then you need to create just that: a common interface (or parent class). And that interface needs to reside in a jar file that both these ClassB can see.
Example:
first jar: interface I
second jar: class B implements I
third jar: class B implements I
Now you have two versions of class B, but they can both be cast to I.
Needless to say, you should find a better solution to whatever problem you have here.
Maybe you can use CDI to #Inject the desired class into class A. Doing so helps you to mock classes and provide alternatives. See also the #Alternative annotation of CDI. Basically you are using the interface methods, the implementation behind it is chosen at runtime or injectione time, resp.
I'm writing a functionality where it would be helpful to get the classes inside a certain package of my program. Also, I only want the classes that subclass a certain class.
I need the classes in order to call static methods on them.
Is there an automatic way to do this? If so, is it slow?
In case I was not clear, what I want is something like this:
ArrayList<Class<? extends MySuperClass>> classes = ;
classes.add(MyClass.class);
classes.add(MyClass2.class);
Instead of having to call add for each class, I would like to automatically get that class list.
The number of classes is small, so I would not mind declaring them manually if the automatic trick would be slow - this app is for a mobile platform.
In either way, I would also like to know how to call the static method for each method in the ArrayList:
// error The method nameOfStaticMethod is undefined for the type Class<capture#2-of ? extends MySuperClass>
classes.get(0).nameOfStaticMethod ();
Thanks for your comments.
Java doesn't provide this ability. There is no introspection at the package level. The classes could be records in a database, or on the other side of a network connection. There's no requirement for them to be stored and organized so as to facilitate enumerating them by package.
You could make a custom class loader and API to provide a method of listing the class names.
I too would like to list all classes in a package but so far the methods of doing this is pretty bad:
Like JOTN suggested - needs file access - not if it is a jar
Listing a JAR entries - well, also needs the jar file
Quoting a older SO question:
It isn't possible to query a Package for it's Classes (or even its subpackages). http://forums.sun.com/thread.jspa?threadID=341935&start=0&tstart=0 contains a very good discussion about why this is problematic, as well as a handful of solutions to your problem.
Anyways, here is how you invoke static methods on the class:
Method m = Integer.class.getMethod("toString", Integer.TYPE);
System.out.println(m.invoke(null, 123));