From linuxhippy at gmail.com  Mon Nov  2 17:28:05 2009
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Mon, 2 Nov 2009 12:28:05 -0500
Subject: [OpenJDK 2D-Dev] Howto install a custom rendering engine?
Message-ID: <194f62550911020928l49ceb32aw62eebbacf261894f@mail.gmail.com>

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


From gnu_andrew at member.fsf.org  Mon Nov  2 19:59:01 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Mon, 2 Nov 2009 19:59:01 +0000
Subject: [OpenJDK 2D-Dev] Howto install a custom rendering engine?
In-Reply-To: <194f62550911020928l49ceb32aw62eebbacf261894f@mail.gmail.com>
References: <194f62550911020928l49ceb32aw62eebbacf261894f@mail.gmail.com>
Message-ID: <17c6771e0911021159j3e9598f3ya1cc5feb6b28b3e0@mail.gmail.com>

2009/11/2 Clemens Eisserer <linuxhippy at gmail.com>:
> 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


From Phil.Race at Sun.COM  Tue Nov  3 19:35:36 2009
From: Phil.Race at Sun.COM (Phil Race)
Date: Tue, 03 Nov 2009 11:35:36 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [PATCH FOR APPROVAL]: Fix broken
 build on newer versions of X11 (libXext >= 1.1.0)
In-Reply-To: <17c6771e0911031120u35e9d69fh53d45dd41393abdf@mail.gmail.com>
References: <17c6771e0911031120u35e9d69fh53d45dd41393abdf@mail.gmail.com>
Message-ID: <4AF08608.8080509@sun.com>

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 at gmail.com>, 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,


From gnu_andrew at member.fsf.org  Tue Nov  3 21:12:21 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Tue, 3 Nov 2009 21:12:21 +0000
Subject: [OpenJDK 2D-Dev] <AWT Dev> [PATCH FOR APPROVAL]: Fix broken
	build on newer versions of X11 (libXext >= 1.1.0)
In-Reply-To: <4AF08608.8080509@sun.com>
References: <17c6771e0911031120u35e9d69fh53d45dd41393abdf@mail.gmail.com>
	<4AF08608.8080509@sun.com>
Message-ID: <17c6771e0911031312i6b63e734g91b134ab1e247f33@mail.gmail.com>

2009/11/3 Phil Race <Phil.Race at sun.com>:
> 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 at gmail.com>, 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,
>



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


From Phil.Race at Sun.COM  Tue Nov  3 21:18:26 2009
From: Phil.Race at Sun.COM (Phil Race)
Date: Tue, 03 Nov 2009 13:18:26 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [PATCH FOR APPROVAL]: Fix
 broken	build on newer versions of X11 (libXext >= 1.1.0)
In-Reply-To: <17c6771e0911031312i6b63e734g91b134ab1e247f33@mail.gmail.com>
References: <17c6771e0911031120u35e9d69fh53d45dd41393abdf@mail.gmail.com>
	<4AF08608.8080509@sun.com>
	<17c6771e0911031312i6b63e734g91b134ab1e247f33@mail.gmail.com>
Message-ID: <4AF09E22.8070202@sun.com>



Andrew John Hughes wrote:
> 2009/11/3 Phil Race <Phil.Race at sun.com>:
>> 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 at gmail.com>, 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,
> 
> 
> 


From Phil.Race at Sun.COM  Tue Nov  3 21:21:27 2009
From: Phil.Race at Sun.COM (Phil Race)
Date: Tue, 03 Nov 2009 13:21:27 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [PATCH FOR APPROVAL]: Fix
 broken	build on newer versions of X11 (libXext >= 1.1.0)
In-Reply-To: <4AF09E22.8070202@sun.com>
References: <17c6771e0911031120u35e9d69fh53d45dd41393abdf@mail.gmail.com>
	<4AF08608.8080509@sun.com>
	<17c6771e0911031312i6b63e734g91b134ab1e247f33@mail.gmail.com>
	<4AF09E22.8070202@sun.com>
Message-ID: <4AF09ED7.7070605@sun.com>


PS

>>
>> Is the patch ok?  

yes.

-phil.


From gnu_andrew at member.fsf.org  Tue Nov  3 21:50:50 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Tue, 3 Nov 2009 21:50:50 +0000
Subject: [OpenJDK 2D-Dev] <AWT Dev> [PATCH FOR APPROVAL]: Fix broken
	build on newer versions of X11 (libXext >= 1.1.0)
