You are viewing a plain text version of this content. The canonical link for it is here.
Posted to announce@apache.org by Oleg Kalnichevski <ol...@apache.org> on 2010/11/19 08:48:10 UTC
[ANNOUNCEMENT] HttpComponents HttpCore 4.1 (GA) Released
The Apache HttpComponents project is pleased to announce the release of
HttpComponents HttpCore 4.1.
This is the first stable (GA) release of HttpCore 4.1. This release
provides a compatibility mode with JREs that have a naive (broken)
implementation of SelectionKey API and also improves compatibility with
the Google Android platform. There has also been a number of performance
related improvements and bug fixes in both blocking and non-blocking
components.
All upstream projects are encouraged to upgrade.
Download -
<http://hc.apache.org/downloads.cgi>
Release notes -
<http://www.apache.org/dist/httpcomponents/httpcore/RELEASE_NOTES.txt>
HttpComponents site -
<http://hc.apache.org/>
About HttpComponents Core -
HttpCore is a set of low level HTTP transport components that can be
used to build custom client and server side HTTP services with a minimal
footprint. HttpCore supports two I/O models: blocking I/O model based on
the classic Java I/O and non-blocking, event driven I/O model based on
Java NIO. The blocking I/O model may be more appropriate for data
intensive, low latency scenarios, whereas the non-blocking model may be
more appropriate for high latency scenarios where raw data throughput is
less important than the ability to handle thousands of simultaneous HTTP
connections in a resource efficient manner.
HttpClient 4.1 release plan; was RE: [ANNOUNCEMENT] HttpComponents
HttpCore 4.1 (GA) Released
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2010-11-19 at 18:22 +0000, Gary Gregory wrote:
> Hi Oleg:
>
> Is there a schedule for when this will trickle into a HttpClient release?
>
> Thank you,
>
> Gary
Hi Gary
HttpClient 4.1-beta1 packages will become available tomorrow. HttpClient
4.1-beta1 depends on HttpCore 4.1 (GA). If no major problems are found,
HttpClient 4.1 (GA) is likely to be released in early Q1 2011.
Cheers
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
RE: [ANNOUNCEMENT] HttpComponents HttpCore 4.1 (GA) Released
Posted by Gary Gregory <GG...@seagullsoftware.com>.
Hi Oleg:
Is there a schedule for when this will trickle into a HttpClient release?
Thank you,
Gary
> -----Original Message-----
> From: Oleg Kalnichevski [mailto:olegk@apache.org]
> Sent: Thursday, November 18, 2010 23:48
> To: announce@apache.org; private@hc.apache.org; dev@hc.apache.org; httpclient-
> users@hc.apache.org
> Subject: [ANNOUNCEMENT] HttpComponents HttpCore 4.1 (GA) Released
>
> The Apache HttpComponents project is pleased to announce the release of
> HttpComponents HttpCore 4.1.
>
> This is the first stable (GA) release of HttpCore 4.1. This release
> provides a compatibility mode with JREs that have a naive (broken)
> implementation of SelectionKey API and also improves compatibility with
> the Google Android platform. There has also been a number of performance
> related improvements and bug fixes in both blocking and non-blocking
> components.
>
> All upstream projects are encouraged to upgrade.
>
> Download -
> <http://hc.apache.org/downloads.cgi>
> Release notes -
> <http://www.apache.org/dist/httpcomponents/httpcore/RELEASE_NOTES.txt>
> HttpComponents site -
> <http://hc.apache.org/>
>
> About HttpComponents Core -
> HttpCore is a set of low level HTTP transport components that can be
> used to build custom client and server side HTTP services with a minimal
> footprint. HttpCore supports two I/O models: blocking I/O model based on
> the classic Java I/O and non-blocking, event driven I/O model based on
> Java NIO. The blocking I/O model may be more appropriate for data
> intensive, low latency scenarios, whereas the non-blocking model may be
> more appropriate for high latency scenarios where raw data throughput is
> less important than the ability to handle thousands of simultaneous HTTP
> connections in a resource efficient manner.
>