Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Getting Started Repl doesnt start on WIndows w/ Oracle Java 15 and 16 #1162

Closed
stuartstein777 opened this issue Apr 30, 2021 · 54 comments
Closed
Labels
bug Something isn't working jack-in upstream

Comments

@stuartstein777
Copy link

Issue Type: Bug

Click nREPL in bottom toolbar
Click Fire Up Getting Started REPL
Click Use Existing Directory
repl fails to start with the error in the terminal:

The output window shows
; Jacking in...
; Starting Jack-in Terminal: java -jar ".calva\deps.clj.jar" -Sdeps "{:deps {nrepl/nrepl {:mvn/version,""0.8.3""},cider/cider-nrepl {:mvn/version,""0.25.11""}}}" -m nrepl.cmdline --middleware "[cider.nrepl/cider-middleware]"

The terminal, on fail, shows:
java -jar ".calva\deps.clj.jar" -Sdeps "{:deps {nrepl/nrepl {:mvn/version,""0.8.3""},cider/cider-nrepl {:mvn/version,""0.25.11""}}}" -m nrepl.cmdline --middleware "[cider.nrepl/cider-middleware]"
Error while parsing option "--config-data {:deps {nrepl/nrepl {:mvn/version,0.8.3},cider/cider-nrepl {:mvn/version,0.25.11}}}": java.lang.NumberFormatException: Invalid number: 0.8.3
Jack-in process exited. Status: 1

Extension version: 2.0.194
VS Code version: Code 1.55.2 (3c4e3df9e89829dce27b7b5c24508306b151f30d, 2021-04-13T09:35:57.887Z)
OS version: Windows_NT x64 10.0.18363

System Info
Item Value
CPUs Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz (8 x 2712)
GPU Status 2d_canvas: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
oop_rasterization: enabled
opengl: enabled_on
protected_video_decode: unavailable_off
rasterization: enabled
skia_renderer: enabled_on
video_decode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled
Load (avg) undefined
Memory (System) 15.89GB (3.60GB free)
Process Argv --crash-reporter-id 88f8d9b0-038d-493b-8525-6ef9c92ebe8c
Screen Reader no
VM 0%
e to send. Please paste.
@bpringe bpringe added bug Something isn't working jack-in labels May 1, 2021
@bpringe
Copy link
Member

bpringe commented May 1, 2021

Thanks for the report.

@PEZ
Copy link
Collaborator

PEZ commented May 1, 2021

Not sure I would label this a bug, at least not if the label is to indicate a bug in our code. It could be, but so far it seems to be rather upstreams and far upstream and tricky to figure out.

There are many layers to this. And some of those are unknown (at least to me), making it extremely difficult. For instance, it is unclear to me how the shell being used is determined. A while back I changed from using the Clojure CLI to deps.clj and a java command line. WorksOnMyMachine(s), and on many more of the ones where the Clojure CLI method didn't work.

(With Leiningen we use a cmd.exe command line.)

I am unsure what the ratio is between Windows machines where it is working and where it is not. Maybe it is 90/10, maybe something else... Everytime I try to fix this it seems to be improved (but what do I know), but also does not nail it 100%. The sample size is not big since most Windows users are wise enough to use WSL for development work.

Neither the Getting Started REPL nor the Standalone REPL can assume WSL. They need to work with the least common denominator. I might give up on this pipe dream at some point, and just tell Windows users that if the Getting Started REPL works, celebrate, and otherwise point them at some longer path to get to test the Clojure REPL plugged to the editor. But I am not there yet. (Probably should figure out how to inform about the longer path meanwhile, but anyway).

There are at least two parameters to the puzzle that I know of.

  1. The quoting
  2. A shell boolean I can pass to child_process.spawn()

The shell boolean determines if spawn() will use a shell to spawn the command line or just plain Windows. I am not very clear about what that means, but from what I have understood one difference is that more of the user's environment can be assumed to be present in the shell scenario. From experience I also know that it influences the effect of the quoting.

The current command line, let's denote it A, is built using a system where arguments are double quoted, let's denote DQ and double quotes in arguments use ”doubled double quotes”, let's call it DDQ and shell: true:

