Nabble - OpenJDK Java 2D API

hg: jdk7/2d/jdk: 6904962: GlyphVector.getVisualBounds should not be affected by leading or trailing white space.

2009-11-30T14:46:34Z

Changeset: 479c14bec7f1
Author: prr
Date: 2009-11-30 14:39 -0800
URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/479c14bec7f1

6904962: GlyphVector.getVisualBounds should not be affected by leading or trailing white space.
Reviewed-by: igor, dougfelt

! src/share/classes/sun/font/StandardGlyphVector.java
+ test/java/awt/font/GlyphVector/VisualBounds.java

Re: [PATCH] Request for review: 6888734, regression test fails when java.security.manager is enabled

2009-11-30T13:37:12Z

Roman Kennke wrote:
> I added the (previously closed) testcase, keeping it in the same
> relative directory location:
>
> http://cr.openjdk.java.net/~rkennke/6888734/webrev.01/
>
> Is this ok?
>

Almost. Reg tests don't have the classpath exception.

And probably the copyright year should be a range, starting
with whatever the existing year is.

-phil.

>
> /Roman
>
>
> Am Montag, den 30.11.2009, 11:19 -0800 schrieb Phil Race:
>
>> The fix looks fine to me. One thing. The test is
>> in closed just because no one got round to moving it to open.
>> At least I don't see any reason it can't be opened up.
>> Now would be a good time and it can be included with this
>> changeset.
>> Don't forget to tag it with this additional bug ID.
>>
>> -phil.
>>
>> Roman Kennke wrote:
>>
>>> Hi again,
>>>
>>> is this ok for committing?
>>>
>>> Thanks, Roman
>>>
>>> Am Donnerstag, den 15.10.2009, 15:22 +0200 schrieb Roman Kennke:
>>>
>>>> Hi there,
>>>>
>>>> Here's a fix for Bug#6888734. One regression test was failing with an
>>>> AccessControlException in new FontManager code. We need to move
>>>> Class.forName() and newInstance() call into the privileged block. Webrev
>>>> here:
>>>>
>>>> http://cr.openjdk.java.net/~rkennke/6888734/webrev.00/
>>>>
>>>> Good? Comments?
>>>>
>>>> /Roman
>>>>
>>>>
>>>>
>>>
>
>
>

Re: [PATCH] Request for review: 6888734, regression test fails when java.security.manager is enabled

2009-11-30T12:32:52Z

I added the (previously closed) testcase, keeping it in the same
relative directory location:

http://cr.openjdk.java.net/~rkennke/6888734/webrev.01/

Is this ok?

/Roman

Am Montag, den 30.11.2009, 11:19 -0800 schrieb Phil Race:

> The fix looks fine to me. One thing. The test is
> in closed just because no one got round to moving it to open.
> At least I don't see any reason it can't be opened up.
> Now would be a good time and it can be included with this
> changeset.
> Don't forget to tag it with this additional bug ID.
>
> -phil.
>
> Roman Kennke wrote:
> > Hi again,
> >
> > is this ok for committing?
> >
> > Thanks, Roman
> >
> > Am Donnerstag, den 15.10.2009, 15:22 +0200 schrieb Roman Kennke:
> >> Hi there,
> >>
> >> Here's a fix for Bug#6888734. One regression test was failing with an
> >> AccessControlException in new FontManager code. We need to move
> >> Class.forName() and newInstance() call into the privileged block. Webrev
> >> here:
> >>
> >> http://cr.openjdk.java.net/~rkennke/6888734/webrev.00/
> >>
> >> Good? Comments?
> >>
> >> /Roman
> >>
> >>
> >
> >

Re: [PATCH] Request for review: 6896335: GraphicsEnvironment.getDefaultScreenDevice() throws UnsatisfiedLinkError in headless mode

2009-11-30T11:58:50Z

I will add/open-existing regression test for that, just like I'll do for
the other fixes I sent today.

/Roman

Am Montag, den 30.11.2009, 20:52 +0100 schrieb Roman Kennke:

> This is a relatively simple fix for 6896335. When I did the change to
> GraphicsEnvironment initialization, I missed this small line that's only
> executed in headless mode, leading to weird exceptions...
>
> http://cr.openjdk.java.net/~rkennke/6896335/webrev.00/
>
> Ok to commit?
>
> /Roman
>
>

Re: [PATCH] Request for review: 6896335: GraphicsEnvironment.getDefaultScreenDevice() throws UnsatisfiedLinkError in headless mode

2009-11-30T11:56:31Z

sorry to sound like a broken record, fix looks fine,
regression test needed. In this case I don't think we
have one .. I suppose in this and the last case too it
could be that adding noreg-jck might be sufficient but
a regression test would be better for various reasons.

-phil.

Roman Kennke wrote:

[PATCH] Request for review: 6896335: GraphicsEnvironment.getDefaultScreenDevice() throws UnsatisfiedLinkError in headless mode

2009-11-30T11:52:11Z

This is a relatively simple fix for 6896335. When I did the change to
GraphicsEnvironment initialization, I missed this small line that's only
executed in headless mode, leading to weird exceptions...

http://cr.openjdk.java.net/~rkennke/6896335/webrev.00/

Ok to commit?

/Roman

Re: [PATCH] Request for review: 6904882: java.awt.Font.createFont() causes AccessControlException if executed with "-Djava.security.manager"

2009-11-30T11:49:27Z

