From Andrei.Dmitriev at Sun.COM  Mon Dec  8 06:47:26 2008
From: Andrei.Dmitriev at Sun.COM (Andrei V. Dmitriev)
Date: Mon, 08 Dec 2008 17:47:26 +0300
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <1221833318.21961.0.camel@moonlight>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight>
	<48D2327E.8020306@sun.com> <1221735554.6609.16.camel@moonlight>
	<48D397C3.8060604@sun.com> <1221832564.983.7.camel@moonlight>
	<48D3B0F2.6030605@sun.com> <1221833318.21961.0.camel@moonlight>
Message-ID: <493D337E.9080401@sun.com>

Hi Roman,

did you already send updated patch for peer's documentation?
I'd love to review it again. :)

Thanks,
   Andrei



From roman.kennke at aicas.com  Mon Dec  8 07:10:34 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Mon, 08 Dec 2008 16:10:34 +0100
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <493D337E.9080401@sun.com>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight>
	<48D2327E.8020306@sun.com> <1221735554.6609.16.camel@moonlight>
	<48D397C3.8060604@sun.com> <1221832564.983.7.camel@moonlight>
	<48D3B0F2.6030605@sun.com> <1221833318.21961.0.camel@moonlight>
	<493D337E.9080401@sun.com>
Message-ID: <1228749034.9562.22.camel@moonlight>

Hi Andrei,

> did you already send updated patch for peer's documentation?
> I'd love to review it again. :)

No I didn't. Actually I was caught up in some other project, then did
some stuff in OpenJDK, found that the hotspot build is broken on my
(Ubuntu) machine (this is notorious: everytime I update my repos, the
hotspot build becomes broken...), gave up and went back to other
projects. I will send something for you to review soon :-)

/Roman

-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt



From roman.kennke at aicas.com  Tue Dec  9 03:39:24 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Tue, 09 Dec 2008 12:39:24 +0100
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <491AE866.10605@sun.com>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight>
	<48D2327E.8020306@sun.com> <1221735554.6609.16.camel@moonlight>
	<48D397C3.8060604@sun.com> <1221832564.983.7.camel@moonlight>
	<48D3B0F2.6030605@sun.com> <1221833318.21961.0.camel@moonlight>
	<491AE866.10605@sun.com>
Message-ID: <1228822765.6920.37.camel@moonlight>

Hi Andrei,

Finally I came around to fix the suggested stuff. See comments inline.

> 1) src/share/classes/java/awt/peer/CheckboxMenuItemPeer.java
> 
> +import java.awt.CheckboxMenuItem;
> if that's really needed? I thought that {@link ...} doesn't require such 
> stuff.

I don't know. If you fully qualify the stuff in the {@link } it's not
needed. Should I fully-qualify things everywhere or let the import in
place? I don't care really.


> 2) src/share/classes/java/awt/peer/ContainerPeer.java
> There is a typo in the second word:
> -     * Indicates availabiltity of restacking operation in this container.
> +     * Indicates availability of restacking operation in this container.

Fixed.

> 3) Common thing.
> <code>true</code> have a shorter synonym since JDK 5: {@code true}

Fixed.

> 4) src/share/classes/java/awt/peer/RobotPeer.java
> I noticed that you prefer not to leave "public" modifier in an 
> interface. But here you are leaving all of them.

Fixed.

> 5) src/share/classes/java/awt/peer/RobotPeer.java
> public int getNumberOfButtons(); has left w/o any comments.

Fixed. I'm not sure if I got the sematics right.

> 6) src/share/classes/java/awt/peer/ComponentPeer.java
> +    /**
> +     * Called by {@link EventQueue#coalescePaintEvent} to let the component
> +     * peer coalesce paint events.
> +     *
> +     * @param e the paint event to consider to coalesce
> +     *
> +     * @see EventQueue#coalescePaintEvent
> +     */
> +    void coalescePaintEvent(PaintEvent e);
> 
> I'd say it's not "to let .... coalesce paint events", but "to coalesce 
> paint events".

Fixed.

> 7) at the same class.
> You wrote:
> +    // TODO: Maybe change this to force Graphics2D, since many things will
> +    // break with plain Graphics nowadays.
> +    Graphics getGraphics();
> 
> Do you know a scenario to show what's exactly might be broken. We 
> probably need to introduce another peer for that, right?

I already explained my reason in earlier mails. You think this is
reasonable?


> 8) Similar to 7):
> +    // TODO: Maybe make that return a BufferedImage, because some stuff 
> will
> +    // break if a different kind of image is returned.
> +    Image createImage(int width, int height);

Dito.

This time I did the work on top of the -awt workspace and created a
webrev for your reviewing pleasure:

http://kennke.org/~roman/docpeers/webrev/

