8359163: Fix path to current module on ios

[johanvos]

Minimize ios-specific logic to calculate the location for java_home.
The java_home property should be based on the jvm_path, and not on the user_home

Fix JDK-8359163

This patch still has ios-specific logic, e.g. we don't have a {client/server} suffix to the jvm home. More important, though, is that we do not want to point to userspace for the location of the jvm modules etc itself. Those should be derived from the installed application location, which matches the jvm_home property.
Applying this patch removes one more location where the mobile repository differs from upstream jdk.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8359163: Fix path to current module on ios (Bug - P4)

Reviewers

• Magnus Ihse Bursie (@magicus - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/mobile.git pull/39/head:pull/39
$ git checkout pull/39

Update a local copy of the PR:
$ git checkout pull/39
$ git pull https://git.openjdk.org/mobile.git pull/39/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 39

View PR using the GUI difftool:
$ git pr show -t 39

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/mobile/pull/39.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back jvos! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@johanvos This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8359163: Fix path to current module on ios

Reviewed-by: ihse

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 863 new commits pushed to the master branch:

• 1878e3b: Automatic merge of jdk:master into master
• e320162: 8365218: [JVMCI] AArch64 CPU features are not computed correctly after 8364128
• 6cc3fe4: Automatic merge of jdk:master into master
• ... and 860 more: https://git.openjdk.org/mobile/compare/c702197a418a503e315ba2ec649b45c194a6cd2e...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[mlbridge]

Webrevs

• 00: Full (cad2ebb4)

[johanvos]

@magicus can you review this?

[magicus]

LGTM. There is still a couple of #ifndef __IOS__ left so the diff towards main is unfortunately mostly there. :( But sure, just ifdeffing out code is superior to adding new logic so it's definitely a step in the right direction.

[johanvos]

/integrate

[openjdk]

Going to push as commit 4c77792.
Since your change was applied there have been 863 commits pushed to the master branch:

• 1878e3b: Automatic merge of jdk:master into master
• e320162: 8365218: [JVMCI] AArch64 CPU features are not computed correctly after 8364128
• 6cc3fe4: Automatic merge of jdk:master into master
• ... and 860 more: https://git.openjdk.org/mobile/compare/c702197a418a503e315ba2ec649b45c194a6cd2e...master

Your commit was automatically rebased without conflicts.

[openjdk]

@johanvos Pushed as commit 4c77792.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

[johanvos]

LGTM. There is still a couple of #ifndef __IOS__ left so the diff towards main is unfortunately mostly there. :( But sure, just ifdeffing out code is superior to adding new logic so it's definitely a step in the right direction.

Agree. There is more work to be done. I'm not 100% sure though about the best approach to fix the other IOS specific logic. There are a couple of options, and I try to avoid commiting option A only to realize later that option B would have been better.
But with this PR, we can run HelloWorld without much boilerplate code, and we can gain experience and feedback now.
Thanks!