From jvos at openjdk.org  Wed Aug 13 14:25:44 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 13 Aug 2025 14:25:44 GMT
Subject: RFR: 8359163: Fix path to current module on ios
In-Reply-To: <fA6RszOee6TUnP0V_zdzjvQktUVoDmfPJGC7iHmmPlo=.1def58e6-ce00-4564-bf93-08f737e390b0@github.com>
References: <fA6RszOee6TUnP0V_zdzjvQktUVoDmfPJGC7iHmmPlo=.1def58e6-ce00-4564-bf93-08f737e390b0@github.com>
Message-ID: <kNtzlRRX0kI0ZSDphJU39LFebyVF1WczcxUbZuYFhSc=.73337d7a-d792-4dee-89e7-ed7326dcf099@github.com>

On Tue, 29 Jul 2025 14:18:28 GMT, Johan Vos <jvos at openjdk.org> wrote:

> 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.

@magicus can you review this?

-------------

PR Comment: https://git.openjdk.org/mobile/pull/39#issuecomment-3184144652

From ihse at openjdk.org  Thu Aug 14 09:25:29 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Aug 2025 09:25:29 GMT
Subject: RFR: 8359163: Fix path to current module on ios
In-Reply-To: <fA6RszOee6TUnP0V_zdzjvQktUVoDmfPJGC7iHmmPlo=.1def58e6-ce00-4564-bf93-08f737e390b0@github.com>
References: <fA6RszOee6TUnP0V_zdzjvQktUVoDmfPJGC7iHmmPlo=.1def58e6-ce00-4564-bf93-08f737e390b0@github.com>
Message-ID: <xRiBzROeW-h2PLMuS4ys62Rvxzt_vGhRTiqQ_O5sLT4=.ed4e88a9-0d75-49cf-90a5-5deb647d223f@github.com>

On Tue, 29 Jul 2025 14:18:28 GMT, Johan Vos <jvos at openjdk.org> wrote:

> 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.

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.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/mobile/pull/39#pullrequestreview-3119792521

From jvos at openjdk.org  Thu Aug 14 09:39:31 2025
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 14 Aug 2025 09:39:31 GMT
Subject: RFR: 8359163: Fix path to current module on ios
In-Reply-To: <xRiBzROeW-h2PLMuS4ys62Rvxzt_vGhRTiqQ_O5sLT4=.ed4e88a9-0d75-49cf-90a5-5deb647d223f@github.com>
References: <fA6RszOee6TUnP0V_zdzjvQktUVoDmfPJGC7iHmmPlo=.1def58e6-ce00-4564-bf93-08f737e390b0@github.com>
 <xRiBzROeW-h2PLMuS4ys62Rvxzt_vGhRTiqQ_O5sLT4=.ed4e88a9-0d75-49cf-90a5-5deb647d223f@github.com>
Message-ID: <GOljfATwCuykPdRKcTVkFGQ5s2hu-mBEMQgkLBalKlY=.b148ca54-9adb-40e8-9637-d9b4e8ecf330@github.com>

On Thu, 14 Aug 2025 09:22:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> 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!

-------------

PR Comment: https://git.openjdk.org/mobile/pull/39#issuecomment-3187794259

From jvos at openjdk.org  Thu Aug 14 09:39:31 2025
From: jvos at openjdk.org (Johan Vos)
Date: Thu, 14 Aug 2025 09:39:31 GMT
Subject: Integrated: 8359163: Fix path to current module on ios
In-Reply-To: <fA6RszOee6TUnP0V_zdzjvQktUVoDmfPJGC7iHmmPlo=.1def58e6-ce00-4564-bf93-08f737e390b0@github.com>
References: <fA6RszOee6TUnP0V_zdzjvQktUVoDmfPJGC7iHmmPlo=.1def58e6-ce00-4564-bf93-08f737e390b0@github.com>
Message-ID: <HF5XWxqarlg0CqH-ODwO67Sx-UlupdST9JOVjpI3Ckg=.c7cc9d9e-2ea1-402a-93dd-7018681ea43d@github.com>

On Tue, 29 Jul 2025 14:18:28 GMT, Johan Vos <jvos at openjdk.org> wrote:

