Fetching source code for maven dependencies extremely unreliable

[kdvolder]

When opening a .class file in a maven project (e.g. by using CTRL-T to open a binary type, or by navigation via CTRL-CLICK)... fetching the sources seems extremely unreliable.

For an example. I was playing with the this project:

https://github.com/kdvolder/chatter/tree/master/chatter-web-ui

I tried opening about a dozen different types. To name a few I remember trying:

• SpringBootApplication
• WebSocketHandlerMapping
• LoggerFactory
• ...

The only one for which I get source code displayed properly was LoggerFactory.

If I open the same project in Eclipse (with m2e) it works for all of the types I have tried without fail.

Environment

• Operating System: Ubuntu 14.04

• JDK version: java version "1.8.0_161"
  Java(TM) SE Runtime Environment (build 1.8.0_161-b12)
  Java HotSpot(TM) 64-Bit Server VM (build 25.161-b12, mixed mode)

• Visual Studio Code version: 1.20.1
  f88bbf9137d24d36d968ea6b2911786bfe103002
  x64

• Java extension version: 0.19.0

Steps To Reproduce

1. clone this repo: https://github.com/kdvolder/chatter/
2. cd chatter/chatter-web-ui
3. code .
4. CTRL-T and try to open a bunch of different types.

Current Result

It doesn't show the source code most of the time. (Just stubs with some comment at the top that fetching source code failed.)

Expected Result

As this is a properly structured maven project with pretty well packaged dependencies that have source jars available on maven central, source code should allways be available.

[fbricon]

So, I managed to reproduced the problem for 1 class (org.springframework.web.socket.server.standard.ServerEndpointExporter) when trying to Ctrl+Click on it from ChatterWebUiApplication (got the same default stubs), but other classes from the spring-websocket jar worked fine. After restarting vscode, all sources were available.

So what happens is: until the sources are available, we delegate source loading to the default decompiler AND we cache the result.
On the subsequent calls, because results were cached, the rendered version is served, instead of the actual source. Best way to recover is to restart the JVM. Changing the value of the java.contentProvider.preferred preference would also work.

TL;DR definitely a bug. Cache should be evicted when classpath changes.