ExifTool (for Java) is designed for a simple and robust Phil Harvey ExifTool Java abstraction. I just made my first public release last week after incubating the project under the umbrella of the imgscalr project for a while.
The project is under the commercial version of the Apache 2 license.
My goal for the library is not only to abstract the external code of the process from the caller (like most other layers of abstraction), but to actually create a shell, so tight integration and stability (I will clarify what I mean here later) that you handle instances of your ExifTool class in the same way as if ExifTool itself was written in Java.
In this initial release, I support reading tag data (add an entry to a future version), and it will be so simple:
File image =
Using ExifTool in the new daemon mode (-stay_open True cmd line) is also supported, and supporting it is as simple as creating an ExifTool instance:
ExifTool tool = new ExifTool(Feature.STAY_OPEN);
The documentation on how to use the ExifTool class is extensive, covering everything from design to performance to thread safety.
In addition to simply using ExifTool with Java, the class uses a significant number of precautions to minimize run-time problems, as well as to correctly catch and report any and all errors that may occur in well-documented ways (instead of surprising exceptions, go out of the main Java classes).
I was so pedantic with this exception handling and error recovery, because the class is designed to allow you to use ExifTool in a highly accessible environment such as a busy web application. I didn’t just want to wrap the simple objects of the Process, and then raise my hands up if something exploded. I knew that myself (and anyone else using the class) needed a well-developed API that made it easy to recover errors.
For example, an attempt to use ExifTool in daemon mode will cause the class to actually verify the ExifTool base installation to support this function and throw an UnsupportedFeatureException with recommendations on how to work around the problem if it is not supported.
In addition to checking the prerequisites, to ensure that using the class (namely, in daemon mode) does not leak OS native processes, as well as the I / O streams used to communicate with them, the class provides an automatic detection that cleans up the stream, which after the specified inactivity interval (10 minutes by default) will completely disable the external process and read / write streams, making the inactive ExifTool instance easy and convenient to reuse.
All resources are reinitialized the next time the class is called to analyze more metadata, so there is no need to throw and re-create new instances. Also, the cleaning flow is performed only after long periods of inactivity, and not according to the established schedule. You can set the interval to whatever you want, or completely disable the cleanup flow and control the cleanup yourself (just call close ()).
These projects are part of my ultimate goal - to make ExifTool's integration into a Java application seamless, efficient, and simple.
You can check the project home page for more information about the project, usage, source, download links, etc., or you can jump directly to GitHub and view the code if you want.