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
I am looking for a java library which can compress files and directories.
I need the following features
-compress
-decompress
-split archives to multiple files based on a size limit
I would really like the following features as well
-encrypt archives
-encrypt file names
I would prefer if the solution was a 7zip library but it's not required.
I know there is an lzma Java sdk but i'm not sure if it supports all the features above. I know it doesn't support encryption, but does it support splitting archives?
Any library supporting all the features above would be preferred.
Thanks.
How about the Deflater/Inflater classes mentioned in the question "What’s a good compression library for Java?".
I know the current interfaces proposed by Java are Stream-based, not "filename"-based, but according to the following article on Java compression.
TrueZip should be able to do most of what you need
Is there a way to update gzip library that JRE uses?
There is a bug in gzip library that is used by latest JRE, and it has been fixed in later version of gzip library, so I would like to make latest JRE work by updating just gzip.
Bug is in a native code from gzip library that JRE uses.
Basically no (but you can probably do operating system magic to override the native library loader to include the new one).
Have you located this issue in the Java Bug Database? http://bugs.sun.com/
I think it's possible by setting the bootclasspath: http://java.sun.com/javase/6/docs/technotes/tools/solaris/java.html to override the class with the newer version.
Please read the warning: "Applications that use this option for the purpose of overriding a class in rt.jar should not be deployed as doing so would contravene the Java 2 Runtime Environment binary code license."
(Or if the bug is located in a native library, you could use java.library.path)
The short and simple answer is "no". At least you would not want to go there for all sorts of reasons.
Unfortunately Commons Compress also only uses the native compressor from java.util.zip but in your case I would still use Commons Compress so the compressor becomes easy to replace from the API point of view. Then write your own Compressor. In java if you don't need the speed or using JNI if want to really go for it. As soon as the bug is fixed in the JRE you can just switch the implementation back to the JRE one.
How can I copy files in Java using JNI on OS X?
You shouldn't use JNI to copy files. If you are looking for performance with copying a lot of files you should take a look at the new Java NIO File Channels.
You don't need JNI to copy files. The standard J2SE libraries will handle this. For a more powerful library, see Apache Commons IO FileUtils.
I need an OpenSource API in Java, which can encode *.wav and *.au formats to MP3 and vice-versa.
I have evaluated Java Sound API and LameOnJ, but they do not meet my requirements and are not stable, respectively. Please suggest one that is free and platform independent.
There may not be an adequate answer for you, yet, as the MP3 format requires the authors of decoder/encoders to obtain a license from the Fraunhofer Institute.
I think the the LAME library is distributed from a country that does not respect these IP issues, but it took a considerably amount of legal hackery to get this far.
For any other libraries - for example one written in Java, the authors need to get a similar license. Where cost is an issue - e.g. in an Open Source project, then this is enough of a disincentive to starting.
For more details see this wikipedia article.
If LAME4J is not stable enough for you, then I'm afraid your options are probably:
wait for Sun to license the format for the core JRE. This, I believe they have done recently, but I don't know of any release dates (perhaps to do with JavaFX)
implement your own in Java, and pay the license. I wouldn't fancy this one, either.
write your own Java wrapper to LAME, via JNA, or SWIG
contribute to Lame4J.
pick another format. OGG and FLAC are quite good, and relatively well supported.
Is has been some time, but Oracle/Sun has released MP3 support for JMF. This can be downloaded from the following url:
http://www.oracle.com/technetwork/java/javase/tech/index-jsp-140239.html
Adding it to the classpath will enable playback via the AudioSystem api.
The LAME4J uses the free but time-limited license and the unlimited license will cost you some money.
I've found the Lamejb library on the SourceForge, which requires only the lame binaries and works well without any additional licensing.
Use the Process API to invoke SoX
SoX comes with source or as precompiled binaries for Windows and Mac.
If you are searching a pure java version of lame, check out these sources:
http://jsidplay2.cvs.sourceforge.net/viewvc/jsidplay2/jump3r/
The Jave2 project is Java library that wraps FFMPEG and provides most of its functionality* through a rather useful Java API.
Pros:
Useful Java API that is powerful and rather simple.
FFMPEG binary is bundled in, so you don't have to manage an FFMPEG installation on your system.
Cons:
Does not support streaming data: you have to work through temporary files: every conversion starts by storing all the content in some files on the system, getting FFMPEG to create new files for you, then reading them. This is not a deficiency in FFMPEG, more of a problem in Java where it is very hard to stream data to external processes**.
*) specifically around format conversion - the filter functionality is mostly not represented.
**) In Java, launching a process and connecting to its standard output and input is possible but not comfortable, and using named pipes (the BKM for piping AV to/from FFMPEG) is almost impossible, and even if you do manage to do that, Jave2 doesn't play well with that. I have a set of tools to workaround these problems, based on JNA, if anyone is intersted - I can share.