> 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.

This pull request has now been integrated.

Changeset: 4c777924
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/mobile/commit/4c7779247d16b83229cb6ebb08c2ec46c91e65e3
Stats:     7 lines in 1 file changed: 1 ins; 6 del; 0 mod

8359163: Fix path to current module on ios

Reviewed-by: ihse

-------------

PR: https://git.openjdk.org/mobile/pull/39

From johan.vos at gluonhq.com  Fri Aug 29 12:33:32 2025
From: johan.vos at gluonhq.com (Johan Vos)
Date: Fri, 29 Aug 2025 14:33:32 +0200
Subject: Beyond OpenJDK builds, announcing openjdk-mobile.github.io
Message-ID: <CABxFH2Hx1q25B0Of9np2ggUAf1rCLwoMJVe4Vi9U=JbWz3wNNQ@mail.gmail.com>

Hi,

With the work being done in the openjdk/mobile project, it is now possible
to build the OpenJDK sources targeting mobile platforms. That by itself is
a great outcome.

However, there is still a significant gap between a platform-specific build
of OpenJDK and a Java-based application running on that platform. In the
server/cloud world, there is a lot of effort going into deploying and
managing Java applications on cloud systems. On mobile, the situation is
different from the server, but additional work is still needed.

This is why Gluon created a GitHub-based project website:
https://openjdk-mobile.github.io, where the steps between a build of
OpenJDK Mobile and a running HelloWorld application are explained and
discussed. I deliberately want this to be a community effort, rather than a
Gluon-only initiative. I don't think the contents of this website belong in
the openjdk/mobile repository, similar to how, for example, Kubernetes is
not part of OpenJDK. I do hope, though, that OpenJDK developers from
different companies will participate in this effort (and I'm very open to
discuss what should be in OpenJDK/mobile and what not).

The openjdk-mobile.github.io website is part of the openjdk-mobile
organization I created on GitHub. I also created another repository under
that organization, named ios-tools. In this repository, we developed a
number of GitHub Actions and scripts that automate most of the process to
run Java apps on ios:

* build libffi on iOS
* build OpenJDK for iOS
* create an Xcode framework based on the artifacts from the OpenJDK build
* use the created Xcode framework to run Java apps on iOS (no automation in
place yet)

Each of these steps is briefly explained, and readers can either download
the artifacts or build them themselves. There are nightly builds in place
that build everything from source code. As a consequence, we immediately
detect regressions in the different parts. This is one of my key focus
areas: maintainability. I don't want to patch a specific version of OpenJDK
just to run on a specific version of iOS; I would rather have the head of
openjdk/mobile continuously work on iOS.

The website is a work in progress. Gluon developers contribute to it, but
as mentioned, I hope others will contribute as well. We currently have a
working pipeline for running HelloWorld on an iOS device, but there is
still plenty of work to do (e.g., support for the iOS simulator and
Android).

I realize there is still a big difference between a HelloWorld application
that prints something on the console and a feature-rich mobile consumer
app. The process we are following, however, allows different steps to be
worked on in parallel:

1. We can now run HelloWorld on iOS using the zero interpreter, without AOT
or any optimization. This can be improved, and thanks to the build
pipelines we can now detect regressions. I am personally very eager to see
integrations of Leyden-based work.

2. We can add JavaFX applications. We've done this before, and there is no
showstopper to doing it again. However, I want to achieve the same level of
quality that we now have in openjdk/mobile. I don't want any
mobile-specific patch in JavaFX that is not 100% understood and justified.
Again, maintainability is key.

3. We can convert Java libraries into native mobile libraries. This
requires an approach to annotating Java methods that need to be exposed to
consumers of the resulting native libraries.

Apart from this, the iOS steps need to be repeated on Android -- which is a
bit easier because we can use a JIT there.

There is a lot of work to be done, and we don't have the same level of
resources as those invested in Java in cloud/server environments. I don't
expect miracles -- but no miracle is needed to run Java as a first-class
citizen on mobile platforms. Java was designed to do this job; it's just a
matter of making it happen.

- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/mobile-dev/attachments/20250829/e2dea9b9/attachment-0001.htm>