I have a problem with finding all the external libraries that a .jar file uses. My .jar file is very big, and manually decompiling it and going through every class, checking all the used paths is impossible. I wonder if there is a way or a tool that would go through a .jar file, and list all the external paths/links to classes that are not in the .jar file?
P.S: I'm not asking "what is the best tool to do so?", I just need to know how to get all the external paths a .jar file uses, without manually decompiling it.
Try this :
Extract the jar contents
Do a directory search for *.class piped to a text file.
Filter out inner and anonymous classes. (Class files names with $)
Write a small program that will simply loop through your list and load the class definition (Class.forName() should be enough)
Run the jar with option -verbose:class piped to a text file
Once your program is completed, you will have a full list of classes loaded from respective jars in the piped file
Filter out rt.jar contents for a more cleaner list
I'm not sure if -verbose:class works with obfustcated code, logically I think it should be fine.
Related
A lot of times in Java we want to use some functionality that is given to us in the form of JARs(ex. some external library). Most often than not I've noticed that JARs contain .class files.
Since .class files represent compiled bytecode ready for use by the JVM, my question is the following:
How is it that .class files are all that's needed for us to make use of an external library? Maybe a certain JAR contains the class file called: Person.class. How am I able to reference this class in my code when all that the JAR file exposes is a .class file. Isn't the source code(.java file) what's important and what's needed? In the same way that I can have two classes in the same package, I'm able to reference one from the other, because the two .java files(not .class files) are in the same scope(just to give an example).
Excuse me if it's a dumb question, but I really want to understand this.
Even if you write your source code in .java files, they are eventually compiled to form .class files which store bytecode that can be interpreted easily. When you use the jar files in your project, all the class files inside those jar files are included in your classpath, hence enabling you to use them.
So in a JAR package, .class files are sufficient to be used as a dependency.
The Java compiler takes your Java code, which is something that humans can understand, into .class files, which is something that the Java Virtual Machine (JVM) can understand. The JVM then takes the .class files and runs them on your machine.
A .jar file is effectively a collection of .class files packaged up (under the hood, it's really little more than a .zip in disguise). When you add a .jar onto your classpath, you are telling the JVM that it is one more place it should look when it needs a particular class.
I am not sure if I totally got your question, but the JARs are simply compiled javacode, which means, that the semantic/logic etc of the code has not been changed. You need to be able to access the functions/classes etc of the java code you want to use, because otherwise you would not gain any advantage of using a JAR.
One advantage of the JARs is, that the source code of these libraries is already compiled. Since these .class files are compiled .java files, they are all you need to access the functions that were written in the .java file.
I read and searched almost everywhere, yet i have no answer.
I have a project with multiple .java files, and i need to export them as a single .jar file.
One of the main questions is based on the fact that i don't have a main class.
What can i do to go through that ? Shall i create a main but never run it? Or there's any way around?
Offtopic ( might be usefull): i want to do this in order to use the jar file in IKVM
Thank you!
You do not need a main method to create a jar. There are many such jars out there such as utilities packages. They don't contain any code that would make sense to execute on it's own since it only contains code that makes your application easier to write.
First compile your code using Netbeans or command line javac utility. This will give you .class files.
Now for creating the jar... You can simply create the jar (which is basically a glorified zip archive) by using the command-line jar tool.
jar -cvf my archive.jar myprogram/
Make sure that the file path within the jar archive match the package name of the classes. It is not uncommon to accidentally get an extra layer of directories.
You probably should have searched stackoverflow first since how-to-create-a-jar-file-in-netbeans seems to cover exactly what you're looking for.
Do you want to use the jar as a external library or a program itself?
If it will be a external library, you don't need a main class. In eclipse you can export as a jar file (select classes-> right click-> export as jar).
If it will be a program itself, then you need a main class.
You really need to create main class file, write code in function main(String args[]) which use your java classes and compile it by javac.
I have a Java application that was converted to an .exe with launch4j. For several reasons I need to get access to the class files of the application.
The first thing I tried was unpacking the exe with 7zip. That way I get a handful of class files, but definately not the whole application packed in the exe (the class files seem to belong to launch4j).
What other options are there?
You can use something like this to extract the JAR from the Launch4j executable:
http://www.nirsoft.net/utils/resources_extract.html
Typically the executable packages necessary JAR's as executable resources and then looks for a JDK on the path to execute.
Once you get the JAR file you should be able to decompile it.
You cannot get access to class files. Exes are created, So that nobody can get access to your code.
If somehow , you are able to get access to jar files then you can decompile them to get the code and make changes.
In computer science I have learned that .jar files are basically a compressed set of .java files that have been compiled. So, when you have a project, instead of those 20 .java files you can have a pile of compressed classes (a .jar). Last year in CSI we worked with a .jar file called DanceStudio, which we had to use to make feet walk across the floor. This year, we are working with a different program to better understand java, so i unzipped the .jar file contained 26 classes, which I then decompiled. I wanted to try to create a program by compiling all of the .java files with the others necessary to make the program run (Walker, Foot, ETC.) When I try to compile all of these files, it will say that I have duplicate files (Walker, Foot, ETC.) What I don't understand is why this would compile if the .jar file was basically the same thing, just in a compressed form. What also confuses me is that the Foot, ETC files in the .jar are actually more complicated and have more code.
Could someone please explain how the .jar file actually works and separates these files apart, and how it could run with a duplicate class that isn't in the .jar file?
First of all, you're missing one step in your explanation of a .jar file.
A .jar file is a collection of .class files. And .class files are what is produced by compiling a .java file.
Usually a single .java file will produce a single .class file, because it will contain a single type definition. But there are several ways for a .java file to produce more than one .class files (inner/nested classes, anonymous classes, top-level non-public classes, ...), so it's not necessarily a 1-to-1 association between .java files and .class files.
Then there's the confusion why the decompiled Java source code looks more complicated than the original Java source. This one is easy to answer: the compilation step was not designed to be reversable.
When the Java compiler turns .java files to .class files it produces a format that is best suited for being executed. That format will not represent the exact same concepts that the Java source file does. For example: there's no classical "if" in the Java bytecode. It will be implemented be appropriate jump commands.
All of this means that the process of converting .class files back to .java files is complicated and usually non-perfect.
You generally compile your (clear text) .java source files into (binary) .class files.
If you use packages, then the class files will be in different subdirectories (representing the package).
A .jar file is a compressed binary file that puts all the .classes in the right directories in one compact, easy to manage file.
.jar file can also contain other files, such as manifests, bitmaps and resources.
.jar files can also be "signed" to insure the integrity/authenticity of their contents.
Here are some good links:
http://en.wikipedia.org/wiki/JAR_%28file_format%29
http://download.oracle.com/javase/tutorial/deployment/jar/
'Hope that helps
About your duplicate: Maybe your .jar is still in your build path, so when you try to compile your project with the decompiled class, you will have duplicate. check and remove the .jar if its still in your build path.
I have a jar file which is used in html file as applet. I want to modify the content of the jar file and to rebuild the jar file so that the html will work fine with the new jar file. How can i do this??
I already tried unzipping using 7zip nad modified the source and created the new jar. But when i use it in html it shows some java.lang.Classnotfound error
You can unjar or rejar the classes and source files as you wish.
unjar
jar -xvf abc.jar
jar
jar cf abc.jar input-files
http://docs.oracle.com/javase/tutorial/deployment/jar/build.html
Make the changes in the code (.java files), recompile to get the .class files. Then simply replace the old .class files in the jar with the new ones. I usually use WinZip, but you can use whatever app that can handle .Zip files. It should just work.
I've faced cases where the launcher of the app uses some sort of verification and checks for this kind of changes. I had to use a new launch script. This doesn't seem to be your case though.
This is surely possible from the command line. Use the u option for jar
From the Java Tutorials:
jar uf jar-file input-file(s)
"Any files already in the archive having the same pathname as a file being added will be overwritten."
See Updating a JAR File
A brief test shows this quickly updates changes apart from trying to delete the file.
I haven't seen this answer on other threads about modifying jar files, and many, marked as duplicates, suggest there is no alternative but to remake the jar completely. Please correct if wrong.
JARs are just ZIP files, use whatever utility you like and edit away!
Disclaimer: When reverse engineering any code be sure that you are staying within the limits of the law and adhering to the license of that code.
Follow the instructions above to unpack the JAR.
Find the original source of the JAR (perhaps its on SourceForge) and download the source, modify the source, and rebuild your own JAR.
You can also decompile the class files in the JAR. This is a rather advanced process and has a lot of "gotchas".