Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of damjan.jov@gmail.com designates
 209.85.212.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <l4e2f4$kr3$1@ger.gmane.org>
References: 
 <CACZkXPxz3fQjtFfDc5d43L7Sz3hC-70BZPXmgEY-REcNvO5mmw@mail.gmail.com>
 <CAOGo0VZ=otGkoex-oSodaTimU4njr1acFdpTD5QNy2+gG2wqKw@mail.gmail.com>
 <CACZkXPyd_sF3oyEHqFbHKpUnM2GSwZ7FTkUQhgT2HO+2oMAf2g@mail.gmail.com>
 <CAJm2B-kdKdx5dqV=yAfbGCF0=4ugzLe3_Qhc+fcECim8HTJOtg@mail.gmail.com>
 <l4c03a$cqt$1@ger.gmane.org>
 <CACZkXPwsoVXHb=Rmb5ohS-wHEFWKWm-PwEJGYUZR9bvawTdO-w@mail.gmail.com>
 <CAJm2B-=NYTrdxF1o+_RwNYUj1Eqbo1VGqOKAPu64zwRAyN-5oA@mail.gmail.com>
 <l4d4vu$ga$1@ger.gmane.org>
 <CAJm2B-mHZ=o8gL6ivx7RkvV+wO0+_X2kKwKoNwfcQN3H4+CQEg@mail.gmail.com>
 <l4dhic$aqt$1@ger.gmane.org>
 <CAJm2B-=ad_FvkpS495HzgafFstDqjc_MuKpY46N5uvk+AUo8JA@mail.gmail.com>
 <l4e2f4$kr3$1@ger.gmane.org>
From: Damjan Jovanovic <damjan.jov@gmail.com>
Date: Sun, 27 Oct 2013 07:51:03 +0200
Message-ID: 
 <CAJm2B-mT-vqydfCO6m7HowV_uggMv2yai3cbOeWH_HLLa6K86A@mail.gmail.com>
Subject: Re: [imaging] Closing stream
To: Commons Developers List <dev@commons.apache.org>, joerg.schaible@gmx.de
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

 an

On Fri, Oct 25, 2013 at 5:24 PM, J=F6rg Schaible <joerg.schaible@gmx.de> wr=
ote:
> Hi Damjan,
>
> Damjan Jovanovic wrote:
>
>> On Fri, Oct 25, 2013 at 12:36 PM, J=F6rg Schaible
>> <Joerg.Schaible@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 =3D factoryMethodThatCanThrow();
>>>> boolean succeeded =3D false;
>>>> try {
>>>>     try {
>>>>         is.methodThatCanThrow();
>>>>     } finally {
>>>>     }
>>>>     succeeded =3D true;
>>>> } finally {
>>>>     closeSafely(!succeeded, is);
>>>> }
>>>
>>> I guess the nested try was unintentionally ;-)
>>>
>>> Cheers,
>>> J=F6rg
>>
>> Well that actually won't work, because the "succeeded =3D 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 =3D true" before the return as well.
>
> To mimic Java 7, we could also implement:
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D %< =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
>  Throwable t =3D null;
>  try {
>  } (catch IOException e) { t =3D e; throw e; }
>  // ... another line for each checked exception
>  } (catch RuntimeException e) { t =3D e; throw e; }
>  } (catch Error e) { t =3D e; throw e; }
>  } finally {
>    closeSafely(t !=3D null, is);
>  }
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D %< =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D
>
> 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=F6rg
>

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-exceptio=
ns-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?

Damjan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org