headers
Andrew John Hughes | 3 Nov 2009 20:20
Picon
Gravatar

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

With the new version of X11 (specifically libXext >= 1.1), the XShm.h
header has been refactored.

As a result, the build fails on awt_GraphicsEnv.c.  This simple patch:

http://cr.openjdk.java.net/~andrew/xshm/webrev.01

fixes the issue, without affecting older versions.  It's trivial, but
very important; this new X11 is already in Gentoo, it'll be in F12
(where we first discovered this issue), and it's no doubt heading to
an Ubuntu near you soon.

The patch was contributed by Diego Pettenò <flameeyes@...>, who
I'm informed has signed the SCA.

Does this look ok? If so, can I have a bug ID to push this to the
awt-gate (or wherever is appropriate)?

Thanks,
--

-- 
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
(Continue reading)

Permalink | Reply | 15 comments |
headers
Dmitry Cherepanov | 11 Nov 2009 10:31
Picon

Re: Review request #2: 6863566 (Java should support the freedesktop.org startup notification specification)

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
(Continue reading)

Permalink | Reply | 5 comments |
headers
dmitry.cherepanov | 11 Nov 2009 15:52
Picon

hg: jdk7/awt/jdk: 6852111: Unhandled 'spurious wakeup' in java.awt.EventQueue.invokeAndWait()

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
Permalink | Reply | 0 comments |
headers
Artem Ananiev | 11 Nov 2009 16:05
Picon

Re: Review request #2: 6863566 (Java should support the freedesktop.org startup notification specification)

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 <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),
(Continue reading)

Permalink | Reply | 1 comment |
headers
dmitry.cherepanov | 11 Nov 2009 17:21
Picon

hg: jdk7/awt/jdk: 6880694: GraphicsDevice.setFullScreenWindow(null) throws NPE if there's a fullscreen window displayed

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
Permalink | Reply | 0 comments |
headers
dmitry.cherepanov | 12 Nov 2009 10:10
Picon

hg: jdk7/awt/jdk: 6882909: Resetting a full-screen window to normal rotates screen to normal orientation.

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
Permalink | Reply | 0 comments |
headers
Alan Bateman | 12 Nov 2009 17:47
Picon

6890458: Datatransfer API should not require RMI to be present

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.
Permalink | Reply | 1 comment |
headers
Alexey Utkin | 13 Nov 2009 13:11
Picon

Re: 6890458: Datatransfer API should not require RMI to be present - approved

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.
Permalink | Reply | 0 comments |
headers
alan.bateman | 16 Nov 2009 19:16
Picon

hg: jdk7/awt/jdk: 6890458: Datatransfer API should not require RMI to be present

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
Permalink | Reply | 0 comments |
headers
Damjan Jovanovic | 17 Nov 2009 16:11
Picon

Re: Review request #2: 6863566 (Java should support the freedesktop.org startup notification specification)

On Wed, Nov 11, 2009 at 11:31 AM, Dmitry Cherepanov
<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
(Continue reading)

Permalink | Reply | 4 comments |

Gmane