uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Burn Lewis <burnle...@gmail.com>
Subject Re: Binary incompatible changes to framework-only code
Date Fri, 17 Feb 2017 19:50:58 GMT
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 <msa@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
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message