<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Phil,<br>
<br>
Thank you for clarification.<br>
JComponent's createImage() is called through the RepaintManager
which does LW painting.<br>
I worried about the server off-screen painting possibility that
could be organized in a JDK port using peer based approach. But
probably the original specs did not assume it.<br>
So the fix looks good.<br>
<br>
--Semyon<br>
<br>
<br>
<div class="moz-cite-prefix">On 9/25/2015 8:51 PM, Phil Race wrote:<br>
</div>
<blockquote cite="mid:56058994.8080403@oracle.com" type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<div class="moz-cite-prefix">There seems to be a lot of back and
forth here.<br>
<br>
Fundamentally what this bug is about is changing one word: "May"
-> "Will"<br>
<br>
So the question to be answered is can we make that change ?<br>
<br>
As I think was noted somewhere in the thread, in headless mode,<br>
the heavyweight AWT components can't exist to begin with.<br>
Still, I think it is perfectly fine and helpful for these
methods to indicate <br>
what they do in headless mode so long as it is in fact the case.<br>
<br>
And in headful mode, components which have not yet been
associated<br>
with a display may not be able to allocate the resource, so we
can<br>
consistently return null in that case.<br>
<br>
The interesting one is lightweight components where the
association<br>
with a native display resource is a lot more distant. However I
do<br>
not see JComponent over-riding createImage, so unless I am
missing<br>
something that should be fine too.<br>
<br>
So with that caveat I think this change is fine.<br>
<br>
Some background notes about headless and peers :<br>
<br>
Headless mode basically means there is no possibility of
connecting<br>
to a display server. <br>
So the only things that are available are those<br>
that can be executed without such a platform resource.<br>
This therefore disallows top-level windows and the set of AWT
components<br>
which are considered 'heavyweight'.<br>
<br>
The details of how headless mode is implemented depends on the
platform.<br>
On Solaris it means we do not even link against X11. It does not
even need<br>
the X11 libraries installed on the O/S<br>
On Windows we still link against GDI, we just disallow using it.<br>
<br>
So you can largely thing of headless mode as "no AWT mode"<br>
Java 2D in general does not need a display server.<br>
[Do not conflate package names containing java.awt with being
AWT.<br>
There is no "java.2d" package so it is all mixed in.]<br>
Java 2D can draw quite happily to a system/java heap<br>
memory image and send that to any destination.<br>
Fonts and printing (part of 2D) do not need a display server.<br>
<br>
Also being able to access a peer is not something that
applications<br>
can/should do. Peer is a concept that is discussed but an actual
peer<br>
type is internal to the implementation. JDK 9 has updates that
make<br>
this more clear than it was.<br>
<br>
-phil.<br>
<br>
On 09/25/2015 10:13 AM, Semyon Sadetsky wrote:<br>
</div>
<blockquote cite="mid:560580C8.1000305@oracle.com" type="cite">
<meta content="text/html; charset=utf-8"
http-equiv="Content-Type">
<br>
<br>
<div class="moz-cite-prefix">On 9/25/2015 7:06 PM, Sergey
Bylokhov wrote:<br>
</div>
<blockquote cite="mid:56057121.8010109@oracle.com" type="cite">On
25.09.15 18:38, Semyon Sadetsky wrote: <br>
<blockquote type="cite"> <br>
<br>
On 9/25/2015 4:51 PM, Sergey Bylokhov wrote: <br>
<blockquote type="cite">On 25.09.15 15:44, Semyon Sadetsky
wrote: <br>
<blockquote type="cite"> <br>
<br>
On 9/25/2015 2:46 PM, Sergey Bylokhov wrote: <br>
<blockquote type="cite">On 25.09.15 10:13, Semyon
Sadetsky wrote: <br>
<blockquote type="cite">Native container based
components are disabled. But other native <br>
resources can be used if available. <br>
</blockquote>
<br>
no hw components -> no backbuffers for them. <br>
</blockquote>
In my understanding it depends on the component. If
component capable to <br>
work in the headless mode it can continue to use its
peer, can't it? <br>
<blockquote type="cite"> <br>
<blockquote type="cite">All **Peer interfaces are
public and external. Peer is not a hidden or <br>
implementation specific term. It isn't allowed to
application <br>
developers <br>
for implementation, but it is used for porting
client libs to other <br>
platforms. Java specification has wider vision than
one particular <br>
implementation. And for porting the headless mode is
very sensitive <br>
topic because specific platforms are headless often.
<br>
</blockquote>
<br>
The java.awt.peer package is private and should be
used by the awt <br>
developers only. If the new port will be implemented
then it should <br>
follow the same specification as our implementation. <br>
</blockquote>
</blockquote>
<br>
<blockquote type="cite">That's correct. And our
specification should be reasonable in its turn. <br>
It must not be simply back-filled from our code
otherwise it would <br>
unlikely have more than one implementation. <br>
JCK team likes direct specs in "if-then" style. But I
see that the <br>
initial doc was soft enough because it just clarify that
exceptions from <br>
the general rule are possible depending on the specific
implementation <br>
concept to leave more possibilities for porting. <br>
</blockquote>
<br>
But it was not strict enough, we always return null for a
long time, <br>
all other ports do the same because jck require this. So
this is not a <br>
problem for possible ports and this removes possible
misleading <br>
assumption for application developers. This fix is a spec
<br>
clarification that an application should not try to create
a buffer <br>
for the hw component in such situations. <br>
<br>
The article I send you <br>
<blockquote type="cite">also contains a lot of soft
phrases. <br>
<blockquote type="cite"> <br>
<blockquote type="cite">
<blockquote type="cite"> <br>
Maybe <br>
<blockquote type="cite">Component#getImage()
implementation should simply check for <br>
isHeadless() <br>
and return null? <br>
</blockquote>
</blockquote>
But what will happen if Unix DISPLAY variable is not
set so <br>
isHeadlessInstance()=true? Will peer be allowed?
Should component <br>
buffering work smoothly? <br>
</blockquote>
<br>
The peers are not allowed in the headless mode. The
DISPLAY var is not <br>
specified in the javadoc, this means that some
implementation can work <br>
when DISPLAY is empty/unset, but in this case they
must return false <br>
from the isHeadlessXX(); <br>
</blockquote>
isHeadlessInstance() just tests DISPLAY on Linux. <br>
</blockquote>
<br>
This is our implementation, other can check other things.
There are <br>
some implementation that can work without display, but in
this case <br>
this environment is not headless. <br>
<br>
Can you specify what sentence you complain? <br>
This cannot be removed since it was there already <br>
"This will always happen if <br>
*
<code>GraphicsEnvironment.isHeadless()</code>
returns <br>
* <code>true</code>." <br>
</blockquote>
<br>
"The return value may be null if the component is not
displayable. This <br>
will always happen if GraphicsEnvironment.isHeadless()
returns true." <br>
<br>
your new version: <br>
<br>
"Returns null value if the component is not displayable or <br>
GraphicsEnvironment.isHeadless() returns true" <br>
<br>
which invited me as a reviewer to find an "if" in the method
body or <br>
deeper, because it sounds "It shall return null if ..." . <br>
But I didn't find it. Imagine if you get this spec to be
implemented <br>
from scratch. Why 'if' is not added as the first line? That
would <br>
eliminate all questions. <br>
</blockquote>
<br>
Is this check in the code is not clear? <br>
(peer != null) ? peer.createImage(width, height) : null <br>
</blockquote>
It is not obvious. It should check
if(GraphicsEnvironment.isHeadless()) {return null;}. Why to
execute anything else?<br>
Look on the similar spec and its implementation:<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=utf-8">
    * @exception HeadlessException if
