uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: Binary incompatible changes to framework-only code
Date Mon, 13 Feb 2017 15:13:00 GMT
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).


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

View raw message