The documentation does state that ClientRequest::getUri() will cache the uri the first time its called and then return that cached value for every call thereafter.
However, I believe there is non-client code (maybe the caching framework?) that calls ClientRequest::getUri(). So the client may think it is calling getUri for the first time and get unexpected results.
For example, on our project we were using a custom Executor (extends ApacheHttpClient4Executor). We overrode the execute() method and from within that method, we add matrix and query params to the request and then called super.execute(ClientRequest).
After a lot of digging, we found that the request we were passing to execute already had getUri called on it (and therefore, when the ApacheHttpClient4Executor::execute method tried to call getUri(), it was getting an "old" version of the URI that didn't reflect the parameters we had added).
Would a boolean property that tracks whether or not the cached value need to be rebuilt be an agreeable fix (set it whenever pathParam(), etc are called; have getUri() check it)? If so, I'll attach the patch once I have some time to figure out the unit testing framework. ( I'm asking because the Javadoc comment seemed pretty clear that the "update the URI once" behavior I'm experiencing is really what's desired.)
I wasn't signed in when I submitted the bug. Sorry.