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