我只是想知道你们中的任何人在使用 java 默认 HttpURLConnection 类时是否有任何问题。某种使您切换到 apache commons 的错误。
或者仅仅是类公开的(丑陋的)接口证明了第 3 方 http lib 的诞生是合理的?
披露:我听到一些反对 java.net 存在一些严重问题的论点,但我发现很难相信作为 java 核心发行版一部分的类在 JDK 的几个版本之后仍然存在问题
我只是想知道你们中的任何人在使用 java 默认 HttpURLConnection 类时是否有任何问题。某种使您切换到 apache commons 的错误。
或者仅仅是类公开的(丑陋的)接口证明了第 3 方 http lib 的诞生是合理的?
披露:我听到一些反对 java.net 存在一些严重问题的论点,但我发现很难相信作为 java 核心发行版一部分的类在 JDK 的几个版本之后仍然存在问题
驱使我使用 Apache HttpClient 的原因是,
您现在应该使用 HttpClient 4(Apache HTTP 组件)。
编辑:第一个问题已在这里讨论过多次。看,
HttpURLConnection.getResponseCode() 在第二次调用时返回 -1
HttpURLConnection:必须阅读整个响应有什么关系?
尽管问题在 Android 上似乎更严重,但我们在 J2SE 上看到了确切的问题。
Android SDK 说 Prefer HttpURLConnection for new code。
Android 包括两个 HTTP 客户端:
HttpURLConnection
和Apache HTTP Client
. 两者都支持 HTTPS、流式上传和下载、可配置的超时、IPv6 和连接池。Apache HTTP 客户端在 Android 2.2 (Froyo) 及更早版本中的错误较少。对于 Android 2.3 (Gingerbread) 及更高版本,HttpURLConnection
是最佳选择。其简单的 API 和小尺寸使其非常适合 Android。透明压缩和响应缓存可减少网络使用、提高速度并节省电池。有关两个 HTTP 客户端的比较,请参阅Android 开发者博客。
...但我发现很难相信作为 java 核心发行版一部分的类在 JDK 的几个版本之后仍然存在问题。
为了保卫孙,他们被夹在一块石头和一个坚硬的地方:
如果他们解决了这些问题,他们无疑会破坏数以万计依赖于当前 API 及其不太理想行为的遗留应用程序。如果他们这样做,他们付费客户群的影响将是巨大的。更多的企业将被困在使用古老的 JDK 版本。
如果他们不解决问题,他们就会受到纯粹主义者的无休止的抨击,他们认为每个问题都应该得到解决,而且该死的兼容性。
至少需要 HTTP 客户端 API 的人有更好的选择……如果他们想使用它。
这就是@deprecated 被发明的原因。
理论上,是的...
然而,在实践中,Oracle 使用弃用作为向程序员(更重要的是管理人员)发出他们需要更改代码的强烈信号。
这在这里没有保证。让我们看一下具体问题:
“HttpURLConnection
无法处理 cookie”不是弃用它的理由。已经构建应用程序的HttpURLConnection
人已经处理过这个问题。对他们来说,更改为不同的 HTTP 客户端类是不必要的工作。
“HttpURLConnection
不支持keep-alives”也不是弃用的理由。大多数应用程序不需要保持活动。
等等。
弃用是一种生硬的工具,Sun / Oracle 的理念是它应该只在 API 难以安全使用的情况下使用;即,当有一个强大的商业案例让开发人员花时间重新编写代码等时。
但不要只相信我的话。查看 Sun / Oracle已弃用方法和类的情况。有一个明确的模式,即使它有历史例外。