On 27 October 2013 05:51, Damjan Jovanovic <damjan....@gmail.com> wrote: > an > > On Fri, Oct 25, 2013 at 5:24 PM, Jörg Schaible <joerg.schai...@gmx.de> wrote: >> Hi Damjan, >> >> Damjan Jovanovic wrote: >> >>> On Fri, Oct 25, 2013 at 12:36 PM, Jörg Schaible >>> <joerg.schai...@scalaris.com> wrote: >>>> Hi Damjan, >>>> >>>> Damjan Jovanovic wrote: >>>> >>>> [snip] >>>> >>>> Thanks for explanation. >>>> >>>>> We would be able to adapt that for Java < 1.7 by swallowing the close >>>>> exception instead of calling addSuppressed() on the primary exception, >>>>> but the show stopper is catching and rethrowing the primary exception >>>>> (Throwable), which javac < 1.7 refuses to compile because it doesn't >>>>> do "Rethrowing Exceptions with More Inclusive Type Checking" >>>>> (http://docs.oracle.com/javase/7/docs/technotes/guides/language/catch-multiple.html). >>>>> >>>>> But this would work and always sets succeeded correctly without >>>>> catch/re-throw: >>>>> >>>>> final InputStream is = factoryMethodThatCanThrow(); >>>>> boolean succeeded = false; >>>>> try { >>>>> try { >>>>> is.methodThatCanThrow(); >>>>> } finally { >>>>> } >>>>> succeeded = true; >>>>> } finally { >>>>> closeSafely(!succeeded, is); >>>>> } >>>> >>>> I guess the nested try was unintentionally ;-) >>>> >>>> Cheers, >>>> Jörg >>> >>> Well that actually won't work, because the "succeeded = true;" will be >>> skipped if there is a "return;" in the inner try. >> >> Well, but this has to be done in our code, so we can either change it or set >> "succedded = true" before the return as well. >> >> To mimic Java 7, we could also implement: >> >> ============= %< =============== >> Throwable t = null; >> try { >> } (catch IOException e) { t = e; throw e; } >> // ... another line for each checked exception >> } (catch RuntimeException e) { t = e; throw e; } >> } (catch Error e) { t = e; throw e; } >> } finally { >> closeSafely(t != null, is); >> } >> ============= %< =============== >> >> but as commented, we have to add a catch for every checked exception, >> anotehr one for RuntimeException and one for Error. The approach with the >> succeeded flag seems easier ... >> >>> Other than a custom Java compiler, I guess there's no clean way of >>> doing this in Java < 1.7. There's really only option 2 - with being >>> careful to always set succeeded correctly on all paths out of the try >>> block. Almost like releasing memory in C. >> >> Yep. >> >> Cheers, >> Jörg >> > > One thing that amuses me to no end, is that while it's at least a > solved problem in Java 7, exceptions thrown from C#'s Dispose() method > in a using() block always swallow the original exception, just like an > uncaught close() exception in Java's finally :) > (http://blogs.infosupport.com/the-c-using-statement-and-suppressed-exceptions-compared-to-java-7-try-with/). > > Anyway I now think the way forward is Java 7. Java 5 was EOL since 3 > November 2009, and Java 6 was EOL since February 2013 (with a last > update on 6 March 2013). There are ways of getting Java 7 features > like try-with-resources on Android > (https://github.com/yareally/Java7-on-Android) and besides Imaging's > use of java.awt.* packages is a bigger barrier there. Applications and > JVMs will eventually support Java 7 anyway, and even if they don't, a > special compiler could produce binaries for earlier versions of Java. > > Can I just go change the POM to Java 7 or do we need a vote?
This should probably be taken to the user list - will requiring Java 7 cause problems for many users of Imaging? > Damjan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
