On Tue, 16 Nov 2021 18:24:15 GMT, Jonathan Gibbons <j...@openjdk.org> wrote:
> > After having looked at this change, I think I might have fallen prey to the > > famous "XY problem". Instead of asking on how to emulate error conditions > > in a black-box fashion first, I asked to provide white-box support for > > those through JavadocTester. > > I didn't see the question this way, and I thought the JBS issue was well > stated. > > Setting aside `JavadocTester` for a moment, there were two ways to solve the > general problem of triggering exceptions to emulate weird conditions. > > 1. Build back doors into the main system `JavaFileManager` ... i..e. > `JavacFileManager` (note `Javac`), such that the code can be triggered by > backdoor access, either reflective, or breaking abstraction or system > properties. > 2. Provide a new file manager to do the job. > > [...] I should've asked an even more general question before creating JDK-8276892: How can I _trigger_ an error from specific operations on a FileManager and a FileObject returned from that FileManager? A simulation through a custom implementation of these types that this PR proposes would be one answer. However, such a simulation is the white-box approach, and as far as I understand, JDK contributors traditionally prefer the black-box approach. In the black-box approach, one seeks ways to emulate the environment that would yield the desired effect. For example, to trigger IOException on an attempt to delete a file, I would ensure that the path does not exist or that the JVM has insufficient file-system permissions to access that path. Here's another example. To achieve socket blocking on write, I would fill it in with as much data as possible (SO_SNDBUF) while simultaneously ensuring that no one reads from it. If you say that a black-box approach is impossible or impractical here, I'll be fine with the white-box approach along the lines of what this PR suggests. ------------- PR: https://git.openjdk.java.net/jdk/pull/6404