Like the last one, this could use a regression test - even though
there's a JCK failure. FWIW a trivial one like this :-

import java.awt.*;
import java.io.File;

public class CreateFontSMTest {
public static void main(String[] args) throws Exception {
System.setSecurityManager(new SecurityManager());
Font font = new Font("Dialog", Font.PLAIN, 12);
System.out.println(font.getFontName());
}
}

will work, but I also found we already have a test .. which I
guess never got run :-(, called FontPrivilege.java that does
something very similar. Its also in closed and I leave it
up to you whether to open that or add a new one but opening
it would be best.

-phil.

Roman Kennke wrote:

> This patches fixes bug #6904882. As suggested by Phil it puts the whole
> static initializer in a privileged block, grouping the existing 4
> smaller blocks into one, and importantly including the offending
> File.exists() call. This requires to make the static fields non-final.
>
> http://cr.openjdk.java.net/~rkennke/6904882/webrev.00/
>
> Ok to commit?
>
> /Roman
>
>

Re: [PATCH] Request for review: 6888734, regression test fails when java.security.manager is enabled

2009-11-30T11:45:17Z

> Could we agree on a slightly more formal reply like 'Go commit', 'Ok,
> but wait for one more review', or do we always stick to the 2 reviews
> rule?

I was assuming a second reviewer would pipe up, then you'd go commit.

In general I'd say that
- we do prefer two reviewers but there are cases where one is
more than enough (test fixes, trivial changes to avoid an NPE,
doc changes). This one is borderline.

- unless there's some pressing need (integration deadline?)
even for a trivial fix I'd wait until it seemed likely
no one else was going to pipe up.

Saying something in your reviewer request might help, like
"Could Phil & Igor please take a look at this" :-).

-phil.

Roman Kennke wrote:

> Hi Phil,
>
>> The fix looks fine to me.
>
> Good. :-)
>
>> One thing. The test is
>> in closed just because no one got round to moving it to open.
>> At least I don't see any reason it can't be opened up.
>> Now would be a good time and it can be included with this
>> changeset.
>
> I'll do that.
>
>> Don't forget to tag it with this additional bug ID.
>
> Ok.
>
> Is this one review enough for committing?
>
> Could we agree on a slightly more formal reply like 'Go commit', 'Ok,
> but wait for one more review', or do we always stick to the 2 reviews
> rule?
>
> Thanks, Roman
>
>

Re: [PATCH] Request for review: 6888734, regression test fails when java.security.manager is enabled

2009-11-30T11:35:12Z

Hi Phil,

> The fix looks fine to me.

Good. :-)

> One thing. The test is
> in closed just because no one got round to moving it to open.
> At least I don't see any reason it can't be opened up.
> Now would be a good time and it can be included with this
> changeset.

I'll do that.

> Don't forget to tag it with this additional bug ID.

Ok.

Is this one review enough for committing?

Could we agree on a slightly more formal reply like 'Go commit', 'Ok,
but wait for one more review', or do we always stick to the 2 reviews
rule?

Thanks, Roman

Re: [PATCH] Request for review: 6888734, regression test fails when java.security.manager is enabled

2009-11-30T11:19:23Z

The fix looks fine to me. One thing. The test is
in closed just because no one got round to moving it to open.
At least I don't see any reason it can't be opened up.
Now would be a good time and it can be included with this
changeset.
Don't forget to tag it with this additional bug ID.

-phil.

Roman Kennke wrote:

> Hi again,
>
> is this ok for committing?
>
> Thanks, Roman
>
> Am Donnerstag, den 15.10.2009, 15:22 +0200 schrieb Roman Kennke:
>> Hi there,
>>
>> Here's a fix for Bug#6888734. One regression test was failing with an
>> AccessControlException in new FontManager code. We need to move
>> Class.forName() and newInstance() call into the privileged block. Webrev
>> here:
>>
>> http://cr.openjdk.java.net/~rkennke/6888734/webrev.00/
>>
>> Good? Comments?
>>
>> /Roman
>>
>>
>
>

[PATCH] Request for review: 6904882: java.awt.Font.createFont() causes AccessControlException if executed with "-Djava.security.manager"

2009-11-30T11:18:23Z

This patches fixes bug #6904882. As suggested by Phil it puts the whole
static initializer in a privileged block, grouping the existing 4
smaller blocks into one, and importantly including the offending
File.exists() call. This requires to make the static fields non-final.

http://cr.openjdk.java.net/~rkennke/6904882/webrev.00/

Ok to commit?

/Roman

Re: [PATCH] Request for review: 6888734, regression test fails when java.security.manager is enabled

2009-11-30T06:28:18Z

Hi again,

is this ok for committing?

Thanks, Roman

Am Donnerstag, den 15.10.2009, 15:22 +0200 schrieb Roman Kennke:

> Hi there,
>
> Here's a fix for Bug#6888734. One regression test was failing with an
> AccessControlException in new FontManager code. We need to move
> Class.forName() and newInstance() call into the privileged block. Webrev
> here:
>
> http://cr.openjdk.java.net/~rkennke/6888734/webrev.00/
>
> Good? Comments?
>
> /Roman
>
>

hg: jdk7/2d/jdk: 6899078: potential deadlock and performance issue in freeing strike resources with D3D pipeline

2009-11-09T14:30:44Z

Changeset: ba01efbf7c70
Author: prr
Date: 2009-11-09 14:23 -0800
URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/ba01efbf7c70

