I'm familiar with .Net and what assemblies are - but sadly my Java knowledge isn't as strong.
I know Java and .Net are different "worlds" (possibly like comparing apples with pears) but are JARs and .Net Assemblies roughly eqivalent concepts?
Edit: Update base on initial responses
The way I interpret this is that yes they have similarities:
Both can contain resources and metadata.
But there's some core differences:
a .Net assembly is compiled a JAR isn't.
JAR files aren't required to make a Java application; .Net assemblies are required for a .Net application.
[This isn't time for a religious war - I'd like to know if / how much of my understanding of .Net Assemblies I can apply to getting my head around Java (and maybe this will even help Java folks going the other way).]
There's a bunch of technical differences, but they are of little consequence most of the time, so basically, YES, they are the same concept.
I would say no, they are not the same concept, noting that a JAR can be used like an assembly. If you really want to get your head around a JAR file, just think of it as a ZIP file. That's all it really is.
Most often, that archive contains compiled class files. And most often, those class files are arranged in a hierarchal fashion corresponding to the class's package.
But JAR files frequently contain other stuff, such as message bundles, images, and even the source files. I'd encourage you to crack one open with the unzip client of your choice and take a look inside.
The JAR format is however the most common way of packaging a distributable for a Java library or application so in that way they are very similar.
From a language standpoint, JAR files are in no way required to make a Java application or library, nor would I say they are intrinsic to Java, however both the standard library and the JDK has support for dealing with JAR files.
At one level, they are conceptually similar (chunk of byte code in a package). However, their implementation is very different.
A JAR file is actually a ZIP file containing some metadata, and all of the Java .class files (yes you can actually open it as a ZIP file and see inside), and whatever else was packaged up in it (resources, etc).
A .NET assembly is actually a valid Win32 PE file, and can be treated as such to some extent. A .NET .exe file actually begins executing as native code which loads the framework, which then load the bytecode. "Executing" a JAR file requires launching the Java runtime through a .bat file, or file association, which then loads the JAR file separately.
Related
I am trying to develop a tool that basically analyses an Android app APK and counts the number of calls to a specific API method (e.g., android.app.AlarmManager.set())
1. What approach do you recommend?
So far I have used APKTool and now I have.smali files.
However, for the same java source, I can have multiple files:
ExportAsyncTask$1.smali
ExportAsyncTask$2.smali
ExportAsyncTask$3.smali
ExportAsyncTask$4.smali
2. What do these multiple files mean?
3. The resulting .smali files also include external libraries that I would like to leave out the analysis. How can I do that?
1. What approach do you recommend?
Yes, Apktool can be used for your task. Each java class in the APK will be represented by a .smali file in directories tree representing the packages. Smali - is the Android Virtual Machine language. The language is much simpler than Java and hence easier for analysis. In your case you should search for invoke opcodes and Landroid/app/AlarmManager;->set strings. If you are working in Linux, you can for example grep and count them. In Windows you have text editors like Notepad++ that allow text search in multiple files.
2. What do these multiple files mean?
In Java there are internal classes and implicit internal classes. The former will appear in OutherClass$InnerClass.smali and the later, having no name of its own, get numbers, like OuterClass$1.smali. You sometimes even get more deep levels like a$b$c$1.smali.
3. The resulting .smali files also include external libraries that I would like to leave out the analysis. How can I do that?
You have no precise way to do that. But generally speaking, when you look at the packages/directory tree of many samples you usually grasp the pattern. E.g. usually application code is in com.* package and android.*, org.* and uk.* include libraries. After such inspection you simply exclude those directories from your search.
Hi I'm trying to create a .jar file to include in Jmeter. Can I create a Jar where the code is written in Javascripts.
Technically, yes, you could, but it would require you to use a JVM Javascript engine like Rhino or Nashorn (supposed to be officially ready at the end of 2013). The running code in jars is contained in .class files, which are the executable "machine code" for the JVM. The most common language to write these in is Java, but many other languages can be compiled into .class files.
Javascript has essentially nothing to do with Java, and while you can use a program that runs on the JVM to run Javascript, I don't think it's quite what you have in mind. This Javascript looks basically like Java with the quirky Javascript syntax, and you still need to be familiar with the Java APIs that you're wanting to use.
I'm trying to limit changes from a jar file. I introduced a fix on the code, a very small fix in a single file. Javac compiler generates the new .class file and I plan to replace ONLY this single file in the jar (we had problems with the build and are unsure if the current build matches the production build).
I'm a C++ pro, but java... not so much. I wouldn't dare to do this in C++ as optimizers inline a lot of stuff from object files and static libs. I'm under the impression I can do this with no great consequences in java.
Any advice?
I usually hot deploy files on server, that creates no problem in JAVA. You can do it as long as your compiler version is same as the other files. It would not be a problem.
The Java Language Specification defines binary compatibility between class files. In general, class files tend to be much more compatible than they would be in C, so you'll probably be ok. However, there are a few gotchas, such as static final fields (constants) which are inlined by the compiler.
In any case, the situation in which you are not sure what code code you have running in production, I would consider to be very dangerous, and try to fix as soon as possible.
For my usecase, I would like to have an in memory directory to store some files for a very short time. Actually I compile source code to .class files at runtime, classload and execute them. The clean way would be to create a virtual directory and let the compiler create .class files there. Of course I could use a temp directory, but I have to clean it before compiling, I don't know if I'm the only one using it, etc.
So, is and how is it possible to create a virtual, in the meaning of in memory, directory in Java?
In Java 6 it is not really possible to do this kind of thing within a Java application. You need to rely on the OS platform to provide the the pseudo-filesystem.
In Java 7, the NIO APIs have been extended to provide an API that allows you to define new file systems; see FileSystemProvider.
Apache Commons VFS is another option, but it has a couple of characteristics that may cause problems for existing code and (3rd-party) libraries:
Files and directories in VFS are named using urls, not File objects. So code that uses File for file manipulation won't work.
FileInputStream, FileOutputStream, FileReader and FileWriter won't work with VFS for much the same reason.
It sounds like you could use a ramdisk. There are many apps out there that will do this, what you use would depend on the target OS. I don't know of any native Java API that supports this.
I am not sure if this is helpful or not, but do check Apache Commons VFS.
It seems that what you need is memory filesystem.
For Java7's NIO there are
https://github.com/marschall/memoryfilesystem and
http://exitcondition.alrubinger.com/2012/08/17/shrinkwrap-nio2/
So, I've been programming for a while now, but since I haven't worked on many larger, modular projects, I haven't come across this issue before.
I know what a .dll is in C++, and how they are used. But every time I've seen similar things in Java, they've always been packaged with source code. For instance, what would I do if I wanted to give a Java library to someone else, but not expose the source code? Instead of the source, I would just give a library as well as a Javadoc, or something along those lines, with the public methods/functions, to another programmer who could then implement them in their own Java code.
For instance, if I wanted to create a SAX parser that could be "borrowed" by another programmer, but (for some reason--can't think of one in this specific example lol) I don't want to expose my source. Maybe there's a login involved that I don't want exploited--I don't know.
But what would be the Java way of doing this? With C++, .dll files make it much easier, but I have never run into a Java equivalent so far. (I'm pretty new to Java, and a pretty new "real-world" programmer, in general as well)
Java .jar library is the Java equivalent of .dll, and it also has "Jar hell", which is the Java version of "dll hell"
http://en.wikipedia.org/wiki/JAR_(file_format)
Google JAR files.
Edit: Wikipedia sums it up nicely: http://en.wikipedia.org/wiki/JAR_%28file_format%29
Software developers generally use .jar files to distribute Java applications or libraries...
A jar is just a uncompressed zip of your classes. All classes can be easily decompiled and viewed. If you really don't want to share your code, you might want to look at obfuscating your code.
The Java analog to a DLL is the .jar file, which is a zip file containing a bunch of Java .class files and (perhaps) other resources. See Sun's, er, Oracle's documentation.
Java's simple moto 'Write Once, Run anywhere'. create your all java classes as jar file but there are possibilities that still some one can see the Java code by using Decompilers. To prevent someone really looking at your code then Obfuscate the jar using the below link.
Java Obfuscation
You could publish a collection of compiled *.class files.
The most common way to package up Java code is to use a ".jar" file. A .jar file is basically just a .zip file.
To distribute just your compiled code, you'll want to build a .jar that contains your .class files. If you want to additionally distribute the source code, you can include the .java files in a separate area of the .jar.
There are a lot of tools and tutorials out there that explain how to build a .jar.
Technically, you can compile Java bytecode down to native code and create a conventional DLL or shared library using an Ahead-Of-Time compiler.
However, that DLL would need the Java runtime specific to the AOT compiler, and two Java runtimes may not coexist in one process. Also, one would have to employ JNI to make any use of that DLL.
Unfortunately, obfuscation has too many weaknesses...
your tittle doesn't match your comment....
simple have a source jar and a code jar. but, as other people pointed out you can obfuscate the code if you don't want people to read it, it's a pain for other people using your library as they would need the mappings in order to compile and the obfuscator.
A dll is a shared library (from what I read gets instantiated one time across multiple processes)
A jar is a shared library (code gets instantiated per process from the same file)
So to answer your title question there doesn't appear to be one built into java. A library could be made and then supported on all 3 major os's to have a dll equivalent version in java. But, the reason why java made it a new instance per program is for security / sanity reasons. there are custom class loaders, asm and reflection that other programs can modify the classes on load. So if your program does any of these things it could mess up other processes.
You don't have to distribute your source code. You can distribute compiled .class files, which contain human-unreadable bytecode. You can bundle them into .jar files, which are just zip files, and are roughly Java equivalent of native .dll files.
Note taht .class files can be easily decompiled (although decompilers cannot recover 100% of information from sources). To make decompilation more difficult, you can use obfuscator to make sources much less legible.