A: DQ+ DDQ + `shell:true``

  • Command line:
    java -jar ".calva\deps.clj.jar" -Sdeps "{:deps {nrepl/nrepl {:mvn/version,""0.8.3""},cider/cider-nrepl {:mvn/version,""0.25.11""}}}"  -m nrepl.cmdline --middleware "[cider.nrepl/cider-middleware]"
    
  • WorksOnMyMachines(s)
  • Maybe works on 90/100 machines?
  • Doesn't work on @stuart's nor @stianalmaas's machines
  • The command line doesn't work from a PowerShell prompt
  • The command line works from a CMD prompt

Despite not really having the time for this now I just conducted some experiments.

B: DQ + DDQ + shell:false

  • Command line:
    java -jar .calva\deps.clj.jar -Sdeps "{:deps {nrepl/nrepl {:mvn/version,""0.8.3""},cider/cider-nrepl {:mvn/version,""0.26.0""}}}"  -m nrepl.cmdline --middleware '[cider.nrepl/cider-middleware]'
    
  • OnMyMachine fails in some similar ways regardless if from Calva or from prompts, PS or CMD.

I think this indicates that OnMyMachine PowerShell is used when shell:false. So trying with single quotes (SQ) and backslash quoted double quotes (BDQ).

C: SQ + BDQ + shell:false

  • Command line:
    java -jar .calva\deps.clj.jar -Sdeps '{:deps {nrepl/nrepl {:mvn/version,\"0.8.3\"},cider/cider-nrepl {:mvn/version,\"0.26.0\"}}}'  -m nrepl.cmdline --middleware '[cider.nrepl/cider-middleware]'
    
  • OnMyMachine Getting Started REPL command fails with
    Error building classpath. Don't know how to create ISeq from: clojure.lang.Symbol
    
  • OnMyMachine this works from the PS prompt
  • OnMyMachine this fails from the CMD prompt, with the exact same message as with the Getting Started REPL command

So, now maybe that indicates the command is being run through the CMD shell after all? At least OnMyMachine... What about other people's machines?

I'm stuck for now. Maybe I should try with a cmd.exe command line like with Leiningen. Even if I know I have tried that at some point too, but there are many moving parts so maybe the right combination has never been tried...

@borkdude
Copy link

borkdude commented May 1, 2021

You can diagnose how CLI args get passed through to Clojure command line args like this with babashka:

bb -e "*command-line-args*" -- 1 2 3
("1" "2" "3")

E.g. in cmd.exe:

bb -e "*command-line-args*" -- -Sdeps "{:mvn/version """1.10.3"""}"
("-Sdeps" "{:mvn/version \"1.10.3\"}")

In Powershell:

bb -e "*command-line-args*" -- -Sdeps '{:mvn/version \"1.10.3\"}'
("-Sdeps" "{:mvn/version \"1.10.3\"}")

I don't understand what cmd.exe and Powershell have to do with this if you are launching the process from NodeJS. The shell isn't involved in that case.
When shelling out from Java on Windows I usually have to apply this trick:

https://github.com/babashka/process/blob/eba04e6c35814296e5bb383804f801aee912cba1/src/babashka/process.clj#L152

PS: you can install babashka on Windows easily with scoop:

https://github.com/littleli/scoop-clojure

@PEZ
Copy link
Collaborator

PEZ commented May 1, 2021

Thanks!

I don't understand what cmd.exe and Powershell have to do with this if you are launching the process from NodeJS. The shell isn't involved in that case.

I don't really understand this, as must be obvious from my comment above. But something is interpreting the command line and needs quoting of some kind. And it seems that this something is different on different machines. Also I want the command line echoed to work if the user copies it and pastes it on the prompt. In which case it is good to know which kind of prompt. And, since the shell option to spawn() makes a difference in the quoting, I think maybe the shell is involved in that case, even if I don't know which shell.

I'll try that trick of yours now...

@borkdude
Copy link

borkdude commented May 1, 2021

From https://nodejs.org/api/child_process.html#child_process_spawning_bat_and_cmd_files_on_windows:

Spawning .bat and .cmd files on Windows#
The importance of the distinction between child_process.exec() and child_process.execFile() can vary based on platform. On Unix-type operating systems (Unix, Linux, macOS) child_process.execFile() can be more efficient because it does not spawn a shell by default. On Windows, however, .bat and .cmd files are not executable on their own without a terminal, and therefore cannot be launched using child_process.execFile(). When running on Windows, .bat and .cmd files can be invoked using child_process.spawn() with the shell option set, with child_process.exec(), or by spawning cmd.exe and passing the .bat or .cmd file as an argument (which is what the shell option and child_process.exec() do). In any case, if the script filename contains spaces it needs to be quoted.

Since you are launching java I think you can get away with NOT using the shell option (unlike when you are running the clojure CLI which is a shell script).

@borkdude
Copy link

borkdude commented May 1, 2021

FWIW, this older clj-kondo plugin for VSCode ran the clj-kondo binary in this way:

https://github.com/marcomorain/clojure-lint/blob/86f699258d7478d44237241ecf1f0be914170887/src/extension.ts#L55

AFAIK it worked cross-platform (and probably still works)

@PEZ
Copy link
Collaborator

PEZ commented May 1, 2021

I don't think we can use execFile() because Calva jack-in is not fire-and-forget, we need to be able to communicate with the process. Anyway, we use spawn() in about an identical way as in that example, which never enters double quote hell.

@PEZ
Copy link
Collaborator

PEZ commented May 1, 2021

Since you are launching java I think you can get away with NOT using the shell option (unlike when you are running the clojure CLI which is a shell script)

I think so too. Just haven't succeeded with that yet. Not for lack of trying.

PEZ added a commit that referenced this issue May 1, 2021
@lread
Copy link

lread commented May 1, 2021

@PEZ at one point I decided I would figure Windows shell escaping out and started taking notes.
I did not get very far before my mind got very numb.
Here are my nascent notes for what they are worth: https://github.com/lread/info-process-builder

@PEZ
Copy link
Collaborator

PEZ commented May 1, 2021

Thanks @lread . I'll certainly check that out because I have also tried to lay this puzzle and I get dizzy. 😄

@PEZ
Copy link
Collaborator

PEZ commented May 1, 2021

The quoting problems seems to have been a red herring. In my Windows dev environment I have removed the quoting out of the picture (latest #1164 VSIX also has this build) which worked on that machine until I upgraded Java.

So the failure seems to be introduced somewhere between Java 8 and Java 15, I haven't bisected it down further than that right now.

Now I am actually stuck again. Can't think of a single thing I can try to make this work. I am hoping som sleep will help.

@PEZ
Copy link
Collaborator

PEZ commented May 2, 2021

I have now tried with Java 12 and the command works then. So the error is then introduced with Java 13, 14 or 15, I guess. Here is some sort of reproduction:

From a directory with deps.clj.jar in it (the .calva directory in the temp folder created by the Getting Started REPL will do):

  1. Start a CMD prompt (if you are using a VS Code terminal use the dropdowns or execute cmd from the PS prompt)
  2. Execute the following command:
    java -jar deps.clj.jar -Sdeps "{:deps {nrepl/nrepl {:mvn/version,""0.8.3""},cider/cider-nrepl {:mvn/version,""0.26.0""}}}"  -m nrepl.cmdline --middleware "[cider.nrepl/cider-middleware]"

Expected:
The nREPL server is started

Actual, using Java 12:
The nREPL server started

Actual, using Java 15 and 16:

Error: Could not find or load main class clojure.main
Caused by: java.lang.ClassNotFoundException: clojure.main

Now I would want to try this with the Clojure CLI as well, but I can't get that to work on my Windows machine. So if someone with the Clojure CLI working on Windows could try this that would be awesome. (Just replace java -jar deps.clj.jar with clojure on the above command line.)

NB: Not that Clojure CLI is an option for the Getting Started REPL, which only requires Java. It is for trying to locate where the error happens.

@PEZ
Copy link
Collaborator

PEZ commented May 2, 2021

Removed some confusing comments. It seems that even if java -version reports a version, it is not necessarily what is used when actually running the command. Creating a new shell after installing java15 actually reproduces the error.

@PEZ
Copy link
Collaborator

PEZ commented May 2, 2021

And now I think I have confirmed that the error seems to happen only with the Java 15 and 16 (and possibly earlier versions) installed with Oracle's installer. Using adopt15-hotspot installed with scoop the Getting Started REPL works with currently released Calva as well as with the this #1164 VSIX:

Which does not add any quoting what so ever to the command shelled out on Windows.

@PEZ PEZ changed the title Getting Started Repl doesnt start on WIndows Getting Started Repl doesnt start on WIndows w/ Oracle Java 15 and 16 May 2, 2021
@stianalmaas
Copy link

I have tried to test some variations on my machine, since it looks like @stuartstein777 have similar issues. If I run from Windows cmd it works, on all versions of java that I have.

Here with Java 16:
`C:\Users\stian\AppData\Local\Temp\betterthantomorrow.calva\ur5dk.calva>java -version
java version "16" 2021-03-16
Java(TM) SE Runtime Environment (build 16+36-2231)
Java HotSpot(TM) 64-Bit Server VM (build 16+36-2231, mixed mode, sharing)