6899078: potential deadlock and performance issue in freeing strike resources with D3D pipeline
Reviewed-by: tdv, igor

! src/share/classes/sun/font/Font2D.java
! src/share/classes/sun/font/FontDesignMetrics.java
! src/share/classes/sun/font/FontStrikeDisposer.java
! src/share/classes/sun/font/StrikeCache.java
! src/share/classes/sun/java2d/Disposer.java

Re: Integration of the xrender pipeline rewite

2009-11-05T15:30:46Z

> PS: Is there an easy way to apply a webrev to a local repository?

The webrev/ dir contains a patch, you could do
patch -p1 -i webrev/stuff.patch

Thanks,
Dmitri

Clemens Eisserer wrote:

> Hello,
>
> I've merged the xrender pipeline with master, please take a look at the webrev:
> http://93.83.133.214/webrev-xrender-jules-0.0.1.zip
>
> It would be great to get the review-process rolling for the critical
> parts like StrikeCache.java or sunFont.c
>
> It also includes a preview of "Jules", a cairo based RenderingEngine
> implementation:
> Because of its complex build-system and the need for a modified
> version of cairo I've seperate the native components and build them
> indepent from OpenJDK - falling back to pisces when loading fails.
>
> The native part can be found at:
> http://93.83.133.214/jules-0.0.1.tar.gz
>
> Simply copy the resulting libjules.so into lib/i386, and activate it
> on the command-line:
> -Dsun.java2d.renderer=sun.java2d.jules.JulesRenderingEngine
>
> Jules is more or less proof-of-concept, especially the native code is
> ugly, full of dirty assumptions and its probably not 64-bit clean.
> (Although it should get a major performance boost, in the case it
> works ;) ).
> However it runs Java2Demo quite well, and usually is a good deal
> faster than pisces even when rendering to software-surfaces.
>
> Known problems:
> - Some clipping problems when rendering to software surfaces
> - Paints get wrong transformation when rendering to XRender surfaces
>
> Thanks, Clemens
>

Re: Integration of the xrender pipeline rewite

2009-11-05T11:08:17Z

Hello,

I've merged the xrender pipeline with master, please take a look at the webrev:
http://93.83.133.214/webrev-xrender-jules-0.0.1.zip

It would be great to get the review-process rolling for the critical
parts like StrikeCache.java or sunFont.c

It also includes a preview of "Jules", a cairo based RenderingEngine
implementation:
Because of its complex build-system and the need for a modified
version of cairo I've seperate the native components and build them
indepent from OpenJDK - falling back to pisces when loading fails.

The native part can be found at:
http://93.83.133.214/jules-0.0.1.tar.gz

Simply copy the resulting libjules.so into lib/i386, and activate it
on the command-line:
-Dsun.java2d.renderer=sun.java2d.jules.JulesRenderingEngine

Jules is more or less proof-of-concept, especially the native code is
ugly, full of dirty assumptions and its probably not 64-bit clean.
(Although it should get a major performance boost, in the case it
works ;) ).
However it runs Java2Demo quite well, and usually is a good deal
faster than pisces even when rendering to software-surfaces.

Known problems:
- Some clipping problems when rendering to software surfaces
- Paints get wrong transformation when rendering to XRender surfaces

Thanks, Clemens

PS: Is there an easy way to apply a webrev to a local repository?

Re: [PATCH FOR APPROVAL]: Fix broken build on newer versions of X11 (libXext >= 1.1.0)

2009-11-05T02:20:07Z

On 11/4/2009 12:18 AM Phil Race wrote:
> The superfluous stuff is the copy of the webrev?
> We archive them. Not all groups do that. Swing, AWT and 2D do.
> Occasionally someone may fail to get one from a contribution

My understanding is that a repository contains all the changesets. And
each changeset is just a patch, which is available directly (hg diff),
or via http://hg.ojn/ (which itself is perfectly searchable with
Google). Why would one need another copy of the changes nowdays?

Whilst exploring the history of webrev versions for a particular fix
does indeed help sometimes, this looks quite inapplicable for external
contributions since the internal robot is not available to them. And
submitting all the versions manually through a Sun employee seems sort
of burdensome.

> but its still the theoretical process to have it.

--
best regards,
Anthony

Re: [PATCH FOR APPROVAL]: Fix broken build on newer versions of X11 (libXext >= 1.1.0)

2009-11-04T09:23:29Z

Hi Andrew,

I will add it. Thanks.

Jennifer

Andrew John Hughes wrote:

> 2009/11/3 Andrew John Hughes <gnu_andrew@...>:
>> 2009/11/3 Jennifer Godinez <Jennifer.Godinez@...>:
>>> The sun bug ID is 6897844.
>>>
>>> Jennifer
>>>
>>> Phil Race wrote:
>>>> PS
>>>>
>>>>>> Is the patch ok?
>>>> yes.
>>>>
>>>> -phil.
>> Pushed: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/90bdc961b3cb
>>
>> Thanks everyone,
>> --
>> Andrew :-)
>>
>> Free Java Software Engineer
>> Red Hat, Inc. (http://www.redhat.com)
>>
>> Support Free Java!
>> Contribute to GNU Classpath and the OpenJDK
>> http://www.gnu.org/software/classpath
>> http://openjdk.java.net
>>
>> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
>> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
>>
>
> I apologise; I forgot to add the Contributed-by credit for Diego
> Pettenò <flameeyes@...>
>
> Can someone add this to the Sun bug report? I'll make sure it goes on
> the version of the fix for OpenJDK6.

Re: [PATCH FOR APPROVAL]: Fix broken build on newer versions of X11 (libXext >= 1.1.0)

2009-11-04T08:14:32Z

2009/11/3 Andrew John Hughes <gnu_andrew@...>:

> 2009/11/3 Jennifer Godinez <Jennifer.Godinez@...>:
>> The sun bug ID is 6897844.
>>
>> Jennifer
>>
>> Phil Race wrote:
>>>
>>> PS
>>>
>>>>>
>>>>> Is the patch ok?
>>>
>>> yes.
>>>
>>> -phil.
>>
>
> Pushed: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/90bdc961b3cb
>
> Thanks everyone,
> --
> Andrew :-)
>
> Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
>
> Support Free Java!
> Contribute to GNU Classpath and the OpenJDK
> http://www.gnu.org/software/classpath
> http://openjdk.java.net
>
> PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
> Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
>

