From gnu_andrew at member.fsf.org Tue Nov 3 11:20:44 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 3 Nov 2009 19:20:44 +0000 Subject: [PATCH FOR APPROVAL]: Fix broken build on newer versions of X11 (libXext >= 1.1.0) Message-ID: <17c6771e0911031120u35e9d69fh53d45dd41393abdf@mail.gmail.com> 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? , 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 11:35:36 2009 From: Phil.Race at Sun.COM (Phil Race) Date: Tue, 03 Nov 2009 11:35:36 -0800 Subject: [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? , 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 13:12:21 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 3 Nov 2009 21:12:21 +0000 Subject: [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 : > 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? , 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 13:18:26 2009 From: Phil.Race at Sun.COM (Phil Race) Date: Tue, 03 Nov 2009 13:18:26 -0800 Subject: [OpenJDK 2D-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 : >> 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? , 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 13:21:27 2009 From: Phil.Race at Sun.COM (Phil Race) Date: Tue, 03 Nov 2009 13:21:27 -0800 Subject: [OpenJDK 2D-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 13: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] [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 : > > > Andrew John Hughes wrote: >> >> 2009/11/3 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? , 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 13:53:45 2009 From: Phil.Race at Sun.COM (Phil Race) Date: Tue, 03 Nov 2009 13:53:45 -0800 Subject: [OpenJDK 2D-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 gnu_andrew at member.fsf.org Tue Nov 3 14: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] [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 : > > > 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 14: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] [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 : > 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 gnu_andrew at member.fsf.org Tue Nov 3 15: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] [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 : > 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 Jim.A.Graham at Sun.COM Tue Nov 3 14: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] [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 14:09:41 2009 From: Jennifer.Godinez at Sun.COM (Jennifer Godinez) Date: Tue, 03 Nov 2009 14:09:41 -0800 Subject: [OpenJDK 2D-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 Jim.A.Graham at Sun.COM Tue Nov 3 14: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] [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 : >> 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 Wed Nov 4 08: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] [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 : > 2009/11/3 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? 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 09:23:29 2009 From: Jennifer.Godinez at Sun.COM (Jennifer Godinez) Date: Wed, 04 Nov 2009 09:23:29 -0800 Subject: [OpenJDK 2D-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 : >> 2009/11/3 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? > > 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 02:20:07 2009 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Thu, 05 Nov 2009 13:20:07 +0300 Subject: [OpenJDK 2D-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 Dmitry.Cherepanov at Sun.COM Wed Nov 11 01:31:44 2009 From: Dmitry.Cherepanov at Sun.COM (Dmitry Cherepanov) Date: Wed, 11 Nov 2009 12:31:44 +0300 Subject: Review request #2: 6863566 (Java should support the freedesktop.org startup notification specification) In-Reply-To: <4ADC682A.3080703@sun.com> References: <4ADC682A.3080703@sun.com> Message-ID: <4AFA8480.60903@sun.com> Just a small suggestion. It might make sense to clarify whether this fix covers the UI tools (like jconsole) or not. So far, the report says that ----------------------------------------------------------------------------------------- Copy this text into a .desktop file in your ~/Desktop directory: [Desktop Entry] Name=Startup notification test Type=Application Exec=jconsole StartupNotify=true jconsole can be replaced by any Java application that opens a window. ----------------------------------------------------------------------------------------- According this description, the fix is supposed to work OK with the UI tools. At the same time, the java process doesn't inherit the env variable (DESKTOP_STARTUP_ID) of the UI process. As a result, the newly introduced method will not remove the startup notification. So, my suggestion is to explicitly clarify this behaviour in the bug report. The fix itself looks fine for me. Thanks, Dmitry Anthony Petrov wrote: > Hello, > > Please review the latest version of the fix contributed by Damjan > Jovanovic: > > RFE: https://bugs.openjdk.java.net/show_bug.cgi?id=100094 > There you can also find some latest comments regarding the fix. > > webrev: > http://cr.openjdk.java.net/~anthony/7-24-startupNotify-6863566.2/ > > The patch no longer unsets the environment variable, and hence does > not need core-libs review. > > -- > best regards, > Anthony > From dmitry.cherepanov at sun.com Wed Nov 11 06:52:43 2009 From: dmitry.cherepanov at sun.com (dmitry.cherepanov at sun.com) Date: Wed, 11 Nov 2009 14:52:43 +0000 Subject: hg: jdk7/awt/jdk: 6852111: Unhandled 'spurious wakeup' in java.awt.EventQueue.invokeAndWait() Message-ID: <20091111145308.8B1B841F75@hg.openjdk.java.net> Changeset: 50321e4d46eb Author: dcherepanov Date: 2009-11-11 17:46 +0300 URL: http://hg.openjdk.java.net/jdk7/awt/jdk/rev/50321e4d46eb 6852111: Unhandled 'spurious wakeup' in java.awt.EventQueue.invokeAndWait() Summary: Introduced InvocationEvent.isDispatched method Reviewed-by: art, anthony ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/event/InvocationEvent.java ! src/share/classes/sun/awt/im/InputMethodManager.java + test/java/awt/event/InvocationEvent/InvocationEventTest.java From Artem.Ananiev at Sun.COM Wed Nov 11 07:05:03 2009 From: Artem.Ananiev at Sun.COM (Artem Ananiev) Date: Wed, 11 Nov 2009 18:05:03 +0300 Subject: Review request #2: 6863566 (Java should support the freedesktop.org startup notification specification) In-Reply-To: <9e89675b0910281057p5206964wdf33deadb50fb82f@mail.gmail.com> References: <4ADC682A.3080703@sun.com> <4AE6E47E.5080308@sun.com> <9e89675b0910281057p5206964wdf33deadb50fb82f@mail.gmail.com> Message-ID: <4AFAD29F.9060109@sun.com> Hi, Damjan, I wonder if WM teams (kwin, metacity, xfwm, etc.) are aware of the errors in the specification/examples, otherwise they'll wait for incorrect atom names and use incorrect windows and will miss the information what Java applications provide to them. No more comments from my side :) Thanks, Artem Damjan Jovanovic wrote: > On Tue, Oct 27, 2009 at 2:15 PM, Artem Ananiev wrote: >> Hi, Anthony, Damjan, > > Hello Artem, Anthony > >> here are a couple of comments from my side: > > You'll find they're followed by my counterarguments :-) > >> 1. _NET_STARTUP_INFO atom looks redundant. Check the example from >> http://www.freedesktop.org/wiki/Specifications/startup-notification-spec for >> details. > > That example has at least 2 problems, the wrong atom name being one of > them. I've complained to freedesktop.org some time ago > (http://lists.freedesktop.org/archives/xdg/2008-December/010106.html), > but things are a bit nebulous that side :-). > > If it makes you feel any better, the equivalent patch I sent to the > Wine project works the same way as this one > (http://www.winehq.org/pipermail/wine-cvs/2009-January/051514.html). > It's been working fine since it got committed on 7 January 2009. > >> 2. I see the client message is currently send to the root window, while the >> same example from freedesktop.org sends it to some "target window". Is the >> fix tested, say, for different virtual desktops? > > The spec says "In multihead setups, the messages should go to the root > window of the X screen where the launchee application is being > launched." > > I think that's what my patch does: > + XlibWrapper.XSendEvent(XToolkit.getDisplay(), > + XlibWrapper.RootWindow(XToolkit.getDisplay(), > getScreenNumber()), > > Now as for different virtual desktops, my tests show that both patched > Java and native applications have the startup notification follow you > and continue, with the window opening on the new desktop, if you > switch virtual desktops during startup. > >> 3. Here is a code from removeStartupNotification(): >> >> 1240 final int msglen = Math.min(message.length - pos, 20); >> 1241 int i = 0; >> 1242 for (; i < msglen; i++) { >> 1243 XlibWrapper.unsafe.putByte(req.get_data() + i, message[pos + i]); >> 1244 } >> 1245 for (; i < 20; i++) { >> 1246 XlibWrapper.unsafe.putByte(req.get_data() + i, (byte)0); >> 1247 } >> >> We first set "msglen" bytes from message array and then 20 zero bytes. It >> seems that 20 should be replaced with (20-message.length % 20) % 20, >> otherwise we'll get out of XClientMessageEvent bounds. > > No, we don't reset the variable i to 0, it starts where it left off > and run up to 20. There can't be an overrun. > >> Thanks, >> >> Artem > > Thank you > Damjan > >> Anthony Petrov wrote: >>> Hello, >>> >>> Please review the latest version of the fix contributed by Damjan >>> Jovanovic: >>> >>> RFE: https://bugs.openjdk.java.net/show_bug.cgi?id=100094 >>> There you can also find some latest comments regarding the fix. >>> >>> webrev: >>> http://cr.openjdk.java.net/~anthony/7-24-startupNotify-6863566.2/ >>> >>> The patch no longer unsets the environment variable, and hence does not >>> need core-libs review. >>> >>> -- >>> best regards, >>> Anthony From dmitry.cherepanov at sun.com Wed Nov 11 08:21:30 2009 From: dmitry.cherepanov at sun.com (dmitry.cherepanov at sun.com) Date: Wed, 11 Nov 2009 16:21:30 +0000 Subject: hg: jdk7/awt/jdk: 6880694: GraphicsDevice.setFullScreenWindow(null) throws NPE if there's a fullscreen window displayed Message-ID: <20091111162143.2DEE141F8F@hg.openjdk.java.net> Changeset: 7dd452521ab3 Author: dcherepanov Date: 2009-11-11 19:18 +0300 URL: http://hg.openjdk.java.net/jdk7/awt/jdk/rev/7dd452521ab3 6880694: GraphicsDevice.setFullScreenWindow(null) throws NPE if there's a fullscreen window displayed Summary: handle "empty" refresh rates Reviewed-by: art, anthony ! src/solaris/native/sun/awt/awt_GraphicsEnv.c From dmitry.cherepanov at sun.com Thu Nov 12 01:10:34 2009 From: dmitry.cherepanov at sun.com (dmitry.cherepanov at sun.com) Date: Thu, 12 Nov 2009 09:10:34 +0000 Subject: hg: jdk7/awt/jdk: 6882909: Resetting a full-screen window to normal rotates screen to normal orientation. Message-ID: <20091112091110.969584143E@hg.openjdk.java.net> Changeset: d0a17624ac54 Author: dcherepanov Date: 2009-11-12 12:06 +0300 URL: http://hg.openjdk.java.net/jdk7/awt/jdk/rev/d0a17624ac54 6882909: Resetting a full-screen window to normal rotates screen to normal orientation. Summary: retain rotation upon change to full screen mode Reviewed-by: art, anthony ! src/solaris/native/sun/awt/awt_GraphicsEnv.c From Alan.Bateman at Sun.COM Thu Nov 12 08:47:01 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 12 Nov 2009 16:47:01 +0000 Subject: 6890458: Datatransfer API should not require RMI to be present Message-ID: <4AFC3C05.1020201@sun.com> Alexey Utkin - would you mind reviewing this? I'd like to change the implementation of the AWT data transfer API so that it doesn't require RMI to be present. In other words, if the application is not using remote interfaces then it shouldn't matter if java.rmi.Remote is accessible or not and DataFlavor.isFlavorRemoteObjectType will always return false. If the application is using remote interfaces then it requires RMI to be present and everything works as it does now. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/6890458/webrev.00/ I didn't find any tests that exercise this code in the jtreg/regression suite but Girish Ramachandran helped me on this so I'm confident that it doesn't introduce any regressions. Thanks, Alan. From Alexey.Utkin at Sun.COM Fri Nov 13 04:11:29 2009 From: Alexey.Utkin at Sun.COM (Alexey Utkin) Date: Fri, 13 Nov 2009 15:11:29 +0300 Subject: 6890458: Datatransfer API should not require RMI to be present - approved In-Reply-To: <4AFC3C05.1020201@sun.com> References: <4AFC3C05.1020201@sun.com> Message-ID: <4AFD4CF1.6060809@sun.com> Looks good for me. The old functionality is conserved by this change. Regards, -uta Alan Bateman wrote: > Alexey Utkin - would you mind reviewing this? > > I'd like to change the implementation of the AWT data transfer API so > that it doesn't require RMI to be present. In other words, if the > application is not using remote interfaces then it shouldn't matter if > java.rmi.Remote is accessible or not and > DataFlavor.isFlavorRemoteObjectType will always return false. If the > application is using remote interfaces then it requires RMI to be > present and everything works as it does now. The webrev with the > changes is here: > http://cr.openjdk.java.net/~alanb/6890458/webrev.00/ > > I didn't find any tests that exercise this code in the > jtreg/regression suite but Girish Ramachandran helped me on this so > I'm confident that it doesn't introduce any regressions. > > Thanks, > Alan. From alan.bateman at sun.com Mon Nov 16 10:16:20 2009 From: alan.bateman at sun.com (alan.bateman at sun.com) Date: Mon, 16 Nov 2009 18:16:20 +0000 Subject: hg: jdk7/awt/jdk: 6890458: Datatransfer API should not require RMI to be present Message-ID: <20091116181717.59E9B41B65@hg.openjdk.java.net> Changeset: 4311194cf851 Author: alanb Date: 2009-11-16 18:13 +0000 URL: http://hg.openjdk.java.net/jdk7/awt/jdk/rev/4311194cf851 6890458: Datatransfer API should not require RMI to be present Reviewed-by: uta ! src/share/classes/java/awt/datatransfer/DataFlavor.java ! src/share/classes/sun/awt/datatransfer/DataTransferer.java From damjan.jov at gmail.com Tue Nov 17 07:11:14 2009 From: damjan.jov at gmail.com (Damjan Jovanovic) Date: Tue, 17 Nov 2009 17:11:14 +0200 Subject: Review request #2: 6863566 (Java should support the freedesktop.org startup notification specification) In-Reply-To: <4AFA8480.60903@sun.com> References: <4ADC682A.3080703@sun.com> <4AFA8480.60903@sun.com> Message-ID: <9e89675b0911170711h2d569173s3287d2530ebe63ad@mail.gmail.com> On Wed, Nov 11, 2009 at 11:31 AM, Dmitry Cherepanov wrote: > Just a small suggestion. > > It might make sense to clarify whether this fix covers the UI tools (like > jconsole) or not. So far, the report says that > > ----------------------------------------------------------------------------------------- > Copy this text into a .desktop file in your ~/Desktop directory: > > [Desktop Entry] > Name=Startup notification test > Type=Application > Exec=jconsole > StartupNotify=true > > jconsole can be replaced by any Java application that opens a window. > ----------------------------------------------------------------------------------------- > > According this description, the fix is supposed to work OK with the UI > tools. > > At the same time, the java process doesn't inherit the env variable > (DESKTOP_STARTUP_ID) of the UI process. As a result, the newly introduced > method will not remove the startup notification. So, my suggestion is to > explicitly clarify this behaviour in the bug report. > > The fix itself looks fine for me. Startup notifications have to start and stop. They don't automatically start when you double-click on an executable file from your file manager or run an executable from a terminal. They can only start when you run a .desktop file that has the "StartupNotify=true" line. If startup notifications don't start, then there is no real problem - it just looks bad because you know you started the application but you aren't getting any feedback that it's starting (busy mouse cursor, "Starting ..." on the task bar). If startup notifications do start, then it looks really bad if they don't stop - the application starts in a separate task bar tab, while the "Starting..." tab and the busy mouse cursor continue for quite some time. My patch addresses this case, by stopping them when the first window shows. The .desktop files for tools like jconsole currently have no "StartupNotify=..." line, so startup notifications are disabled even with my patch. I asked we add "StartupNotify=true" to those files and provided a patch, but my request was denied, see the OpenJDK bug (https://bugs.openjdk.java.net/show_bug.cgi?id=100094) for details. > Thanks, > Dmitry > > Anthony Petrov wrote: >> >> Hello, >> >> Please review the latest version of the fix contributed by Damjan >> Jovanovic: >> >> RFE: https://bugs.openjdk.java.net/show_bug.cgi?id=100094 >> There you can also find some latest comments regarding the fix. >> >> webrev: >> http://cr.openjdk.java.net/~anthony/7-24-startupNotify-6863566.2/ >> >> The patch no longer unsets the environment variable, and hence does not >> need core-libs review. >> >> -- >> best regards, >> Anthony >> > > Thank you Damjan Jovanovic From damjan.jov at gmail.com Tue Nov 17 07:23:13 2009 From: damjan.jov at gmail.com (Damjan Jovanovic) Date: Tue, 17 Nov 2009 17:23:13 +0200 Subject: Review request #2: 6863566 (Java should support the freedesktop.org startup notification specification) In-Reply-To: <4AFAD29F.9060109@sun.com> References: <4ADC682A.3080703@sun.com> <4AE6E47E.5080308@sun.com> <9e89675b0910281057p5206964wdf33deadb50fb82f@mail.gmail.com> <4AFAD29F.9060109@sun.com> Message-ID: <9e89675b0911170723y8c36488ta223c9d08282c952@mail.gmail.com> On Wed, Nov 11, 2009 at 5:05 PM, Artem Ananiev wrote: > Hi, Damjan, > > I wonder if WM teams (kwin, metacity, xfwm, etc.) are aware of the errors in > the specification/examples, otherwise they'll wait for incorrect atom names > and use incorrect windows and will miss the information what Java > applications provide to them. The widely used GUI framework gtk+ has been sending startup notification messages this way for many years, so it must work - for example follow the function gdk_x11_display_broadcast_startup_message in http://git.gnome.org/cgit/gtk+/tree/gdk/x11/gdkdisplay-x11.c > No more comments from my side :) > > Thanks, > > Artem Thank you Damjan Jovanovic > Damjan Jovanovic wrote: >> >> On Tue, Oct 27, 2009 at 2:15 PM, Artem Ananiev >> wrote: >>> >>> Hi, Anthony, Damjan, >> >> Hello Artem, Anthony >> >>> here are a couple of comments from my side: >> >> You'll find they're followed by my counterarguments :-) >> >>> 1. _NET_STARTUP_INFO atom looks redundant. Check the example from >>> http://www.freedesktop.org/wiki/Specifications/startup-notification-spec >>> for >>> details. >> >> That example has at least 2 problems, the wrong atom name being one of >> them. I've complained to freedesktop.org some time ago >> (http://lists.freedesktop.org/archives/xdg/2008-December/010106.html), >> but things are a bit nebulous that side :-). >> >> If it makes you feel any better, the equivalent patch I sent to the >> Wine project works the same way as this one >> (http://www.winehq.org/pipermail/wine-cvs/2009-January/051514.html). >> It's been working fine since it got committed on 7 January 2009. >> >>> 2. I see the client message is currently send to the root window, while >>> the >>> same example from freedesktop.org sends it to some "target window". Is >>> the >>> fix tested, say, for different virtual desktops? >> >> The spec says "In multihead setups, the messages should go to the root >> window of the X screen where the launchee application is being >> launched." >> >> I think that's what my patch does: >> + ? ? ? ? ? ? ? ?XlibWrapper.XSendEvent(XToolkit.getDisplay(), >> + ? ? ? ? ? ? ? ? ? ?XlibWrapper.RootWindow(XToolkit.getDisplay(), >> getScreenNumber()), >> >> Now as for different virtual desktops, my tests show that both patched >> Java and native applications have the startup notification follow you >> and continue, with the window opening on the new desktop, if you >> switch virtual desktops during startup. >> >>> 3. Here is a code from removeStartupNotification(): >>> >>> 1240 final int msglen = Math.min(message.length - pos, 20); >>> 1241 int i = 0; >>> 1242 for (; i < msglen; i++) { >>> 1243 ? XlibWrapper.unsafe.putByte(req.get_data() + i, message[pos + i]); >>> 1244 } >>> 1245 for (; i < 20; i++) { >>> 1246 ? XlibWrapper.unsafe.putByte(req.get_data() + i, (byte)0); >>> 1247 } >>> >>> We first set "msglen" bytes from message array and then 20 zero bytes. It >>> seems that 20 should be replaced with (20-message.length % 20) % 20, >>> otherwise we'll get out of XClientMessageEvent bounds. >> >> No, we don't reset the variable i to 0, it starts where it left off >> and run up to 20. There can't be an overrun. >> >>> Thanks, >>> >>> Artem >> >> Thank you >> Damjan >> >>> Anthony Petrov wrote: >>>> >>>> Hello, >>>> >>>> Please review the latest version of the fix contributed by Damjan >>>> Jovanovic: >>>> >>>> RFE: https://bugs.openjdk.java.net/show_bug.cgi?id=100094 >>>> There you can also find some latest comments regarding the fix. >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~anthony/7-24-startupNotify-6863566.2/ >>>> >>>> The patch no longer unsets the environment variable, and hence does not >>>> need core-libs review. >>>> >>>> -- >>>> best regards, >>>> Anthony > From Anthony.Petrov at Sun.COM Tue Nov 17 07:26:27 2009 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Tue, 17 Nov 2009 18:26:27 +0300 Subject: Review request #2: 6863566 (Java should support the freedesktop.org startup notification specification) In-Reply-To: <9e89675b0911170711h2d569173s3287d2530ebe63ad@mail.gmail.com> References: <4ADC682A.3080703@sun.com> <4AFA8480.60903@sun.com> <9e89675b0911170711h2d569173s3287d2530ebe63ad@mail.gmail.com> Message-ID: <4B02C0A3.6020509@sun.com> On 11/17/2009 06:11 PM, Damjan Jovanovic wrote: > On Wed, Nov 11, 2009 at 11:31 AM, Dmitry Cherepanov > wrote: >> Just a small suggestion. >> >> It might make sense to clarify whether this fix covers the UI tools (like >> jconsole) or not. So far, the report says that >> >> ----------------------------------------------------------------------------------------- >> Copy this text into a .desktop file in your ~/Desktop directory: >> >> [Desktop Entry] >> Name=Startup notification test >> Type=Application >> Exec=jconsole >> StartupNotify=true >> >> jconsole can be replaced by any Java application that opens a window. >> ----------------------------------------------------------------------------------------- >> >> According this description, the fix is supposed to work OK with the UI >> tools. >> >> At the same time, the java process doesn't inherit the env variable >> (DESKTOP_STARTUP_ID) of the UI process. As a result, the newly introduced >> method will not remove the startup notification. So, my suggestion is to >> explicitly clarify this behaviour in the bug report. >> >> The fix itself looks fine for me. > > Startup notifications have to start and stop. They don't automatically > start when you double-click on an executable file from your file > manager or run an executable from a terminal. They can only start when > you run a .desktop file that has the "StartupNotify=true" line. > > If startup notifications don't start, then there is no real problem - > it just looks bad because you know you started the application but you > aren't getting any feedback that it's starting (busy mouse cursor, > "Starting ..." on the task bar). > > If startup notifications do start, then it looks really bad if they > don't stop - the application starts in a separate task bar tab, while > the "Starting..." tab and the busy mouse cursor continue for quite > some time. My patch addresses this case, by stopping them when the > first window shows. > > The .desktop files for tools like jconsole currently have no > "StartupNotify=..." line, so startup notifications are disabled even > with my patch. I asked we add "StartupNotify=true" to those files and > provided a patch, but my request was denied, see the OpenJDK bug > (https://bugs.openjdk.java.net/show_bug.cgi?id=100094) for details. I think Dmitry means that even if you add the "StartupNotify=..." to the .desktop file for jconsole, it won't end the startap notification with your current fix. That is because the .desktop file actually starts the jconsole launcher, which subsequently starts the java process of the jconsole w/o inheriting the environment. Therefore, the java process of the jconsole does not end the startup notification. AFAIR, your then-proposed fix only added the "StartupNotify=..." to some java and java-ws.desktop files. But it didn't address the issues in the native launcher for jconsole. However, the description of the bug in the Bugzilla states that with your fix the .desktop file of the jconsole may be modified, and the jconsole will work correctly: the startup notification will be ended as soon as jconsole starts. Dmitry is pointing out that this is not true. -- best regards, Anthony From damjan.jov at gmail.com Tue Nov 17 10:06:00 2009 From: damjan.jov at gmail.com (Damjan Jovanovic) Date: Tue, 17 Nov 2009 20:06:00 +0200 Subject: Review request #2: 6863566 (Java should support the freedesktop.org startup notification specification) In-Reply-To: <4B02C0A3.6020509@sun.com> References: <4ADC682A.3080703@sun.com> <4AFA8480.60903@sun.com> <9e89675b0911170711h2d569173s3287d2530ebe63ad@mail.gmail.com> <4B02C0A3.6020509@sun.com> Message-ID: <9e89675b0911171006l2840b976k3af9b8cf29b657a7@mail.gmail.com> On Tue, Nov 17, 2009 at 5:26 PM, Anthony Petrov wrote: > On 11/17/2009 06:11 PM, Damjan Jovanovic wrote: >> >> On Wed, Nov 11, 2009 at 11:31 AM, Dmitry Cherepanov >> wrote: >>> >>> Just a small suggestion. >>> >>> It might make sense to clarify whether this fix covers the UI tools (like >>> jconsole) or not. So far, the report says that >>> >>> >>> ----------------------------------------------------------------------------------------- >>> Copy this text into a .desktop file in your ~/Desktop directory: >>> >>> [Desktop Entry] >>> Name=Startup notification test >>> Type=Application >>> Exec=jconsole >>> StartupNotify=true >>> >>> jconsole can be replaced by any Java application that opens a window. >>> >>> ----------------------------------------------------------------------------------------- >>> >>> According this description, the fix is supposed to work OK with the UI >>> tools. >>> >>> At the same time, the java process doesn't inherit the env variable >>> (DESKTOP_STARTUP_ID) of the UI process. As a result, the newly introduced >>> method will not remove the startup notification. So, my suggestion is to >>> explicitly clarify this behaviour in the bug report. >>> >>> The fix itself looks fine for me. >> >> Startup notifications have to start and stop. They don't automatically >> start when you double-click on an executable file from your file >> manager or run an executable from a terminal. They can only start when >> you run a .desktop file that has the "StartupNotify=true" line. >> >> If startup notifications don't start, then there is no real problem - >> it just looks bad because you know you started the application but you >> aren't getting any feedback that it's starting (busy mouse cursor, >> "Starting ..." on the task bar). >> >> If startup notifications do start, then it looks really bad if they >> don't stop - the application starts in a separate task bar tab, while >> the "Starting..." tab and the busy mouse cursor continue for quite >> some time. My patch addresses this case, by stopping them when the >> first window shows. >> >> The .desktop files for tools like jconsole currently have no >> "StartupNotify=..." line, so startup notifications are disabled even >> with my patch. I asked we add "StartupNotify=true" to those files and >> provided a patch, but my request was denied, see the OpenJDK bug >> (https://bugs.openjdk.java.net/show_bug.cgi?id=100094) for details. > > I think Dmitry means that even if you add the "StartupNotify=..." to the > .desktop file for jconsole, it won't end the startap notification with your > current fix. That is because the .desktop file actually starts the jconsole > launcher, which subsequently starts the java process of the jconsole w/o > inheriting the environment. Therefore, the java process of the jconsole does > not end the startup notification. > > AFAIR, your then-proposed fix only added the "StartupNotify=..." to some > ?java and java-ws.desktop files. But it didn't address the issues in the > native launcher for jconsole. > > However, the description of the bug in the Bugzilla states that with your > fix the .desktop file of the jconsole may be modified, and the jconsole will > work correctly: the startup notification will be ended as soon as jconsole > starts. Dmitry is pointing out that this is not true. I see. How can I edit the OpenJDK bugzilla comment? > -- > best regards, > Anthony > Thank you Damjan From Anthony.Petrov at Sun.COM Tue Nov 17 10:16:50 2009 From: Anthony.Petrov at Sun.COM (Anthony Petrov) Date: Tue, 17 Nov 2009 21:16:50 +0300 Subject: Review request #2: 6863566 (Java should support the freedesktop.org startup notification specification) In-Reply-To: <9e89675b0911171006l2840b976k3af9b8cf29b657a7@mail.gmail.com> References: <4ADC682A.3080703@sun.com> <4AFA8480.60903@sun.com> <9e89675b0911170711h2d569173s3287d2530ebe63ad@mail.gmail.com> <4B02C0A3.6020509@sun.com> <9e89675b0911171006l2840b976k3af9b8cf29b657a7@mail.gmail.com> Message-ID: <4B02E892.7060101@sun.com> Hi Damjan, On 11/17/2009 9:06 PM Damjan Jovanovic wrote: >> I think Dmitry means that even if you add the "StartupNotify=..." to the >> .desktop file for jconsole, it won't end the startap notification with your >> current fix. That is because the .desktop file actually starts the jconsole >> launcher, which subsequently starts the java process of the jconsole w/o >> inheriting the environment. Therefore, the java process of the jconsole does >> not end the startup notification. > > I see. > > How can I edit the OpenJDK bugzilla comment? I guess that isn't possible. You could add a comment instead. Regarding the fix itself, it looks like everyone likes it. So I'm going to push it later this week. Thanks Damjan! -- best regards, Anthony From Dalibor.Topic at Sun.COM Tue Nov 17 17:40:16 2009 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Wed, 18 Nov 2009 02:40:16 +0100 Subject: Review request #2: 6863566 (Java should support the freedesktop.org startup notification specification) In-Reply-To: <9e89675b0911171006l2840b976k3af9b8cf29b657a7@mail.gmail.com> References: <4ADC682A.3080703@sun.com> <4AFA8480.60903@sun.com> <9e89675b0911170711h2d569173s3287d2530ebe63ad@mail.gmail.com> <4B02C0A3.6020509@sun.com> <9e89675b0911171006l2840b976k3af9b8cf29b657a7@mail.gmail.com> Message-ID: <4B035080.1090309@sun.com> Damjan Jovanovic wrote: > How can I edit the OpenJDK bugzilla comment? I believe the easiest way to do it is to just add another comment to the issue. I don't think that Bugzilla supports editing past comments: http://weblogs.mozillazine.org/gerv/archives/006449.html cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Wolf Frenkel Vorsitzender des Aufsichtsrates: Martin H?ring From anthony.petrov at sun.com Fri Nov 20 08:12:35 2009 From: anthony.petrov at sun.com (anthony.petrov at sun.com) Date: Fri, 20 Nov 2009 16:12:35 +0000 Subject: hg: jdk7/awt/jdk: 6863566: Java should support the freedesktop.org startup notification specification Message-ID: <20091120161255.3925C41519@hg.openjdk.java.net> Changeset: 6286daeb7d5a Author: anthony Date: 2009-11-20 19:11 +0300 URL: http://hg.openjdk.java.net/jdk7/awt/jdk/rev/6286daeb7d5a 6863566: Java should support the freedesktop.org startup notification specification Summary: The startup notification gets removed as soon as a Java top-level window is shown Reviewed-by: anthony, art, dcherepanov Contributed-by: Damjan Jovanovic ! src/solaris/classes/sun/awt/X11/XWindowPeer.java