I have a jar file. I want to know which external classes and methods are used by classes inside JAR file. Can anyone suggest me any tool?
For example - if below two classes are packaged into Myjar.jar
import java.util.Vector;
class MyJarClass{
public static void main(String args[]){
Vector v = new Vector();
AnotherClass another = new AnotherClass();
v.addElement("one");
another.doSomething();
}
}
class AnotherClass{
void doSomething(){
}
}
When I supply that JAR to a tool - the tool should show java.util.Vector and Vector.adElements() are from external source (not present in MyJar.jar)
Forgot to mention, i don't have access to sourcecode.
Easy
import com.example.*;
Possible
List<com.example.MyType> = new ArrayList<com.example.MyType>();
A challenge
Class<?> clazz = Class.forName("com.example.MyType");
Mission impossible
List<String> classes = getClassNamesFromUrl("http://example.com/classes.txt");
for (String className:classes) {
doSomethingWith(Class.forName(className));
}
I support Jon's advice to look at the byte code (BCEL) but just be aware, that in general it is not possible to read all dependencies from a jar, as they can be dynamic and defined outside the library (see: Mission impossible).
Hard to tell if there's a tool, have a look at those directories on java-source.net:
Open Source ByteCode Libraries in Java
Open Source Code Analyzers in Java (has some applications to work on jars too, like JDepend. JarAnalyzer sounds promising too, but it is quite old, last update in 2005)
Further reading
How can I visualize jar (not plugin) dependencies? (especially VonC's answer)
You might want to look at BCEL, which will allow you to parse the class files and find out what they use. I expect it'll be a certain amount of effort though.
Check untangle
It's a small cli utility that searches usages of class or packages inside jars or directories containing classes.
Disclaimer: I'm the author of untangle
Check JDepend
The graphical user interface displays the afferent and efferent couplings of each analyzed Java package, presented in the familiar Java Swing tree structure.
JavaDepend could help you for such needs, you can for any code elements get all elements used, it can be jar, namespace, class or method.
CQL an SQL like to query code base gives you more flexibility to request any info about your code.
Related
I have a CompilationUnit that contains a class where a reference to another class is not imported.
Eclipse resolves that kind of issue easily and proposes to import the missing class (which is located in the parent package).
How can I import a missing class programmatically without knowing its name or location so that in the resulting Java class source file, the import appears like that : import com.foobar.missingclass.
Thanks.
EDIT 1 :
To respond to some remarks : Reflection, injection, ClassLoader and other runtime mechanisms are not the right choice as I'm processing the classes statically through the Eclipse JDT API.
Please, I'm just looking for a static oriented solution.
FYI : this how we list the imports from a CompilationUnit :
List<ImportDeclaration> existingImports = aCompilationUnit.imports();
Reference.
The problem is that I don't know how to generate missing ImportDeclaration.
Thanks.
Quoting my own answer in the JDT forum:
For manipulating the imports of a Java file please see class org.eclipse.jdt.core.dom.rewrite.ImportRewrite: the javadoc outlines its usage.
If all you have is an unresolvable simple name, utilities like ASTResolving.guessBindingForTypeReference(node) come in handy.
If that doesn't work for you, you may have to use the org.eclipse.jdt.core.search.SearchEngine and somehow cope with potentially many matches for a given simple name.
Let me just add: if creation of an ImportDeclaration is your only problem then use aCompilationUnit.getAST().newImportDeclaration(), but using an ImportRewrite is much more powerful as it directly produces the TextEdits needed for updating the file.
You can use a library like Reflections so search through your classpath for any suitable classes. Of course, if you have more than one class with a given name, you have not much choice but to guess (according to the context) or ask the user.
You can use the ClassLoader to do just that. See :
example as http://docs.oracle.com/javase/7/docs/api/java/lang/ClassLoader.html
ClassLoader loader = new NetworkClassLoader(host, port);
Object main = loader.loadClass("Main", true).newInstance();
I am currently learning about Reflection and I have seen most of the similar posts to my question on stack however, I don't feel they fully answer my question on it.
I want to know if I have a package in Eclipse can I use Reflection to iterate through the classes in the package to find which one implements interface. There is only 1 interface so either they implement it or don't.
Could anyone provide a basic clear example as to how I may go about this? I have been told by some that this is just not possible whilst other people say it is possible using Reflection.
Thank you to any one who could help clear this matter.
Reflection API does not provide directly facility to iterate over classes in specific package. It concentrates on discovery of class once you have it.
To achieve what you want to have to read the class path of your application, iterate over the class path, open jars and go into directories, find files that end with *.class and get them as resource like getResource(full_class_name) or get it directly as class using Class.forName().
This method has a limitation: you will not see classes loaded by custom class loaders.
Unless this is an exercise I'd recommend you to use Reflections library that does everything you need and (probably) even more... :)
Some more details
Java system property "java.class.path" contains class path of your application separated with ; on Windows and : on Unix.
So, this is the way you can get list of class path elements:
System.getProperty("java.class.path").split(File.pathSeparator)
Here is some code sample that can help you to start:
for (String cpElement : System.getProperty("java.class.path").split(File.pathSeparator)) {
File cpFile = new File(cpElement);
if (!cpFile.exists()) {
continue;
}
if (cpFile.isDirectory()) {
findClassesInDirectory(cpFile);
} else {
findClassesInArchive(cpFile);
}
}
Etc, etc. I am leaving implementation of findClassesInDirectory() and findClassesInArchive() for you. Nice exercise. Have fun.
have you heard of guava-libraries for Java.
They provide useful utilities regarding reflection.
For your specific problem, I would have a look a the TypeToken and the method getTypes().
Good luck
yes you can so it. But with eclipse its more of an AST tree translation and not reflections. See if you want to iterate over source code and see which source file implements the interface you probably need AST tree walkers to do that. But on the other hand if you want to introspect at runtime the class files in a given package or a folder which implement the said interface then you need Reflections to do that. Either way its doable. I cant give you the code to try that out as a little time with Google will give you the answers you need though not all at the same place.
Reflection does not provide all operations for a total inspection.
For a known class one can get the physical URL of a class SomeClass using:
CodeSource codeSource = SomeClass.class.getProtectionDomain().getCodeSource();
if (codeSource == null) {
// Run-time class; URL into the rt.jar.
} else {
URL url = codeSource.getLocation();
// "file:/.... /classes/.../SomeClass.class"
// "jar:file:/... /someJar.jar!/.../SomeClass.class"
}
For Java run time classes (rt.jar) codeSource will be null.
On the URL of the jar you can open a (zip) file system, and walk through folders as any real file system.
You'll probably want to inspect classes without $ in the name (embedded, generated anonymous classes): only fileName.matches("[^$]+\\.class").
Frustrated with the damn awful API provided by WebSphere Admin Server, I'm writing my own Java DSL wrapper. My jython files now simply read:
from my.package import MyDSL
config = MyDSL(AdminConfig, AdminTask)
config.goGoGadgetSkates() # or something like that
The essential part is that I send through the (#%$$!##) god objects AdminConfig and AdminTask so that the DSL can use them to perform operations in WAS.
In order to compile the DSL I need to include the class files for this two objects. I find them by first setting the constructor as:
public MyDSL(Object a, Object b) {
System.out.println(a.getClass());
System.out.println(b.getClass());
}
The output showed that the AdminConfig object is an instance of com.ibm.ws.scripting.AdminConfigClient. I easily located the jar that contains this class and all is well.
But AdminTask is an instance of com.ibm.ws.scripting.adminCommand.AdminTask. Despite being present at runtime, this class does not exist anywhere in my classpath or indeed anywhere on my computer's hard drive.
I can only assume com.ibm.ws.scripting.adminCommand.AdminTask is constructed magically by WSAdmin in the jython layer. Perhaps it is defined as a python class?
Before I resort to reflection, can someone please explain where com.ibm.ws.scripting.adminCommand.AdminTask might live and how I might extract a copy of the class file?
The AdminConfigClient class is not API/SPI, so you are creating a fragile infrastructure by relying on that class. The API/SPI entry point is ConfigServiceFactory.
The AdminTask object is backed by the data in CommandMgr. It should be possible to use CommandMgr to do anything you can do with AdminTask.
As everyone knows - public java classes must be placed in their own file named [ClassName].java
( When java class X required to be placed into a file named X.java? )
However, we are auto-generating 50+ java classes, and I'd like to put them all in the same file for our convenience. This would make it substantially easier to generate the file(s), and copy them around when we need to.
Is there any way I can get around this restriction? It seems like more of a stylistic concern - and something I might be able to disable with a compiler flag.
If not, what would you recommend?
Can you put wrapper class around your classes? Something like:
public class Wrapper {
public static class A {...}
public static class B {...}
....
}
Then you can access them via Wrapper.A, Wrapper.B.
At the .class level, this is a requirement per the Java spec. Even the inner classes get broken out into their own class file in the from Outer$Inner.class. I believe the same is true at the language level.
Your best bet is to generate the files and make your copy script smart. Perhaps generate them and zip them up. Usually, if you have to move these files around then either everyone has the same generator script OR you distribute them as a JAR.
Is there any way I can get around this restriction?
You can change your generated source code to make it acceptable; e.g. by using nested classes, by putting the generated classes into their own package.
It seems like more of a stylistic concern - and something I might be able to disable with a compiler flag.
It is not just a stylistic concern:
The one file per class rule is allowed by the Java Language Specification.
It is implemented by all mainstream Java compilers.
It is implemented by all mainstream JVMs in the form of the default classloader behavior.
It is assumed by 3rd party Java tools; e.g. IDEs, style checkers, bug checkers, code generation frameworks, etc.
In short, while it would theoretically be legal to implement a Java ecosystem that didn't have this restriction, it is impractical. No such compiler switch exists, and implementing one would be impractical for the reasons above.
The nested class solution is a good one. Another alternative would be to put the generated classes into a separate package (but with separate file) to make them easier to manage.
I want to replace calls to a given class with calls to anther class within a method body whilst parsing compiled class files...
or put another way, is there a method of detecting usages of a given class in a method and replacing just that part of the method using something like javaassist.
for example.. if I had the compiled version of
class A { public int m() { int i = 2; B.multiply(i,i); return i; } }
is there a method of detecting the use of B and then altering the code to perform
class A { public int m() { int i = 2; C.divide(i,i); return i; } }
I know the alternative would be to write a parser to grep the source files for usages but I would prefer a more elegant solution such as using reflection to generate new compiled class files.
Any thoughts ?
As #djna says, it is possible to modify bytecode files before you load them, but you probably do not want to do this:
The code that does the code modification is likely to be complex and hard to maintain.
The code that has been modified is likely to be difficult to debug. For a start, a source level debugger will show you source code that no longer corresponds to the code that you are actually editing.
Bytecode rewriting is useful in certain cases. For example, JDO implementations use bytecode rewriting to replace object member fetches with calls into the persistence libraries. However, if you have access to the source code for these files, you'll get a better (i.e. more maintainable) solution by preprocessing (or generating) the source code.
EDIT: and AOP or Groovy sound like viable alternatives too, depending on the extent of rewriting that you anticipate doing.
BCEL or ASM.
I recently looked at a number of libraries for reading Java class files. BCEL was the fastest, had the least number of dependencies, compiled out of the box, and had a deliciously simple API. I preferred BCEL to ASM because ASM has more dependencies (although the API is reputedly simpler).
AspectJ, as previously mentioned, is another viable option.
BCEL is truly simple. You can get a list of methods in three lines of code:
ClassParser cp = new ClassParser( "A.class" );
JavaClass jc = cp.parse();
Method[] m = jc.getMethods();
There are other API facilities for further introspection, including, I believe, ways to get the instructions in a method. However, this solution will likely be more laborious than AspectJ.
Another possibility is to change the multiply or divide methods themselves, rather than trying to change all instances of the code that calls the operation. That would be an easier road to take with BCEL (or ASM).
The format of byte code for compiled Java is specified and products exist that manipulate it.
This library appears to have the capability you need. I've no idea how easy it is to do these transformations reliably.
If you don't mind using Groovy, you can intercept the call to B.multiply and replace it with C.divide. You can find an example here.
It's much easier to perform these operations ahead-of-time, where the executable on disk is modified before launching the application. Manipulating the code in memory at run time is even more prone to errors than manipulating code in memory in C/C++. Why do you need to do this?