I apologise; I forgot to add the Contributed-by credit for Diego
Pettenò <flameeyes@...>

Can someone add this to the Sun bug report? I'll make sure it goes on
the version of the fix for OpenJDK6.
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

Re: [PATCH FOR APPROVAL]: Fix broken build on newer versions of X11 (libXext >= 1.1.0)

2009-11-03T15:25:26Z

2009/11/3 Jennifer Godinez <Jennifer.Godinez@...>:

> The sun bug ID is 6897844.
>
> Jennifer
>
> Phil Race wrote:
>>
>> PS
>>
>>>>
>>>> Is the patch ok?
>>
>> yes.
>>
>> -phil.
>

Pushed: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/90bdc961b3cb

Thanks everyone,
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

hg: jdk7/2d/jdk: 6897844: Fix broken build on newer versions of X11 (libXext >= 1.1.0)

2009-11-03T15:24:01Z

Changeset: 90bdc961b3cb
Author: andrew
Date: 2009-11-03 23:23 +0000
URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/90bdc961b3cb

6897844: Fix broken build on newer versions of X11 (libXext >= 1.1.0)
Summary: Recent changes to X11's header structure break the build
Reviewed-by: prr, flar

! src/solaris/native/sun/awt/awt_GraphicsEnv.h

Re: [PATCH FOR APPROVAL]: Fix broken build on newer versions of X11 (libXext >= 1.1.0)

2009-11-03T14:30:08Z

Yes, indeed, that all makes sense for your fix. I wasn't intending to
register an objection with the fix, I was just curious about the changes
they made which, as you say, seem quite convoluted...

...jim

Andrew John Hughes wrote:

> 2009/11/3 Jim Graham <Jim.A.Graham@...>:
>> Andrew John Hughes wrote:
>>> There's http://lists.x.org/archives/xorg-devel/2009-June/001242.html
>>> but I avoided posting this in the original mail because it seems to
>>> have changed again between that commit and the final release,
>>> presumably due to compatibility issues (XShm.h is back and it's now
>>> shmproto.h as seen in the patch). I've built the repo with this patch
>>> here with the old version, and others have built it with the new
>>> version; it does work for both. The same patch is already in Gentoo's
>>> ebuild and IcedTea, and a similar patch has been used for the Fedora
>>> rawhide RPMs for some time. It would be good to get it upstream as
>>> well.
>> At first I was going to ask how the existing #include succeeds when the link
>> says that Xshm.h is going away, but now I see that you said they brought it
>> back. What is it now? Just an empty include to prevent #include failures?
>> (I don't see how that works since the build will break anyway as soon as a
>> missing constant is referenced...?)
>>
>> (It seems odd that they bring it back to [not really] avoid build breakages,
>> but then don't just have it include the new split files to finish the
>> "backwards compatibility" story...?)
>>
>> ...jim
>>
>>
>
> It's quite convoluted, that's why I was just going to avoid posting
> the link, as it makes things even more confusing. I believe the
> reinstated XShm.h does have content that was still needed.
>
> The initial version I linked to did remove XShm.h, so the original fix
> for Fedora 12 removed XShm.h, added the two additional headers and
> defined some other stuff which I believe was in XShm.h originally. It
> was a pretty nasty patch, hence why it wasn't committed to IcedTea or
> OpenJDK. I gather now that XShm.h is back and has the additional
> material in it. I don't have a copy locally to check, but several
> people have said this fix works and Fedora RPMs have been built with
> the original fix. More importantly, I have confirmed myself that it
> doesn't break earlier versions, which are still used on the majority
> of systems. It's now several months on from our initial discovery of
> the problem and more and more people are asking about this in e-mail
> and on IRC, so a general fix is needed and this fits the bill.
>
> Hope that makes some sense!
>
> Thanks,

Re: [PATCH FOR APPROVAL]: Fix broken build on newer versions of X11 (libXext >= 1.1.0)

2009-11-03T14:24:35Z

2009/11/3 Jim Graham <Jim.A.Graham@...>:

> Andrew John Hughes wrote:
>>
>> There's http://lists.x.org/archives/xorg-devel/2009-June/001242.html
>> but I avoided posting this in the original mail because it seems to
>> have changed again between that commit and the final release,
>> presumably due to compatibility issues (XShm.h is back and it's now
>> shmproto.h as seen in the patch). I've built the repo with this patch
>> here with the old version, and others have built it with the new
>> version; it does work for both. The same patch is already in Gentoo's
>> ebuild and IcedTea, and a similar patch has been used for the Fedora
>> rawhide RPMs for some time. It would be good to get it upstream as
>> well.
>
> At first I was going to ask how the existing #include succeeds when the link
> says that Xshm.h is going away, but now I see that you said they brought it
> back. What is it now? Just an empty include to prevent #include failures?
> (I don't see how that works since the build will break anyway as soon as a
> missing constant is referenced...?)
>
> (It seems odd that they bring it back to [not really] avoid build breakages,
> but then don't just have it include the new split files to finish the
> "backwards compatibility" story...?)
>
> ...jim
>
>

