Add current java.home to detected installations

[mickaelistria]

What it does

Auto-discover the VM currently running the IDE as "Installed JRE"

How to test

• Install a good java version in a non-already-detected directory (you can also use JustJ and point to the VM in the bundle)
• Make sure this VM is added in your dev IDE in "Installed JREs"
• Start a launch config, taking care of configuring the JRE in the "Main" tab to use this undetected installatio
• Go to "Installed JRE" in the child/test IDE
• Without this patch: running VM not found 😞 ; with this patch: running VM found 😄

Author checklist

• I have thoroughly tested my changes
• The change is following the coding conventions
• I have signed the Eclipse Contributor Agreement (ECA)

[mickaelistria]

@basilevs by the way, what do you think about this one ?

[basilevs]

@basilevs by the way, what do you think about this one ?

This works for me without the patch, as long as I launch Eclipse for Java as a built product and not from a launch configuration. Is this change really necessary?

I will test again, to be sure.

[mickaelistria]

To me, with latest JustJ snapshot for Java 24, this patch is necessary for justj to be added.

[mickaelistria]

Note that other VMs were already detected before that (maybe it has an influence whether the list of installed VMs is initially empty or not...)

[basilevs]

I will test again, to be sure.

On a fresh Linux installation I've installed Temurin 21 and Eclipse for Java using Oomph selected Temurin 23. When Eclipse started, it already saw both VMs.

I've then copied Temurin 21 to /tmp/random_location and launched the same Eclipse using that installation. The random location was not discovered.

I'm not sure how Oomph installed JVM is discovered then.

[mickaelistria]

@rgrunber @jjohnstn Can you please review (and maybe merge)?

[basilevs]

@mickaelistria could you somehow fix the problem mentioned in #231 (comment) ?

The patch is otherwise good.

[mickaelistria]

could you somehow fix the problem mentioned in #231 (comment) ?

Well, as I'm not a committer, I don't think it would be faster for me to get it merged than for you. So as you identified the problem, I think it's better if you can provide a patch to get proper tracking of who actually did the hard part (ie detecting the problem).
But if submitting a PR for it is a problem to you, I can for sure create one; I just feel like it would be partly stealing your merit here ;)

[basilevs]

Well, as I'm not a committer,

Neither am I. Are you not the author of the original #231 where the collection in question was introduced?

But if submitting a PR for it is a problem to you, I can for sure create one; I just feel like it would be partly stealing your merit here ;)

I have no solution in mind yet. I can create one later, but I've thought that as the collection is touched here, it would make sense to fix it too.

[mickaelistria]

Are you not the author of the original #231 where the collection in question was introduced?

Indeed I am, yet I am not allowed to merge quickfixes with a faster process.

as the collection is touched here, it would make sense to fix it too.

Most people around Eclipse or JDT project prefer finer grain PRs/commits with a single purpose (so it makes it easier to understand the changes when looking at the history). So having the fix in another PR would be fine.

[mickaelistria]

@SougandhS As you seem active on this topic, would you please be able to review (and hopefully merge) this one too?

[SougandhS]

@SougandhS As you seem active on this topic, would you please be able to review (and hopefully merge) this one too?

Sure 👍

[SougandhS]

@mickaelistria does this only works with JustJ vendors ? when I tried with OpenJDK it detected even without patch

[mickaelistria]

Was OpenJDK installed in a directory that is already detected by default? Also, does the detection discover some other JVMs?

[basilevs]

when I tried with OpenJDK it detected even without patch

OpenJDK is usually installed in a standard easy to discover location. To test this, run JDT with Java installed in a non-standard directory. See my comment above

[SougandhS]

OpenJDK is usually installed in a standard easy to discover location. To test this, run JDT with Java installed in a non-standard directory. See my comment above

Didnt installed with any installers, just extracted the binaries to Mac's download folder and tried from there

[SougandhS]

Was OpenJDK installed in a directory that is already detected by default? Also, does the detection discover some other JVMs?

No actually

[mickaelistria]

It could be that in case no VM at all is found, then some other bit of code in JDT does add the current VM. But here, the proposal is to always add it.
To test it:

• Have a VM installed in one of the expected/discovered directories (verify that starting the Eclipse IDE adds it in the Installed JREs)
• Install another VM in another directory, and use this one to run Eclipse
• Expected: current VM added to the Installed JREs
  Got (on my OS): no VM added

Maybe it's also a mac oddity?

[basilevs]

Didnt installed with any installers, just extracted the binaries to Mac's download folder and tried from there

Usually MacOS registers JVM when installing it from *.pkg file, but some magic could perform registration by other means. Could you ensure that output of /usr/libexec/java_home -X does not contain the JVM from downloads folder?

[SougandhS]

Usually MacOS registers JVM when installing it from *.pkg file, but some magic could perform registration by other means. Could you ensure that output of /usr/libexec/java_home -X does not contain the JVM from downloads folder?

verified

[SougandhS]

Maybe it's also a mac oddity?

Does this work with Windows and Linux ?

[mickaelistria]

For Linux, yes, it does work for me.
I also remember that Mac apps may need particular permissions and whatnot. Maybe it can be the issue that the detected VM cannot be used anyway by Eclipse without particular permissions and thus is ignored by default?

[SougandhS]

For Linux, yes, it does work for me. I also remember that Mac apps may need particular permissions and whatnot. Maybe it can be the issue that the detected VM cannot be used anyway by Eclipse without particular permissions and thus is ignored by default?

If its a Mac only issue we can ignore it for now
Any idea about Win OS ?

[basilevs]

Any idea about Win OS ?

Reproduced on Microsoft Windows Server 2019 Datacenter, when launching:

C:\Users\Test\Documents\jdt\eclipse\eclipse.exe -vm C:\Users\Test\Documents\jdk-21.0.6.7-hotspot\bin\javaw.exe

Autodetect does not discover C:\Users\Test\Documents under these circumstances.
I have not tested patched version on Windows (only on Linux). Where can I get artifacts to test?

[mickaelistria]

Where can I get artifacts to test?

Unfortunately, the test builds don't produce artifacts (this could be changed, but that would be a different ticket to discuss).
I have not tested the case using the VM args with Linux; I tested it using the launch configuration. Does this make a difference? In Help > About > Configuraiton, do you see java.home properly defined?

[basilevs]

Where can I get artifacts to test?
I have not tested the case using the VM args with Linux; I tested it using the launch configuration. Does this make a difference?

Yes, many system properties are different when launching from source. I'm not sure if that difference affect this PR, but it might.

In Help > About > Configuraiton, do you see java.home properly defined?

Yes, for my tests it always is.