Runtime fixes/enhancements for static JDK work

[Jiangli Zhou]

Hi Alan,

Thanks a lot for the feedback. Please see some comments inline below.

On Tue, Jun 27, 2023 at 6:07 AM Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> On 27/06/2023 00:46, Jiangli Zhou wrote:
> > :
> >
> > We've already recently integrated some of the static JDK related
> > changes, including duplicate symbol fixes and build changes for static
> > libraries. The main tracking bug is JDK-8303796 [5] currently. We'd
> > like your thoughts and opinions on if a new JEP would be needed/useful
> > for the additional runtime fixes/enhancement. The question has been
> > previously raised by Mark in JDK-8307858 [6] comments.
>
> As I see it, this patch gets you to the point of creating bin/javastatic
> containing all native code needed for headless (and jpackage-less) use
> on Linux. It's as you say, something that someone working on the JDK
> could use for testing, it's not something that suitable for distribution
> as it's incomplete.

Indeed, the makefile change in the github branch
(https://github.com/openjdk/jdk/compare/master...jianglizhou:jdk:static-java)
for building the bin/javastatic is for demo and testing purposes (for
the JDK static linking capability) only. Your comments above made me
realize that I should have been more clear with the earlier questions.
For the JDK/VM static linking related changes only (excluding the
makefile part) in the github branch, any feedback on if it's still
good with integrating them as individual bug fixes and minor
enhancements? Or it might be better to have broader conversations on
static images and start scoping out potential JEPs first? There are
benefits with both ways indeed.

>
> It's probably next steps where a JEP will be important, maybe several
> JEPs depending on far it goes and whether the effort is split into into
> coherent steps. There are many reasons why a JEP (or JEPs) will be
> needed. It's a significant move to produce and consume a self-contained
> static image. Today, the JDK image is zipped up or wrapped in an
> installer for developers to unzip or install. It's a big decision for
> producers of builds as to whether they will publish static images as
> alternative downloads. For developers, or other consumers of builds,
> they it's a hugely significant packaging/deployment option for developers.
>
> A JEP for next steps will also have to answer a lot of questions about
> packaging and the deployment experience. Will a static image include all
> standard + JDK modules, how will be integrate with jlink?   Can
> developers use static image "as is" or do they have to run a tool that
> combines their modular or non-modular application with the static image.
> Is jpackage in this story? There are many topics to discuss here.
>
> A JEP is a great place to capture topics on all the issues that arise
> from moving to a self containing file. Can jpackage or some other tool
> change the user-editable configuration when combining the output from
> the JDK build? What should code do if it re-execs itself with
> ${java.home}/bin/java? Can a self-contained image be
> monitored/management when the troubleshooting/other tools don't exist.
> There are many more questions like this that a JEP could answer.

Agreed, as you pointed out there are many open questions that need to
be discussed. In the hermetic Java prototype, some of the questions
(e.g. what we need to do with the tools that are normally packaged in
JDK binary, etc) are left open. For some of the questions, we have
only high-level thoughts, e.g. can the static image/executable be
re-exec'ed in places where  ${java.home}/bin/java would be used
normally? To help make the potential JEP(s) successful, it's possibly
a good time to start regular discussion meetings on scoping out more
details including considerations on jlink part, as you and Ron have
suggested.

Best,

Jiangli

>
> -Alan