Thanks for having a look at it again,

Roman

-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt



From Andrei.Dmitriev at Sun.COM  Mon Dec 15 06:31:13 2008
From: Andrei.Dmitriev at Sun.COM (Andrei V. Dmitriev)
Date: Mon, 15 Dec 2008 17:31:13 +0300
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <1228822765.6920.37.camel@moonlight>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight>
	<48D2327E.8020306@sun.com> <1221735554.6609.16.camel@moonlight>
	<48D397C3.8060604@sun.com> <1221832564.983.7.camel@moonlight>
	<48D3B0F2.6030605@sun.com> <1221833318.21961.0.camel@moonlight>
	<491AE866.10605@sun.com> <1228822765.6920.37.camel@moonlight>
Message-ID: <49466A31.1070901@sun.com>

Hi Roman,

Cool! I'm comfortable with this fix now.

We still need second approve vote to push this change in.
Artem...? Others? ;)

Thanks,
   Andrei

Roman Kennke wrote:
> Hi Andrei,
> 
> Finally I came around to fix the suggested stuff. See comments inline.
> 
>> 1) src/share/classes/java/awt/peer/CheckboxMenuItemPeer.java
>>
>> +import java.awt.CheckboxMenuItem;
>> if that's really needed? I thought that {@link ...} doesn't require such 
>> stuff.
> 
> I don't know. If you fully qualify the stuff in the {@link } it's not
> needed. Should I fully-qualify things everywhere or let the import in
> place? I don't care really.
> 
> 
>> 2) src/share/classes/java/awt/peer/ContainerPeer.java
>> There is a typo in the second word:
>> -     * Indicates availabiltity of restacking operation in this container.
>> +     * Indicates availability of restacking operation in this container.
> 
> Fixed.
> 
>> 3) Common thing.
>> <code>true</code> have a shorter synonym since JDK 5: {@code true}
> 
> Fixed.
> 
>> 4) src/share/classes/java/awt/peer/RobotPeer.java
>> I noticed that you prefer not to leave "public" modifier in an 
>> interface. But here you are leaving all of them.
> 
> Fixed.
> 
>> 5) src/share/classes/java/awt/peer/RobotPeer.java
>> public int getNumberOfButtons(); has left w/o any comments.
> 
> Fixed. I'm not sure if I got the sematics right.
> 
>> 6) src/share/classes/java/awt/peer/ComponentPeer.java
>> +    /**
>> +     * Called by {@link EventQueue#coalescePaintEvent} to let the component
>> +     * peer coalesce paint events.
>> +     *
>> +     * @param e the paint event to consider to coalesce
>> +     *
>> +     * @see EventQueue#coalescePaintEvent
>> +     */
>> +    void coalescePaintEvent(PaintEvent e);
>>
>> I'd say it's not "to let .... coalesce paint events", but "to coalesce 
>> paint events".
> 
> Fixed.
> 
>> 7) at the same class.
>> You wrote:
>> +    // TODO: Maybe change this to force Graphics2D, since many things will
>> +    // break with plain Graphics nowadays.
>> +    Graphics getGraphics();
>>
>> Do you know a scenario to show what's exactly might be broken. We 
>> probably need to introduce another peer for that, right?
> 
> I already explained my reason in earlier mails. You think this is
> reasonable?
> 
> 
>> 8) Similar to 7):
>> +    // TODO: Maybe make that return a BufferedImage, because some stuff 
>> will
>> +    // break if a different kind of image is returned.
>> +    Image createImage(int width, int height);
> 
> Dito.
> 
> This time I did the work on top of the -awt workspace and created a
> webrev for your reviewing pleasure:
> 
> http://kennke.org/~roman/docpeers/webrev/
> 
> Thanks for having a look at it again,
> 
> Roman
> 


From artem.ananiev at sun.com  Fri Dec 19 05:06:30 2008
From: artem.ananiev at sun.com (artem.ananiev at sun.com)
Date: Fri, 19 Dec 2008 13:06:30 +0000
Subject: <AWT Dev> hg: jdk7/awt/jdk: 6773985: OutOfMemory (PermGen space)
	under Linux /	Firefox when switching bw. applets
Message-ID: <20081219130642.495F7DBBD@hg.openjdk.java.net>

Changeset: d5bf2dd61ed5
Author:    art
Date:      2008-12-19 16:04 +0300
URL:       http://hg.openjdk.java.net/jdk7/awt/jdk/rev/d5bf2dd61ed5

6773985: OutOfMemory (PermGen space) under Linux / Firefox when switching bw. applets
Summary: XEmbedClientHelper is uninstalled when its embedded frame is disposed.
Reviewed-by: dcherepanov, ant

