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