vscode-java-debug icon indicating copy to clipboard operation
vscode-java-debug copied to clipboard

ClassNotFoundException thrown when debugger is run on a project in a symlinked directory

Open sharadhr opened this issue 5 years ago • 3 comments

I have a single .java source file, Duke.java, that's contained in a package, sharadhr.duke, within a project folder that follows the Gradle convention (i.e. the source file is in src/main/java/sharadhr/duke/Duke.java).

When either the F5 key is pressed or the Debug configuration is manually selected from the Debug menu, the VS Code Java Debugger throws a java.lang.ClassNotFoundException, mentioning sharadhr.duke.Duke:

d:\User Libraries\Desktop\NUS\Y2S2\CS2103T—Software Engineering\duke>cd "d:\User Libraries\Desktop\NUS\Y2S2\CS2103T—Software Engineering\duke" && C:\Users\Sharadh\.vscode\extensions\vscjava.vscode-java-debug-0.24.0\scripts\launcher.bat "C:\Program Files\Java\jdk-13.0.1\bin\java" -agentlib:jdwp=transport=dt_socket,server=n,suspend=y,address=localhost:12469 -Dfile.encoding=UTF-8 @C:\Users\Sharadh\AppData\Local\Temp\cp_c7l8f2lsk9vuhhfrvwa7oc4b6.argfile sharadhr.duke.Duke
Error: Could not find or load main class sharadhr.duke.Duke
Caused by: java.lang.ClassNotFoundException: sharadhr.duke.Duke

Following are the required information, as well as the entire project folder, as-is now.

Environment
  • Operating System: Windows 10 Education v1909 [Build no 18363.535]
  • JDK version: 13.0.1
  • Visual Studio Code version: 1.41
  • Java extension version: 0.8.1
  • Java Debugger extension version: 0.24.0

The project is attached. This is a git-tracked folder, too. duke.zip

Current Result

Debugging with VS Code throws java.lang.ClassNotFoundException.

Expected Result

Program should run normally.

Additional Information

The upstream repo, Duke works fine, oddly enough. Furthermore, initially packaging the file and running it also works fine. I'm not sure what causes this, because its occurrence appears to be sudden and random.

sharadhr avatar Jan 09 '20 04:01 sharadhr

Your sample project duke works for me.

May you have a try on the VS Code command "Java: Clean the Java language server workspace" ?

testforstephen avatar Jan 10 '20 08:01 testforstephen

Your sample project duke works for me.

May you have a try on the VS Code command "Java: Clean the Java language server workspace" ?

Thanks for the reply.

I've tried using that command to clean the Java language server workspace; it does not fix the problem.

After further experimention, I noticed that moving the project elsewhere, and re-opening this new path in VS Code, works. The very same project, with all the files intact, is able to be debugged with the built-in debugger, when it's in a different parent folder.

Are there any logs that I can attach to help resolve this?

I've also tried deleting the original folder, cleaning the workspace again, and copying the project back to the same directory, and opening that folder in VS Code. No dice.

sharadhr avatar Jan 10 '20 09:01 sharadhr

Hi guys.

I just spoke to @Eskibear through an interview for VS Code Java, and I noted that this problem actually has got to do with symlinks, and possibly OneDrive as well. In NTFS parlance I believe Windows symlinks are actually called junctions, but I'll use symlink anyway.

I am running the same environment as mentioned above; VS Code has since been updated to 1.43.

Situation:

  • VS Code does not successfully debug or run files when F5 is pressed, or run from the Debug tab, when the project folder is either in a symlinked directory, or is a symlinked directory itself.

The error remains the same as first mentioned: a ClassNotFoundException is thrown, and the debugger stops working.

An example directory structure follows. main is the project directory added to VS Code.

D:\path\to\directory\main, no symlink --> debugger works.

D:\path\to\directory\main, is a symlink target --> debugger fails

D:\path\to\symlink\main, is the symlink itself --> debugger fails

I do hope the information I've provided over the interview, and now here, is sufficient to track down and potentially fix this bug; do let me know if there's any other information I can give.

Note that this symlink was created with the command as follows:

mklink /J X:\path\to\symlink Y:\path\to\target

sharadhr avatar Mar 20 '20 04:03 sharadhr