<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <br>
    <blockquote type="cite">I believe the situation is maybe a bit less
      complex though, because the new headless platform does not depend
      on Monocle. I see it as a replacement for the Monocle Headless
      sub-platform, but it has no compile-time nor run-time dependencies
      on Monocle.</blockquote>
    <br>
    Oh, that does simplify things a fair bit -- and is a good
    illustration of my opinion being "less informed" than it might be.
    :)<br>
    <br>
    Given that there is no dependency on Monocle (good), no native code
    (also good), and no public API (very good), then I don't think it
    matters as much whether it is part of javafx.graphics or a new
    module (if a new module, the qualified exports needed to put it in
    its own module should be straightforward). I might have additional
    thoughts after I look at the code, but as of now either approach
    seems fine.<br>
    <br>
    And you are right that either way you end up going with this, it
    will give some additional experience that could inform what happens
    to Monocle in the future.<br>
    <br>
    -- Kevin<br>
    <br>
    <div class="moz-cite-prefix">On 5/19/2025 1:40 AM, Johan Vos wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CABxFH2EQxAKuem-FMUY7Ms2GnHjR_NcAcqiJ4Xgsd2dY=1hkqA@mail.gmail.com">
      
      <div dir="ltr">Hi Kevin,
        <div><br>
        </div>
        <div>Thanks for the feedback and the valid questions.</div>
        <div>I believe the situation is maybe a bit less complex though,
          because the new headless platform does not depend on Monocle.
          I see it as a replacement for the Monocle Headless
          sub-platform, but it has no compile-time nor run-time
          dependencies on Monocle. The Monocle platform has been very
          valuable to provide "simple" glass implementations for more
          niche-systems (including Android, MX6, OMAP, EPD,...). One of
          those niche-systems is "headless". That makes headless a
          special case of Monocle, and its implementation has to follow
          the Monocle contracts, which are created to add native
          implementations with a minimal amount of code. Therefore, the
          headless Monocle subplatform is more complex than if it was a
          top-level platform.</div>
        <div><br>
        </div>
        <div>Including Monocle in the standard javafx.graphics build is
          very hard, because that requires compiling, linking and
          bundling all the native libraries for all the subprojects
          (Android, MX6,...) on all platforms. For someone who just
          wants to use a headless platform (e.g. for testing or
          printing) on Windows, that is overkill.</div>
        <div><br>
        </div>
        <div>Therefore, the headless platform in the sandbox does not
          contain native code, and it does not
          extend com.sun.glass.ui.monocle.nativePlatform. It is java
          code only, and depends on com.sun.glass.ui, similar to how the
          gtk/mac/win platforms do. </div>
        <div><br>
        </div>
        <div>The SPI question is an interesting one, and I've been
          thinking about that as well. I believe it would be a better,
          more flexible approach than what we currently do within
          Monocle. As said, because Monocle currently contains native
          implementations for a bunch of sub-platforms, we either
          include native libs for all these platforms, or for none
          (which makes it unusable)). That makes it a maintenance
          nightmare (who is going to maintain the OMAP code, for
          example?). It would be easier if each niche-platform could
          have its own module, maintained by their own experts. In that
          case, an SPI approach would be very convenient.</div>
        <div>But that opens more questions and discussions, so I
          personally think that is not something we have to do right
          now. Having the headless platform (either in its own module or
          packaged into the javafx.graphics module) will give us more
          experience in the different usecases, so that could bring in
          the data that is needed to do the SPI approach later.</div>
        <div><br>
        </div>
        <div>But again, I'm totally open to all approaches.</div>
        <div><br>
        </div>
        <div>- Johan</div>
        <div><br>
        </div>
      </div>
      <br>
      <div class="gmail_quote gmail_quote_container">
        <div dir="ltr" class="gmail_attr">On Sat, May 17, 2025 at
          1:25 AM Kevin Rushforth <<a href="mailto:kevin.rushforth@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">kevin.rushforth@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">Interesting
          questions. There are two high level questions here (I <br>
          think). First, should the Monocle headless platform be part of
          the <br>
          javafx.graphics module or should it be a separate module?
          Second, should <br>
          the headless "platform" be considered a completely different
          OS platform <br>
          or, since it is largely platform-independent, should the
          headless <br>
          platform be built and bundled with each OS. The two questions
          are <br>
          somewhat related.<br>
          <br>
          I haven't looked at the implementation of the headless
          platform, so this <br>
          is a somewhat less informed opinion than it would be once I
          do.<br>
          <br>
          As long as it is fairly small and doesn't have any public API
          surface <br>
          (meaning that the only way to use it is a system property that
          then <br>
          loads the Monocle glass backend along with another system
          property that <br>
          selects the headless Monocle platform), it would seem easiest
          to leave <br>
          it in javafx.graphics. This would mean we would start shipping
          the <br>
          Monocle classes that we currently exclude as well as the new
          headless <br>
          package. The second one depends on whether or not there is any
          native <br>
          code associated with the headless glass platform. If not, then
          the <br>
          easiest thing to do would be to always include it on all OS
          platforms.<br>
          <br>
          There might be some advantages to putting it in its own
          module, but <br>
          without also moving all of Monocle to a different module, this
          sounds <br>
          like a lot of work and also would raise some issues that would
          have to <br>
          be solved. Would we need to define an SPI? Formalize the
          Monocle back <br>
          end interfaces? Hmm.<br>
          <br>
          Anyway, this is just food for thought at this point.<br>
          <br>
          -- Kevin<br>
          <br>
          <br>
          On 5/16/2025 5:14 AM, Johan Vos wrote:<br>
          > Hi,<br>
          ><br>
          > The Headless Glass Platform has been in the jfx sandbox
          repository [1] <br>
          > for some time now, and we have provided a number of
          builds allowing <br>
          > users to test the headless platform. The reactions were
          very positive. <br>
          > It's mainly being used in 2 areas: testing is obviously a
          major <br>
          > usecase, especially remote testing and testing on systems
          where you <br>
          > don't want a UI to popup while developing; and
          applications where <br>
          > desktop functionality is used (e.g. printing,
          snapshots,...) without a <br>
          > UI window being shown.<br>
          ><br>
          > I got a number of requests from developers who want to
          see this part <br>
          > of a non-sandbox build of OpenJFX.<br>
          > Hence, I want to start the work on adding the headless
          functionality <br>
          > in the OpenJFX main repository. If you look at the diff
          between the <br>
          > current head of the headless branch [1] and the master
          branch, you'll <br>
          > notice it almost exclusively touches a new package: <br>
          > com.sun.glass.ui.headless.<br>
          > There are some minor changes in quantum and gtk, but
          those can be <br>
          > handled separately.<br>
          ><br>
          > Before starting the work on a JEP and a PR, I'd like to
          discuss the <br>
          > following: do we want the headless platform to be part of
          an existing <br>
          > module (javafx.graphics), or do we want it to be part of
          a new module?<br>
          > Currently, all glass platforms are part of the same
          module <br>
          > (javafx.graphics), and different SDKs contain different <br>
          > implementations -- with the Java top-level API being the
          same in all <br>
          > modules.<br>
          ><br>
          > Apart from Monocle, there is a (non-official) 1-1 match
          between OS <br>
          > platform and glass platform (e.g. linux using GTK, MacOS
          using mac, <br>
          > iOS using ios,...). Therefore, the jmods, which are
          OS-specific, can <br>
          > be (and are) organized in a way that they only contain
          the code that <br>
          > is relevant to the target OS. It would be bad if the
          javafx.graphics <br>
          > jmod for linux contained the windows-specific glass
          platform.<br>
          > Monocle violates this rule, because it is
          platform-independent (at its <br>
          > own top-level, that is, because inside Monocle are a
          bunch of <br>
          > platform-specific components). Our "official" builds do
          not include <br>
          > Monocle, but we also offer builds with monocle, and it is
          pretty <br>
          > confusing. There is some logic in the current
          build.gradle that either <br>
          > includes or excludes monocle from the modules.<br>
          ><br>
          > I want to avoid this confusion with the Headless
          Platform.<br>
          > It is clear that a javafx.graphics module for MacOS
          should not contain <br>
          > code for Windows, but should it contain code for
          Headless? I would <br>
          > expect the answer to be "no". But then, how can
          developers use the <br>
          > Headless Platform? The bad scenario is the one that
          currently is used <br>
          > with monocle, where the answer is: "It depends". If you
          download a <br>
          > "monocle SDK", then the javafx.graphcis jmod contains
          monocle, and <br>
          > your SDK can use monocle, hence setting
          glass.platform=Monocle will <br>
          > work. But with a regular build, the same will not work.<br>
          ><br>
          > Therefore, I believe it is worth considering the Headless
          Platform to <br>
          > move into its own module. If developers want to leverage
          the Headless <br>
          > Platform, they need to add the module. This requires work
          in the <br>
          > javafx.graphics module, as the headless code requires
          access to <br>
          > con.sun.glass.ui code, but I don't see any major issues
          here -- <br>
          > although I don't want to underestimate the work needed to
          securely add <br>
          > "glass providers" inside javafx.graphics. The latter
          might open the <br>
          > road to external glass implementations being added at
          runtime in <br>
          > specific configurations.<br>
          ><br>
          > A drawback I see for this approach is that the Headless
          Platform is <br>
          > then treated differently from the other (existing)
          platforms. The GTK, <br>
          > mac, win, android, ios platforms are all part of a single
          module, <br>
          > where the Headless Platform would be in its own module.
          As explained <br>
          > before, there is a very good reason for this (the 1-1
          match between <br>
          > those platforms and the target system OS), so I don't see
          that as an <br>
          > ugly thing.<br>
          ><br>
          > Before going in more detail, I'd like to hear opinions
          about this <br>
          > proposal to add a new module for the Headless Platform.<br>
          ><br>
          > - Johan<br>
          ><br>
          > [1] <a href="https://urldefense.com/v3/__https://github.com/openjdk/jfx-sandbox/tree/johanvos-headless__;!!ACWV5N9M2RV99hQ!PFyeXAVKVuBuxtHHSBgp33CvwaByV0_HmozohESvm_6wEuvv7moTYT3XOu-OlhSoIFCbvodHKCwFK9rBNVwB42e1Cg$" rel="noreferrer" target="_blank" moz-do-not-send="true">https://github.com/openjdk/jfx-sandbox/tree/johanvos-headless</a><br>
          > [2] <a href="https://urldefense.com/v3/__https://gluonhq.com/products/javafx/__;!!ACWV5N9M2RV99hQ!PFyeXAVKVuBuxtHHSBgp33CvwaByV0_HmozohESvm_6wEuvv7moTYT3XOu-OlhSoIFCbvodHKCwFK9rBNVxD8BKC8Q$" rel="noreferrer" target="_blank" moz-do-not-send="true">https://gluonhq.com/products/javafx/</a>
          , select [Headless] in JavaFX <br>
          > version<br>
          <br>
        </blockquote>
      </div>
    </blockquote>
    <br>
  </body>
</html>