Feedback on Java & Test Explorer Support

vishalovercome commented 2 years ago

Describe the bug

I want to thank everyone for this extension which has served me will for years!

I was really looking forward to the current release as Java & Test Explorer support were two of my most sought after features. I want to share some initial feedback:

Java support "works" but it's a CPU hog at the moment. I've had to switch back to older Metals for now
Previously I was following the instructions in https://github.com/scalameta/metals-feature-requests/issues/5 for Java support (eclipse + redhat + lombok plugins) to get Java support in my project. Are there instructions any different now? Disabling Redhat plugin hasn't helped.
Disabling Redhat Java plugin isn't an option either as Metals won't provide advance Java support (refactoring, etc.)
Test explorer can't seem to detect all tests automatically but after opening files its able to
I'm able to run unit tests with it but not integration tests forcing me to go back to using code lenses
Debugging is still an underwhelming experience as watcher hardly ever has the expressions I'm interested. We also have to navigate through lots of well handled exceptions as there's no filter as such. There are github tickets for both of these issues.
Not sure how to get code formatter to work. I tried these: "metals.javaFormat.eclipseConfigPath": "PATH_TO_GOOGLE_FORMATTER_FILE", "metals.javaFormat.eclipseProfile": "GoogleStyle",

I would ask you to prioritize the performance and debugger issues over other aspects I mentioned. In the interim, can you provide a way to disable newly added Java support?

Many thanks for all your efforts!

Expected behavior

No response

Operating system

Linux

Editor/Extension

VS Code

Version of Metals

v0.11.0

Extra context or search terms

No response

Arthurm1 commented 2 years ago

Hi @vishalovercome

Could you supply some more info on the CPU hogging issues. Is this happening during indexing, compiling or when browsing java files? And if it's browsing java files then is it when using some specific function i.e. "goto definition", formatting, code folding? And does this happen in your java source files or dependency sources?

Also - what size is your code base - how many java and how many scala source files?

As for interoperability - which method did you go for in https://github.com/scalameta/metals-feature-requests/issues/5? Metals and RedHat LSP don't play too well together as the RedHat plugin Java files can't access the compiled Scala sources. Are your Scala and Java codebases separate?

As for formatting - it should work with a default setup using VSCode's "Format Document" and "Format Selection" commands. You can specify a format file/profile to override the defaults. The way you are doing it looks correct. Is it formatting code at all or is the issue that it's not picking up the profile you've specified?

One thing to note - since Metals can run under jdk 8 we are limited to using a slightly older version of the Eclipse libraries for formatting and code folding. These libraries only support up to java 15 source. But this won't affect compiling, references, goto etc.

Unfortunately there's no easy way to currently disable Java support.

vishalovercome commented 2 years ago

I've observed high cpu long after the project is imported and built. Basically auto-completion for my own project's Java classes has become unusable. I haven't tested the performance for external libraries.
There would be around 500 Java files and about 200 Scala files. Both are mixed within a multi-project code base
I've been using Metals + Redhat LSP + sbt-eclipse + lombok plugin and its been fine so far. Maybe the performance drop is due to some other changes that were part of this release.
Metals seems to format Java code similar to Scala code (indentation size of 2, splitting annotations into separate lines, etc.) rather than honouring the configurations I provided.
My code base runs on Java 11.

Many thanks for your quick response and for your work on Java support!

Arthurm1 commented 2 years ago

Thanks for the info.

Could you upload your format file here?

vishalovercome commented 2 years ago

https://github.com/google/styleguide/blob/gh-pages/eclipse-java-google-style.xml

dos65 commented 2 years ago

@vishalovercome Thanks for the feedback.

Java support "works" but it's a CPU hog at the moment. I've had to switch back to older Metals for now

Could you provide a bit more details? At which moment CPU usage get higher? Is it a constantly high from the start or rises during typing/opening source file (in which source scala/java)? Or maybe after saving file and triggering compilation?

vishalovercome commented 2 years ago