It's quite convoluted, that's why I was just going to avoid posting
the link, as it makes things even more confusing. I believe the
reinstated XShm.h does have content that was still needed.

The initial version I linked to did remove XShm.h, so the original fix
for Fedora 12 removed XShm.h, added the two additional headers and
defined some other stuff which I believe was in XShm.h originally. It
was a pretty nasty patch, hence why it wasn't committed to IcedTea or
OpenJDK. I gather now that XShm.h is back and has the additional
material in it. I don't have a copy locally to check, but several
people have said this fix works and Fedora RPMs have been built with
the original fix. More importantly, I have confirmed myself that it
doesn't break earlier versions, which are still used on the majority
of systems. It's now several months on from our initial discovery of
the problem and more and more people are asking about this in e-mail
and on IRC, so a general fix is needed and this fits the bill.

Hope that makes some sense!

Thanks,
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

Re: [PATCH FOR APPROVAL]: Fix broken build on newer versions of X11 (libXext >= 1.1.0)

2009-11-03T14:15:34Z

2009/11/3 Phil Race <Phil.Race@...>:

>
>
> Andrew John Hughes wrote:
>
>> My superfluous comment actually referred to the additional request for
>> an OpenJDK bugzilla entry. I fail to see the point of this, given a
>> Sun bug ID is still needed to commit. Most of the bugs there just
>> seem to be in danger of bitrotting, and I'd prefer to avoid adding one
>> that's just going to be closed fairly swiftly anyway. It would be
>> nice if we could use OpenJDK bugzilla IDs for commits, and thus didn't
>> have to hassle Sun employees for Sun bug IDs. But that still doesn't
>> seem to have been implemented.
>
> Ah .. yes .. well you may be right you don't need that if you
> can push it directly. I keep having to look up that part of the
> process myself. But IIIRC theory its supposed to be used to submit
> patches, not report bugs (sans patch), and you had a patch, which
> is why I suggested it.
>

I guess I'm as confused as you are regarding it, so I've just tended
to go with what I've found to work.

The impression I got from the announcement was that, at the moment,
it's just for posting patches that need a sponsor/mentor to get them
into the repository (i.e. the situations that lead to a 'Contributed
by' tag).
It was supposed to be being developed into something that would
replace the Sun bug ID system altogether for external contributors,
but things seem to have gone no further since the launch
(no doubt in part due to the acquisition and various other things
taking precedence). As such, it's currently a bit pointless for those
with commit access as a Sun bug ID is still needed, regardless.
Commits were supposed to support using OpenJDK IDs, but this has never happened.

The gory details are at: http://openjdk.java.net/groups/web/bugzilla.html

Stages 2 and 3 have not come to fruition, and even the 'one-line
change' to jcheck hasn't happened.

>>
>>>> Is the patch ok? If so, could you please allocate it a bug ID.
>>>
>>> I overlooked that in your email. But I already asked Jennifer to allocate
>>> one.
>>>
>>
>> Thanks. I'll push once it's allocated.
>
> Jennifer says she's doing it now.
>
> -phil.
>

--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

Re: [PATCH FOR APPROVAL]: Fix broken build on newer versions of X11 (libXext >= 1.1.0)

2009-11-03T14:09:41Z

The sun bug ID is 6897844.

Jennifer

Phil Race wrote:
>
> PS
>
>>>
>>> Is the patch ok?
>
> yes.
>
> -phil.

Re: [PATCH FOR APPROVAL]: Fix broken build on newer versions of X11 (libXext >= 1.1.0)

2009-11-03T14:07:59Z

Andrew John Hughes wrote:

> There's http://lists.x.org/archives/xorg-devel/2009-June/001242.html
> but I avoided posting this in the original mail because it seems to
> have changed again between that commit and the final release,
> presumably due to compatibility issues (XShm.h is back and it's now
> shmproto.h as seen in the patch). I've built the repo with this patch
> here with the old version, and others have built it with the new
> version; it does work for both. The same patch is already in Gentoo's
> ebuild and IcedTea, and a similar patch has been used for the Fedora
> rawhide RPMs for some time. It would be good to get it upstream as
> well.

At first I was going to ask how the existing #include succeeds when the
link says that Xshm.h is going away, but now I see that you said they
brought it back. What is it now? Just an empty include to prevent
#include failures? (I don't see how that works since the build will
break anyway as soon as a missing constant is referenced...?)

(It seems odd that they bring it back to [not really] avoid build
breakages, but then don't just have it include the new split files to
finish the "backwards compatibility" story...?)

...jim

Re: [PATCH FOR APPROVAL]: Fix broken build on newer versions of X11 (libXext >= 1.1.0)

2009-11-03T13:53:45Z

Andrew John Hughes wrote:

> My superfluous comment actually referred to the additional request for
> an OpenJDK bugzilla entry. I fail to see the point of this, given a
> Sun bug ID is still needed to commit. Most of the bugs there just
> seem to be in danger of bitrotting, and I'd prefer to avoid adding one
> that's just going to be closed fairly swiftly anyway. It would be
> nice if we could use OpenJDK bugzilla IDs for commits, and thus didn't
> have to hassle Sun employees for Sun bug IDs. But that still doesn't
> seem to have been implemented.

Ah .. yes .. well you may be right you don't need that if you
can push it directly. I keep having to look up that part of the
process myself. But IIIRC theory its supposed to be used to submit
patches, not report bugs (sans patch), and you had a patch, which
is why I suggested it.

>
>>> Is the patch ok? If so, could you please allocate it a bug ID.
>> I overlooked that in your email. But I already asked Jennifer to allocate
>> one.
>>
>
> Thanks. I'll push once it's allocated.

Jennifer says she's doing it now.

-phil.

Re: [PATCH FOR APPROVAL]: Fix broken build on newer versions of X11 (libXext >= 1.1.0)

2009-11-03T13:50:50Z

2009/11/3 Phil Race <Phil.Race@...>:

>
>
> Andrew John Hughes wrote:
>>
>> 2009/11/3 Phil Race <Phil.Race@...>:
>>>
>>> awt_Graphics and XShm is more for 2D than AWT, but
>>> I'm not sure how much it matters for this small change.
>>
>> It's called awt_Graphics hence the AWT list. I doubt the distinction
>> between 2d and awt classes is clear to anyone outside Sun.
>
> But Graphics is I'd hope obviously 2D, and lots of things
> have AWT in the name as hangovers from JDk 1.0, 1.1, where
> there was no 2D.
>

Yeah, it's not clear-cut -- so don't be surprised if we post to the
wrong list :)

>>
>>> Attach the patch to a bugzilla report .. someone will
>>> need to generate a sun bug id too. Can you post a zip
>>> of the webvrev somewhere?
>>
>> I'm aware we need a Sun bug ID; that's why I asked for one to be
>> allocated in the e-mail. I have commit rights so I don't need
>> mentoring; I just need a review and a bug ID so I can push the fix. I
>> don't see why you need all this other superfluous stuff, as it wasn't
>> needed for any of my other pushes to various repos.
>
> The superfluous stuff is the copy of the webrev?
> We archive them. Not all groups do that. Swing, AWT and 2D do.
> Occasionally someone may fail to get one from a contribution
> but its still the theoretical process to have it.
>

That's very sensible. I've been wondering why webrev generates a
webrev.zip and now I know.
I've include the webrev.zip at
http://cr.openjdk.java.net/~andrew/xshm/webrev.01/webrev.zip and will
do so in future. I didn't before, because I didn't realise anyone
made use of this.

My superfluous comment actually referred to the additional request for
an OpenJDK bugzilla entry. I fail to see the point of this, given a
Sun bug ID is still needed to commit. Most of the bugs there just
seem to be in danger of bitrotting, and I'd prefer to avoid adding one
that's just going to be closed fairly swiftly anyway. It would be
nice if we could use OpenJDK bugzilla IDs for commits, and thus didn't
have to hassle Sun employees for Sun bug IDs. But that still doesn't
seem to have been implemented.

>>
>> Is the patch ok? If so, could you please allocate it a bug ID.
>
> I overlooked that in your email. But I already asked Jennifer to allocate
> one.
>

Thanks. I'll push once it's allocated.

>>
>>> And is there an X11 reference you can cite to this apparent
>>> source incompatible change there?
>>>
>>
>> There's http://lists.x.org/archives/xorg-devel/2009-June/001242.html
>> but I avoided posting this in the original mail because it seems to
>> have changed again between that commit and the final release,
>> presumably due to compatibility issues (XShm.h is back and it's now
>> shmproto.h as seen in the patch). I've built the repo with this patch
>> here with the old version, and others have built it with the new
>> version; it does work for both. The same patch is already in Gentoo's
>> ebuild and IcedTea, and a similar patch has been used for the Fedora
>> rawhide RPMs for some time. It would be good to get it upstream as
>> well.
>
> OK .. although I was looking for something where they pointed out
> this was likely to cause build failures but was justified because ...
>

So would I! They do mention it's an API breakage, but only seem to
have considered internal issues. I couldn't see any discussion of
external breakages in the past few months of mail archives. The only
justification seems to be 'we want to clear up some cruft'...

> -phil.
>
>>
>>> -phil.
>>>
>>> Andrew John Hughes wrote:
>>>>
>>>> With the new version of X11 (specifically libXext >= 1.1), the XShm.h
>>>> header has been refactored.
>>>>
>>>> As a result, the build fails on awt_GraphicsEnv.c. This simple patch:
>>>>
>>>> http://cr.openjdk.java.net/~andrew/xshm/webrev.01
>>>>
>>>> fixes the issue, without affecting older versions. It's trivial, but
>>>> very important; this new X11 is already in Gentoo, it'll be in F12
>>>> (where we first discovered this issue), and it's no doubt heading to
>>>> an Ubuntu near you soon.
>>>>
>>>> The patch was contributed by Diego Pettenò <flameeyes@...>, who
>>>> I'm informed has signed the SCA.
>>>>
>>>> Does this look ok? If so, can I have a bug ID to push this to the
>>>> awt-gate (or wherever is appropriate)?
>>>>
>>>> Thanks,
>>
>>
>>
>

Re: [PATCH FOR APPROVAL]: Fix broken build on newer versions of X11 (libXext >= 1.1.0)