In-Reply-To: <4AF09E22.8070202@sun.com>
References: <17c6771e0911031120u35e9d69fh53d45dd41393abdf@mail.gmail.com>
	<4AF08608.8080509@sun.com>
	<17c6771e0911031312i6b63e734g91b134ab1e247f33@mail.gmail.com>
	<4AF09E22.8070202@sun.com>
Message-ID: <17c6771e0911031350y71df0392id8a579e7353c1d8b@mail.gmail.com>

2009/11/3 Phil Race <Phil.Race at sun.com>:
>
>
> Andrew John Hughes wrote:
>>
>> 2009/11/3 Phil Race <Phil.Race at sun.com>:
>>>
>>> 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 at gmail.com>, 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,
>>
>>
>>
>



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


From Phil.Race at Sun.COM  Tue Nov  3 21:53:45 2009
From: Phil.Race at Sun.COM (Phil Race)
Date: Tue, 03 Nov 2009 13:53:45 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [PATCH FOR APPROVAL]: Fix
 broken	build on newer versions of X11 (libXext >= 1.1.0)
In-Reply-To: <17c6771e0911031350y71df0392id8a579e7353c1d8b@mail.gmail.com>
References: <17c6771e0911031120u35e9d69fh53d45dd41393abdf@mail.gmail.com>
	<4AF08608.8080509@sun.com>
	<17c6771e0911031312i6b63e734g91b134ab1e247f33@mail.gmail.com>
	<4AF09E22.8070202@sun.com>
	<17c6771e0911031350y71df0392id8a579e7353c1d8b@mail.gmail.com>
Message-ID: <4AF0A669.5040400@sun.com>



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.


From Jim.A.Graham at Sun.COM  Tue Nov  3 22:07:59 2009
From: Jim.A.Graham at Sun.COM (Jim Graham)
Date: Tue, 03 Nov 2009 14:07:59 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [PATCH FOR APPROVAL]: Fix
 broken	build on newer versions of X11 (libXext >= 1.1.0)
In-Reply-To: <17c6771e0911031312i6b63e734g91b134ab1e247f33@mail.gmail.com>
References: <17c6771e0911031120u35e9d69fh53d45dd41393abdf@mail.gmail.com>
	<4AF08608.8080509@sun.com>
	<17c6771e0911031312i6b63e734g91b134ab1e247f33@mail.gmail.com>
Message-ID: <0KSK008CG05CAEJ0@fe-sfbay-10.sun.com>

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



From Jennifer.Godinez at Sun.COM  Tue Nov  3 22:09:41 2009
From: Jennifer.Godinez at Sun.COM (Jennifer Godinez)
Date: Tue, 03 Nov 2009 14:09:41 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [PATCH FOR APPROVAL]: Fix
 broken	build on newer versions of X11 (libXext >= 1.1.0)
In-Reply-To: <4AF09ED7.7070605@sun.com>
References: <17c6771e0911031120u35e9d69fh53d45dd41393abdf@mail.gmail.com>
	<4AF08608.8080509@sun.com>
	<17c6771e0911031312i6b63e734g91b134ab1e247f33@mail.gmail.com>
	<4AF09E22.8070202@sun.com> <4AF09ED7.7070605@sun.com>
Message-ID: <4AF0AA25.7000601@sun.com>

The sun bug ID is 6897844.

Jennifer

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


From gnu_andrew at member.fsf.org  Tue Nov  3 22:15:34 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Tue, 3 Nov 2009 22:15:34 +0000
Subject: [OpenJDK 2D-Dev] <AWT Dev> [PATCH FOR APPROVAL]: Fix broken
	build on newer versions of X11 (libXext >= 1.1.0)
In-Reply-To: <4AF0A669.5040400@sun.com>
References: <17c6771e0911031120u35e9d69fh53d45dd41393abdf@mail.gmail.com>
	<4AF08608.8080509@sun.com>
	<17c6771e0911031312i6b63e734g91b134ab1e247f33@mail.gmail.com>
	<4AF09E22.8070202@sun.com>
	<17c6771e0911031350y71df0392id8a579e7353c1d8b@mail.gmail.com>
	<4AF0A669.5040400@sun.com>