! src/solaris/classes/sun/awt/X11/XEmbedClientHelper.java
! src/solaris/classes/sun/awt/X11/XEmbeddedFramePeer.java



From Artem.Ananiev at Sun.COM  Tue Dec 23 00:56:11 2008
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Tue, 23 Dec 2008 11:56:11 +0300
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <49466A31.1070901@sun.com>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight>
	<48D2327E.8020306@sun.com> <1221735554.6609.16.camel@moonlight>
	<48D397C3.8060604@sun.com> <1221832564.983.7.camel@moonlight>
	<48D3B0F2.6030605@sun.com> <1221833318.21961.0.camel@moonlight>
	<491AE866.10605@sun.com> <1228822765.6920.37.camel@moonlight>
	<49466A31.1070901@sun.com>
Message-ID: <4950A7AB.4080105@sun.com>


Andrei V. Dmitriev wrote:
> Hi Roman,
> 
> Cool! I'm comfortable with this fix now.
> 
> We still need second approve vote to push this change in.
> Artem...? Others? ;)

Well, I'm fine with the proposed changes in general. Still, some JavaDoc 
comments looks to be too implementation-specific. For example, most of 
Container's methods contain a statement like this:

This is called from {@link ...}, before/after ...

and they really called from the specified places, however this may not 
be true in future. I'd remove all these statements from JavaDoc, leaving 
only behavioral description.

Thanks,

Artem

> Thanks,
>   Andrei
> 
> Roman Kennke wrote:
>> Hi Andrei,
>>
>> Finally I came around to fix the suggested stuff. See comments inline.
>>
>>> 1) src/share/classes/java/awt/peer/CheckboxMenuItemPeer.java
>>>
>>> +import java.awt.CheckboxMenuItem;
>>> if that's really needed? I thought that {@link ...} doesn't require 
>>> such stuff.
>>
>> I don't know. If you fully qualify the stuff in the {@link } it's not
>> needed. Should I fully-qualify things everywhere or let the import in
>> place? I don't care really.
>>
>>
>>> 2) src/share/classes/java/awt/peer/ContainerPeer.java
>>> There is a typo in the second word:
>>> -     * Indicates availabiltity of restacking operation in this 
>>> container.
>>> +     * Indicates availability of restacking operation in this 
>>> container.
>>
>> Fixed.
>>
>>> 3) Common thing.
>>> <code>true</code> have a shorter synonym since JDK 5: {@code true}
>>
>> Fixed.
>>
>>> 4) src/share/classes/java/awt/peer/RobotPeer.java
>>> I noticed that you prefer not to leave "public" modifier in an 
>>> interface. But here you are leaving all of them.
>>
>> Fixed.
>>
>>> 5) src/share/classes/java/awt/peer/RobotPeer.java
>>> public int getNumberOfButtons(); has left w/o any comments.
>>
>> Fixed. I'm not sure if I got the sematics right.
>>
>>> 6) src/share/classes/java/awt/peer/ComponentPeer.java
>>> +    /**
>>> +     * Called by {@link EventQueue#coalescePaintEvent} to let the 
>>> component
>>> +     * peer coalesce paint events.
>>> +     *
>>> +     * @param e the paint event to consider to coalesce
>>> +     *
>>> +     * @see EventQueue#coalescePaintEvent
>>> +     */
>>> +    void coalescePaintEvent(PaintEvent e);
>>>
>>> I'd say it's not "to let .... coalesce paint events", but "to 
>>> coalesce paint events".
>>
>> Fixed.
>>
>>> 7) at the same class.
>>> You wrote:
>>> +    // TODO: Maybe change this to force Graphics2D, since many 
>>> things will
>>> +    // break with plain Graphics nowadays.
>>> +    Graphics getGraphics();
>>>
>>> Do you know a scenario to show what's exactly might be broken. We 
>>> probably need to introduce another peer for that, right?
>>
>> I already explained my reason in earlier mails. You think this is
>> reasonable?
>>
>>
>>> 8) Similar to 7):
>>> +    // TODO: Maybe make that return a BufferedImage, because some 
>>> stuff will
>>> +    // break if a different kind of image is returned.
>>> +    Image createImage(int width, int height);
>>
>> Dito.
>>
>> This time I did the work on top of the -awt workspace and created a
>> webrev for your reviewing pleasure:
>>
>> http://kennke.org/~roman/docpeers/webrev/
>>
>> Thanks for having a look at it again,
>>
>> Roman
>>