C:\Users\stian\AppData\Local\Temp\betterthantomorrow.calva\ur5dk.calva>java -jar deps.clj.jar -Sdeps "{:deps {nrepl/nrepl {:mvn/version,""0.8.3""},cider/cider-nrepl {:mvn/version,""0.26.0""}}}" -m nrepl.cmdline --middleware "[cider.nrepl/cider-middleware]"
nREPL server started on port 54590 on host kubernetes.docker.internal - nrepl://kubernetes.docker.internal:54590`

Here with Java 11:
`C:\Users\stian\AppData\Local\Temp\betterthantomorrow.calva\ur5dk.calva>java -version
java version "11.0.11" 2021-04-20 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.11+9-LTS-194)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.11+9-LTS-194, mixed mode)

C:\Users\stian\AppData\Local\Temp\betterthantomorrow.calva\ur5dk.calva>java -jar deps.clj.jar -Sdeps "{:deps {nrepl/nrepl {:mvn/version,""0.8.3""},cider/cider-nrepl {:mvn/version,""0.26.0""}}}" -m nrepl.cmdline --middleware "[cider.nrepl/cider-middleware]"
nREPL server started on port 54775 on host kubernetes.docker.internal - nrepl://kubernetes.docker.internal:54775`

And now the Getting started REPL in Calva also works!

