On 27/05/13 13:56, leuchtkaefer wrote: > > > Hello, > I want to simulate the Library functionality. > How can I test the SkeletonBTreeMap? > The documentation doesn't explain and I cannot see any test in the source > code. I checked the tests on fred and Library source. > Is there any other place that I should check? Should I check the spider? >
(I haven't worked on the code for years, so the following information might be out-of-date.) AFAIK there are no unit tests for SkelBTreeMap. Having tests for it would be superb, but it would also take significant engineering effort, since it heavily depends on IO. To even begin writing tests, you would need to write a mocking framework for Library's IO code. I'm not sure whether you would want to do that as a GSoC student, and I'm not sure if it would bring enough significant benefit to justify the cost. General comments about the implementation of Library: most of the code is in a blocking/synchronous form. You should get to know concurrency libraries well - first the Java concurrency library, then perhaps the Guava concurrency library too. Unfortunately due to historical reasons, Freenet implements its own concurrency primitives, which are not the best. It would be excellent if you could replace much of this legacy code with the shiny modern libraries I just mentioned. It's important to know concurrency libraries, as they abstract out a lot of the complexity and potential bugs in writing concurrent operations; IMO, in high-level application logic, if you find yourself explicitly directly using a mutex/condvar, your design is likely to be flawed. As a side issue, I now much prefer asynchronous/non-blocking form. Typically, one advantage that sync code has above async code is that it can feel "more intuitive". However, this is a red herring, since without proper understanding of concurrency theory it's so easy to run into livelock / deadlock issues. With network servers parallel execution is not really necessary, so you are actually much better off writing async code that executes in a single thread. Callback-based async code is hard to understand, but in recent times (maybe 4-5 years) the Google Java library, Guava, has now has support for monadic Futures (ListenableFuture)[1] which produces async code that has a much more linear structure (using Futures.transform, the monadic bind operation over ListenableFuture). (In Scala the monadic structures made explicit.) [1] Java's java.util.concurrent.Future is inadequate and only supports synchronous operation. > Thanks, > leuchtkaefer > _______________________________________________ > Devl mailing list > [email protected] > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl -- GPG: 4096R/5FBBDBCE https://github.com/infinity0 https://bitbucket.org/infinity0 https://launchpad.net/~infinity0
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
