I expect it to break with Java 7 runtime as this is marked as "binary incompatibility", too.
----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen <http://www.thetaphi.de/> http://www.thetaphi.de eMail: [email protected] From: Mark Kerzner [mailto:[email protected]] Sent: Wednesday, August 31, 2011 4:49 PM To: [email protected] Subject: Re: Closing streams (Was: Tika leaves files open) Oh, I get it (mighty slow this morning). I will leave the Java 6 build for Tika, but will use Java 7 for my app!!! Will try. Thank you, Mark On Wed, Aug 31, 2011 at 9:42 AM, Mark Kerzner <[email protected]> wrote: This error may have to do with the following in Java 7 Area: API: 2D Synopsis: The Non-standard com.sun.image.jpeg.codec Package is Retired Description: The com.sun.image.codec.jpeg package was added in JDK 1.2 (Dec 1998) as a non-standard way of controlling the loading and saving of JPEG format image files. This package was never part of the platform specification and it has been removed from the Java SE 7 release. The Java Image I/O API was added to the JDK 1.4 release as a standard API and eliminated the need for thecom.sun.image.jpeg.codec package. Nature of Incompatibility: binary and source RFE: <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6527962> 6527962 http://www.oracle.com/technetwork/java/javase/compatibility-417013.html How does one fix it? Mark On Wed, Aug 31, 2011 at 9:31 AM, Mark Kerzner <[email protected]> wrote: Wow, Uwe, I missed it at first. I would use Java 7! This provides me the much-needed workaround. However, yesterday I had this error compiling with Java 7 [ERROR] /home/mark/ThirdParty/tika-source/tika-site/tika-parsers/src/main/java/org/a pache/tika/parser/image/ImageMetadataExtractor.java:[89,34] error: cannot access JPEGDecodeParam Have you seen it? Thank you, Mark On Wed, Aug 31, 2011 at 9:28 AM, Uwe Schindler <[email protected]> wrote: Mark, You can use that code pattern on any class that implement (Auto-)Closeable. It does not affect TIKA if you use try-with-resources or not. It just depends if YOU want to use Java 7 in your code. There is no change needed on the Tika side. Uwe ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de <http://www.thetaphi.de/> eMail: [email protected] From: Mark Kerzner [mailto:[email protected]] Sent: Wednesday, August 31, 2011 3:49 PM To: [email protected] Subject: Re: Closing streams (Was: Tika leaves files open) Uwe, are you suggesting this to the Tika team? How will it handle backward compatibility (you can't require everyone to use Java 7, can you?) Can I do it myself in my version of the code? Java 7 has other problems compiling Tika, as I found out yesterday. Thank you, Mark On Wed, Aug 31, 2011 at 7:35 AM, Uwe Schindler <[email protected]> wrote: Hi, > I think that's a good approach in general (if you open it, you close it). It does > look like it's well documented, which is great. > > > The exception to this rule is the Tika.parseToString(InputStream, > > Metadata) method. The reason for making an exception here is that the > > Tika facade class was designed primarily for convenience and to > > minimize the amount of code that the consumer of the API needs to > > write. The proper resource management pattern in this case would have > > been: > > > > InputStream stream = ...; > > try { > > return tika.parseToString(stream, ...); > > } finally { > > stream.close(); > > } > > > > However, since in this specific case the client application hardly > > ever needs to use the stream for anything else and since in pretty > > much all cases the stream in question is constructed right when the > > parseToString call is made, it makes more sense for the > > parseToString() method to take care of closing the stream. The result > > is that the above code can be reduced to: > > > > return tika.parseToString(..., ...); > > I can appreciate this motivation, ie "convenience trumps consistency", here. > > Still this inconsistency can lead to confusion and to bugs, but since it's only one > API that's "the exception" I think it's OK? > > But maybe we can beef up its javadocs a bit, saying "NOTE: unlike all other APIs > parsing from an InputStream, this API closes the incoming InputStream for you > for convenience" or something? For Java 7 you could simplify this as a try-with-resources statement (which does something similar as Lucene's IOUtils.closeSafely method in a finally block): try (InputStream stream = ...) { return tika.parseToString(stream, ...); } If you can use this type of statement (and Tika also consequently uses the Closeable interface in its public APIs like Lucene does), this is really nice to work with. Uwe
