We need a cross platform solution for compressing files. Our server runs on Windows XP/Vista/7 and 3 Unix distros, SunOS, HPUX, and AIX. Our server creates files that needed to be zipped before being set back to the client. Our initial thought was to compress the files with jar, as most of the servers have java installed, but apparently jar isn't included in the jre, just the jdk. Our server is written in C and the application that needs to create a compressed file is Perl.
I'd really like something I don't have install as our install base is LARGE and adding new required applications is generally difficult. Is there anything that is guaranteed to be built into each of those OSes that I could use for zipping? Even if I have to use something different for each, that would probably be okay also.
If you don't want to have to install anything you're pretty much SOL. Windows doesn't make this easy.
If you want to write something yourself java.util.zip is in the Java 2 Standard Edition (J2SE) and Perl has Archive::Zip
I do like 7-zip a lot but for situations like yours I always go to least-common denominataor: ZIP. Simple old ZIP. Most Unices and linuxes have zip and unzip. And for windows there are lots of options, including 7-zip, that can manipulate zip files. And probably the clients will have a zip client installed.
You could always consider distributing an open source compression tool or even using a compression SDK as part of your app such as 7 ZIP's
If you have Java installed (no matter JRE or JDK), you can use the pack200 and unpack200 to create and unpack the archives. Pack200 uses gzip compression which is pretty standard.
You should note that pack200 doesn't allow to compress multiple files in one archive (nature of gzip). If it's required, you can implement your own tool in pure Java that will create zip files and run anywhere with the unified command line interface (Java has built-in zip support, see some samples).
If you go that route, you can also use the native java implementation of bz2 or 7zip formats to get better compression.
Related
Maybe the question sounds a bit strange...
I would like to distribute my Java application.
I know how to generate a jar file, but it only includes my classes.
What if the user does not have java installed on its computer ?
So what I would like to know is how to include the JVM in my JAR file. Or find the equivalent correct way of doing this.
I found almost nothing about this so I'm probably asking the wrong question...
Many thanks !
You can't include the JVM in the JAR file. You can, however, put the JRE in your distribution next to the JAR file - assuming you know what platform (OS, processor) the distribution is intended for. On how to do that, you can read here.
You do not know anything about client computer architecture, you can't provide common JVM for all types of computers (it depends on OS and processor).
It is not possible, you can easily distribute application, but not virtual machine itself.
You may use some application packager like Launch4j that includes a test for installed Java on the host and if needed forward user to Java download/install page.
Your use case is covered by the readme file. You can and you are allowed to distribute the Java Runtime along your application (jar). It is a question how to start then your app accordingly to the OS.
I've made an application in Java, and I've converted the application jar file to an .exe using software to prevent extraction, since we know that JAR files can be easily extracted and de-compiled.
Can anyone please tell me whether converting the .jar file to .exe is safe enough for distributing to any clients.
Nothing is 100% safe. Converting jar to exe you are killing the super important java feature: cross-platform. Exe file is not cross platform any more. It is created for specific platform (e.g. MS windows).
If you want to prevent your code from reverse engineering use obfuscation: the process that changes your byte code so that it probably can be decompiled but it is extremely hard to understand it after de-compilation. If you want more security you can download parts of your code at runtime and run them. The downloading can be done using SSL, so it will be very secure. You can also create your custom class loader and run against password protected zip file.
So, there are a lot of ways to protect your code and creating exe file is the weakest one.
Well, there are two kinds of EXE generators:
Ones that attack a minimal JRE to your JAR file
Ones that convert your code to native code
well both are harder to decompile that pure JAR file, but 2nd ones are more secure.
Well as far as I know native compilers are all commercial, so if you need a free converter, you just have 1st option. In that case I recommend you to use a (non flow) obfuscator (such as yGuard) first, and then convert the obfuscated JAR file to EXE.
Can anyone please tell me whether converting the .jar file to .exe is safe enough for distributing to any clients?
No, it isn't. Obfuscation can make it a little harder.
Is there any way to process/read/write ARJ compressed file in java without extracting to some directory ?
7-zip has Java bindings for its c++ apis.
Have a look at http://commons.apache.org/compress/ if you want to stay within a JVM and not rely on native apps
On a recent question, I got comments asking whether I was using "native code" in my application. Now, I know that there is some way to call code in traditional binary libraries (DLLs, SOs) from inside a Java application using a thing called "JNI". I have read that Wikipedia entry but I never used this.
I am using a number of libraries, some of which may or may not use native code. How do I find out if they do? I did not have to install any SOs (running on Linux), but I guess that doesn't mean the libraries are not using any? Do I have to browse through all the documentation (which varies greatly in quality between libraries) or can I do some analysis on the JARs?
Usually using libraries that require JNI requires some additional setup (like putting .dll or .so files in the right places or setting the java.library.path System property).
If you did nothing of that, then chances are that you're not using JNI anywhere. This is also somewhat likely, as only quite specialized libraries require JNI.
However there's also JNA, which is a wrapper around JNI which simplifies its usage and which sometimes makes it unnecessary to do any explicit setup. If that's used by one of your libraries, then it's harder to detect.
If you get a crash dump, then checking that for any non-standard libraries can give a hint if a user-loaded native library is to blame.
To nitpick, every single Java application uses JNI indirectly at least. For example, System class contains several native methods, which map to the native JRE (as can be seen from its source code).
Whether your program/libraries use (directly or indirectly) some other native functions than those contained in the standard JRE, is indeed hard to detect. The .dlls / .sos may be packed into the .jar, to be extracted only when needed, so not having to install native libraries doesn't guarantee that it doesn't use any. It should usually be stated in the library documentation, though, because the vendor probably won't provide binaries for every imaginable system that Java runs on. But to be sure, I think the only way is to scan through the source code for native methods.
If a java library (jar) uses a native library (dll on Windows or so on Linux) the chances are that it is a system wide and well known library (such as glibc on Linux) or a custom one. In the last case it is common to pack it within the jar, so you can just open it up with a ZIP decompressor (i.e. 7zip on Windows will do fine) and browse the files. You should see dll files if it is targeted to Windows, so files if targeted to a Unix platform, or even both. The native library files usually are left at the root level of the jar.
If the jar uses custom libraries but it is packed along with an application it is common to leave the native libraries in an external folder with other application files (in this case there is no consensus). In this case you should look for the application launcher (a bat / sh file) or the configuration file if the lanucher is binary (an ini / conf file) and find out the JVM configuration (where java.library.path points to).
Probably the easiest way of doing this is using jmap or pmap to show which .so (shared object) files are mapped into your Java process. If there's anything other than stuff that's in /lib, /usr/lib or the Java lib directory it's a JNI suspect. You can also look at the /proc entry for the Java process under /proc/<pid>/maps. See the following manpages:
http://linux.die.net/man/1/jmap-java-1.6.0-openjdk
http://linux.die.net/man/1/pmap
http://linux.die.net/man/5/proc
My need is to copy some of the zipped files from remote location to my machine and then unzip it in specific location. By which way it can be achieved in fastest way? Are there any open source tool already available for that? I know about Robocopy, but is there any other tool also, better than Robocopy?
I'm using windows xp operating system. I have to do this inside my eclipse application, so I need the tool or any plugin which I can easily incorporate in my eclipse application.
Thanks a lot in advance!!!
Related to adarshr's answer, you could use the Apache Commons IO or NET projects (see http://commons.apache.org/). Or if you want something with paid support you could use JScape. These are Java API's that allow you to do IO and FTP'ing. Then you could use either the java.util.zip classes for zipping/unzipping, or the Apache Compress project.
Any of these options gives you flexibility at the Java programming level.
You probably need an FTP client such as Filezilla.
For working with remote files from within eclipse, take a look at the RSE (Remote System Explorer) Plugin