On 09/19/2016 07:16 PM, Jarl Fransson wrote:
> It turns out there is a problem with the design of Context as a
> ThreadLocal value. There is static data that bitcoinj depends on.
> * When the tests are run from maven "mvn test" many tests run in parallel.
> * Some tests define there own Context in the setUp() method of the test.
> e.g. in base class TestWithWallet.setUp:
> Subclasses sometimes override this and the JUnit testrunner will make a
> mess out of this for each test with a different Context. Note that
> bitcoinj has a few static threads it relies on and these will now change
> Context in non-determined ways, concurrently with running other tests.
> * Tying the Context to the Thread and when threads are re-used or pooled
> for different tests means that Context objects leak and you never really
> know what Context.get() will return.
> Rethink Context design. It was really not very well thought out!
> In my case replacing Context.get() with wallet.getContext() solved the
> problem. I propose deprecating Context.propagate/get and insted rely on
> explicit final fields with the Context in instances of Wallet, Peer,
> PeerGroup, AbstractBlockChain etc as needed.
> This change should also, if completed thoroughly, allow bitcoinj to
> simultaneously connect to different networks/blockchains in the same
So you suggest to deprecate the use of ThreadLocal for Context?
The idea of contexts is we don't need to carry it around on lots of
calls. Not sure if we want to go back to where we came from. Also afaicr
the context refactoring isn't finished yet.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.