Moving forward
fabiani.giovanni at gmail.com
fabiani.giovanni at gmail.com
Mon Oct 23 10:24:45 UTC 2023
Hi all,
I see. I read the possible options. I have been trying to comprehend the various aspects of the topic treated. I have got ten years of java experience but I am new to openjdk developing. The bar is high for me so I ask you be patient.
I have been trying to figure out the subject
Cheers
Giovanni
From: mobile-dev <mobile-dev-retn at openjdk.org> On Behalf Of Johan Vos
Sent: venerdì 13 ottobre 2023 09:18
To: mobile-dev at openjdk.org
Subject: Moving forward
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/20231023/51a6a456/attachment.htm>
More information about the mobile-dev
mailing list