2009-11-03T13:21:27Z

PS

>>
>> Is the patch ok?

yes.

-phil.

Re: [PATCH FOR APPROVAL]: Fix broken build on newer versions of X11 (libXext >= 1.1.0)

2009-11-03T13:18:26Z

Andrew John Hughes wrote:
> 2009/11/3 Phil Race <Phil.Race@...>:
>> awt_Graphics and XShm is more for 2D than AWT, but
>> I'm not sure how much it matters for this small change.
>
> It's called awt_Graphics hence the AWT list. I doubt the distinction
> between 2d and awt classes is clear to anyone outside Sun.

But Graphics is I'd hope obviously 2D, and lots of things
have AWT in the name as hangovers from JDk 1.0, 1.1, where
there was no 2D.

>
>> Attach the patch to a bugzilla report .. someone will
>> need to generate a sun bug id too. Can you post a zip
>> of the webvrev somewhere?
>
> I'm aware we need a Sun bug ID; that's why I asked for one to be
> allocated in the e-mail. I have commit rights so I don't need
> mentoring; I just need a review and a bug ID so I can push the fix. I
> don't see why you need all this other superfluous stuff, as it wasn't
> needed for any of my other pushes to various repos.

The superfluous stuff is the copy of the webrev?
We archive them. Not all groups do that. Swing, AWT and 2D do.
Occasionally someone may fail to get one from a contribution
but its still the theoretical process to have it.

>
> Is the patch ok? If so, could you please allocate it a bug ID.

I overlooked that in your email. But I already asked Jennifer to allocate one.

>
>> And is there an X11 reference you can cite to this apparent
>> source incompatible change there?
>>
>
> There's http://lists.x.org/archives/xorg-devel/2009-June/001242.html
> but I avoided posting this in the original mail because it seems to
> have changed again between that commit and the final release,
> presumably due to compatibility issues (XShm.h is back and it's now
> shmproto.h as seen in the patch). I've built the repo with this patch
> here with the old version, and others have built it with the new
> version; it does work for both. The same patch is already in Gentoo's
> ebuild and IcedTea, and a similar patch has been used for the Fedora
> rawhide RPMs for some time. It would be good to get it upstream as
> well.

OK .. although I was looking for something where they pointed out
this was likely to cause build failures but was justified because ...

-phil.

>
>> -phil.
>>
>> Andrew John Hughes wrote:
>>> With the new version of X11 (specifically libXext >= 1.1), the XShm.h
>>> header has been refactored.
>>>
>>> As a result, the build fails on awt_GraphicsEnv.c. This simple patch:
>>>
>>> http://cr.openjdk.java.net/~andrew/xshm/webrev.01
>>>
>>> fixes the issue, without affecting older versions. It's trivial, but
>>> very important; this new X11 is already in Gentoo, it'll be in F12
>>> (where we first discovered this issue), and it's no doubt heading to
>>> an Ubuntu near you soon.
>>>
>>> The patch was contributed by Diego Pettenò <flameeyes@...>, who
>>> I'm informed has signed the SCA.
>>>
>>> Does this look ok? If so, can I have a bug ID to push this to the
>>> awt-gate (or wherever is appropriate)?
>>>
>>> Thanks,
>
>
>

Re: [PATCH FOR APPROVAL]: Fix broken build on newer versions of X11 (libXext >= 1.1.0)

2009-11-03T13:12:21Z

2009/11/3 Phil Race <Phil.Race@...>:
> awt_Graphics and XShm is more for 2D than AWT, but
> I'm not sure how much it matters for this small change.

It's called awt_Graphics hence the AWT list. I doubt the distinction
between 2d and awt classes is clear to anyone outside Sun.

> Attach the patch to a bugzilla report .. someone will
> need to generate a sun bug id too. Can you post a zip
> of the webvrev somewhere?

I'm aware we need a Sun bug ID; that's why I asked for one to be
allocated in the e-mail. I have commit rights so I don't need
mentoring; I just need a review and a bug ID so I can push the fix. I
don't see why you need all this other superfluous stuff, as it wasn't
needed for any of my other pushes to various repos.

Is the patch ok? If so, could you please allocate it a bug ID.

>
> And is there an X11 reference you can cite to this apparent
> source incompatible change there?
>

There's http://lists.x.org/archives/xorg-devel/2009-June/001242.html
but I avoided posting this in the original mail because it seems to
have changed again between that commit and the final release,
presumably due to compatibility issues (XShm.h is back and it's now
shmproto.h as seen in the patch). I've built the repo with this patch
here with the old version, and others have built it with the new
version; it does work for both. The same patch is already in Gentoo's
ebuild and IcedTea, and a similar patch has been used for the Fedora
rawhide RPMs for some time. It would be good to get it upstream as
well.

> -phil.
>
> Andrew John Hughes wrote:
>>
>> With the new version of X11 (specifically libXext >= 1.1), the XShm.h
>> header has been refactored.
>>
>> As a result, the build fails on awt_GraphicsEnv.c. This simple patch:
>>
>> http://cr.openjdk.java.net/~andrew/xshm/webrev.01
>>
>> fixes the issue, without affecting older versions. It's trivial, but
>> very important; this new X11 is already in Gentoo, it'll be in F12
>> (where we first discovered this issue), and it's no doubt heading to
>> an Ubuntu near you soon.
>>
>> The patch was contributed by Diego Pettenò <flameeyes@...>, who
>> I'm informed has signed the SCA.
>>
>> Does this look ok? If so, can I have a bug ID to push this to the
>> awt-gate (or wherever is appropriate)?
>>
>> Thanks,
>

