Question

I am interesting in parsing the exiftool result with a java api or something like that.

I have been researching, but I didn’t find any example. For example, how could I get these results in my java project?

ExifTool Version Number : 8.22

File Name :
ExifTool.jpg

Directory : t/images File

Size : 24 kB File Modification Date/Time

Etc.. I am looking for a ‘how to’ or something like that.

Answer 1

ExifTool (for Java) is designed to be a simple-to-use and robust Java abstraction of Phil Harvey’s ExifTool. I just made the first public release this past week after incubating the project under the imgscalr project umbrella for a while.

The project is under the commercial-friendly Apache 2 license.

My goal for the library isn’t just to abstract out the external process execution code from the caller (like most of the other abstraction layers are seeming to do) but to actually design a wrapper so tightly integration and resilient (I will clarify what I mean here later), that you treat instances of your ExifTool class exactly as you would if ExifTool itself was written in Java.

In this initial release I support reading tag data (will add writing in a future release) and it is as simple as this:

File image = // path to some image
ExifTool tool = new ExifTool();

Map<Tag, String> valueMap =
    tool.getImageMeta(image, Tag.GPS_LATITUDE, Tag.GPS_LONGITUDE);

System.out.println("Lat: " + valueMap.get(Tag.GPS_LATITUDE) +
    "\tLong: " + valueMap.get(Tag.GPS_LONGITUDE));

Using ExifTool in the new “daemon mode” (-stay_open True cmd line) is also supported and turning on support for it is as easy as creating your ExifTool instance like so:

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 making use of ExifTool simple from Java, the class employs a considerable amount of precautions to minimize runtime issues as well as correctly catching and reporting any and all errors that can arise in well-documented ways (instead of letting surprise exceptions bubble up from core Java classes).

I was so pedantic with this exception handling and error recovery because the class is designed to allow you to utilize ExifTool in a high-availability environment like a busy web application. I didn’t just want to wrap simple Process objects then throw my hands up in the air if something exploded. I knew myself (and anyone else using the class) would need a well designed API to allow for easy error recovery.

For example, attempting to use ExifTool in daemon mode will cause the class to actually check the underlying install of ExifTool for support for that feature and throw an UnsupportedFeatureException with recommendations on how to work around the problem if it isn’t supported.

In addition to the pre-condition checking, to ensure that usage of the class (namely in daemon mode) doesn’t leak native OS processes as well as Input/OutputStreams used to communicate with them, the class provides an auto-cleanup thread that after a specified interval of inactivity (default is 10 mins) will shut down the external process cleanly and the read/write streams, making the idle instance of ExifTool lightweight and easy to keep around for re-use.

All the resources are re-initialized on the next call to the class to parse more metadata so there is no need to throw out and re-create new instances. Also the cleanup thread only executes after extended periods of inactivity, not on a set schedule. You can set the interval to anything you want or shut off the cleanup thread completely and manage cleanup yourself (just call close()).

These designs are all part of my ultimate goal of making ExifTool integration into a Java application seamless, performant and easy.

You can check out the main project page for more info on the project, usage, source, download links, etc. or you can jump right to GitHub and look through the code if you prefer.