Headless Platform module?

[Craig Raw]

Hi Johan,

Thanks for working on this - count me as another developer who would love
to see this part of a non-sandbox build of OpenJFX.

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

I am not sure the answer should be expected to be "no". Given as you say
the headless platform in the sandbox does not contain native code - Java
code only - and is to my knowledge compact as an implementation, it seems
that the simplest approach is to place it in javafx.graphics, enabled by a
system property. This will support the testing and other use cases with
minimal configuration for all existing javafx.graphics modules, and allow
immediate use without updating build plugins etc to handle a new platform.
A headless mode is useful on every platform, so including it for every
platform module is a reasonable choice.

Regardless of what you decide, excited to see the Headless Glass Platform
progressing.

- Craig


On Mon, May 19, 2025 at 10:42 AM Johan Vos <johan.vos at gluonhq.com> 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
>> > [2] https://gluonhq.com/products/javafx/ , select [Headless] in JavaFX
>> > version
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250519/76f1d813/attachment.htm>