Message-ID: <17c6771e0911031415w278a90cdn73d0c264a87cb58d@mail.gmail.com>

2009/11/3 Phil Race <Phil.Race at sun.com>:
>
>
> 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


From gnu_andrew at member.fsf.org  Tue Nov  3 22:24:35 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Tue, 3 Nov 2009 22:24:35 +0000
Subject: [OpenJDK 2D-Dev] <AWT Dev> [PATCH FOR APPROVAL]: Fix broken
	build on newer versions of X11 (libXext >= 1.1.0)
In-Reply-To: <0KSK008CG05CAEJ0@fe-sfbay-10.sun.com>
References: <17c6771e0911031120u35e9d69fh53d45dd41393abdf@mail.gmail.com>
	<4AF08608.8080509@sun.com>
	<17c6771e0911031312i6b63e734g91b134ab1e247f33@mail.gmail.com>
	<0KSK008CG05CAEJ0@fe-sfbay-10.sun.com>
Message-ID: <17c6771e0911031424q20a20cb3ubedd1ba892038d7d@mail.gmail.com>

2009/11/3 Jim Graham <Jim.A.Graham at sun.com>:
> 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


From Jim.A.Graham at Sun.COM  Tue Nov  3 22:30:08 2009
From: Jim.A.Graham at Sun.COM (Jim Graham)
Date: Tue, 03 Nov 2009 14:30:08 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [PATCH FOR APPROVAL]: Fix broken
 build on newer versions of X11 (libXext >= 1.1.0)
In-Reply-To: <17c6771e0911031424q20a20cb3ubedd1ba892038d7d@mail.gmail.com>
References: <17c6771e0911031120u35e9d69fh53d45dd41393abdf@mail.gmail.com>
	<4AF08608.8080509@sun.com>
	<17c6771e0911031312i6b63e734g91b134ab1e247f33@mail.gmail.com>
	<0KSK008CG05CAEJ0@fe-sfbay-10.sun.com>
	<17c6771e0911031424q20a20cb3ubedd1ba892038d7d@mail.gmail.com>
Message-ID: <0KSK00BIP168XEM0@fe-sfbay-09.sun.com>

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 at sun.com>:
>> 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,


From gnu_andrew at member.fsf.org  Tue Nov  3 23:25:26 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Tue, 3 Nov 2009 23:25:26 +0000
Subject: [OpenJDK 2D-Dev] <AWT Dev> [PATCH FOR APPROVAL]: Fix broken
	build on newer versions of X11 (libXext >= 1.1.0)
In-Reply-To: <4AF0AA25.7000601@sun.com>
References: <17c6771e0911031120u35e9d69fh53d45dd41393abdf@mail.gmail.com>
	<4AF08608.8080509@sun.com>
	<17c6771e0911031312i6b63e734g91b134ab1e247f33@mail.gmail.com>
	<4AF09E22.8070202@sun.com> <4AF09ED7.7070605@sun.com>
	<4AF0AA25.7000601@sun.com>
Message-ID: <17c6771e0911031525t16a116dekd6978c0e68f1bb1e@mail.gmail.com>

2009/11/3 Jennifer Godinez <Jennifer.Godinez at sun.com>:
> 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


From ahughes at redhat.com  Tue Nov  3 23:24:01 2009
From: ahughes at redhat.com (ahughes at redhat.com)
Date: Tue, 03 Nov 2009 23:24:01 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6897844: Fix broken build on
	newer versions of X11	(libXext >= 1.1.0)
Message-ID: <20091103232414.D07AB41F96@hg.openjdk.java.net>

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



From gnu_andrew at member.fsf.org  Wed Nov  4 16:14:32 2009
From: gnu_andrew at member.fsf.org (Andrew John Hughes)
Date: Wed, 4 Nov 2009 16:14:32 +0000
Subject: [OpenJDK 2D-Dev] <AWT Dev> [PATCH FOR APPROVAL]: Fix broken
	build on newer versions of X11 (libXext >= 1.1.0)
