Sounds good to me.
2013/10/30 Damjan Jovanovic <damjan....@gmail.com> > For the sake of similarity of 1.0 with 0.x versions, I've stayed with Java > 1.5 and in commit 1537238 I've gone with the set flag on every successful > return path + closeQuietly() idea. > > It was a mission and broke things (DeflaterOutputStream apparently doesn't > honor flush()). I am moving Imaging to Java 7 as soon as 1.0 is released. > > Damjan > > > On Sun, Oct 27, 2013 at 8:32 PM, Gary Gregory <garydgreg...@gmail.com > >wrote: > > > On Sun, Oct 27, 2013 at 1:51 AM, 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? > > > > > > > I do not think you need a vote. Since the 0.x version is used in the > wild, > > you might want to poll the user base as to their JRE requirements. > > > > For me, moving to Java 6 is fine. Java 7 is a little more adventurous, a > > good thing in general since no [commons] component has made Java 7 a > > minimum yet. Might as well test the waters. > > > > Gary > > > > > > > > > > > > Damjan > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > -- > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > > Java Persistence with Hibernate, Second Edition< > > http://www.manning.com/bauer3/> > > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > > Spring Batch in Action <http://www.manning.com/templier/> > > Blog: http://garygregory.wordpress.com > > Home: http://garygregory.com/ > > Tweet! http://twitter.com/GaryGregory > > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
