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 >
