Java adapter #106
Java adapter #106
Conversation
Thats fixed by supplying: "mainClass": "${file}",
"modulePaths": ["${folder}"]Now the Debugger fails with: Debugger does not reply to runInTerminal. Is this a known issue? |
|
Okey, I found the comment in |
modules/adapters/java.py
Outdated
| url = 'https://marketplace.visualstudio.com/_apis/public/gallery/publishers/vscjava/vsextensions/vscode-java-debug/latest/vspackage' | ||
| await adapter.vscode.install(self.type, url, log) |
There was a problem hiding this comment.
@daveleroy I'm fairly certain this isn't allowed, unfortunately...
Offerings are intended for use only with Visual Studio Products and Services and you may only install and use Marketplace Offerings with Visual Studio Products and Services.
There was a problem hiding this comment.
In this case its actually possible to compile the jar and ship it with Debugger (or download it elsewhere.) The plugin itself is under Eclipse Public License - v 1.0. See https://github.com/microsoft/java-debug/blob/master/LICENSE.txt
There was a problem hiding this comment.
You cannot download or in any way install software provided through the “marketplace” if it’s not a “visual studio product”. The license you link to does allow one to compile/use the software. But obtaining that software cannot be done through the marketplace (or, risk a cease and desist I guess).
There was a problem hiding this comment.
If that debugger jar is somewhere else on the internet available for download and the terms and conditions of that source allow it, then we can use that.
There was a problem hiding this comment.
Why do you think VSCodium has its own marketplace?
There was a problem hiding this comment.
We would want the full extension https://github.com/Microsoft/vscode-java-debug which includes all the snippets and a schema for the configurations.
There was a problem hiding this comment.
Incidentally, open-vsx.org is hosted by the eclipse foundation https://www.eclipse.org/community/eclipse_newsletter/2020/march/1.php
There was a problem hiding this comment.
Right, I think you can also just fetch the .vsix file from https://github.com/microsoft/vscode-java-debug/releases/ and extract it as a zip.
There was a problem hiding this comment.
Looks like you can in this case. Other adapters do not add the vscode package to their releases so those will probably need to be changed.
There was a problem hiding this comment.
Yes. What a coincidence that the assets are not in a GitHub release... ;)
It relies on winpty and dependencies don't work on the 3.8 environment |
@LDAP for now you can probably change your configuration to not use the integrated terminal.
|
In this case the Server errors with: |
|
What request is this failing on? If its the initialize request its likely there are additional required parameters in the configuration that get patched in. I would try adding |
Still erroring, this is the Debugger Protocol: Config: {
"type": "java",
"name": "Launch Current File",
"request": "launch",
"mainClass": "${file}",
"modulePaths": ["${folder}"],
"cwd": "${folder}",
"console": "internalConsole",
"env": {},
"stopOnEntry": false
}, |
|
Looks to be way past the initialize request. From the looks of it they are just not handling the configurationDone request correctly and treating the arguments as none optional. Try changing |
That did the trick. Now the command gets executed, but fails too... |
|
It's working now. Although I am still getting Settings: |
Error parsing message: com.google.gson.JsonSyntaxException: Expected a com.google.gson.JsonObject but was com.google.gson.JsonNull
|
Fixed that too. Since I changed the Protocol to |
|
@daveleroy How would an adapter add/set configuration variables? I would like to fetch classpath, mainclass,... with the Language Server because for example classpath can get very complicated on a big maven Project. |
Unlikely to break anything and is probably what vscode does despite the threads request not having any arguments specified in the spec https://microsoft.github.io/debug-adapter-protocol/specification |
You can adjust a configuration after the variables are expanded but before it is sent to the adapter using |
|
If you are talking about adding custom variables that can't currently be done and would need support added for it |
That should work :) |
|
Implemented auto-configuration of mainClass and classPaths allowing for a plug & play solution together with sublimelsp/LSP-jdtls#7 |
|
@daveleroy I get errors in the client. Protocol: |
|
@daveleroy The Java Language Server returns URIs like: leading to an empty view. JDT.LS can actually provide the contents of the class file, does Debugger support that the server resolves the content itself? |
|
I've enabled LSP-jdtls to understand |
|
The jar you are looking for is available at https://mvnrepository.com/artifact/com.microsoft.java/com.microsoft.java.debug.plugin and is exactly the same VSCode use to debug Java applications. |
|
@daveleroy @rwols The current implementation (together with sublimelsp/LSP-jdtls#7) does work, but uses a dirty hack to get the view created by the LSP-plugin. Ideally, I could await a future which does return the created view. |
|
You could just expose the request like we do for Also maybe that should be more generic since I think there are some other commands that need to get run as well to fetch configuration stuff. They seem to be also using # LSP side
class DebuggerJdtlsExecuteCommandCommand(LspWindowCommand):
session_name = 'jdtls'
def run(self, id: int, command: str, arguments: 'Optional[list[Any]]' = None):
session = self.session()
if not session:
self.handle_response(id, ValueError('Unable to find `jdtls` session'))
return
session.execute_command({"command": command, 'arguments': arguments}, False).then(lambda resp: self.handle_response(id, resp))
def handle_response(self, id, response):
if isinstance(response, Exception):
self.window.run_command('debugger_lsp_jdtls_excute_command_response', {'id': id, 'reject': str(response)})
else:
self.window.run_command('debugger_lsp_jdtls_excute_command_response', {'id': id, 'resolve': response})# Debugger Side
pending_futures: Dict[int, core.Future] = {}
pending_futures_current_id = 0
class DebuggerLspJdtlsResponseCommand(sublime_plugin.WindowCommand):
def run(self, **args):
future = pending_futures.get(args["id"])
if not future:
print("Hmm... unable to find a future port for this id")
return
if error := args.get('reject'):
future.set_exception(core.Error(error))
else:
future.set_result(args.get('resolve'))
async def jdtls_execute_command(self, command: str, arguments: list[Any]|None = None):
# probably need to add some sort of timeout
# probably need to ensure lsp_jdts is installed
# probably need to ensure lsp_jdts has the plugin jar patched in
future = core.Future()
sublime.set_timeout(lambda: future.cancel(), 2500)
global pending_futures_current_id
id = pending_futures_current_id
pending_futures_current_id += 1
pending_futures[id] = future
# ask lsp_jdts to start the debug adapter
# lsp_jdts will call debugger_lsp_jdts_command_response with the id it was given and a port to connect to the adapter with or an error
# note: the active window might not match the debugger window but generally will... probably need a way to get the actual window.
sublime.active_window().run_command('debugger_jdtls_execute_command', {
'id': id,
'command': command,
'arguments': arguments
})
try:
return await future
except CancelledError:
raise core.Error('Unable to execute `jdtls` command (timed out)')port: int = await jdtls_execute_command('vscode.java.startDebugSession')) |
|
Not sure what the difference between |
|
That should work. Then the only thing left is to move the special case into the Java adapter instead of the core module. |
|
@daveleroy The Java Adapter should work now. You might want to change the |
|
The configuration logic now uses a generic bridge which allows sending requests to the LSP. |
| raise core.Error('LSP and LSP-jdtls required to debug Java!') | ||
|
|
||
| # Get configuration from LSP | ||
| lsp_config = await self.get_configuration_from_lsp() |
There was a problem hiding this comment.
I might change that next week to only request if the user did not provide certain config option, by splitting in multiple methods. I should also use the correct main class in the checkProjectSettings command below.
|
@LDAP I'm merging this if its not ready for release it can be put behind the |
|
@daveleroy Alright. Please do not release it until I fixed the user configuration overwrite. I'll open a follow up PR in the next few days. |
|
I'll notify you when I release the new LSP-jdtls version containing the necessary debug plugin and bridge. |
This PR adds Java support to the Debugger. LSP and LSP-jdtls are required for this adapter to work.
Closes #147
Closes #118
Closes sublimelsp/LSP-jdtls#24