This one is a proper Heisenbug indeed.

What I did was open a powershell in VS Code. There I started the cmd shell and ran the command :
java -jar deps.clj.jar -Sdeps "{:deps {nrepl/nrepl {:mvn/version,""0.8.3""},cider/cider-nrepl {:mvn/version,""0.26.0""}}}" -m nrepl.cmdline --middleware "[cider.nrepl/cider-middleware]"
I had Java 11 active. This downloaded and started up the nREPL server.

After that every combination I have tried has worked. I have set Java 16 in JAVA_HOME and path, and started from cmd. And now it also works in Calva.

java -jar .calva\deps.clj.jar -Sdeps {:deps {nrepl/nrepl {:mvn/version,"0.8.1"},cider/cider-nrepl {:mvn/version,"0.26.0"}}} -m nrepl.cmdline --middleware [cider.nrepl/cider-middleware] Downloading: nrepl/nrepl/0.8.1/nrepl-0.8.1.pom from clojars Downloading: nrepl/nrepl/0.8.1/nrepl-0.8.1.jar from clojars nREPL server started on port 55059 on host kubernetes.docker.internal - nrepl://kubernetes.docker.internal:55059

Here I have downgraded the nrepl version to see if the download affects something. It didn't.

@PEZ
Copy link
Collaborator

PEZ commented May 2, 2021

Thanks, @stianalmaas !

How does docker and kubernetes fit into your setup? Can you also paste the output from the Jack-in terminal, when it works?

@stianalmaas
Copy link

I have Docker Desktop for Windows installed. Isn't it normal that the nREPL server uses that?

Here is what the output looks like when starting up:

; Jacking in...
; nREPL Connection was closed
; Starting Jack-in Terminal: java -jar .calva\deps.clj.jar -Sdeps {:deps {nrepl/nrepl {:mvn/version,"0.8.1"},cider/cider-nrepl {:mvn/version,"0.26.0"}}}  -m nrepl.cmdline --middleware [cider.nrepl/cider-middleware]
; Hooking up nREPL sessions...
clj꞉user꞉> 
; Jack-in done.
clj꞉user꞉> 
; Evaluating file: hello_repl.clj
"hello_repl.clj is loaded, and ready with some things for you to try."
clj꞉hello-repl꞉> 

@lread
Copy link

lread commented May 2, 2021

@PEZ, I haven't been following your attempts and strategies closely, and maybe you have thought of this already but:

I wonder if deps.clj could be modified to retrieve its args from a specified generated file rather than the command line. This way you could remove Windows escaping rules from the equation.