Re: [PATCH FOR APPROVAL]: Fix broken build on newer versions of X11 (libXext >= 1.1.0)

2009-11-03T11:35:36Z

awt_Graphics and XShm is more for 2D than AWT, but
I'm not sure how much it matters for this small change.
Attach the patch to a bugzilla report .. someone will
need to generate a sun bug id too. Can you post a zip
of the webvrev somewhere?

And is there an X11 reference you can cite to this apparent
source incompatible change there?

-phil.

Andrew John Hughes wrote:

> With the new version of X11 (specifically libXext >= 1.1), the XShm.h
> header has been refactored.
>
> As a result, the build fails on awt_GraphicsEnv.c. This simple patch:
>
> http://cr.openjdk.java.net/~andrew/xshm/webrev.01
>
> fixes the issue, without affecting older versions. It's trivial, but
> very important; this new X11 is already in Gentoo, it'll be in F12
> (where we first discovered this issue), and it's no doubt heading to
> an Ubuntu near you soon.
>
> The patch was contributed by Diego Pettenò <flameeyes@...>, who
> I'm informed has signed the SCA.
>
> Does this look ok? If so, can I have a bug ID to push this to the
> awt-gate (or wherever is appropriate)?
>
> Thanks,

Re: Howto install a custom rendering engine?

2009-11-02T11:59:01Z

2009/11/2 Clemens Eisserer <linuxhippy@...>:

> Hi,
>
> I am trying to install my own RenderingEngine implementation, however
> I am not accustomed to the ServiceLoader concept:
>
>> ServiceLoader<RenderingEngine> reLoader =
>> ServiceLoader.loadInstalled(RenderingEngine.class);
>
> the ServiceLoader doesn't e.g. contain my CairoRenderingEngine.
>
> Would it be enough to simply create a META-INF directory with a single
> file in it, similar to what has been done for pisces?
> Is there any way to influence the iteration-order?
> If possible I would prefer my RendeingEngine to be tried before Pisces
> when its mature and complete, at least it should be configureable
> without passing the cmd-line parameter every time.
>
> Whats the purpose of the ServiceLoader, wouldn't it be possible to
> simply load the class specified on the command-line directly?
>
> Thank you in advance, Clemens
>

http://java.sun.com/javase/6/docs/api/java/util/ServiceLoader.html

You need a text file in META-INF/services/<package
name>.RenderingEngine which lists the provided implementations.
loadInstalled uses the extension class loader so that resources needs
to be loadable by that classloader. I presume this means it needs to
be available in ${JAVA_HOME}/jre/lib/ext.

You seem to contradict yourself, you want it to be 'configurable
without passing the command-line parameter every time' but then ask
why we can't simply load a class specified on the command-line. The
job of ServiceLoader and the META-INF/services files is to facilitate
exactly what you appear to want -- configuring things once and having
the service loaded on normal java invocations.

As to ordering, you can make sure your engine is first in this list at
least, but that is affected by caching and the time it takes to load a
class.
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

Howto install a custom rendering engine?

2009-11-02T09:28:05Z

Hi,

I am trying to install my own RenderingEngine implementation, however
I am not accustomed to the ServiceLoader concept:

> ServiceLoader<RenderingEngine> reLoader =
> ServiceLoader.loadInstalled(RenderingEngine.class);

the ServiceLoader doesn't e.g. contain my CairoRenderingEngine.

Would it be enough to simply create a META-INF directory with a single
file in it, similar to what has been done for pisces?
Is there any way to influence the iteration-order?
If possible I would prefer my RendeingEngine to be tried before Pisces
when its mature and complete, at least it should be configureable
without passing the cmd-line parameter every time.

Whats the purpose of the ServiceLoader, wouldn't it be possible to
simply load the class specified on the command-line directly?

Thank you in advance, Clemens

Re: Integration of the xrender pipeline rewite

2009-10-30T13:34:40Z

Hi,

Thanks for all your work, integrating and maintaining the pipeline.

> So I should just ditch what we have in IcedTea7 and use this webrev?
> I had to reroll all the patches for b74 anyway so get rid of that
> maintenance headache would be nice.

Yes, in the long run I hope this code will replace what is currently in IcedTea.
However the rewrite has more impact on independent parts (like the
StrikeCache changes), so even with the pipeline disabled it could
break some stuff. Thats why some review would be great...

- Clemens

Re: Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised

2009-10-30T11:26:09Z

2009/10/30 Mario Torre <mario.torre@...>:

> Il 30/10/2009 18:50, Jennifer Godinez ha scritto:
>>
>> Hi Mario,
>>
>> Since you are pushing the fix yourself, you don't really need the
>> "Contributed-by". This is used for someone pushing it for you.
>>
>> Jennifer
>
> Hi Jennifer, Jim and all,
>
> Committed!
>
> Thanks for the help, I'll celebrate with some Port wine tonight :)
>
> Cheers!
> Mario
> --
> Mario Torre, Software Developer, http://www.jroller.com/neugens/
> 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-44
> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF
>
> USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim
> Geschäftsführer: Dr. James J. Hunt
>
> Please, support open standards:
> http://endsoftpatents.org/
>
>

w00t! http://hg.openjdk.java.net/jdk7/2d/jdk/rev/634221297c37

Congratulations!
--
Andrew :-)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8