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.

Sign up for GitHub

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

Jump to bottom

Add support to open decompiled symbols through the symbols list #2087

Closed
gayanper opened this issue May 12, 2022 · 3 comments · Fixed by #2090
Closed

Add support to open decompiled symbols through the symbols list #2087

gayanper opened this issue May 12, 2022 · 3 comments · Fixed by #2090
Labels
bug documentSymbols
Milestone
Early June 2022

Comments

@gayanper
Copy link
Contributor

gayanper commented May 12, 2022 •
edited
Loading

Steps:

  • Install java decompiler extension
  • Search for a class which doesn't have attached source code.
  • Select the class name to open the class

Expectation:
Open the decompiled class source.

Actual:
Nothing happens.

IllegalArgumentException is thrown at Symbol information construction due to lack of proper location. I have a fix for it by resolving the location for BinaryType, I will push it as a PR.
@jdneo jdneo added the bug label May 16, 2022
@jdneo
Copy link
Contributor

jdneo commented May 16, 2022

BTW, do you mean to contribute a PR for the decompiler extension? Is that this one: https://marketplace.visualstudio.com/items?itemName=dgileadi.java-decompiler?

@jdneo jdneo removed the bug label May 16, 2022
@gayanper
Copy link
Contributor Author

No its not a issue in the decompiler, but rather how we resolve the resource uri in the LS.

gayanper added a commit to gayanper/eclipse.jdt.ls that referenced this issue May 16, 2022
@gayanper
Add support for opening binary symbols with no source
ccb7309 
As reported in eclipse-jdtls#2087 when searching for workspace symbols
which doesn't have attached source, trying to open them result
in a NPE in logs. This is due to the location ending up null.

The fix fallback in this situation to find the location by using the
class file.

Signed-off-by: Gayan Perera <[email protected]>
@gayanper gayanper mentioned this issue May 16, 2022
Merged
gayanper added a commit to gayanper/eclipse.jdt.ls that referenced this issue May 16, 2022
@gayanper
Add support for opening binary symbols with no source
b99d433 
As reported in eclipse-jdtls#2087 when searching for workspace symbols
which doesn't have attached source, trying to open them result
in a NPE in logs. This is due to the location ending up null.

The fix fallback in this situation to find the location by using the
class file.

Signed-off-by: Gayan Perera <[email protected]>
testforstephen pushed a commit that referenced this issue May 18, 2022
@gayanper
Add support for opening binary symbols with no source (#2090)
3599212 
As reported in #2087 when searching for workspace symbols
which doesn't have attached source, trying to open them result
in a NPE in logs. This is due to the location ending up null.

The fix fallback in this situation to find the location by using the
class file.

Signed-off-by: Gayan Perera <[email protected]>
@testforstephen testforstephen added this to the Early June 2022 milestone May 18, 2022
@testforstephen testforstephen linked a pull request May 18, 2022 that will close this issue
Add support for opening binary symbols with no source #2090
Merged
@rgrunber
Copy link
Contributor

For the sake of completeness, here's the error :

[Error - 2:19:46 p.m.] May 18, 2022, 2:19:46 p.m. Problems occurred when invoking code from plug-in: "org.eclipse.jdt.ls.core".
Property must not be null: location
java.lang.NullPointerException: Property must not be null: location
	at org.eclipse.lsp4j.util.Preconditions.checkNotNull(Preconditions.java:29)
	at org.eclipse.lsp4j.SymbolInformation.setLocation(SymbolInformation.java:195)
	at org.eclipse.jdt.ls.core.internal.commands.ProjectCommand.resolveWorkspaceSymbol(ProjectCommand.java:343)
	at org.eclipse.jdt.ls.core.internal.JDTDelegateCommandHandler.executeCommand(JDTDelegateCommandHandler.java:124)
	at org.eclipse.jdt.ls.core.internal.handlers.WorkspaceExecuteCommandHandler$1.run(WorkspaceExecuteCommandHandler.java:215)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45)
	at org.eclipse.jdt.ls.core.internal.handlers.WorkspaceExecuteCommandHandler.executeCommand(WorkspaceExecuteCommandHandler.java:205)
	at org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer.lambda$4(JDTLanguageServer.java:525)
	at org.eclipse.jdt.ls.core.internal.BaseJDTLanguageServer.lambda$0(BaseJDTLanguageServer.java:75)
	at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(Unknown Source)
	at java.base/java.util.concurrent.CompletableFuture$Completion.exec(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinPool.scan(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source)

The PR resolves this, so thanks for the contribution.

@raulvaldoleiros raulvaldoleiros mentioned this issue Jun 16, 2022
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug documentSymbols
Projects
None yet
Milestone
Early June 2022
Development

Successfully merging a pull request may close this issue.

Add support for opening binary symbols with no source gayanper/eclipse.jdt.ls
4 participants
@rgrunber @jdneo @gayanper @testforstephen