I mean, the IDE can totally write out the import statements for you as you type and choose resolutions for identifiers; but if you paste in a random code snippet that references ambiguous identifiers from a third-party lib, no IDE can magically generate the import statements required to discriminate the correct resolutions. You have to go through and resolve the symbols yourself (or advance through them as error sites to get the class to compile.)

Or, to put that another way: import statements aren’t pure boilerplate that should be thrown away; they encode real information (ambiguous symbol resolutions); and so, by eliding them from code examples, you’re discarding that information and forcing the learner to re-derive it.

Which is especially bad when your code examples are referencing ambiguous undocumented static inner classes nested deep inside your library’s package namespace, where all the potential resolutions differ only by the particular package they exist in (since they’re all e.g. essentially batteries-included extensions of the base library implementing the same interface.) And where all this structure is as ugly as it is precisely because you didn’t expect the end-user of the library to need to understand it / interact with it. Yet your own [usually “advanced” or “feature demonstrating”] code examples force exactly that.