Moving forward
Johan Vos
johan.vos at gluonhq.com
Fri Oct 13 07:18:14 UTC 2023
Hi,
I want to toss a few ideas about how to move OpenJDK on Mobile forward.
There are 2 main areas I want to touch: code organization and validation
1. CODE ORGANIZATION
The git repository for this project is at https://github.com/openjdk/mobile
and it has a single branch (main) which contains a few changes compared to
the jdk repository.
The openjdk/jdk repository is not an upstream for openjdk/mobile, but the
Skara bot will sync all changes done in openjdk/jdk into openjdk/mobile.
This works really well, and only once every few months there are merge
conflicts which I solve manually.
However, the openjdk/mobile repository itself does not have all required
changes to build an ios/Android version of the JDK. Gluon has a fork of
openjdk/mobile (at gluonhq/mobile) that has 2 branches for building a
mobile JDK for Java 11 and Java 19 [1].
The changes introduced in these forks are minimal, but not (yet) upstreamed
to openjdk/mobile. The main reason for this is that that might conflict
with the "ultimate" goal of having all changes required to build the JDK on
mobile are in the upstream openjdk/jdk repository. The quality bar for
having changes in the openjdk/jdk repository is (for very good reasons)
pretty high, and it requires time and sponsoring from jdk
committers/reviewers.
Hence, I want the changes in the openjdk/mobile main branch to be as small
as possible, and with a top-quality, preferably already reviewed by a jdk
reviewer.
On the other hand, not having the changes from the gluonhq/mobile
repository upstreamed to openjdk/mobile makes it harder for others to build
OpenJDK Mobile. A solution I propose is to create a development branch that
accepts mobile-specific changes that are reviewed in the Mobile project.
Once there is enough experience and consensus, changes can be merged into
the openjdk/mobile main branch.
There are a number of options for this development branch or branches.
1. a single branch from main/HEAD that is automatically or manually being
synced from main (which is synced from openjdk/jdk).
2. version-specific branches (e.g. 21-dev) that either are not synced
(easiest) or that are synced from the respective jdk repositories (e.g.
openjdk/jdk21u). The latter requires help from the Skara team and/or the
OpenJDK infrastructure team.
2. VALIDATION
Successfully building the OpenJDK mobile libraries is 1 thing, but it would
be good to have some criteria that determines if a build is ok or not.
Given the goal of this project (running Java code on mobile systems), that
is not easy.
Again, there are a number of options here:
1. create a project (for ios/android) and use a no-jit/zero-interpreter
mode to run a basic HelloWorld (this is what is described at the project
pages [2] and [3]).
2. use an AOT compiled VM + sample code using GraalVM to convert a standard
HelloWorld app into a shared library, which is then linked with the
compiled VM into an ios/android project (this is what we currently do with
Gluon Substrate [4]).
If there are other options we should consider, I would love to hear that.
In general, feedback/comments are very welcome!
- Johan
[1] https://github.com/gluonhq/mobile/tree/jdk19
[2] https://openjdk.org/projects/mobile/ios.html
[3] https://openjdk.org/projects/mobile/android.html
[4] https://github.com/gluonhq/substrate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/mobile-dev/attachments/20231013/94311ba0/attachment.htm>
More information about the mobile-dev
mailing list