<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Recent changes to bugs</title><link>https://sourceforge.net/p/jniosocket/bugs/</link><description>Recent changes to bugs</description><atom:link href="https://sourceforge.net/p/jniosocket/bugs/feed.rss" rel="self"/><language>en</language><lastBuildDate>Thu, 21 Apr 2005 17:37:57 -0000</lastBuildDate><atom:link href="https://sourceforge.net/p/jniosocket/bugs/feed.rss" rel="self" type="application/rss+xml"/><item><title>jnio2: this passed from constructor</title><link>https://sourceforge.net/p/jniosocket/bugs/2/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;In NioSocket's constructor the "this" reference is&lt;br /&gt;
passed to the worker's registerChannel method. As the&lt;br /&gt;
worker is probably running, this makes it possible for&lt;br /&gt;
the NioSocket object to be used before its construction&lt;br /&gt;
is complete, which is a very bad idea.&lt;/p&gt;
&lt;p&gt;This effect can be minimized by making the&lt;br /&gt;
registerChannel call the last in the constructor, but&lt;br /&gt;
there are no guarantees that the compiler or JIT won't&lt;br /&gt;
rearrange the code, thus brining the bug back.&lt;/p&gt;
&lt;p&gt;Besides, the attachment is added to the key after the&lt;br /&gt;
call, which even if the call were pulled out of the&lt;br /&gt;
constructor, it can cause the attachment to be&lt;br /&gt;
referenced by the worker (i.e., from handleRead) before&lt;br /&gt;
it's actually attached. This just happened to me, so&lt;br /&gt;
it's far from a hypothetical case. However, it's easy&lt;br /&gt;
to fix by passing the attachment as a parameter to&lt;br /&gt;
registerChannel and using the three-argument form of&lt;br /&gt;
SelectableChannel.register that takes the attachment.&lt;/p&gt;
&lt;p&gt;In conclusion, there's a bug in the design,&lt;br /&gt;
registerChannel must be called from outside the&lt;br /&gt;
constructor. I'll post a patch if I fix this myself,&lt;br /&gt;
but that might take some time at this point.&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Javier Kohen</dc:creator><pubDate>Thu, 21 Apr 2005 17:37:57 -0000</pubDate><guid>https://sourceforge.net6032ae106ac369866889e9485acc600d0ba1e7dd</guid></item><item><title>jnio2: please recode source to utf-8</title><link>https://sourceforge.net/p/jniosocket/bugs/1/</link><description>&lt;div class="markdown_content"&gt;&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;could you please recode the source code from ISO-8859-1&lt;br /&gt;
to UTF-8, which is what the toolsets expect? It causes&lt;br /&gt;
real trouble with IBM's JDK, which refuses to compile&lt;br /&gt;
those files by default. Other JDK's should work as&lt;br /&gt;
expected with UTF-8 files, by default.&lt;/p&gt;
&lt;p&gt;It's trivial to do with GNU Recode: recode&lt;br /&gt;
latin1..utf-8 file.java&lt;/p&gt;
&lt;p&gt;Thanks.&lt;/p&gt;
&lt;p&gt;PS: contact me for a patch if you don't have access to&lt;br /&gt;
GNU Recode.&lt;/p&gt;&lt;/div&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Javier Kohen</dc:creator><pubDate>Wed, 06 Apr 2005 17:32:11 -0000</pubDate><guid>https://sourceforge.net3f41d268adaabe3a6b38720cfa30f45ad241615a</guid></item></channel></rss>