<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>On 2024-03-25 18:43, Johan Vos wrote:</p>
<blockquote type="cite" cite="mid:CABxFH2EbAKhxE-MDt3RxZiCRzvtcjtmHuN1NOuR7KSy4vZpoUQ@mail.gmail.com">
<div dir="ltr">Hi Magnus,
<div><br>
</div>
<div>Thanks for your reply. I can indeed tell that there are
major changes in upstream openjdk/jdk related to static
builds, as the Skara ran into 3 conflicts over the past week
while merging from upstream :)</div>
<div>That is great news, and I'm glad the static build gets
traction in openjdk/jdk. </div>
</div>
</blockquote>
<p>Great! I look forward working with you to make sure we get a
proper solution in upstream that will fit your needs as well.<br>
</p>
<blockquote type="cite" cite="mid:CABxFH2EbAKhxE-MDt3RxZiCRzvtcjtmHuN1NOuR7KSy4vZpoUQ@mail.gmail.com">
<div dir="ltr">
<div>This might be a good moment to work on the
remaining android/ios specific clauses that are in
openjdk/mobile but not (yet) in openjdk/jdk. </div>
</div>
</blockquote>
<p>Unfortunately, that is a bit of a different story. :-( We tend to
be very reluctant of accepting ports to new platforms, unless we
have someone (basically, an organization or a company) backing up
the port. That means things like providing a CI system for the
platform, making sure there is engineering resources available in
case there is trouble with the platform in a future PR, committing
to making the kind of changes necessary if the platform evolves
(virtual threads is a great example of a highly complicated kind
of change that might be needed), and finally, helping remove the
platform if it falls out of grace.</p>
<p>I don't know if you and/or Gluon might be able to provide what
would be needed. If you want to go down that route, we'd have to
start a discussion on porters-dev and involve Dalibor.</p>
<p>There are at least two points in favor in this case, though:</p>
<p>1) The changes required are fairly minimal. ios is basically
macosx, from the point of building, and android is basically
linux. It's not like porting to RISC-V where the entire C2 needs
to be rewritten.</p>
<p>2) I saw that you have already created tests on GitHub action for
these ports. That means there is a simple way to make sure we keep
the functionality tested, at least build-wise. (Someone will still
need to run the tests on a regular basis, to make sure they don't
break, though.)</p>
<p>/Magnus<br>
</p>
<p><br>
</p>
<blockquote type="cite" cite="mid:CABxFH2EbAKhxE-MDt3RxZiCRzvtcjtmHuN1NOuR7KSy4vZpoUQ@mail.gmail.com">
<div dir="ltr">
<div>It is probably best to wait until you finished your current
refactory of the static builds approach. I'll make sure the
openjdk/mobile follows the new approach, so that the diff will
be really small.</div>
<div><br>
</div>
<div>I will probably merge my PR with the latest additional
ios/Android changes into mobile/HEAD as that will make it
easier to merge the incoming (openjdk/HEAD) changes with the
latest changes for mobile.</div>
<div><br>
</div>
<div>Thanks again,</div>
<div><br>
</div>
<div>- Johan</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Mar 25, 2024 at
3:31 PM Magnus Ihse Bursie <<a href="mailto:magnus.ihse.bursie@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">magnus.ihse.bursie@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On
2024-03-23 17:42, Johan Vos wrote:<br>
<br>
> Hi,<br>
><br>
> I created a PR that brings in the remaining changes
needed to compile <br>
> an image containing the static JDK libs (not the VM libs)
for ios/android:<br>
> <a href="https://github.com/openjdk/mobile/pull/20" rel="noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/openjdk/mobile/pull/20</a><br>
><br>
> As a major improvement, this PR also adds ios/android
build scripts <br>
> for GA (thanks to Abhinay Agarwal for doing this). As a
consequence, <br>
> we will immediately notice if an upstream commit (in
openjdk/jdk) is <br>
> breaking the build for the mobile static libs.<br>
><br>
> In a previous message, I suggested a separate branch
would be my <br>
> preference for doing development work. However, there are
2 reasons <br>
> why I prefer this PR to go into the main branch:<br>
> 1. it seems I don't have permission to create new
branches<br>
> 2. there is at least 1 major embarrassing bug in the
current main <br>
> branch (fi instead of endif) hence an improvement sounds
appropriate.<br>
><br>
> Slightly related: the auto-merge operation by the skara
bot had 2 <br>
> merge conflicts recently, due to changes in the upstream
make <br>
> directories. I fixed the conflicts, and while I didn't
look in the <br>
> details yet, it seems Magnus is doing simplifications in
openjdk/jdk <br>
> that are also simplifying some of the build logic for
mobile. That is <br>
> great, thanks for that!<br>
<br>
<ominous music>More change is on the horizon. A storm is
<br>
coming.</ominous music> Or maybe not. But things will
happen in the area <br>
of static build. Hopefully good changes. :-) This is driven by
the <br>
Hermetic Java project, which requires static builds of the
entire JDK.<br>
<br>
I guess in the end this part of Hermetic Java is quite similar
to the <br>
mobile project, but with the intention of bringing this to
mainline. As <br>
a result of this wish, I wanted to make sure that static build
is <br>
properly treated as a "first class citizen" in the build
system.<br>
<br>
I was under the impression that the mobile project was more or
less <br>
abandoned, but I'm happy to see this is not the case. I hope I
can <br>
communicate with you so that we end up creating a single
solution for <br>
producing static builds that are usable both for mobile and
Hermetic Java.<br>
<br>
/Magnus<br>
<br>
<br>
</blockquote>
</div>
</blockquote>
</body>
</html>