In-Reply-To: <17c6771e0911031525t16a116dekd6978c0e68f1bb1e@mail.gmail.com>
References: <17c6771e0911031120u35e9d69fh53d45dd41393abdf@mail.gmail.com>
	<4AF08608.8080509@sun.com>
	<17c6771e0911031312i6b63e734g91b134ab1e247f33@mail.gmail.com>
	<4AF09E22.8070202@sun.com> <4AF09ED7.7070605@sun.com>
	<4AF0AA25.7000601@sun.com>
	<17c6771e0911031525t16a116dekd6978c0e68f1bb1e@mail.gmail.com>
Message-ID: <17c6771e0911040814v234049c1g50dc223ad6153be4@mail.gmail.com>

2009/11/3 Andrew John Hughes <gnu_andrew at member.fsf.org>:
> 2009/11/3 Jennifer Godinez <Jennifer.Godinez at sun.com>:
>> 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 at gmail.com>

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


From Jennifer.Godinez at Sun.COM  Wed Nov  4 17:23:29 2009
From: Jennifer.Godinez at Sun.COM (Jennifer Godinez)
Date: Wed, 04 Nov 2009 09:23:29 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> [PATCH FOR APPROVAL]: Fix broken
 build on newer versions of X11 (libXext >= 1.1.0)
In-Reply-To: <17c6771e0911040814v234049c1g50dc223ad6153be4@mail.gmail.com>
References: <17c6771e0911031120u35e9d69fh53d45dd41393abdf@mail.gmail.com>
	<4AF08608.8080509@sun.com>
	<17c6771e0911031312i6b63e734g91b134ab1e247f33@mail.gmail.com>
	<4AF09E22.8070202@sun.com> <4AF09ED7.7070605@sun.com>
	<4AF0AA25.7000601@sun.com>
	<17c6771e0911031525t16a116dekd6978c0e68f1bb1e@mail.gmail.com>
	<17c6771e0911040814v234049c1g50dc223ad6153be4@mail.gmail.com>
Message-ID: <4AF1B891.80209@Sun.COM>

Hi Andrew,

I will add it.  Thanks.

Jennifer

Andrew John Hughes wrote:
> 2009/11/3 Andrew John Hughes <gnu_andrew at member.fsf.org>:
>> 2009/11/3 Jennifer Godinez <Jennifer.Godinez at sun.com>:
>>> 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 at gmail.com>
> 
> Can someone add this to the Sun bug report?  I'll make sure it goes on
> the version of the fix for OpenJDK6.


From Anthony.Petrov at Sun.COM  Thu Nov  5 10:20:07 2009
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Thu, 05 Nov 2009 13:20:07 +0300
Subject: [OpenJDK 2D-Dev] <AWT Dev> [PATCH FOR APPROVAL]: Fix
 broken	build on newer versions of X11 (libXext >= 1.1.0)
In-Reply-To: <4AF09E22.8070202@sun.com>
References: <17c6771e0911031120u35e9d69fh53d45dd41393abdf@mail.gmail.com>
	<4AF08608.8080509@sun.com>
	<17c6771e0911031312i6b63e734g91b134ab1e247f33@mail.gmail.com>
	<4AF09E22.8070202@sun.com>
Message-ID: <4AF2A6D7.8000209@sun.com>

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


From linuxhippy at gmail.com  Thu Nov  5 19:08:17 2009
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Thu, 5 Nov 2009 14:08:17 -0500
Subject: [OpenJDK 2D-Dev] Integration of the xrender pipeline rewite
In-Reply-To: <194f62550910301334r6a518cecq6ea9fd9b37af973b@mail.gmail.com>
References: <194f62550910271411mf9c7450w9221ac0ed8a3c775@mail.gmail.com>
	<4AE780A2.5040009@sun.com>
	<194f62550910280223q1e5fc2a1y40790910544f90ee@mail.gmail.com>
	<194f62550910300750u1410e722xa031915f43df3c70@mail.gmail.com>
	<17c6771e0910300755x3abe74dah2b832d7adef1183f@mail.gmail.com>
	<194f62550910300836tfae9720g3dcc22aae3d0a696@mail.gmail.com>
	<17c6771e0910300841t3080474dn254430877c0b191e@mail.gmail.com>
	<194f62550910301334r6a518cecq6ea9fd9b37af973b@mail.gmail.com>
Message-ID: <194f62550911051108y84a5529y7563a8da11655761@mail.gmail.com>

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?


