OOI, why are the stubs in query-tests instead of stubs? And why do we need JDK stubs in the first place?

In order to test the query on the top-500 JDK APIs, I needed a database containing those top-500 APIs as callables (since the query is database-dependent and counts APIs as callables). So the stubs are not really being used as stubs here, but rather as the code that the query is being tested against. Let me know if you have a better idea regarding how to set this test case up. 😄
(Note that this is the same structure as the original test case for this query, but at a larger scale since the top-500 JDK API test case is testing against many more models).

Yes, that's because utils is under src, and you can import lib modules in src, but not the other way around.

Ah, sorry, my question wasn't clear; I knew the issue was because utils.modelgenerator.internal.CaptureModels is under src, but I wanted to make sure that where I ended up placing the .qll files due to that issue was okay.
Although, I think this issue will actually be resolved once I change this query to not use DataFlowTargetApi anymore.

So the stubs are not really being used as stubs here, but rather as the code that the query is being tested against.

Ah, I see! Thanks for the clarification. I was a bit misled by the name, but they are stubs, so it makes sense. The alternative would be adding code that makes all those calls so that they are extracted, which seems equally bothersome, so I think it's good as it is 😄.

I wanted to make sure that where I ended up placing the .qll files due to that issue was okay.

It looks okay to me. The only thing we should keep in mind is that TopJdkApis.qll will now be part of our public API, which means that users will be able to use it, any breaking change will need to go through the deprecation process, and so on. But since you're using it both in src and test, I don't think we have many alternatives.

The only thing we should keep in mind is that TopJdkApis.qll will now be part of our public API, which means that users will be able to use it, any breaking change will need to go through the deprecation process, and so on.

Would storing TopJdkApis.qll in the ../src/Metrics/Summaries directory instead avoid this situation? It's importable in the test directory when stored there.

Or would it make sense to at least put an INTERNAL use only. comment in the file similar to the comment in ExternalFlow.qll?

It's importable in the test directory when stored there.

Ah, then I think I slightly favor having it in src.

Ah, then I think I slightly favor having it in src.

Moved in b534f40.

Also, I renamed the stubs directory to just TopJdkApis to avoid confusion with the name.