Moving forward

[Magnus Ihse Bursie]

On 2023-10-13 09:18, Johan Vos wrote:

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

That is correct, but I would like to add that we tend to be more 
forgiving to pure build changes. We have code in the build system for a 
lot of systems that are not considered "supported" platforms. (Many of 
them to allow zero to compile on all amount of odd processor 
architectures...)

We also have a long-standing bug about the sad state of static library 
compilation in the JDK, where we basically have two different systems 
trying to achieve basically the same thing. I would definitely like for 
this state of affairs to improve (even if I'm not sure how much time I 
can personally spend on it), and it would not make sense to try and fix 
this without at the same time making sure that the end result is usable 
by the mobile project.

(See https://bugs.openjdk.org/browse/JDK-8211732 and 
https://bugs.openjdk.org/browse/JDK-8303796)


I am not a mobile developer, but in general terms I think your ideas 
with two branches -- one "integratable" with high-quality, properly 
reviewed commits, and one "development" branch where the bar for 
inclusion is lower, seem sound to me.

/Magnus


> 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