Thank you Remi and David for your detailed explanations, this was very helpful, and I understand the issues now. Please go ahead and close the Jira bug I created for this (JDK-8173252), I see this is WAI.
On Tue, Jan 24, 2017 at 12:39 AM, <fo...@univ-mlv.fr> wrote: > Here is your code slightly modified, with no lambda, that deadlock too: Thanks, I discovered that I hit a deadlock with anonymous inner classes when I access fields in the enclosing class too. On Tue, Jan 24, 2017 at 1:39 AM, David Holmes <david.hol...@oracle.com> wrote: > I have to second Remi's view here - hidden concurrency is an accident > waiting to happen, far too many things can go wrong if the users of your > API don't know that new threads can be involved. FastClasspathScanner only uses concurrency for its own internal processing. The standard API that most users call is synchronous, and blocks on response. The user-provided lambdas in question are run single-threaded on a separate thread, but it does not execute concurrently with the main thread (which is blocked), precisely to prevent surprises. If the user calls the async API, they should understand about concurrency. I agree that in general the burden falls to the user to read the docs and understand the threading considerations of a given library. In the end I decided to throw an exception if there is a "<clinit>" line in the stacktrace. This is better than the possibility of hitting a deadlock. The following makes me think though that I should refactor my code to ensure that, for the synchronous API, user-supplied methods are always executed on the calling thread: If the lambda code is called on the main thread and accesses the LambdaBug > class it will see it as a recursive initialization attempt and simply > return.
