[External] : Re: Headless Platform module?

Mon May 19 15:13:04 UTC 2025

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

Oh, that does simplify things a fair bit -- and is a good illustration 
of my opinion being "less informed" than it might be. :)

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.

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.

-- Kevin

On 5/19/2025 1:40 AM, Johan Vos wrote:
> Hi Kevin,
>
> Thanks for the feedback and the valid questions.
> 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.
>
> 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.
>
> 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.
>
> 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.
> 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.
>
> But again, I'm totally open to all approaches.
>
> - Johan
>
>
> On Sat, May 17, 2025 at 1:25 AM Kevin Rushforth 
> <kevin.rushforth at oracle.com> wrote:
>
>     Interesting questions. There are two high level questions here (I
>     think). First, should the Monocle headless platform be part of the
>     javafx.graphics module or should it be a separate module? Second,
>     should
>     the headless "platform" be considered a completely different OS
>     platform
>     or, since it is largely platform-independent, should the headless
>     platform be built and bundled with each OS. The two questions are
>     somewhat related.
>
>     I haven't looked at the implementation of the headless platform,
>     so this
>     is a somewhat less informed opinion than it would be once I do.
>
>     As long as it is fairly small and doesn't have any public API surface
>     (meaning that the only way to use it is a system property that then
>     loads the Monocle glass backend along with another system property
>     that
>     selects the headless Monocle platform), it would seem easiest to
>     leave
>     it in javafx.graphics. This would mean we would start shipping the
>     Monocle classes that we currently exclude as well as the new headless
>     package. The second one depends on whether or not there is any native
>     code associated with the headless glass platform. If not, then the
>     easiest thing to do would be to always include it on all OS platforms.
>
>     There might be some advantages to putting it in its own module, but
>     without also moving all of Monocle to a different module, this sounds
>     like a lot of work and also would raise some issues that would
>     have to
>     be solved. Would we need to define an SPI? Formalize the Monocle back
>     end interfaces? Hmm.
>
>     Anyway, this is just food for thought at this point.
>
>     -- Kevin
>
>
>     On 5/16/2025 5:14 AM, Johan Vos wrote:
>     > Hi,
>     >
>     > The Headless Glass Platform has been in the jfx sandbox
>     repository [1]
>     > for some time now, and we have provided a number of builds allowing
>     > users to test the headless platform. The reactions were very
>     positive.
>     > It's mainly being used in 2 areas: testing is obviously a major
>     > usecase, especially remote testing and testing on systems where you
>     > don't want a UI to popup while developing; and applications where
>     > desktop functionality is used (e.g. printing, snapshots,...)
>     without a
>     > UI window being shown.
>     >
>     > I got a number of requests from developers who want to see this
>     part
>     > of a non-sandbox build of OpenJFX.
>     > Hence, I want to start the work on adding the headless
>     functionality
>     > in the OpenJFX main repository. If you look at the diff between the
>     > current head of the headless branch [1] and the master branch,
>     you'll
>     > notice it almost exclusively touches a new package:
>     > com.sun.glass.ui.headless.
>     > There are some minor changes in quantum and gtk, but those can be
>     > handled separately.
>     >
>     > Before starting the work on a JEP and a PR, I'd like to discuss the
>     > following: do we want the headless platform to be part of an
>     existing
>     > module (javafx.graphics), or do we want it to be part of a new
>     module?
>     > Currently, all glass platforms are part of the same module
>     > (javafx.graphics), and different SDKs contain different
>     > implementations -- with the Java top-level API being the same in
>     all
>     > modules.
>     >
>     > Apart from Monocle, there is a (non-official) 1-1 match between OS
>     > platform and glass platform (e.g. linux using GTK, MacOS using mac,
>     > iOS using ios,...). Therefore, the jmods, which are OS-specific,
>     can
>     > be (and are) organized in a way that they only contain the code
>     that
>     > is relevant to the target OS. It would be bad if the
>     javafx.graphics
>     > jmod for linux contained the windows-specific glass platform.
>     > Monocle violates this rule, because it is platform-independent
>     (at its
>     > own top-level, that is, because inside Monocle are a bunch of
>     > platform-specific components). Our "official" builds do not include
>     > Monocle, but we also offer builds with monocle, and it is pretty
>     > confusing. There is some logic in the current build.gradle that
>     either
>     > includes or excludes monocle from the modules.
>     >
>     > I want to avoid this confusion with the Headless Platform.
>     > It is clear that a javafx.graphics module for MacOS should not
>     contain
>     > code for Windows, but should it contain code for Headless? I would
>     > expect the answer to be "no". But then, how can developers use the
>     > Headless Platform? The bad scenario is the one that currently is
>     used
>     > with monocle, where the answer is: "It depends". If you download a
>     > "monocle SDK", then the javafx.graphcis jmod contains monocle, and
>     > your SDK can use monocle, hence setting glass.platform=Monocle will
>     > work. But with a regular build, the same will not work.
>     >
>     > Therefore, I believe it is worth considering the Headless
>     Platform to
>     > move into its own module. If developers want to leverage the
>     Headless
>     > Platform, they need to add the module. This requires work in the
>     > javafx.graphics module, as the headless code requires access to
>     > con.sun.glass.ui code, but I don't see any major issues here --
>     > although I don't want to underestimate the work needed to
>     securely add
>     > "glass providers" inside javafx.graphics. The latter might open the
>     > road to external glass implementations being added at runtime in
>     > specific configurations.
>     >
>     > A drawback I see for this approach is that the Headless Platform is
>     > then treated differently from the other (existing) platforms.
>     The GTK,
>     > mac, win, android, ios platforms are all part of a single module,
>     > where the Headless Platform would be in its own module. As
>     explained
>     > before, there is a very good reason for this (the 1-1 match between
>     > those platforms and the target system OS), so I don't see that
>     as an
>     > ugly thing.
>     >
>     > Before going in more detail, I'd like to hear opinions about this
>     > proposal to add a new module for the Headless Platform.
>     >
>     > - Johan
>     >
>     > [1]
>     https://github.com/openjdk/jfx-sandbox/tree/johanvos-headless
>     <https://urldefense.com/v3/__https://github.com/openjdk/jfx-sandbox/tree/johanvos-headless__;!!ACWV5N9M2RV99hQ!PFyeXAVKVuBuxtHHSBgp33CvwaByV0_HmozohESvm_6wEuvv7moTYT3XOu-OlhSoIFCbvodHKCwFK9rBNVwB42e1Cg$>
>     > [2] https://gluonhq.com/products/javafx/
>     <https://urldefense.com/v3/__https://gluonhq.com/products/javafx/__;!!ACWV5N9M2RV99hQ!PFyeXAVKVuBuxtHHSBgp33CvwaByV0_HmozohESvm_6wEuvv7moTYT3XOu-OlhSoIFCbvodHKCwFK9rBNVxD8BKC8Q$>
>     , select [Headless] in JavaFX
>     > version
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250519/bf65583f/attachment-0001.htm>