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