From Dmitri.Trembovetski at Sun.COM  Thu Nov  5 23:30:46 2009
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Thu, 05 Nov 2009 15:30:46 -0800
Subject: [OpenJDK 2D-Dev] Integration of the xrender pipeline rewite
In-Reply-To: <194f62550911051108y84a5529y7563a8da11655761@mail.gmail.com>
References: <194f62550910271411mf9c7450w9221ac0ed8a3c775@mail.gmail.com>
	<4AE780A2.5040009@sun.com>
	<194f62550910280223q1e5fc2a1y40790910544f90ee@mail.gmail.com>
	<194f62550910300750u1410e722xa031915f43df3c70@mail.gmail.com>
	<17c6771e0910300755x3abe74dah2b832d7adef1183f@mail.gmail.com>
	<194f62550910300836tfae9720g3dcc22aae3d0a696@mail.gmail.com>
	<17c6771e0910300841t3080474dn254430877c0b191e@mail.gmail.com>
	<194f62550910301334r6a518cecq6ea9fd9b37af973b@mail.gmail.com>
	<194f62550911051108y84a5529y7563a8da11655761@mail.gmail.com>
Message-ID: <4AF36026.304@Sun.COM>


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



From phil.race at sun.com  Mon Nov  9 22:30:44 2009
From: phil.race at sun.com (phil.race at sun.com)
Date: Mon, 09 Nov 2009 22:30:44 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6899078: potential deadlock and
	performance issue in	freeing strike resources with D3D pipeline
Message-ID: <20091109223114.0D99D41CD7@hg.openjdk.java.net>

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



From Roman.Kennke at Sun.COM  Mon Nov 30 14:28:18 2009
From: Roman.Kennke at Sun.COM (Roman Kennke)
Date: Mon, 30 Nov 2009 15:28:18 +0100
Subject: [OpenJDK 2D-Dev] [PATCH] Request for review: 6888734,
 regression test fails when java.security.manager is enabled
In-Reply-To: <1255612943.10319.3.camel@moonlight>
References: <1255612943.10319.3.camel@moonlight>
Message-ID: <1259591298.7241.446.camel@moonlight>

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




From Roman.Kennke at Sun.COM  Mon Nov 30 19:18:23 2009
From: Roman.Kennke at Sun.COM (Roman Kennke)
Date: Mon, 30 Nov 2009 20:18:23 +0100
Subject: [OpenJDK 2D-Dev] [PATCH] Request for review: 6904882:
 java.awt.Font.createFont() causes AccessControlException if executed with
 "-Djava.security.manager"
Message-ID: <1259608703.7241.1631.camel@moonlight>

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




From Phil.Race at Sun.COM  Mon Nov 30 19:19:23 2009
From: Phil.Race at Sun.COM (Phil Race)
Date: Mon, 30 Nov 2009 11:19:23 -0800
Subject: [OpenJDK 2D-Dev] [PATCH] Request for review: 6888734,
 regression test fails when java.security.manager is enabled
In-Reply-To: <1259591298.7241.446.camel@moonlight>
References: <1255612943.10319.3.camel@moonlight>
	<1259591298.7241.446.camel@moonlight>
Message-ID: <4B141ABB.9090209@sun.com>

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


From Roman.Kennke at Sun.COM  Mon Nov 30 19:35:12 2009
From: Roman.Kennke at Sun.COM (Roman Kennke)
Date: Mon, 30 Nov 2009 20:35:12 +0100
Subject: [OpenJDK 2D-Dev] [PATCH] Request for review: 6888734,
 regression test fails when java.security.manager is enabled
In-Reply-To: <4B141ABB.9090209@sun.com>
References: <1255612943.10319.3.camel@moonlight>
	<1259591298.7241.446.camel@moonlight> <4B141ABB.9090209@sun.com>
Message-ID: <1259609712.7241.1634.camel@moonlight>

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




From Phil.Race at Sun.COM  Mon Nov 30 19:45:17 2009
From: Phil.Race at Sun.COM (Phil Race)
Date: Mon, 30 Nov 2009 11:45:17 -0800
Subject: [OpenJDK 2D-Dev] [PATCH] Request for review: 6888734,
 regression test fails when java.security.manager is enabled
In-Reply-To: <1259609712.7241.1634.camel@moonlight>
References: <1255612943.10319.3.camel@moonlight>
	<1259591298.7241.446.camel@moonlight> <4B141ABB.9090209@sun.com>
	<1259609712.7241.1634.camel@moonlight>
