On Fri, Nov 7, 2008 at 4:16 PM, Jiří Kuhn <[EMAIL PROTECTED]> wrote: > I'm interested in ListenerFactory a little bit, as you may know. Ther was no > ListenerFactory in 1.0.0-M3 build therefore I aked question myself why is > there now. First commit message of the class sais: Make listeners immutable > (FTPSERVER-187). The JIRA issue contains no discussion to be informed more > about the reason (which is quite obvious for those who was trying to embed > ftpserver before).
There has been descriptions on this change in general earlier on this list, I'll try dig them up if you want. The reasoning is that immutable classes are thread safe without any additional effort, and highly efficient in a concurrent environment. Now, Listeners are not really immutable (the commit log is somewhat incorrect) since they can be started/stopped/suspended. But, what we did was to remove the possibility of reconfiguring them while running, something that caused quite a few problems (not only with listeners, but with all configurable classes). > But my question now is - isn't the immutability only an illusion? Calling > ListenerFactory.createListener() more then once produces several instances > of NioListener but these instances share those object instances of > ListenerFactory which are not primitive types. Isn't it? And is it correct? Yes, correct. Note that if you're using the implementations shipped with FtpServer, those other objects would also be immutable and thus I don't think this is a problem, right? Of course, anyone can provide their own implementations and doing so, all bets are off. /niklas
