Skip to content

/ vscode-java-debug

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.

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

Support for an alternative jvm #471

Open
wants to merge 1 commit into
base: master
from
Open

Support for an alternative jvm #471

wants to merge 1 commit into from

Conversation

@RobertDeRose
Copy link

@RobertDeRose RobertDeRose commented Nov 9, 2018

  • Added new launch configuration property jvm
  • Changed updateDebugSettings to optionally take in the config object
    • uses config.jvm if available instead for calling getJavaHome
@RobertDeRose
Copy link
Author

@RobertDeRose RobertDeRose commented Nov 9, 2018

inkedshow_vscode-java-debug_running_alternative_jvm_li
@RobertDeRose RobertDeRose force-pushed the RobertDeRose:feature/support-alternative-jvm branch 3 times, most recently from ff44a0b to 14e86e0 Nov 10, 2018
@RobertDeRose
Copy link
Author

@RobertDeRose RobertDeRose commented Nov 16, 2018

ping @Eskibear What do you think about this feature? Anything I missed that you can see? I personally need it for VSCode to even be a possible editor for my work.
@yaohaizh
Copy link

@yaohaizh yaohaizh commented Nov 16, 2018

@testforstephen @andxu Would you please help evaluate this PR?
@Eskibear
Copy link
Member

@Eskibear Eskibear commented Nov 16, 2018

For example, Java Language Server is running on JDK 8 64-bit, but your app only works on 32-bit

As a dependent, java-debugger uses the same JAVA_HOME with language server for consistency. Personally, I don't understand the reason why you have to run language server on 64-bit and debug the app on 32-bit. Can you share the motivation? And can you simply change settings java.home to your 32-bit JDK?
@RobertDeRose
Copy link
Author

@RobertDeRose RobertDeRose commented Nov 16, 2018

@Eskibear The motivation is that my project (inherited, new job, old code base) is a rather large (106MB of source code) monolithic code base. I need Java 64-bit for the JLS (Java Language Server) because it needs well over 4 GB of RAM just to be usable, which is not possible when running on the 32-bit JVM.

Side note, the use of ${env:JAVA_HOME} as the default is because the JLS defaults to using ${JDK_HOME} before ${JAVA_HOME} so this was an easy way to set a different JDK for debugging than the one the JLS uses.

That's the primary motivation. The other, this just makes it easier to test your code against alternative JVM installs without need to constantly change and restart the VSCode (Which for me, is a slow process that can take up to 5 minutes to become stable enough to start working). So if for example I wanted to test against the newly announced Amazon Corretto JVM, or the Redhat compiled JVM, or maybe GraalVM (no idea how to use that yet, just throwing out examples).

The only issue I am having with my PR is that when I change the jvm setting I introduced, it doesn't seem to update the value it sends to the JLS, it works perfectly on initialization of VSCode and the extension, so I assume I am missing some change event to the launch.json that I either need to hook into or add so that the config object is re-created.
@RobertDeRose
Copy link
Author

@RobertDeRose RobertDeRose commented Nov 19, 2018

@Eskibear Any thoughts? Would love to see this merged, but I would love even more feedback on where to add the needed change to ensure that if the config file is changed, the value I pass in via jvm is updated as well.
@andxu
andxu reviewed Nov 22, 2018
View changes
package.json Outdated
@@ -131,6 +131,11 @@
"description": "Automatically pause the program after launching.",
"default": true
},
"jvm": {

This comment has been minimized.

Sign in to view
@andxu

andxu Nov 22, 2018
Contributor

javaHome is better, since we can not infer the jave.exe or the folder from jvm

This comment has been minimized.

Sign in to view
@RobertDeRose

RobertDeRose Nov 25, 2018
Author

Ok
@andxu
andxu reviewed Nov 22, 2018
View changes
src/configurationProvider.ts
@@ -128,7 +129,7 @@ export class JavaDebugConfigurationProvider implements vscode.DebugConfiguration
try {
if (this.isUserSettingsDirty) {

This comment has been minimized.

Sign in to view
@andxu

andxu Nov 22, 2018 •
edited
Contributor

Could you please help to change the older mechanism of detecting setting dirty of using vscode.workspace.onDidChangeConfiguration and affectsConfiguration(see debugCodeLensProvider.ts)
instead of isUserSettingsDirty

This comment has been minimized.

Sign in to view
@RobertDeRose

RobertDeRose Nov 25, 2018
Author

Ok, I’ll take a look

This comment has been minimized.

Sign in to view
@andxu

andxu Dec 4, 2018
Contributor

Please also update the branch too.
@RobertDeRose RobertDeRose force-pushed the RobertDeRose:feature/support-alternative-jvm branch 2 times, most recently from d9691a3 to 5d477ff Aug 2, 2019
@RobertDeRose
Support for an alternative javaHome
Unverified
This user has not uploaded their public key yet.
GPG key ID: 754C0E6BE0E36A16 Learn about signing commits
Loading status checks…
454f94a 
* Added new launch configuration property `javaHome`
* Changed `updateDebugSettings` to optionally take in the config object
  - uses `config.javaHome` if available instead for calling `getJavaHome`
@RobertDeRose RobertDeRose force-pushed the RobertDeRose:feature/support-alternative-jvm branch from 5d477ff to 454f94a Aug 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@andxu andxu

At least 1 approving review is required to merge this pull request.

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants
@RobertDeRose @yaohaizh @Eskibear @andxu
You can’t perform that action at this time.