Binary incompatible changes to framework-only code

[Burn Lewis <bu...@gmail.com>]

Recently in UIMA-5274 I changed the return value of the static method
UimaContextHolder.setContext(UimaContext uimaContext) from void to
UimaContext (so it could return the previous value).  Although this doesn't
cause any compile problems it does break binary compatibility at the
byte-code level.  But this call is intended only for framework use (to set
the context before calling user code) ... user code should only use the
getContext method.  Existing user code should not be using this method, so
is this change a concern?

Burn

Re: Binary incompatible changes to framework-only code

[Richard Eckart de Castilho <re...@apache.org>]

On 17.02.2017, at 20:50, Burn Lewis <bu...@gmail.com> wrote:
> 
> That test worked fine.  But when I added a call to setContext it failed
> with NoSuchMethodError.  So as expected at runtime the method must have a
> fully matching signature.  So we're OK as user code should not be using
> this method, but do other packages such as UimaFit use it?

uimaFIT doesn't use the call yet. However, I was considering to use it
although I am not yet sure if it is necessary:

https://issues.apache.org/jira/browse/UIMA-5297

-- Richard

Re: Binary incompatible changes to framework-only code

[Burn Lewis <bu...@gmail.com>]

That test worked fine.  But when I added a call to setContext it failed
with NoSuchMethodError.  So as expected at runtime the method must have a
fully matching signature.  So we're OK as user code should not be using
this method, but do other packages such as UimaFit use it?


On Mon, Feb 13, 2017 at 10:13 AM, Marshall Schor <ms...@schor.com> wrote:

> I tried looking this up on the internet, and found one reference that
> suggest
> this would be OK, since the changed method is unreference in user code.
>
> However, I think a reliable way to see if this is an issue is to test it,
> something like:
> 1) make a class that uses UimaContext.getContext(), and compile that and
> run it
> using the former definition of UimaContext.
> 2) try running the same compiled class (without recompiling it) with the
> class
> path changed to include the changed version of UimaContext.
>
> If it complains, then even though this isn't referencing the changed
> method,
> Java is saying it can't be run without recompiling it.
> If it doesn't complain, then I don't think there's any issue (except for
> code
> using the internal use only APIs of UimaContext, which I think is OK).
>
> -Marshall
>
> On 2/13/2017 8:17 AM, Burn Lewis wrote:
> > Recently in UIMA-5274 I changed the return value of the static method
> > UimaContextHolder.setContext(UimaContext uimaContext) from void to
> > UimaContext (so it could return the previous value).  Although this
> doesn't
> > cause any compile problems it does break binary compatibility at the
> > byte-code level.  But this call is intended only for framework use (to
> set
> > the context before calling user code) ... user code should only use the
> > getContext method.  Existing user code should not be using this method,
> so
> > is this change a concern?
> >
> > Burn
> >
>
>

Re: Binary incompatible changes to framework-only code

[Marshall Schor <ms...@schor.com>]

I tried looking this up on the internet, and found one reference that suggest
this would be OK, since the changed method is unreference in user code.

However, I think a reliable way to see if this is an issue is to test it,
something like:
1) make a class that uses UimaContext.getContext(), and compile that and run it
using the former definition of UimaContext.
2) try running the same compiled class (without recompiling it) with the class
path changed to include the changed version of UimaContext.

If it complains, then even though this isn't referencing the changed method,
Java is saying it can't be run without recompiling it.
If it doesn't complain, then I don't think there's any issue (except for code
using the internal use only APIs of UimaContext, which I think is OK).

-Marshall

On 2/13/2017 8:17 AM, Burn Lewis wrote:
> Recently in UIMA-5274 I changed the return value of the static method
> UimaContextHolder.setContext(UimaContext uimaContext) from void to
> UimaContext (so it could return the previous value).  Although this doesn't
> cause any compile problems it does break binary compatibility at the
> byte-code level.  But this call is intended only for framework use (to set
> the context before calling user code) ... user code should only use the
> getContext method.  Existing user code should not be using this method, so
> is this change a concern?
>
> Burn
>