On Tue, 2014-01-28 at 19:39 +0000, sebb wrote: ...
> > > > Why? The new implementation honors the same contract by implementing the > > same interfaces and using the same API classes as the old version. As > > long as the application does not directly depend on the old > > DefaultHttpClient (in which case we cannot do much) but rather relies on > > HttpClient interface, the newer implementation can be used without any > > alternations. > > Suppose the code depends on the class > org.apache.http.entity.HttpEntityWrapper > > This won't exist in the new jar as it is one of the HC4-suffix classes. > > Assume also that the new HttpClient implementation makes use of the class > org.apache.http.entity.HttpEntityWrapperHC4 > > Seems to me that this could well cause a problem where the app works > fine on Java but fails on Android - and the failure could be very > tricky to debug. > > That's why I think the application needs to avoid using the classes > that are renamed with the HC4 suffix. > It is theoretically possible but not very likely. Besides, HC4 classes are absolutely no different from any custom interface implementation or a custom subclass HttpClient must be able to handle. This is no different from hitting a perfectly ordinary bug. HC4 classes are just ugly. This is the only problem with them. I could make some (probably most) of those classes package private, but a few utility classes are being used all over the place and need to remain public. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