From roman.kennke at aicas.com  Mon Dec 29 02:27:46 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Mon, 29 Dec 2008 11:27:46 +0100
Subject: <AWT Dev> [PATCH] Cleanup AWT peer interfaces
In-Reply-To: <4950A7AB.4080105@sun.com>
References: <1221555747.6579.11.camel@moonlight>
	<1221559913.6579.36.camel@moonlight>
	<1221563176.20626.5.camel@moonlight>
	<48D2327E.8020306@sun.com> <1221735554.6609.16.camel@moonlight>
	<48D397C3.8060604@sun.com> <1221832564.983.7.camel@moonlight>
	<48D3B0F2.6030605@sun.com> <1221833318.21961.0.camel@moonlight>
	<491AE866.10605@sun.com> <1228822765.6920.37.camel@moonlight>
	<49466A31.1070901@sun.com>  <4950A7AB.4080105@sun.com>
Message-ID: <1230546467.6637.1.camel@moonlight>

Hi Artem,

> > Cool! I'm comfortable with this fix now.
> > 
> > We still need second approve vote to push this change in.
> > Artem...? Others? ;)
> 
> Well, I'm fine with the proposed changes in general. Still, some JavaDoc 
> comments looks to be too implementation-specific. For example, most of 
> Container's methods contain a statement like this:
> 
> This is called from {@link ...}, before/after ...
> 
> and they really called from the specified places, however this may not 
> be true in future. I'd remove all these statements from JavaDoc, leaving 
> only behavioral description.

Yeah, you are right. I put these in because I found it very useful while
implementing the peers to see exactly where and when it is called. I
removed those comments and only let the @see references in there. The
updated webrev is here:

http://kennke.org/~roman/docpeers/webrev/

Ok now?

Cheers, Roman

> 
> Thanks,
> 
> Artem
> 
> > Thanks,
> >   Andrei
> > 
> > Roman Kennke wrote:
> >> Hi Andrei,
> >>
> >> Finally I came around to fix the suggested stuff. See comments inline.
> >>
> >>> 1) src/share/classes/java/awt/peer/CheckboxMenuItemPeer.java
> >>>
> >>> +import java.awt.CheckboxMenuItem;
> >>> if that's really needed? I thought that {@link ...} doesn't require 
> >>> such stuff.
> >>
> >> I don't know. If you fully qualify the stuff in the {@link } it's not
> >> needed. Should I fully-qualify things everywhere or let the import in
> >> place? I don't care really.
> >>
> >>
> >>> 2) src/share/classes/java/awt/peer/ContainerPeer.java
> >>> There is a typo in the second word:
> >>> -     * Indicates availabiltity of restacking operation in this 
> >>> container.
> >>> +     * Indicates availability of restacking operation in this 
> >>> container.
> >>
> >> Fixed.
> >>
> >>> 3) Common thing.
> >>> <code>true</code> have a shorter synonym since JDK 5: {@code true}
> >>
> >> Fixed.
> >>
> >>> 4) src/share/classes/java/awt/peer/RobotPeer.java
> >>> I noticed that you prefer not to leave "public" modifier in an 
> >>> interface. But here you are leaving all of them.
> >>
> >> Fixed.
> >>
> >>> 5) src/share/classes/java/awt/peer/RobotPeer.java
> >>> public int getNumberOfButtons(); has left w/o any comments.
> >>
> >> Fixed. I'm not sure if I got the sematics right.
> >>
> >>> 6) src/share/classes/java/awt/peer/ComponentPeer.java
> >>> +    /**
> >>> +     * Called by {@link EventQueue#coalescePaintEvent} to let the 
> >>> component
> >>> +     * peer coalesce paint events.
> >>> +     *
> >>> +     * @param e the paint event to consider to coalesce
> >>> +     *
> >>> +     * @see EventQueue#coalescePaintEvent
> >>> +     */
> >>> +    void coalescePaintEvent(PaintEvent e);
> >>>
> >>> I'd say it's not "to let .... coalesce paint events", but "to 
> >>> coalesce paint events".
> >>
> >> Fixed.
> >>
> >>> 7) at the same class.
> >>> You wrote:
> >>> +    // TODO: Maybe change this to force Graphics2D, since many 
> >>> things will
> >>> +    // break with plain Graphics nowadays.
> >>> +    Graphics getGraphics();
> >>>
> >>> Do you know a scenario to show what's exactly might be broken. We 
> >>> probably need to introduce another peer for that, right?
> >>
> >> I already explained my reason in earlier mails. You think this is
> >> reasonable?
> >>
> >>
> >>> 8) Similar to 7):
> >>> +    // TODO: Maybe make that return a BufferedImage, because some 
> >>> stuff will
> >>> +    // break if a different kind of image is returned.
> >>> +    Image createImage(int width, int height);
> >>
> >> Dito.
> >>
> >> This time I did the work on top of the -awt workspace and created a
> >> webrev for your reviewing pleasure:
> >>
> >> http://kennke.org/~roman/docpeers/webrev/
> >>
> >> Thanks for having a look at it again,
> >>
> >> Roman
> >>
-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt