Calling a lambda expression from a new thread before the main method is run causes the thread to lock up

[Luke Hutchison]

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, <forax at 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.holmes at 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.