Message-ID: <4B1420CD.1000605@sun.com>


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


From Roman.Kennke at Sun.COM  Mon Nov 30 19:52:11 2009
From: Roman.Kennke at Sun.COM (Roman Kennke)
Date: Mon, 30 Nov 2009 20:52:11 +0100
Subject: [OpenJDK 2D-Dev] [PATCH] Request for review: 6896335:
 GraphicsEnvironment.getDefaultScreenDevice() throws UnsatisfiedLinkError in
 headless mode
Message-ID: <1259610731.7241.1637.camel@moonlight>

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




From Phil.Race at Sun.COM  Mon Nov 30 19:49:27 2009
From: Phil.Race at Sun.COM (Phil Race)
Date: Mon, 30 Nov 2009 11:49:27 -0800
Subject: [OpenJDK 2D-Dev] [PATCH] Request for review: 6904882:
 java.awt.Font.createFont() causes AccessControlException if executed with
 "-Djava.security.manager"
In-Reply-To: <1259608703.7241.1631.camel@moonlight>
References: <1259608703.7241.1631.camel@moonlight>
Message-ID: <4B1421C7.1050204@sun.com>

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


From Roman.Kennke at Sun.COM  Mon Nov 30 19:58:50 2009
From: Roman.Kennke at Sun.COM (Roman Kennke)
Date: Mon, 30 Nov 2009 20:58:50 +0100
Subject: [OpenJDK 2D-Dev] [PATCH] Request for review: 6896335:
 GraphicsEnvironment.getDefaultScreenDevice() throws UnsatisfiedLinkError in
 headless mode
In-Reply-To: <1259610731.7241.1637.camel@moonlight>
References: <1259610731.7241.1637.camel@moonlight>
Message-ID: <1259611130.7241.1638.camel@moonlight>

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




From Phil.Race at Sun.COM  Mon Nov 30 19:56:31 2009
From: Phil.Race at Sun.COM (Phil Race)
Date: Mon, 30 Nov 2009 11:56:31 -0800
Subject: [OpenJDK 2D-Dev] [PATCH] Request for review: 6896335:
 GraphicsEnvironment.getDefaultScreenDevice() throws UnsatisfiedLinkError in
 headless mode
In-Reply-To: <1259610731.7241.1637.camel@moonlight>
References: <1259610731.7241.1637.camel@moonlight>
Message-ID: <4B14236F.2040101@sun.com>

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


From Roman.Kennke at Sun.COM  Mon Nov 30 20:32:52 2009
From: Roman.Kennke at Sun.COM (Roman Kennke)
Date: Mon, 30 Nov 2009 21:32:52 +0100
Subject: [OpenJDK 2D-Dev] [PATCH] Request for review: 6888734,
 regression test fails when java.security.manager is enabled
In-Reply-To: <4B141ABB.9090209@sun.com>
References: <1255612943.10319.3.camel@moonlight>
	<1259591298.7241.446.camel@moonlight> <4B141ABB.9090209@sun.com>
Message-ID: <1259613172.7241.1640.camel@moonlight>

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




From Phil.Race at Sun.COM  Mon Nov 30 21:37:12 2009
From: Phil.Race at Sun.COM (Phil Race)
Date: Mon, 30 Nov 2009 13:37:12 -0800
Subject: [OpenJDK 2D-Dev] [PATCH] Request for review: 6888734,
 regression test fails when java.security.manager is enabled
In-Reply-To: <1259613172.7241.1640.camel@moonlight>
References: <1255612943.10319.3.camel@moonlight>
	<1259591298.7241.446.camel@moonlight> <4B141ABB.9090209@sun.com>
	<1259613172.7241.1640.camel@moonlight>
Message-ID: <4B143B08.8090109@sun.com>

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



From phil.race at sun.com  Mon Nov 30 22:46:34 2009
From: phil.race at sun.com (phil.race at sun.com)
Date: Mon, 30 Nov 2009 22:46:34 +0000
Subject: [OpenJDK 2D-Dev] hg: jdk7/2d/jdk: 6904962:
	GlyphVector.getVisualBounds should not be	affected by leading
	or trailing white space.
Message-ID: <20091130224723.7F25D418ED@hg.openjdk.java.net>

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