Hi Praveen,
Yes, we usually mark unused things deprecated and then remove it in the next major feature release. Unfortunately, Netty 4 is not backward compatible in many ways from 3, so it has no point of marking things deprecated - there will be so many surprising changes already if you merely update the version number in your dependency list. I'm writing a migration guide instead.
Thanks,
T
On Tuesday, June 12, 2012 12:41:15 AM UTC+9, Praveen Krishnaiah wrote:
> Hi Trustin,
> I don't use BlockingReadHandler, but had more of a general question. Should't we mark Classes/methods as deprecated for one or two versions before we remove them? This gives a chance to developers who do not follow this forum to make changes. </div>
>
> </div>
> Thanks, </div>
> Praveen.
>
> On Monday, June 11, 2012 8:21:07 AM UTC-4, Trustin Lee wrote:<blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,
>
>
>
> I wonder if anyone is really using BlockingReadHandler, which appeared
>
> first in Netty 3.2. It was initially meant to help a user read inbound
>
> messages from a non-I/O thread in a blocking manner (e.g. writing a
>
> blocking client on top of Netty).
>
>
>
> It always was marked as 'special purpose only' because it never scales.
>
> If you use BlockingReadHandler, you get the bad part of both NIO and
>
> OIO - higher latency and low scalability. :-)
>
>
>
> Therefore, if there's no objection, I'd like to remove
>
> BlockingReadHandler from master (i.e. dropping it from Netty 4). Please
>
> let me know if you know a good reason to keep it.
>
>
>
> Thanks,
>
> T
>
>
>
> --
>
> <a href="
https://twitter.com/trustin" target="_blank">
https://twitter.com/trustin</a>
>
> <a href="
https://twitter.com/trustin_ko" target="_blank">
https://twitter.com/trustin_ko</a>
>
> <a href="
https://twitter.com/netty_project" target="_blank">
https://twitter.com/netty_<WBR>project</a>
>
> </blockquote></div>