On Tue, 22 Nov 2022 19:54:51 GMT, Magnus Ihse Bursie <i...@openjdk.org> wrote:
> Now that the javacserver no longer has any ambitions outside being a > buildtool customized for the JDK build process, a lot of abstractions and > generalizations can be removed. > > This will allow the actual behavior to be more clearly visible, and will help > debugging the issues we are still seeing (most likely race conditions), and > to convert the tool to use the ToolProvider API in the future. The remaining changes are "pure" refactorings. I have moved code around, and reworked the abstraction layers. Basically, I put everything pertaining to the client in a long sequence (calling the client is basically a trivial sequence of events), and similarly for the server. Code that were shared between both were put in the `shared` or `util` packages (the latter for more auxiliary classes, the former for more central). Everything else were mercilessly removed. I then abstracted out what seemed like reasonable parts from the long sequences in Client and Server, in the process mostly recreating the thread pool and idle detection classes of the former structure (so git will present them as renames). I've been extra careful not to change any behavior regarding the portfile locking and synchronization, or the actual protocol exchanged by the server and client (with one exception: the exit code from javac is now returned as an integer, and not as a string representing the `Result` enum.) I believe there are a number of places where races can be introduced, and I intend to come back later and try to patch this. But I deemed it essential that I do not change any behavior in that regard in this patch, otherwise it would be hopeless to know if a potential future regression was caused by a mistake in my refactoring, or that any changed behavior was faulty. ------------- PR: https://git.openjdk.org/jdk/pull/11298