So maybe you'd have:

java -jar .calva/deps.clj.jar -Sargs-file some-generated-args-file.edn

Would something like that maybe help?

@stianalmaas
Copy link

@PEZ I also managed to get it working with the Clojure CLI now. For that I have to use Powershell. The trick here was to escape the double-quotes with back-ticks. Like this:


PS C:\Users\stian\AppData\Local\Temp\betterthantomorrow.calva\ur5dk\.calva> clojure -Sdeps "{:deps {nrepl/nrepl {:mvn/version,`"`"0.8.3`"`"},cider/cider-nrepl {:mvn/version,`"`"0.26.0`"`"}}}"  -m nrepl.cmdline --middleware "[cider.nrepl/cider-middleware]"
WARNING: When invoking clojure.main, use -M
nREPL server started on port 58254 on host kubernetes.docker.internal - nrepl://kubernetes.docker.internal:58254

This also works with Java, so it seems everything works no matter what I do...


PS C:\Users\stian\AppData\Local\Temp\betterthantomorrow.calva\ur5dk\.calva> java -jar deps.clj.jar -Sdeps "{:deps {nrepl/nrepl {:mvn/version,`"`"0.8.3`"`"},cider/cider-nrepl {:mvn/version,`"`"0.26.0`"`"}}}"  -m nrepl.cmdline --middleware "[cider.nrepl/cider-middleware]"
nREPL server started on port 58273 on host kubernetes.docker.internal - nrepl://kubernetes.docker.internal:58273

But maybe it is better to think outside the box as @lread suggests.

@PEZ
Copy link
Collaborator

PEZ commented May 2, 2021

Latest findings is that

  1. Clojure CLI suffers from the same problems
  2. It so far only is related to the java executable that the Oracle installer wires up as the current

Using the command line from https://clojure.atlassian.net/browse/TDEPS-133#icft=TDEPS-133 as an example:

PS C:\Program Files\Common Files\Oracle\Java\javapath> .\java.exe -jar .\deps.clj.jar -Sdeps '{:deps {viebel/klipse-repl {:mvn/version \"0.2.3\"}}}' -m klipse-repl.main
Error while parsing option "--config-data {:deps {viebel/klipse-repl {:mvn/version 0.2.3}}}": java.lang.NumberFormatException: Invalid number: 0.2.3
PS C:\Program Files\Common Files\Oracle\Java\javapath>

But:

PS C:\Program Files\Java\jdk-16.0.1\bin> .\java.exe -jar .\deps.clj.jar -Sdeps '{:deps {viebel/klipse-repl {:mvn/version \"0.2.3\"}}}' -m klipse-repl.main
Welcome to Klipse REPL (Read-Eval-Print Loop)
Clojure 1.10.3
user=>

Both experiments need to be run with this setting of JAVA_CMD:

PS C:\ ...\bin> $env:JAVA_CMD = ".\java.exe"