GraphicsEnvironment.isHeadless()<br>
    * returns true<br>
    * @see java.awt.GraphicsEnvironment#isHeadless<br>
    */<br>
   public Button(String label) throws HeadlessException {<br>
       GraphicsEnvironment.checkHeadless();<br>
       this.label = label;<br>
   }<br>
<blockquote cite="mid:56057121.8010109@oracle.com" type="cite">
<br>
<blockquote type="cite"> <br>
The previous version doesn't demand "if" because it is
indirect and as <br>
developer I would never rely on the null value promised by
such spec. <br>
But with the new version of the spec the null should be
guaranteed for <br>
the specified conditions otherwise we receive a bug. <br>
</blockquote>
<br>
And if an application, which will tested on your code, will
start on our jdk it will fail with npe. <br>
<br>
</blockquote>
No, its reversed. I meant "relay on null value". That means any
logic that expects null value only at this conditions may fail.
<br>
<blockquote cite="mid:56057121.8010109@oracle.com" type="cite">
<blockquote type="cite"> <br>
And I cannot see the reason why non-null value cannot be
allowed because <br>
it doesn't brake anything. <br>
Explanation "we define this and developers should follow" is
a bit <br>
frustrating because I see scenarios when component buffer
could be <br>
useful in the headless mode. <br>
</blockquote>
<br>
This is not about a headless. <br>
</blockquote>
Why? I provided you reference to the article in which states
opposite. Peer#createVolatileImage() may be used in headless.<br>
For example, a network server without GUI can render images and
send them to client via network or to printer. Why it cannot use
its available hardware for image rendering?<br>
Maybe there are some obstacles for that which I don't know. I'd
appreciate it if you provide them.<br>
<blockquote cite="mid:56057121.8010109@oracle.com" type="cite">
<br>
<blockquote type="cite"> <br>
I suspect the original spec didn't imply strict binding to
the values, <br>
and this fix may simplify testing but distorts the original
approach. <br>
</blockquote>
<br>
It is always good to specify strict and clear null behavior to
suppress possible surprises. <br>
<br>
<blockquote type="cite">I just unsure that this issue should
be resolved. Maybe other reviewers <br>
could add their opinion. <br>
<blockquote type="cite"> <br>
<br>
<blockquote type="cite">
<blockquote type="cite"> <br>
<blockquote type="cite">Note this is a common network
server scenario which runs Java app from <br>
the text console. I cannot get from the spec is it
completely <br>
different <br>
headless mode or it is the same as the global
headless? <br>
<blockquote type="cite"> <br>
<blockquote type="cite"> <br>
And more global question: Why should we disable
the creating of <br>
component image buffer for the headless mode?It
could be used for <br>
the <br>
same performance reason as in non-headless. <br>
</blockquote>
<br>
in the headless mode we cannot create most of the
hw components, <br>
actually non of top level window can be created.
And for lw <br>
components <br>
like in swing the one global buffer is used in the
RepaintManager. <br>
</blockquote>
One global buffer means one global repaint <br>
</blockquote>
<br>
No this is not true. If one component is changed then
only one <br>
component is repainted. <br>
<br>
off all components for any <br>
<blockquote type="cite">single component change. Why
can't we be isomorphic here? <br>
<blockquote type="cite"> <br>
<blockquote type="cite">
<blockquote type="cite"> <br>
<blockquote type="cite">
<blockquote type="cite"> <br>
The headless case is covered, heavyweight
components cannot be <br>
created <br>
in such mode, so only lightweight buttons
are checked. <br>
<br>
On 24.09.15 15:58, Semyon Sadetsky wrote:
<br>
<blockquote type="cite"> <br>
<br>
On 9/24/2015 3:25 PM, Sergey Bylokhov
wrote: <br>
<blockquote type="cite">On 24.09.15
11:36, Semyon Sadetsky wrote: <br>
<blockquote type="cite">Hi Sergey, <br>
<br>
 isHeadless()=true must return
