Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
MIME-Version: 1.0
In-Reply-To: <1497A08C-E12E-490F-B5E0-EF56FAE1E046@hibnet.org>
References: <001b01d2d853$6b7ac9a0$42705ce0$@de> <260C6FFD-2382-44CD-AFB0-06AF0F7A8B7F@gmail.com>
 <003d01d2d860$84d88c90$8e89a5b0$@de> <1497A08C-E12E-490F-B5E0-EF56FAE1E046@hibnet.org>
From: Matt Sicker <boards@gmail.com>
Date: Mon, 29 May 2017 10:26:39 -0500
Message-ID: <CACmp6kozw6srn-1wbyVfdiiF3eyEhTBJ6Hd=mpTcGmEx8dxChg@mail.gmail.com>
Subject: Re: PR-33: problems
To: Ant Developers List <dev@ant.apache.org>
Content-Type: multipart/alternative; boundary="001a1141130844c6190550ab506e"
archived-at: Mon, 29 May 2017 15:26:47 -0000

--001a1141130844c6190550ab506e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Removing a checked exception can affect source compatibility, for example,
if that particular exception is caught in a try block and nothing else in
the try block can throw the exception. Or at least that's how I remember it
I think.

On 29 May 2017 at 06:05, Nicolas Lalev=C3=A9e <nicolas.lalevee@hibnet.org> =
wrote:

>
> > Le 29 mai 2017 =C3=A0 11:46, Jan Mat=C3=A8rne (jhm) <apache@materne.de>=
 a =C3=A9crit :
> >
> > Sounds like I would do ;)
> > I'll merge the PR locally and insert the delegates.
> >
> > Open is
> > "src/java/org/apache/ivy/osgi/util/Version.java:
> >  the constructor removes the (IMO unneccessary) ParseException.
> >  But because it is a checked Exception we break BC."
> >
> > https://wiki.eclipse.org/Evolving_Java-based_APIs_2 defines the removal
> of a checked exception:
> > "Breaks compatibility"
> > "Adding and deleting checked exceptions declared as thrown by an API
> method
> >  does not break binary compatibility; however,
> >  it breaks contract compatibility (and source code compatibility)."
> >
> > What do we want?
>
> Thanks for the link, I=E2=80=99ll bookmark it.
>
> Then I am OK with that. The Ivy jar can still be a upgraded without
> worries, and if somebody compile against it, then he has the source so he
> can modify them.
>
> I am OK with that also because having stricter compatibility rules will b=
e
> painful considering the wide API Ivy is exposing.
>
> Nicolas
>
> >
> >
> >
> > Jan
> >
> >> -----Urspr=C3=BCngliche Nachricht-----
> >> Von: J Pai [mailto:jai.forums2013@gmail.com]
> >> Gesendet: Montag, 29. Mai 2017 10:26
> >> An: Ant Developers List
> >> Betreff: Re: PR-33: problems
> >>
> >> IMO, for each of these public classes/methods/fields that we are fixin=
g
> >> for typos, we should mark them @Deprecated (and add a @deprecated
> >> javadoc too and point to the new field/method/class) and introduce the
> >> rightly named class/method/field. For methods it=E2=80=99s straightfor=
ward, the
> >> deprecated method internally calls the new method. For fields too it=
=E2=80=99s
> >> straightforward. The deprecated field uses the value of the new field.
> >> For classes, I think we can copy over the existing class into the new
> >> one and leave around the existing one just for possible external
> >> references (that we can=E2=80=99t control off) and migrate all interna=
l
> >> references to the new one.
> >>
> >> At some point, in some future version of Ivy, we remove/delete these
> >> deprecated method/field/class.
> >>
> >>
> >> -Jaikiran
> >>
> >>
> >> On 29-May-2017, at 1:43 PM, Jan Mat=C3=A8rne <jan@materne.de> wrote:
> >>
> >> I did a review of  <https://github.com/apache/ant-ivy/pull/33>
> >> https://github.com/apache/ant-ivy/pull/33
> >>
> >> Here are the points I have problems with, so I want to discuss them
> >> here.
> >>
> >> Basically it's about breaking BC. So how to deal with that?
> >>
> >>
> >>
> >>
> >>
> >> Jan
> >>
> >>
> >>
> >>
> >>
> >> Fixing the spell error in DelegateHandler$ChildElementHandler
> >> (s/childHanlded/childHandled/) means breaking beakward compatiblity.
> >>
> >> We could introduce a delegetate for that:
> >>
> >> /** for BC */
> >>
> >> @Deprecated
> >>
> >> public void childHanlded(DH child) throws SAXParseException {
> >>
> >>   childHandled(DH child);
> >>
> >> }
> >>
> >> While refactoring you have renamed all occurences in the Ivy codebase.
> >>
> >> On the other hand I don't know the impact (maybe outside of Ivy). I'll
> >> bring that to the dev-list.
> >>
> >>
> >>
> >>
> >>
> >> src/java/org/apache/ivy/osgi/repo/FSManifestIterable.java: renaming th=
e
> >> public constant DEFAULT_BUNLDE_FILTER also means breaking BC.
> >>
> >>
> >>
> >>
> >>
> >> src/java/org/apache/ivy/osgi/util/Version.java: the constructor remove=
s
> >> the (IMO unneccessary) ParseException. But because it is a checked
> >> Exception we break BC.
> >>
> >>
> >>
> >>
> >>
> >> renaming EncrytedProperties to EncryptedProperties means breaking BC.
> >> If required we could introduce a delegating class or a subclass.
> >>
> >>
> >>
> >>
> >>
> >> ArtifactOrigin: renaming unkwnown() to unknown() means breaking BC. If
> >> required we could introduce a delegating method.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For additional
> >> commands, e-mail: dev-help@ant.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>


--=20
Matt Sicker <boards@gmail.com>

--001a1141130844c6190550ab506e--