8256308: Send arguments to javac server in a config file #1195
Currently, to use the javac server, a horrendously long command line option is created, looking like this:
Apart from making java command lines hard to read (and copy/paste!) by developers, it also makes it hard for scripts to parse. The upcoming winenv rewrite is dependent on being able to differentiate between path names and other arguments, which is not possible in this mess.
So, instead, let's write it to a file, without any escaping, and just pass the configuration file name to the server.
Note that this will change the behavior of the javac server, but as the source code states this is not a documented or externally supported API no CSR is needed.
I also cleaned up some code in SjavacClient, in particular code relating to the passing of arguments. (We never change poolsize or keepalive when we call it.)
@magicus This change now passes all automated pre-integration checks.
After integration, the commit message for the final commit will be:
At the time when this comment was updated there had been 192 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.
jonathan-gibbons left a comment
There seems to be much more here than there needs to be.
If the issue is just long command lines, then the obvious/conventional solution would be to use @files, which would be a tiny change to the sjavac source code, to insert a single call to
So, before reading all the various details in this proposed change, is there any reason why the simple @file solution cannot be used?
The main issue is not the long command lines. Getting shorter command lines is nice, but more a side-effect.
The real driver here is the awkward encoding of the command line, with spaces replaced by %20. This makes it impossible to parse the --server option to Java and properly replace unix paths with Windows paths, in the way that is needed by the upcoming changes to how we build on Windows.
I hope I could adequately answer why @files is not a solution to the
Since this is a blocker for the winenv rewrite, I'd very much like to
On 2020-11-16 13:43, Magnus Ihse Bursie wrote:
@magicus Since your change was applied there have been 194 commits pushed to the
Your commit was automatically rebased without conflicts.
Pushed as commit 9e4944f.
Reviewed-by: erikj, jfranck