null. If so please add the <br>
corresponding <br>
test case. It is not not obvious
from the code. <br>
</blockquote>
<br>
isHeadless()=true is headless mode
where the frames are always <br>
not <br>
displayable, so everything is similar
to the current test <br>
except <br>
that <br>
in headless the pack() will be throw
an exception and second <br>
part of <br>
the test in this mode is unnecessary.
<br>
</blockquote>
Then maybe simply do not call pack() for
the headless test? <br>
Okay, let me rephrase what I meant.
Since isHeadless()=true <br>
case is <br>
mentioned in those 3 specs so explicitly
it must be guarantied <br>
that <br>
the <br>
specified behavior works for the case as
described. I cannot <br>
trace <br>
the <br>
result by reading the code of the
createImage(), isHeadless() <br>
method is <br>
not even called there. So the test case
should be added. Or you <br>
could <br>
remove isHeadless() references from the
specs. Or write <br>
something <br>
like <br>
"the result is non-deterministic if
isHeadless() is not <br>
false..." <br>
<blockquote type="cite"> <br>
<blockquote type="cite"> <br>
--Semyon <br>
<br>
On 9/23/2015 9:14 PM, Sergey
Bylokhov wrote: <br>
<blockquote type="cite">Hello. <br>
Please review the fix for jdk9. <br>
The specification is updated as
suggested in JDK-6186530 and <br>
JDK-6815345. The test is added to
prove that we always return <br>
null <br>
when the component is not
displayable. <br>
<br>
ccc request will be created after
the technical review. One <br>
additional <br>
bug filed <a
moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://bugs.openjdk.java.net/browse/JDK-8137047"><a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8137047">https://bugs.openjdk.java.net/browse/JDK-8137047</a></a>
<br>
<br>
Bug: <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://bugs.openjdk.java.net/browse/JDK-6815345">https://bugs.openjdk.java.net/browse/JDK-6815345</a>
<br>
Webrev can be found at: <br>
<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Eserb/6815345/webrev.04">http://cr.openjdk.java.net/~serb/6815345/webrev.04</a>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>