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:* 6527962<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=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/apache/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**** >>> >>> 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**** >>> >>> ** ** >>> >> >> >