(No, it doesn't matter if we try with other quoting. It is not related to our quoting.)

Note that the Oracle installer installs both these executables. One is fine, the other is not. Problem is that it makes the one not working the default, and that cause the Getting Started REPL to fail.

@bpringe
Copy link
Member

bpringe commented May 2, 2021

Great isolation of the problem! This has been quite a journey that I've been following.

@PEZ
Copy link
Collaborator

PEZ commented May 2, 2021

@lread, I doubt that would help. The args are delivered just fine to java and to deps.clj.

@borkdude
Copy link

borkdude commented May 2, 2021

@PEZ Can you also add to the details whether you set the environment variable JAVA_CMD to the local directory's java.exe executable? This is important to mention because if you don't set it, then deps.clj will pick up the java.exe that is on the system's PATH.

@borkdude
Copy link

borkdude commented May 2, 2021

To check from a REPL which Java version you are running: (System/getProperty "java.version") and (System/getProperty "java.vendor").

@PEZ
Copy link
Collaborator

PEZ commented May 2, 2021

Updated the comment above with info about setting JAVA_CMD.

@borkdude
Copy link

borkdude commented May 3, 2021

Also note that @PEZ could not pass Java properties with the "system" Oracle JDK 16:

PS C:\Program Files\Java\jdk-16.0.1\bin> java -Djdk.lang.process.allowAmbiguousCommands=true PrintArgs '\"bar\"'
Error: Could not find or load main class .lang.process.allowAmbiguousCommands=true

I'm not sure what we're dealing with here, it looks like the Oracle JDK 16 wrapper is seriously screwing up command line parsing in multiple ways. Have you included this in the issue Oracle issue @PEZ? If not, I think it warrants another issue.

@eerohele
Copy link

eerohele commented May 3, 2021

This might've been covered by one of the earlier posts in this thread, but this workaround (for a project REPL, not for a getting started REPL — sorry!) works on my colleague's Windows machine:

image

That is, wrap every value in the Value column in double double quotes.

Java version:

java version "15.0.2" 2021-01-19
Java(TM) SE Runtime Environment (build 15.0.2+7-27)
Java HotSpot(TM) 64-Bit Server VM (build 15.0.2+7-27, mixed mode, sharing)

Output of where java:

C:\Program Files\Common Files\Oracle\Java\javapath\java.exe
C:\Program Files (x86)\Common Files\Oracle\Java\javapath\java.exe

@PEZ
Copy link
Collaborator

PEZ commented May 3, 2021

Thanks, @eerohele Very good to know about this workaround!

Just tell your colleague to remember to reset those settings later, because it probably will mess up jack-in to other project types. (And also, already is not following the latest Calva which is using cider-mrepl 26.0).

@PEZ
Copy link
Collaborator

PEZ commented May 3, 2021

java version "15.0.2" 2021-01-19

Very interesting that it seems to hit also on JDK15. Note to self: I should check if the issue I reported to Oracle is reproducable there as well.

@borkdude
Copy link

borkdude commented May 3, 2021

@PEZ Can you please specify when you mention a Java version, also if this is Oracle or some other vendor's JDK?

@PEZ
Copy link
Collaborator

PEZ commented May 3, 2021

I was mainly quoting from the comment above.

But to elaborate some little more on where this seems to live, I've only seen it in the ..../javapath/java.exe wrapper (if that is what it is). If I install Oracle's OpenJDK using scoop I don't get the problem.

@eerohele
Copy link

eerohele commented May 3, 2021

Oh, sorry — the workaround above was not for a Getting Started REPL, it's for a project REPL. So it might be a workaround for a different (but maybe related?) issue?

Apologies for muddying the waters!

PEZ added a commit that referenced this issue May 3, 2021
@PEZ
Copy link
Collaborator

PEZ commented May 3, 2021

@eerohele is it a deps.edn project?

@eerohele
Copy link

eerohele commented May 3, 2021

Leiningen.

@borkdude
Copy link

borkdude commented May 3, 2021

@PEZ Can you test the following with the PrintArgs test program?

Put some args in a file called args.txt:

-Dfoo.bar=xs PrintArgs 1 2 3 "\"dude\""

Then run java like this:

java @args.txt

On macOS JDK 11 (AdoptOpenJDK) I see the output:

1
2
3
"dude"

If this workaround works, perhaps that will be an escape hatch.

Hat tip to @lread for suggesting this.

@PEZ
Copy link
Collaborator

PEZ commented May 3, 2021

There is hope!

PS C:\Users\Public\javaargs> type args.txt
-Dfoo.bar=xs PrintArgs 1 2 3 "\"dude\""
PS C:\Users\Public\javaargs> java '@args.txt'
1
2
3
"dude"
PS C:\Users\Public\javaargs> java -version
java version "16.0.1" 2021-04-20
Java(TM) SE Runtime Environment (build 16.0.1+9-24)
Java HotSpot(TM) 64-Bit Server VM (build 16.0.1+9-24, mixed mode, sharing)
PS C:\Users\Public\javaargs> get-command java

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Application     java.exe                                           16.0.1.0   C:\Program Files\Common Files\Oracle\Java\javapath\java.exe


PS C:\Users\Public\javaargs>

@borkdude
Copy link

borkdude commented May 3, 2021

@PEZ ok nice. So this could be an escape hatch. The only downsize here is that this only works with JDK9+.

@PEZ
Copy link
Collaborator

PEZ commented May 3, 2021

Which is a pretty big downside, but I take what I can get. 😄

@borkdude
Copy link

borkdude commented May 3, 2021

Maybe Calva can detect the java version first and then apply this trick?

@PEZ
Copy link
Collaborator

PEZ commented May 3, 2021

That's what we will need to do. But I will be happy to do it. I really thought for a while that I was out of options.

@borkdude
Copy link

borkdude commented May 3, 2021

This is the first part of a full solution. Deps.clj will also have to pass its argument to the java subprocess in a similar way.

@PEZ
Copy link
Collaborator

PEZ commented May 4, 2021

The bug has been confirmed by Oracle and is being tracked here: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8266473

They have confirmed it with JDK11 even. I will test it, but my guess is that it is with JDK15 or 16 that the installer wires up the problematic java.exe as system default.

@PEZ
Copy link
Collaborator

PEZ commented May 4, 2021

I can also confirm it with JDK11, actually. I am not super savvy with WIndows, but I managed to uninstall Java 16 and now can do this:

PS C:\Program Files\Java\jdk-11.0.11> dir


    Directory: C:\Program Files\Java\jdk-11.0.11


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----          5/3/2021  10:18 PM                bin
d-----          5/3/2021  10:18 PM                conf
d-----          5/3/2021  10:18 PM                include
d-----          5/3/2021  10:18 PM                jmods
d-----          5/3/2021  10:18 PM                legal
d-----          5/3/2021  10:18 PM                lib
-a----         3/18/2021   6:05 PM           3244 COPYRIGHT
-a----          5/3/2021  10:36 PM            497 PrintArgs.class
-a----          5/3/2021  10:18 PM            160 README.html
-a----          5/3/2021  10:18 PM           1310 release


PS C:\Program Files\Java\jdk-11.0.11> java -version
java version "11.0.11" 2021-04-20 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.11+9-LTS-194)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.11+9-LTS-194, mixed mode)
PS C:\Program Files\Java\jdk-11.0.11> java PrintArgs '\"foo\"'
foo
PS C:\Program Files\Java\jdk-11.0.11> .\bin\java.exe -version
java version "11.0.11" 2021-04-20 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.11+9-LTS-194)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.11+9-LTS-194, mixed mode)
PS C:\Program Files\Java\jdk-11.0.11> bin\java.exe PrintArgs '\"foo\"'
"foo"
PS C:\Program Files\Java\jdk-11.0.11>

