Unfortunately, it hasn't answered my question. I understand that the behavior of SoapUI may have changed due to a change in the behavior of an underlying library, but isn't that exactly the point? Shouldn't SoapUI's behavior remain consistent with the expectations of the user even when underlying library behavior changes? To say that a contract with a SoapUI user must be broken just because a dependency changed doesn't make any sense. To me being one of SoapUI's users, a JSON path existence test should respond with "false" for a JSON path that does not exist. To say that because the JSON library's behavior changed necessarily means that expectations must not be met doesn't make sense to me. In this particular case, it seems that a try { } catch (Exception e) { } should surround the library function, with the SoapUI assertion returning "false" is more appropriate than just blaming the library for SoapUI's regression error. - Steve