It spikes as soon as I type and until auto-complete suggestions load. Then it drops back again.

dos65 commented 2 years ago

@vishalovercome in any type of source or in only in .java or .scala ?

vishalovercome commented 2 years ago

I didn't try Scala files before I switched back to the older version of the extension. I'll try it over the weekend and get back to you. Thank you very much for your quick response!

tgodzik commented 2 years ago

Thanks for the feedback!

Test explorer can't seem to detect all tests automatically but after opening files its able to

We need to compile the entire codebase for all tests to appear so most likely once you open the file that module gets compiled. You can use cascade-compile to make sure that the entire project is compiled, but it should be compiled at the start when the workspace is open.

I'm able to run unit tests with it but not integration tests forcing me to go back to using code lenses

Code lenses use the same mechanism for running, so there should really be no difference in regards to what works. Could you create a small reproduction?

Debugging is still an underwhelming experience as watcher hardly ever has the expressions I'm interested. We also have to navigate through lots of well handled exceptions as there's no filter as such. There are github tickets for both of these issues.

Could you comment on those issues to show your case? It's useful to see if there are more people having issues or just one that raised the issue. It might also go under the radar sometimes.

Arthurm1 commented 2 years ago

Java formatting wasn't picking up the user settings. Should be fixed by https://github.com/scalameta/metals/pull/3504

arturopala commented 2 years ago

After migrating to 0.11.1 I've been not able to run tests anymore, the log shows each time only:

2022.01.14 12:56:19 INFO  Starting debug proxy for [here comes my test class full name][0m
2022.01.14 12:56:20 ERROR java.io.UncheckedIOException: java.nio.file.NoSuchFileException: /Users[0m
2022.01.14 12:56:20 INFO  Closing debug server tcp://0.0.0.0:49623[0m

tgodzik commented 2 years ago

After migrating to 0.11.1 I've been not able to run tests anymore, the log shows each time only:

Is there anything more in .metals/metals.log ?

arturopala commented 2 years ago

ok, problem has been solved by swithing to openjdk from zulu

before

openjdk version "1.8.0_312"
OpenJDK Runtime Environment (Zulu 8.58.0.13-CA-macos-aarch64) (build 1.8.0_312-b07)
OpenJDK 64-Bit Server VM (Zulu 8.58.0.13-CA-macos-aarch64) (build 25.312-b07, mixed mode)

after

openjdk version "11.0.12" 2021-07-20
OpenJDK Runtime Environment Homebrew (build 11.0.12+0)
OpenJDK 64-Bit Server VM Homebrew (build 11.0.12+0, mixed mode)

arturopala commented 2 years ago

but 0.10.15 has been working fine running tests on Zulu 8.58.0.13-CA-macos-aarch64, is it a bloop issue?

kpodsiad commented 2 years ago

@arturopala do you run tests via code lenses or test explorer?

arturopala commented 2 years ago

both Testing and Run & Debug

vishalovercome commented 2 years ago

@vishalovercome in any type of source or in only in .java or .scala ?

Retried it today and I can confirm that the issue is far worse:

CPU constantly pegged at over 99% in both Scala/Java code
Code takes a lot longer to compile
Auto-complete is unusable
CPU drops back after auto-complete pop up or after compilation
All of the above is true even after switching to Code Lens. Thus the issue you created yesterday (#3501) is most likely not the root cause.

This is what I see in the logs (while editing a test file):

2022.01.14 18:59:25 INFO time: code lens generation in 1m20s 2022.01.14 18:59:27 INFO time: code lens generation in 1m12s 2022.01.14 18:59:27 INFO time: code lens generation in 59s 2022.01.14 18:59:29 INFO time: code lens generation in 1m7s 2022.01.14 18:59:30 INFO time: code lens generation in 20s 2022.01.14 18:59:31 INFO time: code lens generation in 14s 2022.01.14 18:59:32 INFO time: code lens generation in 38s 2022.01.14 18:59:32 INFO time: code lens generation in 14s 2022.01.14 18:59:32 INFO time: code lens generation in 15s 2022.01.14 18:59:33 INFO time: code lens generation in 7.82s 2022.01.14 18:59:54 INFO compiling XXXXXXX (1 scala source) 2022.01.14 18:59:54 INFO time: compiled XXXXXXX in 0.66s Jan 14, 2022 7:00:24 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation WARNING: Unmatched cancel notification for request id 2221 Jan 14, 2022 7:00:25 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation WARNING: Unmatched cancel notification for request id 2225 Jan 14, 2022 7:00:27 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation WARNING: Unmatched cancel notification for request id 2234 Jan 14, 2022 7:00:30 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation WARNING: Unmatched cancel notification for request id 2232 Jan 14, 2022 7:00:31 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation WARNING: Unmatched cancel notification for request id 2243 Jan 14, 2022 7:00:33 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation WARNING: Unmatched cancel notification for request id 2244 Jan 14, 2022 7:00:34 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation WARNING: Unmatched cancel notification for request id 2249 Jan 14, 2022 7:00:35 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation WARNING: Unmatched cancel notification for request id 2251 Jan 14, 2022 7:00:35 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation WARNING: Unmatched cancel notification for request id 2255 Jan 14, 2022 7:00:35 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation WARNING: Unmatched cancel notification for request id 2257 Jan 14, 2022 7:00:35 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation WARNING: Unmatched cancel notification for request id 2258 Jan 14, 2022 7:00:35 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation WARNING: Unmatched cancel notification for request id 2259 Jan 14, 2022 7:00:35 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation WARNING: Unmatched cancel notification for request id 2260 Jan 14, 2022 7:00:35 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation WARNING: Unmatched cancel notification for request id 2261 Jan 14, 2022 7:00:35 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation WARNING: Unmatched cancel notification for request id 2262 2022.01.14 19:00:38 INFO time: code lens generation in 19s 2022.01.14 19:00:43 INFO time: code lens generation in 21s 2022.01.14 19:00:43 INFO time: code lens generation in 18s 2022.01.14 19:00:45 INFO time: code lens generation in 9.93s 2022.01.14 19:00:47 INFO time: code lens generation in 6.92s 2022.01.14 19:00:52 INFO time: code lens generation in 5.24s 2022.01.14 19:00:58 INFO compiling XXXXXXX (1 scala source) 2022.01.14 19:01:00 INFO time: code lens generation in 9.18s 2022.01.14 19:01:04 INFO time: compiled XXXXXXXX in 6.17s 2022.01.14 19:01:05 INFO time: code lens generation in 10s 2022.01.14 19:01:06 INFO time: code lens generation in 7.3s

Seems as though code lens generation is taking a lot of time but compilation itself isn't?

kpodsiad commented 2 years ago

both Testing and Run & Debug

@arturopala then it looks like an issue with the bloop

tgodzik commented 2 years ago

but 0.10.15 has been working fine running tests on Zulu 8.58.0.13-CA-macos-aarch64, is it a bloop issue?

That might be already fixed, though did you restart Bloop when switching Java versions? Could you try both with 1.4.12-6-1261d1aa Bloop version? IT can be changed in the metals settings.

@vishalovercome that is unexpected, I wonder why it is influencing you more than others, maybe it's due to added Java support combined with autosave? Would it be possible for you to do a stacktrace when things freeze?

vishalovercome commented 2 years ago

I don't have auto-save enabled actually. That's why I don't think the other issue tracking this might not be the root cause (but could be aggravating things). One thing I do see different from earlier version is that there are many more code lens generation related logs and they seem to take quite a bit of time.

Can you tell me the exact command to capture the stacktrace?

tgodzik commented 2 years ago

I don't have auto-save enabled actually. That's why I don't think the other issue tracking this might not be the root cause (but could be aggravating things). One thing I do see different from earlier version is that there are many more code lens generation related logs and they seem to take quite a bit of time.

Can you tell me the exact command to capture the stacktrace?

In the same place where you have java located there should be the jstack and jps command. You can use jps to locate which PID Metals has and then run jstack <PID> > jtack.txt repalceing <PID> with the one you got from jsp

arturopala commented 2 years ago

That might be already fixed, though did you restart Bloop when switching Java versions? Could you try both with 1.4.12-6-1261d1aa Bloop version? IT can be changed in the metals settings.

yes, I did kill bloop process and have deleted .bloop folder before restarting VSCode after VM change to openjdk.

arturopala commented 2 years ago

after switching back clean to Zulu 8.58.0.13-CA-macos-aarch64, the test attempt hangs forever and metals.log shows:

2022.01.14 15:00:45 INFO  Connected to Build server: Bloop v1.4.12[0m
2022.01.14 15:00:47 INFO  time: indexed workspace in 1.94s[0m
Jan 14, 2022 3:00:47 PM scala.meta.internal.pc.ScalaPresentationCompiler newCompiler
WARNING: Unknown compiler options: utf8
2022.01.14 15:00:48 INFO  compiling root (223 scala sources and 3 java sources)[0m
Jan 14, 2022 3:00:56 PM scala.meta.internal.pc.ScalaPresentationCompiler newCompiler
WARNING: Unknown compiler options: utf8
2022.01.14 15:00:57 INFO  Deduplicating compilation of root from bsp client 'Metals 0.11.0' (since 11.686s)[0m
2022.01.14 15:00:57 INFO  compiling root (223 scala sources and 3 java sources)[0m
2022.01.14 15:01:07 INFO  compiling root-it (37 scala sources)[0m
2022.01.14 15:01:07 INFO  compiling root-test (52 scala sources)[0m
2022.01.14 15:01:07 INFO  time: compiled root in 10s[0m
2022.01.14 15:01:12 WARN  177 feature warnings; re-run with -feature for details[0m
2022.01.14 15:01:12 INFO  time: compiled root-it in 5.62s[0m
2022.01.14 15:01:12 WARN  two feature warnings; re-run with -feature for details[0m
2022.01.14 15:01:12 INFO  time: compiled root-test in 6.01s[0m
2022.01.14 15:01:23 INFO  Deduplicating compilation of root from bsp client 'Metals 0.11.0' (since 38.491s)[0m
2022.01.14 15:01:23 INFO  Deduplicating compilation of root-test from bsp client 'Metals 0.11.0' (since 38.525s)[0m
2022.01.14 15:01:24 INFO  tracing is disabled for protocol dap-server, to enable tracing of incoming and outgoing JSON messages create an empty file at /Users/arturopala/workspace/.../.metals/dap-server.trace.json or /Users/arturopala/Library/Caches/org.scalameta.metals/dap-server.trace.json[0m
2022.01.14 15:01:24 INFO  tracing is disabled for protocol dap-client, to enable tracing of incoming and outgoing JSON messages create an empty file at /Users/arturopala/workspace/.../.metals/dap-client.trace.json or /Users/arturopala/Library/Caches/org.scalameta.metals/dap-client.trace.json[0m
2022.01.14 15:01:24 INFO  Starting debug proxy for [...][0m
2022.01.14 15:01:25 ERROR java.io.UncheckedIOException: java.nio.file.NoSuchFileException: /Users[0m
2022.01.14 15:01:25 INFO  Closing debug server tcp://0.0.0.0:52530[0m

and after rolling back the bloop version to v1.4.12-6-1261d1aa nothing improves :-(

2022.01.14 15:10:20 INFO  Connected to Build server: Bloop v1.4.12-6-1261d1aa[0m
2022.01.14 15:10:25 ERROR issues while parsing: /Users/arturopala/Library/Caches/Coursier/v1/https/repo1.maven.org/maven2/com/openhtmltopdf/openhtmltopdf-core/0.0.1-RC13/openhtmltopdf-core-0.0.1-RC13-sources.jar
scala.meta.internal.mtags.IndexingExceptions$PathIndexingException: /Users/arturopala/Library/Caches/Coursier/v1/https/repo1.maven.org/maven2/com/openhtmltopdf/openhtmltopdf-core/0.0.1-RC13/openhtmltopdf-core-0.0.1-RC13-sources.jar
2022.01.14 15:10:25 INFO  time: indexed workspace in 5.01s[0m
Jan 14, 2022 3:10:28 PM scala.meta.internal.pc.ScalaPresentationCompiler newCompiler
WARNING: Unknown compiler options: utf8
2022.01.14 15:10:29 INFO  compiling root (223 scala sources and 3 java sources)[0m
2022.01.14 15:10:47 INFO  compiling root-test (52 scala sources)[0m
2022.01.14 15:10:47 INFO  time: compiled root in 18s[0m
2022.01.14 15:10:53 WARN  two feature warnings; re-run with -feature for details[0m
2022.01.14 15:10:53 INFO  time: compiled root-test in 6.06s[0m
Jan 14, 2022 3:10:55 PM scala.meta.internal.pc.ScalaPresentationCompiler newCompiler
WARNING: Unknown compiler options: utf8
2022.01.14 15:10:57 INFO  Deduplicating compilation of root from bsp client 'Metals 0.11.0' (since 36.738s)[0m
2022.01.14 15:10:57 INFO  Deduplicating compilation of root-test from bsp client 'Metals 0.11.0' (since 36.772s)[0m
2022.01.14 15:10:57 INFO  tracing is disabled for protocol dap-server, to enable tracing of incoming and outgoing JSON messages create an empty file at /Users/arturopala/workspace/.../.metals/dap-server.trace.json or /Users/arturopala/Library/Caches/org.scalameta.metals/dap-server.trace.json[0m
2022.01.14 15:10:57 INFO  tracing is disabled for protocol dap-client, to enable tracing of incoming and outgoing JSON messages create an empty file at /Users/arturopala/workspace/.../.metals/dap-client.trace.json or /Users/arturopala/Library/Caches/org.scalameta.metals/dap-client.trace.json[0m
2022.01.14 15:10:57 INFO  Starting debug proxy for [...][0m
2022.01.14 15:10:58 ERROR java.io.UncheckedIOException: java.nio.file.NoSuchFileException: /Users[0m
2022.01.14 15:10:58 INFO  Closing debug server tcp://0.0.0.0:52708[0m

kpodsiad commented 2 years ago

@arturopala Is it shown for which path java.nio.file.NoSuchFileException is raised? It seems like the path is incomplete.

arturopala commented 2 years ago

@kpodsiad nope, just /Users

kpodsiad commented 2 years ago

@arturopala could you create and fill a separate issue for it? It's hard to tell what's going on, this may require additional investigation.

tgodzik commented 2 years ago

@arturopala could you create and fill a separate issue for it? It's hard to tell what's going on, this may require additional investigation.

This might be the usual issue with /Users directory included in some jar.

tgodzik commented 2 years ago

It seems the issue is connected to https://github.com/scalameta/metals/pull/3512 we should be able to release a new version soon.

tgodzik commented 2 years ago

0.11.0+15-ea6ea86c-SNAPSHOT should fix the performance issue, please test it out if you have time!

arturopala commented 2 years ago

how to test snapshot with VSCode?

kpodsiad commented 2 years ago

@arturopala open settings, then search and change server version:

vishalovercome commented 2 years ago

In the same place where you have java located there should be the jstack and jps command. You can use jps to locate which PID Metals has and then run jstack <PID> > jtack.txt repalceing <PID> with the one you got from jsp

jstack.txt

Running jstack itself causes metals to crash sometimes. Managed to grab some output when the cpu was > 99% which is the norm now.

Arthurm1 commented 2 years ago

@vishalovercome The new snapshot should fix that exact stacktrace issue

arturopala commented 2 years ago

after playing a bit with 0.11.0 and 0.11.0+15-ea6ea86c-SNAPSHOT:

it seems CPU demand is much lower when using the snapshot
in both versions:
- cannot run tests on (Zulu 8.58.0.13-CA-macos-aarch64) (build 1.8.0_312-b07)
- can run tests on Zulu11.52+13-CA (build 11.0.13+8-LTS)

arturopala commented 2 years ago

additionally, when using OpenJDK Runtime Environment Homebrew (build 11.0.12+0) then metals logs 2022.01.15 17:01:19 WARN Can't instantiate JavaInteractiveSemanticdb (version: None, jdkHome: /Users/arturopala/.jenv/versions/openjdk64-11.0.12, javac exists: true)[0m

dos65 commented 2 years ago

@arturopala

additionally, when using OpenJDK Runtime Environment Homebrew (build 11.0.12+0) then metals logs 2022.01.15 17:01:19 WARN Can't instantiate JavaInteractiveSemanticdb (version: None, jdkHome: /Users/arturopala/.jenv/versions/openjdk64-11.0.12, javac exists: true)�[0m

Could you look at /Users/arturopala/.jenv/versions/openjdk64-11.0.12/release file? Does it exist? What does it have in version field?

arturopala commented 2 years ago

cat: /Users/arturopala/.jenv/versions/openjdk64-11.0.12/release: No such file or directory
cat: /opt/homebrew/Cellar/openjdk@11/11.0.12/release: No such file or directory
cat: /Users/arturopala/.jenv/versions/openjdk64-17.0.1/releases: No such file or directory

vishalovercome commented 2 years ago

Java formatting wasn't picking up the user settings. Should be fixed by #3504

With the latest plugin, it still doesn't seem to work. Can you tell me for the file I linked above, what should be the value of metals.javaFormat.eclipseProfile. I tried empty string, "GoogleStyle", "google-java-format" but the response is always ERROR Java formatting profile NAME not found

Arthurm1 commented 2 years ago

@vishalovercome I have the following in my workspace settings...

    "metals.javaFormat.eclipseConfigPath": "/fullpath/eclipse-java-google-style.xml",
    "metals.javaFormat.eclipseProfile": "GoogleStyle"

Arthurm1 commented 2 years ago

@vishalovercome The format file should start with something like...

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<profiles version="13">
<profile kind="CodeFormatterProfile" name="GoogleStyle" version="13">
<setting id="org.eclipse.jdt.core.formatter.comment.insert_new_line_before_root_tags" value="insert"/>

and the metals.javaFormat.eclipseProfile setting should match whatever name="XXX" is set to. In this case GoogleStyle

vishalovercome commented 2 years ago

@vishalovercome The format file should start with something like...
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<profiles version="13">
<profile kind="CodeFormatterProfile" name="GoogleStyle" version="13">
<setting id="org.eclipse.jdt.core.formatter.comment.insert_new_line_before_root_tags" value="insert"/>
and the metals.javaFormat.eclipseProfile setting should match whatever name="XXX" is set to. In this case GoogleStyle

I've had to switch to an older version of this extension due to some other issues I'm facing, particularly to do with performance. My suggestion would be that the default Metals formatter should be the same as https://github.com/sbt/sbt-java-formatter as that's what Scala developers would be looking to use in the absence of metals. Thanks a lot for your support!

dos65 commented 2 years ago

@arturopala

cat: /Users/arturopala/.jenv/versions/openjdk64-11.0.12/release: No such file or directory cat: /opt/homebrew/Cellar/openjdk@11/11.0.12/release: No such file or directory cat: /Users/arturopala/.jenv/versions/openjdk64-17.0.1/releases: No such file or directory

Thx, turned it into an issue - #3505

tgodzik commented 2 years ago

Closing this one, I would like to propose the following:

if it's specific problem, please raise an issue
if it's more general, let's use the discussions

scalameta / metals