And the Getting Started REPL fails because of this, of course.

@tallpeak
Copy link

tallpeak commented May 7, 2021

Confirming that 15.0.2 drops "s on my Windows box, whereas java 15.0.1 does not:

C:\java\jdk-15.0.1\bin\java.exe PrintArgs.java '"bar"'
'"bar"'

java.exe PrintArgs.java '"bar"'
'bar'

@PEZ
Copy link
Collaborator

PEZ commented May 7, 2021

It's actually more peculiar than that, @tallpeak . 😄 Try

C:\java\jdk-15.0.2\bin\java.exe PrintArgs.java '"bar"'

@stuartstein777
Copy link
Author

image

@PEZ
Copy link
Collaborator

PEZ commented May 29, 2021

Perhaps a bit unsurprisingly, we can now confirm that this hits Leiningen jack-in as well. Also for CIDER users: clojure-emacs/cider#2963

@hanyuone
Copy link

The bug has been confirmed by Oracle and is being tracked here: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8266473

They have confirmed it with JDK11 even. I will test it, but my guess is that it is with JDK15 or 16 that the installer wires up the problematic java.exe as system default.

The bug's been fixed, and they said it's getting put into versions 17 and 18.

@PEZ
Copy link
Collaborator

PEZ commented Jul 15, 2021

That's good. But really they should put the fix into the JDK11-16 distributions too.

@timrobinson33
Copy link

For those who are struggling to understand this behavior, it might help to understand that Windows itself has no concept of parameters or quoting. In unix/macOS a process is invoked with a list of arguments, and the shell is responsible for parsing a command line to build that list, but for Windows, when a process is invoked it is simply passed the raw command line. It's completely up to the process itself to decide how to interpret that command line as a list of arguments, and so there is no guarantee of consistency between different programs.

@PEZ
Copy link
Collaborator

PEZ commented Feb 8, 2023

Closing this now. We reported the bug to the Java team and they fixed it, they even back-ported it to Java11-16. It is a bit too involved to create a workaround in Calva. Even if someone put in the work, we would still need to maintain it.

@PEZ PEZ closed this as completed Feb 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working jack-in upstream
Projects
None yet
Development

No branches or pull requests

10 participants