From peter.zhelezniakov at sun.com  Mon Sep  1 11:22:37 2008
From: peter.zhelezniakov at sun.com (peter.zhelezniakov at sun.com)
Date: Mon, 01 Sep 2008 11:22:37 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 5062055: JEditorPane HTML: HR-tag
	with attribute	size=1px causes NumberFormatException
Message-ID: <20080901112249.23344DFD0@hg.openjdk.java.net>

Changeset: 291feed36076
Author:    peterz
Date:      2008-09-01 15:21 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/291feed36076

5062055: JEditorPane HTML: HR-tag with attribute size=1px causes NumberFormatException
Summary: Wrapped parseInt() with try/catch
Reviewed-by: gsm

! src/share/classes/javax/swing/text/html/HRuleView.java
+ test/javax/swing/text/html/HRuleView/Test5062055.java



From sergey.malenkov at sun.com  Mon Sep  1 13:34:58 2008
From: sergey.malenkov at sun.com (sergey.malenkov at sun.com)
Date: Mon, 01 Sep 2008 13:34:58 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 5026703: RFE: DOC: Are
	PropertyChangeSupport &	VetoableChangeSupport Thread-Safe?
	--Docs Should Say
Message-ID: <20080901133509.B0A6DD007@hg.openjdk.java.net>

Changeset: 71df74bef5ba
Author:    malenkov
Date:      2008-09-01 17:36 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/71df74bef5ba

5026703: RFE: DOC: Are PropertyChangeSupport & VetoableChangeSupport Thread-Safe? --Docs Should Say
Reviewed-by: peterz, rupashka

! src/share/classes/java/beans/PropertyChangeSupport.java
! src/share/classes/java/beans/VetoableChangeSupport.java



From sergey.malenkov at sun.com  Wed Sep  3 17:05:35 2008
From: sergey.malenkov at sun.com (sergey.malenkov at sun.com)
Date: Wed, 03 Sep 2008 17:05:35 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6397609: DOC: De-register API
	required for	PropertyEditorManager and/or doc change
Message-ID: <20080903170555.705AFD169@hg.openjdk.java.net>

Changeset: 9765266e5aea
Author:    malenkov
Date:      2008-09-03 21:00 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/9765266e5aea

6397609: DOC: De-register API required for PropertyEditorManager and/or doc change
Reviewed-by: peterz, rupashka

+ src/share/classes/com/sun/beans/WeakCache.java
! src/share/classes/java/beans/PropertyEditorManager.java
+ test/java/beans/PropertyEditor/MemoryClassLoader.java
+ test/java/beans/PropertyEditor/Test6397609.java
! test/java/beans/PropertyEditor/TestEditor.java



From fbrunnerlist at gmx.ch  Thu Sep  4 07:36:39 2008
From: fbrunnerlist at gmx.ch (Florian Brunner)
Date: Thu, 4 Sep 2008 09:36:39 +0200
Subject: <Swing Dev> Compilation problems
In-Reply-To: <200808311514.01346.fbrunnerlist@gmx.ch>
References: <200808311514.01346.fbrunnerlist@gmx.ch>
Message-ID: <200809040936.39270.fbrunnerlist@gmx.ch>

Can anybody help me? Thanks

-Florian

Am Sonntag, 31. August 2008 schrieb Florian Brunner:
> Hi,
>
> I cloned the repository http://hg.openjdk.java.net/jdk7/swing/jdk but I
> get "cannot find symbol" errors. (eg. sun.awt.EventQueueDelegate in
> com.sun.java.swing.SwingUtilities3) when compiling the Swing project (I use
> NetBeans 6.1).
>
> I tried with the binary build of the jdk7 version b32, b33 and b34.
>
> How can I build the Swing sources?
>
> -Florian




From pavel.porvatov at sun.com  Thu Sep  4 11:20:45 2008
From: pavel.porvatov at sun.com (pavel.porvatov at sun.com)
Date: Thu, 04 Sep 2008 11:20:45 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6278700: JSlider created with
	BoundedRangeModel	fires twice when changed
Message-ID: <20080904112105.AAC52D1DF@hg.openjdk.java.net>

Changeset: 2055acc62a85
Author:    rupashka
Date:      2008-09-04 15:15 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/2055acc62a85

6278700: JSlider created with BoundedRangeModel fires twice when changed
Summary: Removed second registration of listener
Reviewed-by: peterz

! src/share/classes/javax/swing/JSlider.java
+ test/javax/swing/JSlider/6278700/bug6278700.java



From Pavel.Porvatov at Sun.COM  Fri Sep  5 12:09:34 2008
From: Pavel.Porvatov at Sun.COM (Pavel Porvatov)
Date: Fri, 05 Sep 2008 16:09:34 +0400
Subject: <Swing Dev> Compilation problems
In-Reply-To: <200809040936.39270.fbrunnerlist@gmx.ch>
References: <200808311514.01346.fbrunnerlist@gmx.ch>
	<200809040936.39270.fbrunnerlist@gmx.ch>
Message-ID: <48C1217E.1080309@sun.com>

Hi Florian,

I've cloned the repository http://hg.openjdk.java.net/jdk7/swing/jdk 
today and built jdk without problems. Do you have 
\src\share\classes\sun\awt\EventQueueDelegate.java in your repository?

Regards, Pavel.

> Can anybody help me? Thanks
> 
> -Florian
> 
> Am Sonntag, 31. August 2008 schrieb Florian Brunner:
>> Hi,
>>
>> I cloned the repository http://hg.openjdk.java.net/jdk7/swing/jdk but I
>> get "cannot find symbol" errors. (eg. sun.awt.EventQueueDelegate in
>> com.sun.java.swing.SwingUtilities3) when compiling the Swing project (I use
>> NetBeans 6.1).
>>
>> I tried with the binary build of the jdk7 version b32, b33 and b34.
>>
>> How can I build the Swing sources?
>>
>> -Florian
> 
> 



From roman.kennke at aicas.com  Fri Sep  5 18:55:05 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Fri, 05 Sep 2008 20:55:05 +0200
Subject: <Swing Dev> [PATCH] SwingUtilities2.isLocalDisplay()
Message-ID: <1220640905.6422.43.camel@moonlight>

Hi there,

I've just synced up the Cacio forest with the JDK7 master forest, and
I'd like to discuss and try to merge back (into JDK7) some of our
patches. The following one affects all of AWT, Swing and J2D, this is
why I'm posting it to 3 lists at once.

In SwingUtilities2.isLocalDisplay(), we have some crazy platform
specific code to find if we have a local display or not. This is of
course not very nice for other Toolkit implementations than the Win32
and X11 ones in OpenJDK. Our solution is to introduce an abstract method
isLocalDisplay() in SunGraphicsEnvironment, which we call from
SwingUtilities2. This method is then overridden by the specific GE
implementations. If we don't have a SGE, we assume a local display.

There are also some changes in the native font code, which used to call
the static X11GraphicsEnvironment.isLocalDisplay(), to call the new
instance method in SGE.

What do you think? Is this reasonable to merge into mainline?

/Roman

-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt
-------------- next part --------------
# HG changeset patch
# User Mario Torre <mario.torre at aicas.com>
# Date 1217450571 -7200
# Node ID f3ae1241a9b87efec5e22618dcf978ae38c94abd
# Parent  9e3c020a78dd72dcbcc8580762f2542055110e2e
imported patch j2d-localdisplay.patch

diff -r 9e3c020a78dd -r f3ae1241a9b8 src/share/classes/sun/java2d/SunGraphicsEnvironment.java
--- a/src/share/classes/sun/java2d/SunGraphicsEnvironment.java	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/share/classes/sun/java2d/SunGraphicsEnvironment.java	Wed Jul 30 22:42:51 2008 +0200
@@ -1270,6 +1270,13 @@
         displayChanger.notifyPaletteChanged();
     }
 
+    /**
+     * Returns true when the display is local, false for remote displays.
+     *
+     * @return true when the display is local, false for remote displays
+     */
+    public abstract boolean isDisplayLocal();
+
     /*
      * ----DISPLAY CHANGE SUPPORT----
      */
diff -r 9e3c020a78dd -r f3ae1241a9b8 src/share/classes/sun/swing/SwingUtilities2.java
--- a/src/share/classes/sun/swing/SwingUtilities2.java	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/share/classes/sun/swing/SwingUtilities2.java	Wed Jul 30 22:42:51 2008 +0200
@@ -55,6 +55,7 @@
 import java.util.*;
 import sun.font.FontDesignMetrics;
 import sun.font.FontManager;
+import sun.java2d.SunGraphicsEnvironment;
 
 import java.util.concurrent.Callable;
 import java.util.concurrent.Future;
@@ -1482,22 +1483,14 @@
      * appear capable of performing gamma correction needed for LCD text.
      */
     public static boolean isLocalDisplay() {
-        try {
-            // On Windows just return true. Permission to read os.name
-            // is granted to all code but wrapped in try to be safe.
-            if (OSInfo.getOSType() == OSInfo.OSType.WINDOWS) {
-                return true;
-            }
-            // Else probably Solaris or Linux in which case may be remote X11
-            Class x11Class = Class.forName("sun.awt.X11GraphicsEnvironment");
-            Method isDisplayLocalMethod = x11Class.getMethod(
-                      "isDisplayLocal", new Class[0]);
-            return (Boolean)isDisplayLocalMethod.invoke(null, (Object[])null);
-        } catch (Throwable t) {
+        boolean isLocal;
+        GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
+        if (ge instanceof SunGraphicsEnvironment) {
+            isLocal = ((SunGraphicsEnvironment) ge).isDisplayLocal();
+        } else {
+            isLocal = true;
         }
-        // If we get here we're most likely being run on some other O/S
-        // or we didn't properly detect Windows.
-        return true;
+        return isLocal;
     }
 
     /**
diff -r 9e3c020a78dd -r f3ae1241a9b8 src/solaris/classes/sun/awt/X11GraphicsEnvironment.java
--- a/src/solaris/classes/sun/awt/X11GraphicsEnvironment.java	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/solaris/classes/sun/awt/X11GraphicsEnvironment.java	Wed Jul 30 22:42:51 2008 +0200
@@ -208,7 +208,7 @@
     private static native int checkShmExt();
 
     private static  native String getDisplayString();
-    private static Boolean isDisplayLocal;
+    private Boolean isDisplayLocal;
 
     /**
      * This should only be called from the static initializer, so no need for
@@ -233,7 +233,7 @@
         return getScreenDevices()[getDefaultScreenNum()];
     }
 
-    public static boolean isDisplayLocal() {
+    public boolean isDisplayLocal() {
         if (isDisplayLocal == null) {
             SunToolkit.awtLock();
             try {
diff -r 9e3c020a78dd -r f3ae1241a9b8 src/solaris/native/sun/awt/fontpath.c
--- a/src/solaris/native/sun/awt/fontpath.c	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/solaris/native/sun/awt/fontpath.c	Wed Jul 30 22:42:51 2008 +0200
@@ -150,15 +150,26 @@
     static jboolean isLocalSet = False;
     jboolean ret;
 
-    if (isLocalSet) {
-        return isLocal;
+    if (! isLocalSet) {
+      jclass geCls = (*env)->FindClass(env, "java/awt/GraphicsEnvironment");
+      jmethodID getLocalGE = (*env)->GetStaticMethodID(env, geCls,
+                                                 "getLocalGraphicsEnvironment",
+                                           "()Ljava/awt/GraphicsEnvironment;");
+      jobject ge = (*env)->CallStaticObjectMethod(env, geCls, getLocalGE);
+
+      jclass sgeCls = (*env)->FindClass(env,
+                                        "sun/java2d/SunGraphicsEnvironment");
+      if ((*env)->IsInstanceOf(env, ge, sgeCls)) {
+        jmethodID isDisplayLocal = (*env)->GetMethodID(env, sgeCls,
+                                                       "isDisplayLocal",
+                                                       "()Z");
+        isLocal = (*env)->CallBooleanMethod(env, ge, isDisplayLocal);
+      } else {
+        isLocal = True;
+      }
+      isLocalSet = True;
     }
 
-    isLocal = JNU_CallStaticMethodByName(env, NULL,
-                                         "sun/awt/X11GraphicsEnvironment",
-                                         "isDisplayLocal",
-                                         "()Z").z;
-    isLocalSet = True;
     return isLocal;
 }
 
diff -r 9e3c020a78dd -r f3ae1241a9b8 src/windows/classes/sun/awt/Win32GraphicsEnvironment.java
--- a/src/windows/classes/sun/awt/Win32GraphicsEnvironment.java	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/windows/classes/sun/awt/Win32GraphicsEnvironment.java	Wed Jul 30 22:42:51 2008 +0200
@@ -346,4 +346,8 @@
 
         return new WFontConfiguration(this, preferLocaleFonts,preferPropFonts);
     }
+
+    public boolean isDisplayLocal() {
+        return true;
+    }
 }

From Dmitri.Trembovetski at Sun.COM  Fri Sep  5 20:25:25 2008
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Fri, 05 Sep 2008 13:25:25 -0700
Subject: <Swing Dev> [OpenJDK 2D-Dev] [PATCH]
	SwingUtilities2.isLocalDisplay()
In-Reply-To: <1220640905.6422.43.camel@moonlight>
References: <1220640905.6422.43.camel@moonlight>
Message-ID: <48C195B5.2010205@Sun.COM>


   Hi Roman,

   the patch looks reasonable to me.

   Thanks,
     Dmitri


Roman Kennke wrote:
> Hi there,
> 
> I've just synced up the Cacio forest with the JDK7 master forest, and
> I'd like to discuss and try to merge back (into JDK7) some of our
> patches. The following one affects all of AWT, Swing and J2D, this is
> why I'm posting it to 3 lists at once.
> 
> In SwingUtilities2.isLocalDisplay(), we have some crazy platform
> specific code to find if we have a local display or not. This is of
> course not very nice for other Toolkit implementations than the Win32
> and X11 ones in OpenJDK. Our solution is to introduce an abstract method
> isLocalDisplay() in SunGraphicsEnvironment, which we call from
> SwingUtilities2. This method is then overridden by the specific GE
> implementations. If we don't have a SGE, we assume a local display.
> 
> There are also some changes in the native font code, which used to call
> the static X11GraphicsEnvironment.isLocalDisplay(), to call the new
> instance method in SGE.
> 
> What do you think? Is this reasonable to merge into mainline?
> 
> /Roman
> 
> 


From roman.kennke at aicas.com  Sat Sep  6 09:04:01 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Sat, 06 Sep 2008 11:04:01 +0200
Subject: <Swing Dev> <AWT Dev> [PATCH] SwingUtilities2.isLocalDisplay()
In-Reply-To: <271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
Message-ID: <1220691841.6571.22.camel@moonlight>

Hi Oleg,

> I'm not the person who is supposed to review this changes from
> technical point of view,
> but I have one concern about idea of the fix.  It adds one more place
> where Swing uses sun-specific API.

No. It takes advantage of Sun internal API, but it does not depend on
it. (if (ge instanceof SunGraphicsEnvironment)  { doSomethingCool(); }
else { useReasonableDefault(); } ).

> Of course you can say that SwingUtilities2.isLocalDisplay() even
> before your fix uses code which is specific
> for Sun's implementation, and you will be right.  But this doesn't
> mean that we should leave with this.
> IMHO, if we change such code we should remove dependency between Swing
> and Sun-specific code,
> i.e. we should add public API.

I completely agree. That, of course, would be the best solution. But in
the past it has been communicated several times to me that I can't just
send in patches to public API and hope that it will be accepted easily.
I propose to get in this patch if possible first, then start a
discussion about adding public API.

/Roman

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



From fbrunnerlist at gmx.ch  Sat Sep  6 10:53:06 2008
From: fbrunnerlist at gmx.ch (Florian Brunner)
Date: Sat, 6 Sep 2008 12:53:06 +0200
Subject: <Swing Dev> Compilation problems
In-Reply-To: <48C1217E.1080309@sun.com>
References: <200808311514.01346.fbrunnerlist@gmx.ch>
	<200809040936.39270.fbrunnerlist@gmx.ch> <48C1217E.1080309@sun.com>
Message-ID: <200809061253.06641.fbrunnerlist@gmx.ch>

Hi Pavel,

yes, that class is there. Note however that I would like to build the Swing 
project only. Some months ago this was possible using a binary version of 
jdk7 and the make/netbeans/swing project. Then I usually could just use the 
IDEs context menu and call "Clean and Build". This seems not to be possible 
anymore. I tried to manipulate the build.properties file by once 
adding "sun/awt/" and once replacing "sun/swing/" with "sun/" in the value 
of "includes". Both times I got various other errors, though.

Could somebody fix this or tell me how I can easily build the Swing (or the 
whole JDK) project?

Against which build of the jdk should the Swing project compile? The latest 
jdk version is b34 but at http://hg.openjdk.java.net/jdk7/swing/jdk the last 
tag is "jdk7-b32".

Thanks for your help.

-Florian


Am Freitag, 5. September 2008 schrieb Pavel Porvatov:
> Hi Florian,
>
> I've cloned the repository http://hg.openjdk.java.net/jdk7/swing/jdk
> today and built jdk without problems. Do you have
> \src\share\classes\sun\awt\EventQueueDelegate.java in your repository?
>
> Regards, Pavel.
>
> > Can anybody help me? Thanks
> >
> > -Florian
> >
> > Am Sonntag, 31. August 2008 schrieb Florian Brunner:
> >> Hi,
> >>
> >> I cloned the repository http://hg.openjdk.java.net/jdk7/swing/jdk but I
> >> get "cannot find symbol" errors. (eg. sun.awt.EventQueueDelegate in
> >> com.sun.java.swing.SwingUtilities3) when compiling the Swing project (I
> >> use NetBeans 6.1).
> >>
> >> I tried with the binary build of the jdk7 version b32, b33 and b34.
> >>
> >> How can I build the Swing sources?
> >>
> >> -Florian




From yuka.kamiya at sun.com  Mon Sep  8 01:52:00 2008
From: yuka.kamiya at sun.com (yuka.kamiya at sun.com)
Date: Mon, 08 Sep 2008 01:52:00 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6665028: native code of
	method	j*.text.Bidi.nativeBidiChars is using the contents of
	a	primitive array direct
Message-ID: <20080908015226.019FAD497@hg.openjdk.java.net>

Changeset: 77dc7ca7879f
Author:    peytoia
Date:      2008-09-08 10:44 +0900
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/77dc7ca7879f

6665028: native code of method j*.text.Bidi.nativeBidiChars is using the contents of a primitive array direct
Reviewed-by: okutsu

! src/share/native/sun/font/bidi/ubidi.c
+ test/java/text/Bidi/Bug6665028.java



From yuka.kamiya at sun.com  Mon Sep  8 02:54:12 2008
From: yuka.kamiya at sun.com (yuka.kamiya at sun.com)
Date: Mon, 08 Sep 2008 02:54:12 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6607310: InputContext may cause
	loading of swing	classes even for non-Swing applets
Message-ID: <20080908025430.9EE4ED49E@hg.openjdk.java.net>

Changeset: 3d8640f597b2
Author:    peytoia
Date:      2008-09-08 11:49 +0900
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/3d8640f597b2

6607310: InputContext may cause loading of swing classes even for non-Swing applets
Reviewed-by: okutsu

! src/share/classes/sun/awt/im/CompositionArea.java
! src/share/classes/sun/awt/im/InputContext.java



From yuka.kamiya at sun.com  Mon Sep  8 04:36:52 2008
From: yuka.kamiya at sun.com (yuka.kamiya at sun.com)
Date: Mon, 08 Sep 2008 04:36:52 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6645292: [Fmt-Da] Timezone Western
	Summer Time	(Australia) is parsed incorrectly
Message-ID: <20080908043719.EFEFAD4A5@hg.openjdk.java.net>

Changeset: 9b8e20a3c5f0
Author:    peytoia
Date:      2008-09-08 13:31 +0900
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/9b8e20a3c5f0

6645292: [Fmt-Da] Timezone Western Summer Time (Australia) is parsed incorrectly
Reviewed-by: okutsu

! src/share/classes/java/text/SimpleDateFormat.java
+ test/java/text/Format/DateFormat/Bug6645292.java



From yuka.kamiya at sun.com  Mon Sep  8 05:34:59 2008
From: yuka.kamiya at sun.com (yuka.kamiya at sun.com)
Date: Mon, 08 Sep 2008 05:34:59 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 4823811: [Fmt-Da] SimpleDateFormat
	patterns don't	allow embedding of some literal punctuation
Message-ID: <20080908053518.B810DD4AC@hg.openjdk.java.net>

Changeset: 1b0b3a777a6c
Author:    peytoia
Date:      2008-09-08 14:31 +0900
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/1b0b3a777a6c

4823811: [Fmt-Da] SimpleDateFormat patterns don't allow embedding of some literal punctuation
Reviewed-by: okutsu

! src/share/classes/java/text/SimpleDateFormat.java
+ test/java/text/Format/DateFormat/Bug4823811.java



From yuka.kamiya at sun.com  Mon Sep  8 05:53:06 2008
From: yuka.kamiya at sun.com (yuka.kamiya at sun.com)
Date: Mon, 08 Sep 2008 05:53:06 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6650748: (tz) Java runtime doesn't
	detect VET	time zone correctly on Windows
Message-ID: <20080908055325.EA6C9D4B3@hg.openjdk.java.net>

Changeset: 21346d9b372a
Author:    peytoia
Date:      2008-09-08 14:48 +0900
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/21346d9b372a

6650748: (tz) Java runtime doesn't detect VET time zone correctly on Windows
Reviewed-by: okutsu

! src/windows/lib/tzmappings



From yuka.kamiya at sun.com  Mon Sep  8 06:27:15 2008
From: yuka.kamiya at sun.com (yuka.kamiya at sun.com)
Date: Mon, 08 Sep 2008 06:27:15 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6466476: (tz) Introduction of
	tzdata2005r can	introduce incompatility issues with some
	JDK1.1 3-letter TZ Ids
Message-ID: <20080908062735.8885AD4C1@hg.openjdk.java.net>

Changeset: 67c41d740e6d
Author:    peytoia
Date:      2008-09-08 15:21 +0900
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/67c41d740e6d

6466476: (tz) Introduction of tzdata2005r can introduce incompatility issues with some JDK1.1 3-letter TZ Ids
Reviewed-by: okutsu

! make/java/java/FILES_java.gmk
+ src/share/classes/sun/util/calendar/TzIDOldMapping.java
! src/share/classes/sun/util/calendar/ZoneInfo.java
+ test/java/util/TimeZone/OldIDMappingTest.java
+ test/java/util/TimeZone/OldIDMappingTest.sh



From son.two at gmail.com  Sat Sep  6 04:07:15 2008
From: son.two at gmail.com (Oleg Sukhodolsky)
Date: Sat, 6 Sep 2008 08:07:15 +0400
Subject: <Swing Dev> <AWT Dev> [PATCH] SwingUtilities2.isLocalDisplay()
In-Reply-To: <1220640905.6422.43.camel@moonlight>
References: <1220640905.6422.43.camel@moonlight>
Message-ID: <271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>

I'm not the person who is supposed to review this changes from
technical point of view,
but I have one concern about idea of the fix.  It adds one more place
where Swing uses sun-specific API.
Of course you can say that SwingUtilities2.isLocalDisplay() even
before your fix uses code which is specific
for Sun's implementation, and you will be right.  But this doesn't
mean that we should leave with this.
IMHO, if we change such code we should remove dependency between Swing
and Sun-specific code,
i.e. we should add public API.

Regards, Oleg.

On Fri, Sep 5, 2008 at 10:55 PM, Roman Kennke <roman.kennke at aicas.com> wrote:
> Hi there,
>
> I've just synced up the Cacio forest with the JDK7 master forest, and
> I'd like to discuss and try to merge back (into JDK7) some of our
> patches. The following one affects all of AWT, Swing and J2D, this is
> why I'm posting it to 3 lists at once.
>
> In SwingUtilities2.isLocalDisplay(), we have some crazy platform
> specific code to find if we have a local display or not. This is of
> course not very nice for other Toolkit implementations than the Win32
> and X11 ones in OpenJDK. Our solution is to introduce an abstract method
> isLocalDisplay() in SunGraphicsEnvironment, which we call from
> SwingUtilities2. This method is then overridden by the specific GE
> implementations. If we don't have a SGE, we assume a local display.
>
> There are also some changes in the native font code, which used to call
> the static X11GraphicsEnvironment.isLocalDisplay(), to call the new
> instance method in SGE.
>
> What do you think? Is this reasonable to merge into mainline?
>
> /Roman
>
> --
> Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
> aicas Allerton Interworks Computer Automated Systems GmbH
> Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
> http://www.aicas.com   * Tel: +49-721-663 968-48
> USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
> Gesch?ftsf?hrer: Dr. James J. Hunt
>

From yuka.kamiya at sun.com  Mon Sep  8 08:43:00 2008
From: yuka.kamiya at sun.com (yuka.kamiya at sun.com)
Date: Mon, 08 Sep 2008 08:43:00 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6730743: (tz) Support tzdata2008e
Message-ID: <20080908084319.9A1FDD4F4@hg.openjdk.java.net>

Changeset: 66b0b1231530
Author:    peytoia
Date:      2008-09-08 17:35 +0900
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/66b0b1231530

6730743: (tz) Support tzdata2008e
Reviewed-by: okutsu

! make/sun/javazic/tzdata/VERSION
! make/sun/javazic/tzdata/africa
! make/sun/javazic/tzdata/asia
! make/sun/javazic/tzdata/australasia
! make/sun/javazic/tzdata/backward
! make/sun/javazic/tzdata/europe
! make/sun/javazic/tzdata/iso3166.tab
! make/sun/javazic/tzdata/leapseconds
! make/sun/javazic/tzdata/northamerica
! make/sun/javazic/tzdata/southamerica
! make/sun/javazic/tzdata/zone.tab
! src/share/classes/sun/util/resources/TimeZoneNames.java
! src/share/classes/sun/util/resources/TimeZoneNames_de.java
! src/share/classes/sun/util/resources/TimeZoneNames_es.java
! src/share/classes/sun/util/resources/TimeZoneNames_fr.java
! src/share/classes/sun/util/resources/TimeZoneNames_it.java
! src/share/classes/sun/util/resources/TimeZoneNames_ja.java
! src/share/classes/sun/util/resources/TimeZoneNames_ko.java
! src/share/classes/sun/util/resources/TimeZoneNames_sv.java
! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java
! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java



From Pavel.Porvatov at Sun.COM  Mon Sep  8 08:46:13 2008
From: Pavel.Porvatov at Sun.COM (Pavel Porvatov)
Date: Mon, 08 Sep 2008 12:46:13 +0400
Subject: <Swing Dev> Compilation problems
In-Reply-To: <200809061253.06641.fbrunnerlist@gmx.ch>
References: <200808311514.01346.fbrunnerlist@gmx.ch>
	<200809040936.39270.fbrunnerlist@gmx.ch> <48C1217E.1080309@sun.com>
	<200809061253.06641.fbrunnerlist@gmx.ch>
Message-ID: <48C4E655.70607@sun.com>

Hi Florian,

I don't know info about the make/netbeans/swing project. But as I 
understand you have an old build of jdk and it's the main problem.
Sometimes (when there are a lot of changes in repository) you have to 
rebuild WHOLE jdk (or get a fresh build).

Here are some ideas:
1. Build schedule is here:
http://openjdk.java.net/projects/jdk7/builds/
So, a fresh build will be available at 2008/09/11.

2. You can try to modify your netbeans project for rebuild whole jdk

3. You can try to rebuild jdk without netbeans project. Info about this 
process is available in the make/README-builds.html file.

Regards, Pavel.

> Hi Pavel,
> 
> yes, that class is there. Note however that I would like to build the Swing 
> project only. Some months ago this was possible using a binary version of 
> jdk7 and the make/netbeans/swing project. Then I usually could just use the 
> IDEs context menu and call "Clean and Build". This seems not to be possible 
> anymore. I tried to manipulate the build.properties file by once 
> adding "sun/awt/" and once replacing "sun/swing/" with "sun/" in the value 
> of "includes". Both times I got various other errors, though.
> 
> Could somebody fix this or tell me how I can easily build the Swing (or the 
> whole JDK) project?
> 
> Against which build of the jdk should the Swing project compile? The latest 
> jdk version is b34 but at http://hg.openjdk.java.net/jdk7/swing/jdk the last 
> tag is "jdk7-b32".
> 
> Thanks for your help.
> 
> -Florian
> 
> 
> Am Freitag, 5. September 2008 schrieb Pavel Porvatov:
>> Hi Florian,
>>
>> I've cloned the repository http://hg.openjdk.java.net/jdk7/swing/jdk
>> today and built jdk without problems. Do you have
>> \src\share\classes\sun\awt\EventQueueDelegate.java in your repository?
>>
>> Regards, Pavel.
>>
>>> Can anybody help me? Thanks
>>>
>>> -Florian
>>>
>>> Am Sonntag, 31. August 2008 schrieb Florian Brunner:
>>>> Hi,
>>>>
>>>> I cloned the repository http://hg.openjdk.java.net/jdk7/swing/jdk but I
>>>> get "cannot find symbol" errors. (eg. sun.awt.EventQueueDelegate in
>>>> com.sun.java.swing.SwingUtilities3) when compiling the Swing project (I
>>>> use NetBeans 6.1).
>>>>
>>>> I tried with the binary build of the jdk7 version b32, b33 and b34.
>>>>
>>>> How can I build the Swing sources?
>>>>
>>>> -Florian
> 
> 



From Alexander.Potochkin at Sun.COM  Mon Sep  8 13:03:27 2008
From: Alexander.Potochkin at Sun.COM (Alexander Potochkin)
Date: Mon, 08 Sep 2008 17:03:27 +0400
Subject: <Swing Dev> Compilation problems
In-Reply-To: <200809061253.06641.fbrunnerlist@gmx.ch>
References: <200808311514.01346.fbrunnerlist@gmx.ch>
	<200809040936.39270.fbrunnerlist@gmx.ch> <48C1217E.1080309@sun.com>
	<200809061253.06641.fbrunnerlist@gmx.ch>
Message-ID: <48C5229F.4020402@sun.com>

Hello Florian

Have you read this FAQ
http://hg.openjdk.java.net/jdk7/2d/raw-file/8a275f439862/README-builds.html

there also some blogs about building OpenJDK can be found in the internet

I am not sure it is possible to build the Swing only
I would try to build the whole JDK project

Thanks
alexp

> Hi Pavel,
> 
> yes, that class is there. Note however that I would like to build the Swing 
> project only. Some months ago this was possible using a binary version of 
> jdk7 and the make/netbeans/swing project. Then I usually could just use the 
> IDEs context menu and call "Clean and Build". This seems not to be possible 
> anymore. I tried to manipulate the build.properties file by once 
> adding "sun/awt/" and once replacing "sun/swing/" with "sun/" in the value 
> of "includes". Both times I got various other errors, though.
> 
> Could somebody fix this or tell me how I can easily build the Swing (or the 
> whole JDK) project?
> 
> Against which build of the jdk should the Swing project compile? The latest 
> jdk version is b34 but at http://hg.openjdk.java.net/jdk7/swing/jdk the last 
> tag is "jdk7-b32".
> 
> Thanks for your help.
> 
> -Florian
> 
> 
> Am Freitag, 5. September 2008 schrieb Pavel Porvatov:
>> Hi Florian,
>>
>> I've cloned the repository http://hg.openjdk.java.net/jdk7/swing/jdk
>> today and built jdk without problems. Do you have
>> \src\share\classes\sun\awt\EventQueueDelegate.java in your repository?
>>
>> Regards, Pavel.
>>
>>> Can anybody help me? Thanks
>>>
>>> -Florian
>>>
>>> Am Sonntag, 31. August 2008 schrieb Florian Brunner:
>>>> Hi,
>>>>
>>>> I cloned the repository http://hg.openjdk.java.net/jdk7/swing/jdk but I
>>>> get "cannot find symbol" errors. (eg. sun.awt.EventQueueDelegate in
>>>> com.sun.java.swing.SwingUtilities3) when compiling the Swing project (I
>>>> use NetBeans 6.1).
>>>>
>>>> I tried with the binary build of the jdk7 version b32, b33 and b34.
>>>>
>>>> How can I build the Swing sources?
>>>>
>>>> -Florian
> 
> 



From roman.kennke at aicas.com  Mon Sep  8 19:04:33 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Mon, 08 Sep 2008 21:04:33 +0200
Subject: <Swing Dev> <AWT Dev> [PATCH] SwingUtilities2.isLocalDisplay()
In-Reply-To: <271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
Message-ID: <1220900673.7112.25.camel@moonlight>

Hi Oleg and lists,

> >> I'm not the person who is supposed to review this changes from
> >> technical point of view,
> >> but I have one concern about idea of the fix.  It adds one more place
> >> where Swing uses sun-specific API.
> >
> > No. It takes advantage of Sun internal API, but it does not depend on
> > it. (if (ge instanceof SunGraphicsEnvironment)  { doSomethingCool(); }
> > else { useReasonableDefault(); } ).
> 
> it uses Sun-specific class, so this code can not be compiled by JDK
> from another vendor :(

Ehe :-) Try compiling Swing on any JDK from another vendor! Good luck!
(Ok, the Caciocavallo project will certainly help alot, but we are still
very far away from such a portable Swing).

> >> Of course you can say that SwingUtilities2.isLocalDisplay() even
> >> before your fix uses code which is specific
> >> for Sun's implementation, and you will be right.  But this doesn't
> >> mean that we should leave with this.
> >> IMHO, if we change such code we should remove dependency between Swing
> >> and Sun-specific code,
> >> i.e. we should add public API.
> >
> > I completely agree. That, of course, would be the best solution. But in
> > the past it has been communicated several times to me that I can't just
> > send in patches to public API and hope that it will be accepted easily.
> > I propose to get in this patch if possible first, then start a
> > discussion about adding public API.
> 
> I understand your point, but I have a feeling that we you will not
> start the discussion right now,
> the idea of new API may be lost :(  So, I'd suggest to try one more time ;)

Ok, so here we go. This patch is slightly modified, the isDisplayLocal()
method is now declared in GraphicsEnvironment, with the addition of
throwing a HeadlessException in the headless case. Also, in fontpath.c,
we don't call isDisplayLocal(), but instead call _isDisplayLocal(). We
call it on X11GraphicsEnvironment only. In my original patch I tried to
be more portable by calling
GraphicsEnvironment.getLocalGraphicsEnvironment().isDisplayLocal(), but
this resulted in an initialization loop (this code is very sensible to
this kind of problem). I left that out for now, because fontpath.c is
X11 specific anyway, and a real solution will come soon in the form of a
huge FontManager patch :-)

What do you think? Can we add this API to GE?

/Roman

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



From roman.kennke at aicas.com  Mon Sep  8 19:11:14 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Mon, 08 Sep 2008 21:11:14 +0200
Subject: <Swing Dev> [PATCH] SwingUtilities2.isLocalDisplay()
In-Reply-To: <1220900673.7112.25.camel@moonlight>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
	<1220900673.7112.25.camel@moonlight>
Message-ID: <1220901074.7112.27.camel@moonlight>

Bah, forgot the actual patch. Here it comes now!

/Roman

Am Montag, den 08.09.2008, 21:04 +0200 schrieb Roman Kennke:
> Hi Oleg and lists,
> 
> > >> I'm not the person who is supposed to review this changes from
> > >> technical point of view,
> > >> but I have one concern about idea of the fix.  It adds one more place
> > >> where Swing uses sun-specific API.
> > >
> > > No. It takes advantage of Sun internal API, but it does not depend on
> > > it. (if (ge instanceof SunGraphicsEnvironment)  { doSomethingCool(); }
> > > else { useReasonableDefault(); } ).
> > 
> > it uses Sun-specific class, so this code can not be compiled by JDK
> > from another vendor :(
> 
> Ehe :-) Try compiling Swing on any JDK from another vendor! Good luck!
> (Ok, the Caciocavallo project will certainly help alot, but we are still
> very far away from such a portable Swing).
> 
> > >> Of course you can say that SwingUtilities2.isLocalDisplay() even
> > >> before your fix uses code which is specific
> > >> for Sun's implementation, and you will be right.  But this doesn't
> > >> mean that we should leave with this.
> > >> IMHO, if we change such code we should remove dependency between Swing
> > >> and Sun-specific code,
> > >> i.e. we should add public API.
> > >
> > > I completely agree. That, of course, would be the best solution. But in
> > > the past it has been communicated several times to me that I can't just
> > > send in patches to public API and hope that it will be accepted easily.
> > > I propose to get in this patch if possible first, then start a
> > > discussion about adding public API.
> > 
> > I understand your point, but I have a feeling that we you will not
> > start the discussion right now,
> > the idea of new API may be lost :(  So, I'd suggest to try one more time ;)
> 
> Ok, so here we go. This patch is slightly modified, the isDisplayLocal()
> method is now declared in GraphicsEnvironment, with the addition of
> throwing a HeadlessException in the headless case. Also, in fontpath.c,
> we don't call isDisplayLocal(), but instead call _isDisplayLocal(). We
> call it on X11GraphicsEnvironment only. In my original patch I tried to
> be more portable by calling
> GraphicsEnvironment.getLocalGraphicsEnvironment().isDisplayLocal(), but
> this resulted in an initialization loop (this code is very sensible to
> this kind of problem). I left that out for now, because fontpath.c is
> X11 specific anyway, and a real solution will come soon in the form of a
> huge FontManager patch :-)
> 
> What do you think? Can we add this API to GE?
> 
> /Roman
> 
-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 4808 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20080908/8cfaf878/patch.txt>

From son.two at gmail.com  Tue Sep  9 03:26:46 2008
From: son.two at gmail.com (Oleg Sukhodolsky)
Date: Tue, 9 Sep 2008 07:26:46 +0400
Subject: <Swing Dev> [PATCH] SwingUtilities2.isLocalDisplay()
In-Reply-To: <1220901074.7112.27.camel@moonlight>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
	<1220900673.7112.25.camel@moonlight>
	<1220901074.7112.27.camel@moonlight>
Message-ID: <271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com>

I'd vote for this API, but it is 2D team who should make the decision.

Oleg.

On Mon, Sep 8, 2008 at 11:11 PM, Roman Kennke <roman.kennke at aicas.com> wrote:
> Bah, forgot the actual patch. Here it comes now!
>
> /Roman
>
> Am Montag, den 08.09.2008, 21:04 +0200 schrieb Roman Kennke:
>> Hi Oleg and lists,
>>
>> > >> I'm not the person who is supposed to review this changes from
>> > >> technical point of view,
>> > >> but I have one concern about idea of the fix.  It adds one more place
>> > >> where Swing uses sun-specific API.
>> > >
>> > > No. It takes advantage of Sun internal API, but it does not depend on
>> > > it. (if (ge instanceof SunGraphicsEnvironment)  { doSomethingCool(); }
>> > > else { useReasonableDefault(); } ).
>> >
>> > it uses Sun-specific class, so this code can not be compiled by JDK
>> > from another vendor :(
>>
>> Ehe :-) Try compiling Swing on any JDK from another vendor! Good luck!
>> (Ok, the Caciocavallo project will certainly help alot, but we are still
>> very far away from such a portable Swing).
>>
>> > >> Of course you can say that SwingUtilities2.isLocalDisplay() even
>> > >> before your fix uses code which is specific
>> > >> for Sun's implementation, and you will be right.  But this doesn't
>> > >> mean that we should leave with this.
>> > >> IMHO, if we change such code we should remove dependency between Swing
>> > >> and Sun-specific code,
>> > >> i.e. we should add public API.
>> > >
>> > > I completely agree. That, of course, would be the best solution. But in
>> > > the past it has been communicated several times to me that I can't just
>> > > send in patches to public API and hope that it will be accepted easily.
>> > > I propose to get in this patch if possible first, then start a
>> > > discussion about adding public API.
>> >
>> > I understand your point, but I have a feeling that we you will not
>> > start the discussion right now,
>> > the idea of new API may be lost :(  So, I'd suggest to try one more time ;)
>>
>> Ok, so here we go. This patch is slightly modified, the isDisplayLocal()
>> method is now declared in GraphicsEnvironment, with the addition of
>> throwing a HeadlessException in the headless case. Also, in fontpath.c,
>> we don't call isDisplayLocal(), but instead call _isDisplayLocal(). We
>> call it on X11GraphicsEnvironment only. In my original patch I tried to
>> be more portable by calling
>> GraphicsEnvironment.getLocalGraphicsEnvironment().isDisplayLocal(), but
>> this resulted in an initialization loop (this code is very sensible to
>> this kind of problem). I left that out for now, because fontpath.c is
>> X11 specific anyway, and a real solution will come soon in the form of a
>> huge FontManager patch :-)
>>
>> What do you think? Can we add this API to GE?
>>
>> /Roman
>>
> --
> Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
> aicas Allerton Interworks Computer Automated Systems GmbH
> Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
> http://www.aicas.com   * Tel: +49-721-663 968-48
> USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
> Gesch?ftsf?hrer: Dr. James J. Hunt
>

From Dmitri.Trembovetski at Sun.COM  Tue Sep  9 18:16:20 2008
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Tue, 09 Sep 2008 11:16:20 -0700
Subject: <Swing Dev> [OpenJDK 2D-Dev] [PATCH]
	SwingUtilities2.isLocalDisplay()
In-Reply-To: <271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
	<1220900673.7112.25.camel@moonlight>
	<1220901074.7112.27.camel@moonlight>
	<271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com>
Message-ID: <48C6BD74.1070705@Sun.COM>


   Hi Oleg, Roman,

   I myself don't think that this API belongs in public.

   It is used by the platform implementation for doing
   specific tasks and is of questionable value for
   general public. Also, it is too platform-specific
   and typically we refrain from adding platform-specific
   APIs to the Java platform.

   How do you think the developers would use it anyway?

   Those developers who know what a "remote display" is -
   which I assume is a minority since most developers never
   leave the Windows world - can detect it themselves if
   they really needed something like this - it's not a
   big deal, just read the DISPLAY env. variable and
   figure it out.

   In the specific case of SwingUtilities I believe they
   only use it to determine whether to enable AA text
   or not. So perhaps that's something that should
   be exposed instead.

   And talking about implementation - if we were to add
   something to this effect to the platform, we'd need
   to go all the way and possibly detect remote desktop
   session on Windows as well. And what about VNC sessions?
   In our current implementation we only care about
   "remote X display" situation, but the developers who
   see this public API could assume otherwise.

   I suggest to fall back to the original Roman's
   patch which just exposed this method in
   SunGraphicsEnvironment.

   Thanks,
     Dmitri

Oleg Sukhodolsky wrote:
> I'd vote for this API, but it is 2D team who should make the decision.
> 
> Oleg.
> 
> On Mon, Sep 8, 2008 at 11:11 PM, Roman Kennke <roman.kennke at aicas.com> wrote:
>> Bah, forgot the actual patch. Here it comes now!
>>
>> /Roman
>>
>> Am Montag, den 08.09.2008, 21:04 +0200 schrieb Roman Kennke:
>>> Hi Oleg and lists,
>>>
>>>>>> I'm not the person who is supposed to review this changes from
>>>>>> technical point of view,
>>>>>> but I have one concern about idea of the fix.  It adds one more place
>>>>>> where Swing uses sun-specific API.
>>>>> No. It takes advantage of Sun internal API, but it does not depend on
>>>>> it. (if (ge instanceof SunGraphicsEnvironment)  { doSomethingCool(); }
>>>>> else { useReasonableDefault(); } ).
>>>> it uses Sun-specific class, so this code can not be compiled by JDK
>>>> from another vendor :(
>>> Ehe :-) Try compiling Swing on any JDK from another vendor! Good luck!
>>> (Ok, the Caciocavallo project will certainly help alot, but we are still
>>> very far away from such a portable Swing).
>>>
>>>>>> Of course you can say that SwingUtilities2.isLocalDisplay() even
>>>>>> before your fix uses code which is specific
>>>>>> for Sun's implementation, and you will be right.  But this doesn't
>>>>>> mean that we should leave with this.
>>>>>> IMHO, if we change such code we should remove dependency between Swing
>>>>>> and Sun-specific code,
>>>>>> i.e. we should add public API.
>>>>> I completely agree. That, of course, would be the best solution. But in
>>>>> the past it has been communicated several times to me that I can't just
>>>>> send in patches to public API and hope that it will be accepted easily.
>>>>> I propose to get in this patch if possible first, then start a
>>>>> discussion about adding public API.
>>>> I understand your point, but I have a feeling that we you will not
>>>> start the discussion right now,
>>>> the idea of new API may be lost :(  So, I'd suggest to try one more time ;)
>>> Ok, so here we go. This patch is slightly modified, the isDisplayLocal()
>>> method is now declared in GraphicsEnvironment, with the addition of
>>> throwing a HeadlessException in the headless case. Also, in fontpath.c,
>>> we don't call isDisplayLocal(), but instead call _isDisplayLocal(). We
>>> call it on X11GraphicsEnvironment only. In my original patch I tried to
>>> be more portable by calling
>>> GraphicsEnvironment.getLocalGraphicsEnvironment().isDisplayLocal(), but
>>> this resulted in an initialization loop (this code is very sensible to
>>> this kind of problem). I left that out for now, because fontpath.c is
>>> X11 specific anyway, and a real solution will come soon in the form of a
>>> huge FontManager patch :-)
>>>
>>> What do you think? Can we add this API to GE?
>>>
>>> /Roman
>>>
>> --
>> Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
>> aicas Allerton Interworks Computer Automated Systems GmbH
>> Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
>> http://www.aicas.com   * Tel: +49-721-663 968-48
>> USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
>> Gesch?ftsf?hrer: Dr. James J. Hunt
>>


From Dmitri.Trembovetski at Sun.COM  Tue Sep  9 22:12:03 2008
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Tue, 09 Sep 2008 15:12:03 -0700
Subject: <Swing Dev> [OpenJDK 2D-Dev] [PATCH]
	SwingUtilities2.isLocalDisplay()
In-Reply-To: <1ccfd1c10809091309q60417565y3303817c4f3bff63@mail.gmail.com>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
	<1220900673.7112.25.camel@moonlight>
	<1220901074.7112.27.camel@moonlight>
	<271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com>
	<48C6BD74.1070705@Sun.COM>
	<1ccfd1c10809091309q60417565y3303817c4f3bff63@mail.gmail.com>
Message-ID: <48C6F4B3.50506@Sun.COM>



Martin Buchholz wrote:
> It's very hard to get these kinds of UI issues right.
> 
> I once tried to configure my xemacs to have less eye candy
> when talking to a "slow" X server by actually timing
> some operation that requires a round trip.
> 
> Note that a method like isLocalDisplay would have the
> wrong semantics for me, because I mostly cared about
> whether I was bottlenecked by VPN.
> 
> This did help me get my work done, but this kind of
> timing-dependent behavior is disconcerting to the user,
> especially if they feel they have no control or do not
> understand the behavior.  It "looks like a bug".
> 
> Will FAQs and bug reports appear
> Q: Sometimes my java app starts up with funky fonts.
> A: Try restarting a few times in a loop, or try setting this magic
> system property:

   http://java.sun.com/javase/6/webnotes/trouble/TSG-Desktop/html/gdlvo.html#gdlwn

   Thanks,
     Dmitri


> 
> Martin
> 
> On Tue, Sep 9, 2008 at 11:16, Dmitri Trembovetski
> <Dmitri.Trembovetski at sun.com> wrote:
>>  Hi Oleg, Roman,
>>
>>  I myself don't think that this API belongs in public.
>>
>>  It is used by the platform implementation for doing
>>  specific tasks and is of questionable value for
>>  general public. Also, it is too platform-specific
>>  and typically we refrain from adding platform-specific
>>  APIs to the Java platform.
>>
>>  How do you think the developers would use it anyway?
>>
>>  Those developers who know what a "remote display" is -
>>  which I assume is a minority since most developers never
>>  leave the Windows world - can detect it themselves if
>>  they really needed something like this - it's not a
>>  big deal, just read the DISPLAY env. variable and
>>  figure it out.
>>
>>  In the specific case of SwingUtilities I believe they
>>  only use it to determine whether to enable AA text
>>  or not. So perhaps that's something that should
>>  be exposed instead.
>>
>>  And talking about implementation - if we were to add
>>  something to this effect to the platform, we'd need
>>  to go all the way and possibly detect remote desktop
>>  session on Windows as well. And what about VNC sessions?
>>  In our current implementation we only care about
>>  "remote X display" situation, but the developers who
>>  see this public API could assume otherwise.
>>
>>  I suggest to fall back to the original Roman's
>>  patch which just exposed this method in
>>  SunGraphicsEnvironment.
>>
>>  Thanks,
>>    Dmitri
>>
>> Oleg Sukhodolsky wrote:
>>> I'd vote for this API, but it is 2D team who should make the decision.
>>>
>>> Oleg.
>>>
>>> On Mon, Sep 8, 2008 at 11:11 PM, Roman Kennke <roman.kennke at aicas.com>
>>> wrote:
>>>> Bah, forgot the actual patch. Here it comes now!
>>>>
>>>> /Roman
>>>>
>>>> Am Montag, den 08.09.2008, 21:04 +0200 schrieb Roman Kennke:
>>>>> Hi Oleg and lists,
>>>>>
>>>>>>>> I'm not the person who is supposed to review this changes from
>>>>>>>> technical point of view,
>>>>>>>> but I have one concern about idea of the fix.  It adds one more place
>>>>>>>> where Swing uses sun-specific API.
>>>>>>> No. It takes advantage of Sun internal API, but it does not depend on
>>>>>>> it. (if (ge instanceof SunGraphicsEnvironment)  { doSomethingCool(); }
>>>>>>> else { useReasonableDefault(); } ).
>>>>>> it uses Sun-specific class, so this code can not be compiled by JDK
>>>>>> from another vendor :(
>>>>> Ehe :-) Try compiling Swing on any JDK from another vendor! Good luck!
>>>>> (Ok, the Caciocavallo project will certainly help alot, but we are still
>>>>> very far away from such a portable Swing).
>>>>>
>>>>>>>> Of course you can say that SwingUtilities2.isLocalDisplay() even
>>>>>>>> before your fix uses code which is specific
>>>>>>>> for Sun's implementation, and you will be right.  But this doesn't
>>>>>>>> mean that we should leave with this.
>>>>>>>> IMHO, if we change such code we should remove dependency between
>>>>>>>> Swing
>>>>>>>> and Sun-specific code,
>>>>>>>> i.e. we should add public API.
>>>>>>> I completely agree. That, of course, would be the best solution. But
>>>>>>> in
>>>>>>> the past it has been communicated several times to me that I can't
>>>>>>> just
>>>>>>> send in patches to public API and hope that it will be accepted
>>>>>>> easily.
>>>>>>> I propose to get in this patch if possible first, then start a
>>>>>>> discussion about adding public API.
>>>>>> I understand your point, but I have a feeling that we you will not
>>>>>> start the discussion right now,
>>>>>> the idea of new API may be lost :(  So, I'd suggest to try one more
>>>>>> time ;)
>>>>> Ok, so here we go. This patch is slightly modified, the isDisplayLocal()
>>>>> method is now declared in GraphicsEnvironment, with the addition of
>>>>> throwing a HeadlessException in the headless case. Also, in fontpath.c,
>>>>> we don't call isDisplayLocal(), but instead call _isDisplayLocal(). We
>>>>> call it on X11GraphicsEnvironment only. In my original patch I tried to
>>>>> be more portable by calling
>>>>> GraphicsEnvironment.getLocalGraphicsEnvironment().isDisplayLocal(), but
>>>>> this resulted in an initialization loop (this code is very sensible to
>>>>> this kind of problem). I left that out for now, because fontpath.c is
>>>>> X11 specific anyway, and a real solution will come soon in the form of a
>>>>> huge FontManager patch :-)
>>>>>
>>>>> What do you think? Can we add this API to GE?
>>>>>
>>>>> /Roman
>>>>>
>>>> --
>>>> Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
>>>> aicas Allerton Interworks Computer Automated Systems GmbH
>>>> Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
>>>> http://www.aicas.com   * Tel: +49-721-663 968-48
>>>> USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
>>>> Gesch?ftsf?hrer: Dr. James J. Hunt
>>>>


From son.two at gmail.com  Wed Sep 10 03:40:29 2008
From: son.two at gmail.com (Oleg Sukhodolsky)
Date: Wed, 10 Sep 2008 07:40:29 +0400
Subject: <Swing Dev> [OpenJDK 2D-Dev] [PATCH]
	SwingUtilities2.isLocalDisplay()
In-Reply-To: <48C6BD74.1070705@Sun.COM>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
	<1220900673.7112.25.camel@moonlight>
	<1220901074.7112.27.camel@moonlight>
	<271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com>
	<48C6BD74.1070705@Sun.COM>
Message-ID: <271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com>

Hi Dmitri,

I understand than you do not want to add questionable code in 2D,
but I do not like the idea to make this by adding questionable code
to Swing. So before falliwing back to hack I'd suggest to thinkabout
possible API, otherwise we have a good chance to keep this hack
in Swing code forever :(

Oleg.

On Tue, Sep 9, 2008 at 10:16 PM, Dmitri Trembovetski
<Dmitri.Trembovetski at sun.com> wrote:
>
>  Hi Oleg, Roman,
>
>  I myself don't think that this API belongs in public.
>
>  It is used by the platform implementation for doing
>  specific tasks and is of questionable value for
>  general public. Also, it is too platform-specific
>  and typically we refrain from adding platform-specific
>  APIs to the Java platform.
>
>  How do you think the developers would use it anyway?
>
>  Those developers who know what a "remote display" is -
>  which I assume is a minority since most developers never
>  leave the Windows world - can detect it themselves if
>  they really needed something like this - it's not a
>  big deal, just read the DISPLAY env. variable and
>  figure it out.
>
>  In the specific case of SwingUtilities I believe they
>  only use it to determine whether to enable AA text
>  or not. So perhaps that's something that should
>  be exposed instead.
>
>  And talking about implementation - if we were to add
>  something to this effect to the platform, we'd need
>  to go all the way and possibly detect remote desktop
>  session on Windows as well. And what about VNC sessions?
>  In our current implementation we only care about
>  "remote X display" situation, but the developers who
>  see this public API could assume otherwise.
>
>  I suggest to fall back to the original Roman's
>  patch which just exposed this method in
>  SunGraphicsEnvironment.
>
>  Thanks,
>    Dmitri
>
> Oleg Sukhodolsky wrote:
>>
>> I'd vote for this API, but it is 2D team who should make the decision.
>>
>> Oleg.
>>
>> On Mon, Sep 8, 2008 at 11:11 PM, Roman Kennke <roman.kennke at aicas.com>
>> wrote:
>>>
>>> Bah, forgot the actual patch. Here it comes now!
>>>
>>> /Roman
>>>
>>> Am Montag, den 08.09.2008, 21:04 +0200 schrieb Roman Kennke:
>>>>
>>>> Hi Oleg and lists,
>>>>
>>>>>>> I'm not the person who is supposed to review this changes from
>>>>>>> technical point of view,
>>>>>>> but I have one concern about idea of the fix.  It adds one more place
>>>>>>> where Swing uses sun-specific API.
>>>>>>
>>>>>> No. It takes advantage of Sun internal API, but it does not depend on
>>>>>> it. (if (ge instanceof SunGraphicsEnvironment)  { doSomethingCool(); }
>>>>>> else { useReasonableDefault(); } ).
>>>>>
>>>>> it uses Sun-specific class, so this code can not be compiled by JDK
>>>>> from another vendor :(
>>>>
>>>> Ehe :-) Try compiling Swing on any JDK from another vendor! Good luck!
>>>> (Ok, the Caciocavallo project will certainly help alot, but we are still
>>>> very far away from such a portable Swing).
>>>>
>>>>>>> Of course you can say that SwingUtilities2.isLocalDisplay() even
>>>>>>> before your fix uses code which is specific
>>>>>>> for Sun's implementation, and you will be right.  But this doesn't
>>>>>>> mean that we should leave with this.
>>>>>>> IMHO, if we change such code we should remove dependency between
>>>>>>> Swing
>>>>>>> and Sun-specific code,
>>>>>>> i.e. we should add public API.
>>>>>>
>>>>>> I completely agree. That, of course, would be the best solution. But
>>>>>> in
>>>>>> the past it has been communicated several times to me that I can't
>>>>>> just
>>>>>> send in patches to public API and hope that it will be accepted
>>>>>> easily.
>>>>>> I propose to get in this patch if possible first, then start a
>>>>>> discussion about adding public API.
>>>>>
>>>>> I understand your point, but I have a feeling that we you will not
>>>>> start the discussion right now,
>>>>> the idea of new API may be lost :(  So, I'd suggest to try one more
>>>>> time ;)
>>>>
>>>> Ok, so here we go. This patch is slightly modified, the isDisplayLocal()
>>>> method is now declared in GraphicsEnvironment, with the addition of
>>>> throwing a HeadlessException in the headless case. Also, in fontpath.c,
>>>> we don't call isDisplayLocal(), but instead call _isDisplayLocal(). We
>>>> call it on X11GraphicsEnvironment only. In my original patch I tried to
>>>> be more portable by calling
>>>> GraphicsEnvironment.getLocalGraphicsEnvironment().isDisplayLocal(), but
>>>> this resulted in an initialization loop (this code is very sensible to
>>>> this kind of problem). I left that out for now, because fontpath.c is
>>>> X11 specific anyway, and a real solution will come soon in the form of a
>>>> huge FontManager patch :-)
>>>>
>>>> What do you think? Can we add this API to GE?
>>>>
>>>> /Roman
>>>>
>>> --
>>> Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
>>> aicas Allerton Interworks Computer Automated Systems GmbH
>>> Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
>>> http://www.aicas.com   * Tel: +49-721-663 968-48
>>> USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
>>> Gesch?ftsf?hrer: Dr. James J. Hunt
>>>
>

From martinrb at google.com  Tue Sep  9 20:09:13 2008
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 9 Sep 2008 13:09:13 -0700
Subject: <Swing Dev> [OpenJDK 2D-Dev] [PATCH]
	SwingUtilities2.isLocalDisplay()
In-Reply-To: <48C6BD74.1070705@Sun.COM>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
	<1220900673.7112.25.camel@moonlight>
	<1220901074.7112.27.camel@moonlight>
	<271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com>
	<48C6BD74.1070705@Sun.COM>
Message-ID: <1ccfd1c10809091309q60417565y3303817c4f3bff63@mail.gmail.com>

It's very hard to get these kinds of UI issues right.

I once tried to configure my xemacs to have less eye candy
when talking to a "slow" X server by actually timing
some operation that requires a round trip.

Note that a method like isLocalDisplay would have the
wrong semantics for me, because I mostly cared about
whether I was bottlenecked by VPN.

This did help me get my work done, but this kind of
timing-dependent behavior is disconcerting to the user,
especially if they feel they have no control or do not
understand the behavior.  It "looks like a bug".

Will FAQs and bug reports appear
Q: Sometimes my java app starts up with funky fonts.
A: Try restarting a few times in a loop, or try setting this magic
system property:

Martin

On Tue, Sep 9, 2008 at 11:16, Dmitri Trembovetski
<Dmitri.Trembovetski at sun.com> wrote:
>
>  Hi Oleg, Roman,
>
>  I myself don't think that this API belongs in public.
>
>  It is used by the platform implementation for doing
>  specific tasks and is of questionable value for
>  general public. Also, it is too platform-specific
>  and typically we refrain from adding platform-specific
>  APIs to the Java platform.
>
>  How do you think the developers would use it anyway?
>
>  Those developers who know what a "remote display" is -
>  which I assume is a minority since most developers never
>  leave the Windows world - can detect it themselves if
>  they really needed something like this - it's not a
>  big deal, just read the DISPLAY env. variable and
>  figure it out.
>
>  In the specific case of SwingUtilities I believe they
>  only use it to determine whether to enable AA text
>  or not. So perhaps that's something that should
>  be exposed instead.
>
>  And talking about implementation - if we were to add
>  something to this effect to the platform, we'd need
>  to go all the way and possibly detect remote desktop
>  session on Windows as well. And what about VNC sessions?
>  In our current implementation we only care about
>  "remote X display" situation, but the developers who
>  see this public API could assume otherwise.
>
>  I suggest to fall back to the original Roman's
>  patch which just exposed this method in
>  SunGraphicsEnvironment.
>
>  Thanks,
>    Dmitri
>
> Oleg Sukhodolsky wrote:
>>
>> I'd vote for this API, but it is 2D team who should make the decision.
>>
>> Oleg.
>>
>> On Mon, Sep 8, 2008 at 11:11 PM, Roman Kennke <roman.kennke at aicas.com>
>> wrote:
>>>
>>> Bah, forgot the actual patch. Here it comes now!
>>>
>>> /Roman
>>>
>>> Am Montag, den 08.09.2008, 21:04 +0200 schrieb Roman Kennke:
>>>>
>>>> Hi Oleg and lists,
>>>>
>>>>>>> I'm not the person who is supposed to review this changes from
>>>>>>> technical point of view,
>>>>>>> but I have one concern about idea of the fix.  It adds one more place
>>>>>>> where Swing uses sun-specific API.
>>>>>>
>>>>>> No. It takes advantage of Sun internal API, but it does not depend on
>>>>>> it. (if (ge instanceof SunGraphicsEnvironment)  { doSomethingCool(); }
>>>>>> else { useReasonableDefault(); } ).
>>>>>
>>>>> it uses Sun-specific class, so this code can not be compiled by JDK
>>>>> from another vendor :(
>>>>
>>>> Ehe :-) Try compiling Swing on any JDK from another vendor! Good luck!
>>>> (Ok, the Caciocavallo project will certainly help alot, but we are still
>>>> very far away from such a portable Swing).
>>>>
>>>>>>> Of course you can say that SwingUtilities2.isLocalDisplay() even
>>>>>>> before your fix uses code which is specific
>>>>>>> for Sun's implementation, and you will be right.  But this doesn't
>>>>>>> mean that we should leave with this.
>>>>>>> IMHO, if we change such code we should remove dependency between
>>>>>>> Swing
>>>>>>> and Sun-specific code,
>>>>>>> i.e. we should add public API.
>>>>>>
>>>>>> I completely agree. That, of course, would be the best solution. But
>>>>>> in
>>>>>> the past it has been communicated several times to me that I can't
>>>>>> just
>>>>>> send in patches to public API and hope that it will be accepted
>>>>>> easily.
>>>>>> I propose to get in this patch if possible first, then start a
>>>>>> discussion about adding public API.
>>>>>
>>>>> I understand your point, but I have a feeling that we you will not
>>>>> start the discussion right now,
>>>>> the idea of new API may be lost :(  So, I'd suggest to try one more
>>>>> time ;)
>>>>
>>>> Ok, so here we go. This patch is slightly modified, the isDisplayLocal()
>>>> method is now declared in GraphicsEnvironment, with the addition of
>>>> throwing a HeadlessException in the headless case. Also, in fontpath.c,
>>>> we don't call isDisplayLocal(), but instead call _isDisplayLocal(). We
>>>> call it on X11GraphicsEnvironment only. In my original patch I tried to
>>>> be more portable by calling
>>>> GraphicsEnvironment.getLocalGraphicsEnvironment().isDisplayLocal(), but
>>>> this resulted in an initialization loop (this code is very sensible to
>>>> this kind of problem). I left that out for now, because fontpath.c is
>>>> X11 specific anyway, and a real solution will come soon in the form of a
>>>> huge FontManager patch :-)
>>>>
>>>> What do you think? Can we add this API to GE?
>>>>
>>>> /Roman
>>>>
>>> --
>>> Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
>>> aicas Allerton Interworks Computer Automated Systems GmbH
>>> Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
>>> http://www.aicas.com   * Tel: +49-721-663 968-48
>>> USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
>>> Gesch?ftsf?hrer: Dr. James J. Hunt
>>>
>


From pavel.porvatov at sun.com  Wed Sep 10 15:21:33 2008
From: pavel.porvatov at sun.com (pavel.porvatov at sun.com)
Date: Wed, 10 Sep 2008 15:21:33 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6587742: filling half of a
	JSlider's track is no	longer optional
Message-ID: <20080910152144.ED7F2D6D1@hg.openjdk.java.net>

Changeset: 32fb1f4f40b8
Author:    rupashka
Date:      2008-09-10 19:16 +0400
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/32fb1f4f40b8

6587742: filling half of a JSlider's track is no longer optional
Summary: now OceanTheme uses the JSlider.isFilled property like other themes
Reviewed-by: alexp

! src/share/classes/javax/swing/plaf/metal/MetalSliderUI.java
+ test/javax/swing/JSlider/6587742/bug6587742.html
+ test/javax/swing/JSlider/6587742/bug6587742.java



From Dmitri.Trembovetski at Sun.COM  Wed Sep 10 16:19:51 2008
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Wed, 10 Sep 2008 09:19:51 -0700
Subject: <Swing Dev> [OpenJDK 2D-Dev] [PATCH]
	SwingUtilities2.isLocalDisplay()
In-Reply-To: <271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
	<1220900673.7112.25.camel@moonlight>
	<1220901074.7112.27.camel@moonlight>
	<271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com>
	<48C6BD74.1070705@Sun.COM>
	<271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com>
Message-ID: <48C7F3A7.6010803@Sun.COM>



   Hi Oleg,

Oleg Sukhodolsky wrote:
> I understand than you do not want to add questionable code in 2D,
> but I do not like the idea to make this by adding questionable code
> to Swing. So before falliwing back to hack I'd suggest to thinkabout

   I'm not sure what you mean by "adding questionable code
   to Swing" - the code was already there. Now instead of
   directly calling sun internal API it will call a better
   defined internal API.

> possible API, otherwise we have a good chance to keep this hack
> in Swing code forever :(

   Swing is part of the platform, and will always have to
   use some APIs in the implementation which are not available
   to external developers.

   I don't see a problem with that. In this particular case
   I really don't see any benefit in exposing this very
   platform-specific API to the developers.

   Thanks,
     Dmitri


> 
> Oleg.
> 
> On Tue, Sep 9, 2008 at 10:16 PM, Dmitri Trembovetski
> <Dmitri.Trembovetski at sun.com> wrote:
>>  Hi Oleg, Roman,
>>
>>  I myself don't think that this API belongs in public.
>>
>>  It is used by the platform implementation for doing
>>  specific tasks and is of questionable value for
>>  general public. Also, it is too platform-specific
>>  and typically we refrain from adding platform-specific
>>  APIs to the Java platform.
>>
>>  How do you think the developers would use it anyway?
>>
>>  Those developers who know what a "remote display" is -
>>  which I assume is a minority since most developers never
>>  leave the Windows world - can detect it themselves if
>>  they really needed something like this - it's not a
>>  big deal, just read the DISPLAY env. variable and
>>  figure it out.
>>
>>  In the specific case of SwingUtilities I believe they
>>  only use it to determine whether to enable AA text
>>  or not. So perhaps that's something that should
>>  be exposed instead.
>>
>>  And talking about implementation - if we were to add
>>  something to this effect to the platform, we'd need
>>  to go all the way and possibly detect remote desktop
>>  session on Windows as well. And what about VNC sessions?
>>  In our current implementation we only care about
>>  "remote X display" situation, but the developers who
>>  see this public API could assume otherwise.
>>
>>  I suggest to fall back to the original Roman's
>>  patch which just exposed this method in
>>  SunGraphicsEnvironment.
>>
>>  Thanks,
>>    Dmitri
>>
>> Oleg Sukhodolsky wrote:
>>> I'd vote for this API, but it is 2D team who should make the decision.
>>>
>>> Oleg.
>>>
>>> On Mon, Sep 8, 2008 at 11:11 PM, Roman Kennke <roman.kennke at aicas.com>
>>> wrote:
>>>> Bah, forgot the actual patch. Here it comes now!
>>>>
>>>> /Roman
>>>>
>>>> Am Montag, den 08.09.2008, 21:04 +0200 schrieb Roman Kennke:
>>>>> Hi Oleg and lists,
>>>>>
>>>>>>>> I'm not the person who is supposed to review this changes from
>>>>>>>> technical point of view,
>>>>>>>> but I have one concern about idea of the fix.  It adds one more place
>>>>>>>> where Swing uses sun-specific API.
>>>>>>> No. It takes advantage of Sun internal API, but it does not depend on
>>>>>>> it. (if (ge instanceof SunGraphicsEnvironment)  { doSomethingCool(); }
>>>>>>> else { useReasonableDefault(); } ).
>>>>>> it uses Sun-specific class, so this code can not be compiled by JDK
>>>>>> from another vendor :(
>>>>> Ehe :-) Try compiling Swing on any JDK from another vendor! Good luck!
>>>>> (Ok, the Caciocavallo project will certainly help alot, but we are still
>>>>> very far away from such a portable Swing).
>>>>>
>>>>>>>> Of course you can say that SwingUtilities2.isLocalDisplay() even
>>>>>>>> before your fix uses code which is specific
>>>>>>>> for Sun's implementation, and you will be right.  But this doesn't
>>>>>>>> mean that we should leave with this.
>>>>>>>> IMHO, if we change such code we should remove dependency between
>>>>>>>> Swing
>>>>>>>> and Sun-specific code,
>>>>>>>> i.e. we should add public API.
>>>>>>> I completely agree. That, of course, would be the best solution. But
>>>>>>> in
>>>>>>> the past it has been communicated several times to me that I can't
>>>>>>> just
>>>>>>> send in patches to public API and hope that it will be accepted
>>>>>>> easily.
>>>>>>> I propose to get in this patch if possible first, then start a
>>>>>>> discussion about adding public API.
>>>>>> I understand your point, but I have a feeling that we you will not
>>>>>> start the discussion right now,
>>>>>> the idea of new API may be lost :(  So, I'd suggest to try one more
>>>>>> time ;)
>>>>> Ok, so here we go. This patch is slightly modified, the isDisplayLocal()
>>>>> method is now declared in GraphicsEnvironment, with the addition of
>>>>> throwing a HeadlessException in the headless case. Also, in fontpath.c,
>>>>> we don't call isDisplayLocal(), but instead call _isDisplayLocal(). We
>>>>> call it on X11GraphicsEnvironment only. In my original patch I tried to
>>>>> be more portable by calling
>>>>> GraphicsEnvironment.getLocalGraphicsEnvironment().isDisplayLocal(), but
>>>>> this resulted in an initialization loop (this code is very sensible to
>>>>> this kind of problem). I left that out for now, because fontpath.c is
>>>>> X11 specific anyway, and a real solution will come soon in the form of a
>>>>> huge FontManager patch :-)
>>>>>
>>>>> What do you think? Can we add this API to GE?
>>>>>
>>>>> /Roman
>>>>>
>>>> --
>>>> Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
>>>> aicas Allerton Interworks Computer Automated Systems GmbH
>>>> Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
>>>> http://www.aicas.com   * Tel: +49-721-663 968-48
>>>> USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
>>>> Gesch?ftsf?hrer: Dr. James J. Hunt
>>>>


From roman.kennke at aicas.com  Wed Sep 10 19:04:31 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Wed, 10 Sep 2008 21:04:31 +0200
Subject: <Swing Dev> [OpenJDK 2D-Dev] [PATCH]
	SwingUtilities2.isLocalDisplay()
In-Reply-To: <48C7F3A7.6010803@Sun.COM>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
	<1220900673.7112.25.camel@moonlight>
	<1220901074.7112.27.camel@moonlight>
	<271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com>
	<48C6BD74.1070705@Sun.COM>
	<271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com>
	<48C7F3A7.6010803@Sun.COM>
Message-ID: <1221073471.6592.27.camel@moonlight>

Hi Dmitri and Oleg,

> > I understand than you do not want to add questionable code in 2D,
> > but I do not like the idea to make this by adding questionable code
> > to Swing. So before falliwing back to hack I'd suggest to thinkabout
> 
>    I'm not sure what you mean by "adding questionable code
>    to Swing" - the code was already there. Now instead of
>    directly calling sun internal API it will call a better
>    defined internal API.

Yeah, I agree.

> > possible API, otherwise we have a good chance to keep this hack
> > in Swing code forever :(
> 
>    Swing is part of the platform, and will always have to
>    use some APIs in the implementation which are not available
>    to external developers.
> 
>    I don't see a problem with that. In this particular case
>    I really don't see any benefit in exposing this very
>    platform-specific API to the developers.

Yeah. It looks like most (all?) Sun-specific code is in SwingUtilities2
anyway, so this is more or less the porting interface for Swing for
people who really need to port OpenJDK Swing to a different JDK. If it
is a goal to support that, it might make sense to find all remaining
uses of Sun-specific code in Swing and refactor that to also use
SwingUtilities2. Or even better, create a separate interface and factory
for implementations of that interface that would be provided by the
developer who ports Swing. But that seems a little over the top right
now. I also suggest to get the original patch through.

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



From roman at kennke.org  Wed Sep 10 21:54:34 2008
From: roman at kennke.org (Roman Kennke)
Date: Wed, 10 Sep 2008 23:54:34 +0200
Subject: <Swing Dev> [OpenJDK 2D-Dev] [PATCH]
	SwingUtilities2.isLocalDisplay()
In-Reply-To: <1221073471.6592.27.camel@moonlight>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
	<1220900673.7112.25.camel@moonlight>
	<1220901074.7112.27.camel@moonlight>
	<271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com>
	<48C6BD74.1070705@Sun.COM>
	<271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com>
	<48C7F3A7.6010803@Sun.COM>  <1221073471.6592.27.camel@moonlight>
Message-ID: <1221083674.6592.35.camel@moonlight>

I need to repost my original patch for two reasons: 1. it doesn't apply
cleanly (only with some fuzz), 2. it also has this init-loop problem.
Find attached the correct version. I'd be happy to see it committed
ASAP.

/Roman

Am Mittwoch, den 10.09.2008, 21:04 +0200 schrieb Roman Kennke:
> Hi Dmitri and Oleg,
> 
> > > I understand than you do not want to add questionable code in 2D,
> > > but I do not like the idea to make this by adding questionable code
> > > to Swing. So before falliwing back to hack I'd suggest to thinkabout
> > 
> >    I'm not sure what you mean by "adding questionable code
> >    to Swing" - the code was already there. Now instead of
> >    directly calling sun internal API it will call a better
> >    defined internal API.
> 
> Yeah, I agree.
> 
> > > possible API, otherwise we have a good chance to keep this hack
> > > in Swing code forever :(
> > 
> >    Swing is part of the platform, and will always have to
> >    use some APIs in the implementation which are not available
> >    to external developers.
> > 
> >    I don't see a problem with that. In this particular case
> >    I really don't see any benefit in exposing this very
> >    platform-specific API to the developers.
> 
> Yeah. It looks like most (all?) Sun-specific code is in SwingUtilities2
> anyway, so this is more or less the porting interface for Swing for
> people who really need to port OpenJDK Swing to a different JDK. If it
> is a goal to support that, it might make sense to find all remaining
> uses of Sun-specific code in Swing and refactor that to also use
> SwingUtilities2. Or even better, create a separate interface and factory
> for implementations of that interface that would be provided by the
> developer who ports Swing. But that seems a little over the top right
> now. I also suggest to get the original patch through.
> 
> /Roman
-- 
http://kennke.org/blog/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 4368 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20080910/be736a0a/patch.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20080910/be736a0a/signature.asc>

From Dmitri.Trembovetski at Sun.COM  Wed Sep 10 22:45:04 2008
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Wed, 10 Sep 2008 15:45:04 -0700
Subject: <Swing Dev> [OpenJDK 2D-Dev] [PATCH]
	SwingUtilities2.isLocalDisplay()
In-Reply-To: <1221083674.6592.35.camel@moonlight>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
	<1220900673.7112.25.camel@moonlight>
	<1220901074.7112.27.camel@moonlight>
	<271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com>
	<48C6BD74.1070705@Sun.COM>
	<271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com>
	<48C7F3A7.6010803@Sun.COM> <1221073471.6592.27.camel@moonlight>
	<1221083674.6592.35.camel@moonlight>
Message-ID: <48C84DF0.1090506@Sun.COM>



Roman Kennke wrote:
> I need to repost my original patch for two reasons: 1. it doesn't apply
> cleanly (only with some fuzz), 2. it also has this init-loop problem.
> Find attached the correct version. I'd be happy to see it committed
> ASAP.

   I have a question about the fix:
--- a/src/solaris/native/sun/awt/fontpath.c	Thu Aug 07 09:42:31 2008 -0700
+++ b/src/solaris/native/sun/awt/fontpath.c	Wed Sep 10 23:52:15 2008 +0200
@@ -156,7 +156,7 @@

      isLocal = JNU_CallStaticMethodByName(env, NULL,
                                           "sun/awt/X11GraphicsEnvironment",
-                                         "isDisplayLocal",
+                                         "_isDisplayLocal",
                                           "()Z").z;

   Didn't you change isDisplayLocal to be non-static
   in X11GraphicsEnvironment? If so how does this actually
   work since you still call CallStaticMethodByName?

   Thanks,
     Dmitri


> 
> /Roman
> 
> Am Mittwoch, den 10.09.2008, 21:04 +0200 schrieb Roman Kennke:
>> Hi Dmitri and Oleg,
>>
>>>> I understand than you do not want to add questionable code in 2D,
>>>> but I do not like the idea to make this by adding questionable code
>>>> to Swing. So before falliwing back to hack I'd suggest to thinkabout
>>>    I'm not sure what you mean by "adding questionable code
>>>    to Swing" - the code was already there. Now instead of
>>>    directly calling sun internal API it will call a better
>>>    defined internal API.
>> Yeah, I agree.
>>
>>>> possible API, otherwise we have a good chance to keep this hack
>>>> in Swing code forever :(
>>>    Swing is part of the platform, and will always have to
>>>    use some APIs in the implementation which are not available
>>>    to external developers.
>>>
>>>    I don't see a problem with that. In this particular case
>>>    I really don't see any benefit in exposing this very
>>>    platform-specific API to the developers.
>> Yeah. It looks like most (all?) Sun-specific code is in SwingUtilities2
>> anyway, so this is more or less the porting interface for Swing for
>> people who really need to port OpenJDK Swing to a different JDK. If it
>> is a goal to support that, it might make sense to find all remaining
>> uses of Sun-specific code in Swing and refactor that to also use
>> SwingUtilities2. Or even better, create a separate interface and factory
>> for implementations of that interface that would be provided by the
>> developer who ports Swing. But that seems a little over the top right
>> now. I also suggest to get the original patch through.
>>
>> /Roman


From mario.torre at aicas.com  Wed Sep 10 23:15:54 2008
From: mario.torre at aicas.com (Mario Torre)
Date: Thu, 11 Sep 2008 01:15:54 +0200
Subject: <Swing Dev> <AWT Dev> [OpenJDK 2D-Dev]
	[PATCH]	SwingUtilities2.isLocalDisplay()
In-Reply-To: <48C84DF0.1090506@Sun.COM>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
	<1220900673.7112.25.camel@moonlight>
	<1220901074.7112.27.camel@moonlight>
	<271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com>
	<48C6BD74.1070705@Sun.COM>
	<271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com>
	<48C7F3A7.6010803@Sun.COM> <1221073471.6592.27.camel@moonlight>
	<1221083674.6592.35.camel@moonlight>  <48C84DF0.1090506@Sun.COM>
Message-ID: <1221088554.3336.17.camel@nirvana>

Il giorno mer, 10/09/2008 alle 15.45 -0700, Dmitri Trembovetski ha
scritto:

> --- a/src/solaris/native/sun/awt/fontpath.c	Thu Aug 07 09:42:31 2008 -0700
> +++ b/src/solaris/native/sun/awt/fontpath.c	Wed Sep 10 23:52:15 2008 +0200
> @@ -156,7 +156,7 @@
> 
>       isLocal = JNU_CallStaticMethodByName(env, NULL,
>                                            "sun/awt/X11GraphicsEnvironment",
> -                                         "isDisplayLocal",
> +                                         "_isDisplayLocal",
>                                            "()Z").z;

Hi Dmitri!

Calling "isDisplayLocal" fires up a infinite loop. Here we call
_isDisplayLocal, which is declared as:

private static boolean _isDisplayLocal

And we don't touch it in the patch.

We are not super happy with this, but I don't see much alternatives.
This code is X11 specific anyway.

All this Font code is really sensible to this kind of infinite loops...

Cheers,
Mario
-- 
?Mario Torre, Software Developer, http://www.jroller.com/neugens/
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-53
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim
Gesch?ftsf?hrer: Dr. James J. Hunt

Please, support open standards:
http://opendocumentfellowship.org/petition/
http://www.nosoftwarepatents.com/



From roman at kennke.org  Wed Sep 10 23:45:08 2008
From: roman at kennke.org (Roman Kennke)
Date: Thu, 11 Sep 2008 01:45:08 +0200
Subject: <Swing Dev> [OpenJDK 2D-Dev] [PATCH]
	SwingUtilities2.isLocalDisplay()
In-Reply-To: <48C84DF0.1090506@Sun.COM>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
	<1220900673.7112.25.camel@moonlight>
	<1220901074.7112.27.camel@moonlight>
	<271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com>
	<48C6BD74.1070705@Sun.COM>
	<271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com>
	<48C7F3A7.6010803@Sun.COM> <1221073471.6592.27.camel@moonlight>
	<1221083674.6592.35.camel@moonlight>  <48C84DF0.1090506@Sun.COM>
Message-ID: <1221090308.6500.3.camel@moonlight>

Hi Dmitri,

> > I need to repost my original patch for two reasons: 1. it doesn't apply
> > cleanly (only with some fuzz), 2. it also has this init-loop problem.
> > Find attached the correct version. I'd be happy to see it committed
> > ASAP.
> 
>    I have a question about the fix:
> --- a/src/solaris/native/sun/awt/fontpath.c	Thu Aug 07 09:42:31 2008 -0700
> +++ b/src/solaris/native/sun/awt/fontpath.c	Wed Sep 10 23:52:15 2008 +0200
> @@ -156,7 +156,7 @@
> 
>       isLocal = JNU_CallStaticMethodByName(env, NULL,
>                                            "sun/awt/X11GraphicsEnvironment",
> -                                         "isDisplayLocal",
> +                                         "_isDisplayLocal",
>                                            "()Z").z;
> 
>    Didn't you change isDisplayLocal to be non-static
>    in X11GraphicsEnvironment? If so how does this actually
>    work since you still call CallStaticMethodByName?

The _isDisplayLocal() is a static method in X11GraphicsEnvironment,
which is called by isDisplayLocal() after entering the AWT monitor. The
above code is already executed inside the AWT lock, so this is not a
problem. And it is only called from the X11 backend anyway. Calling
isDisplayLocal() results in a loop though, because it tries to load the
X11GraphicsEnvironment class, which in turn causes the class initializer
of SGE to be executed, which calls back into the code above, ad
infinitum. This is why we call the static _isDisplayLocal() instead. The
real solution would be to rework all the SGE and FontManager code, which
we did, but send in a separate patch. :-) (You can also take a peek at
this code in our repository
(http://hg.openjdk.java.net/caciocavallo/jdk7/) ).

Thanks, Roman


-- 
http://kennke.org/blog/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20080911/ec816682/signature.asc>

From Dmitri.Trembovetski at Sun.COM  Wed Sep 10 23:54:02 2008
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Wed, 10 Sep 2008 16:54:02 -0700
Subject: <Swing Dev> [OpenJDK 2D-Dev] [PATCH]
	SwingUtilities2.isLocalDisplay()
In-Reply-To: <1221090308.6500.3.camel@moonlight>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
	<1220900673.7112.25.camel@moonlight>
	<1220901074.7112.27.camel@moonlight>
	<271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com>
	<48C6BD74.1070705@Sun.COM>
	<271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com>
	<48C7F3A7.6010803@Sun.COM> <1221073471.6592.27.camel@moonlight>
	<1221083674.6592.35.camel@moonlight> <48C84DF0.1090506@Sun.COM>
	<1221090308.6500.3.camel@moonlight>
Message-ID: <48C85E1A.3030801@Sun.COM>


   Yep, I see. I didn't look at the file itself, only at the
   patch, and got confused.

   Thanks,
     Dmitri


Roman Kennke wrote:
> Hi Dmitri,
> 
>>> I need to repost my original patch for two reasons: 1. it doesn't apply
>>> cleanly (only with some fuzz), 2. it also has this init-loop problem.
>>> Find attached the correct version. I'd be happy to see it committed
>>> ASAP.
>>    I have a question about the fix:
>> --- a/src/solaris/native/sun/awt/fontpath.c	Thu Aug 07 09:42:31 2008 -0700
>> +++ b/src/solaris/native/sun/awt/fontpath.c	Wed Sep 10 23:52:15 2008 +0200
>> @@ -156,7 +156,7 @@
>>
>>       isLocal = JNU_CallStaticMethodByName(env, NULL,
>>                                            "sun/awt/X11GraphicsEnvironment",
>> -                                         "isDisplayLocal",
>> +                                         "_isDisplayLocal",
>>                                            "()Z").z;
>>
>>    Didn't you change isDisplayLocal to be non-static
>>    in X11GraphicsEnvironment? If so how does this actually
>>    work since you still call CallStaticMethodByName?
> 
> The _isDisplayLocal() is a static method in X11GraphicsEnvironment,
> which is called by isDisplayLocal() after entering the AWT monitor. The
> above code is already executed inside the AWT lock, so this is not a
> problem. And it is only called from the X11 backend anyway. Calling
> isDisplayLocal() results in a loop though, because it tries to load the
> X11GraphicsEnvironment class, which in turn causes the class initializer
> of SGE to be executed, which calls back into the code above, ad
> infinitum. This is why we call the static _isDisplayLocal() instead. The
> real solution would be to rework all the SGE and FontManager code, which
> we did, but send in a separate patch. :-) (You can also take a peek at
> this code in our repository
> (http://hg.openjdk.java.net/caciocavallo/jdk7/) ).
> 
> Thanks, Roman
> 
> 


From roman at kennke.org  Fri Sep 12 07:42:11 2008
From: roman at kennke.org (Roman Kennke)
Date: Fri, 12 Sep 2008 09:42:11 +0200
Subject: <Swing Dev> [OpenJDK 2D-Dev]
	[PATCH]	SwingUtilities2.isLocalDisplay()
In-Reply-To: <48C85E1A.3030801@Sun.COM>
References: <1220640905.6422.43.camel@moonlight>
	<271e55d20809052107p23c59abbk34975d4f512b0c0e@mail.gmail.com>
	<1220691841.6571.22.camel@moonlight>
	<271e55d20809060245k24d721d2k65d55b09c45114a@mail.gmail.com>
	<1220900673.7112.25.camel@moonlight>
	<1220901074.7112.27.camel@moonlight>
	<271e55d20809082026n2ba12817s8a8f55d23a32c0e9@mail.gmail.com>
	<48C6BD74.1070705@Sun.COM>
	<271e55d20809092040w3ce3b1ebxdd66eb001bd47958@mail.gmail.com>
	<48C7F3A7.6010803@Sun.COM> <1221073471.6592.27.camel@moonlight>
	<1221083674.6592.35.camel@moonlight> <48C84DF0.1090506@Sun.COM>
	<1221090308.6500.3.camel@moonlight>  <48C85E1A.3030801@Sun.COM>
Message-ID: <1221205331.6511.0.camel@moonlight>

Hi,

> Yep, I see. I didn't look at the file itself, only at the
>    patch, and got confused.

Ok, what's next? Will the patch be included?

/Roman

> 
>    Thanks,
>      Dmitri
> 
> 
> Roman Kennke wrote:
> > Hi Dmitri,
> > 
> >>> I need to repost my original patch for two reasons: 1. it doesn't apply
> >>> cleanly (only with some fuzz), 2. it also has this init-loop problem.
> >>> Find attached the correct version. I'd be happy to see it committed
> >>> ASAP.
> >>    I have a question about the fix:
> >> --- a/src/solaris/native/sun/awt/fontpath.c	Thu Aug 07 09:42:31 2008 -0700
> >> +++ b/src/solaris/native/sun/awt/fontpath.c	Wed Sep 10 23:52:15 2008 +0200
> >> @@ -156,7 +156,7 @@
> >>
> >>       isLocal = JNU_CallStaticMethodByName(env, NULL,
> >>                                            "sun/awt/X11GraphicsEnvironment",
> >> -                                         "isDisplayLocal",
> >> +                                         "_isDisplayLocal",
> >>                                            "()Z").z;
> >>
> >>    Didn't you change isDisplayLocal to be non-static
> >>    in X11GraphicsEnvironment? If so how does this actually
> >>    work since you still call CallStaticMethodByName?
> > 
> > The _isDisplayLocal() is a static method in X11GraphicsEnvironment,
> > which is called by isDisplayLocal() after entering the AWT monitor. The
> > above code is already executed inside the AWT lock, so this is not a
> > problem. And it is only called from the X11 backend anyway. Calling
> > isDisplayLocal() results in a loop though, because it tries to load the
> > X11GraphicsEnvironment class, which in turn causes the class initializer
> > of SGE to be executed, which calls back into the code above, ad
> > infinitum. This is why we call the static _isDisplayLocal() instead. The
> > real solution would be to rework all the SGE and FontManager code, which
> > we did, but send in a separate patch. :-) (You can also take a peek at
> > this code in our repository
> > (http://hg.openjdk.java.net/caciocavallo/jdk7/) ).
> > 
> > Thanks, Roman
> > 
> > 
-- 
http://kennke.org/blog/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20080912/ee2c4cda/signature.asc>

From roman.kennke at aicas.com  Tue Sep 16 08:54:01 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Tue, 16 Sep 2008 10:54:01 +0200
Subject: <Swing Dev> [PATCH] Make RepaintManager more portable
Message-ID: <1221555241.6579.5.camel@moonlight>

Hello,

The attached patch fixes two problems in RepaintManager. The first one
is a direct cast from Toolkit to SunToolkit, without checking for the
actual type, the second is using a SunToolkit static method without
checking if we are actually using a SunToolkit. This makes it impossible
to use a non-SunToolkit as AWT backend. The solution in the first case
is to check for SunToolkit (of course) and in the 2nd case to also check
for SunToolkit, and using a different method to post event to the EQ.
This patch was developed as part of the Caciocavallo project and it
would be good to have it merged it into mainline. What do you think?

/Roman

-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt
-------------- next part --------------
# HG changeset patch
# User Mario Torre <mario.torre at aicas.com>
# Date 1217450571 -7200
# Node ID 87fd234ed5ab0bac1ffa8731e80ded5830aa1684
# Parent  9af1670d56ecb4d3e49a21c9389c390e4c9e003f
imported patch RepaintManager.patch

diff -r 9af1670d56ec -r 87fd234ed5ab src/share/classes/javax/swing/RepaintManager.java
--- a/src/share/classes/javax/swing/RepaintManager.java	Wed Jul 30 22:42:51 2008 +0200
+++ b/src/share/classes/javax/swing/RepaintManager.java	Wed Jul 30 22:42:51 2008 +0200
@@ -1261,9 +1261,12 @@
             if (doubleBufferingEnabled && !nativeDoubleBuffering) {
                 switch (bufferStrategyType) {
                 case BUFFER_STRATEGY_NOT_SPECIFIED:
-                    if (((SunToolkit)Toolkit.getDefaultToolkit()).
-                                                useBufferPerWindow()) {
-                        paintManager = new BufferStrategyPaintManager();
+                    Toolkit tk = Toolkit.getDefaultToolkit();
+                    if (tk instanceof SunToolkit) {
+                        SunToolkit stk = (SunToolkit) tk;
+                        if (stk.useBufferPerWindow()) {
+                            paintManager = new BufferStrategyPaintManager();
+                        }
                     }
                     break;
                 case BUFFER_STRATEGY_SPECIFIED_ON:
@@ -1285,9 +1288,16 @@
 
     private void scheduleProcessingRunnable(AppContext context) {
         if (processingRunnable.markPending()) {
-            SunToolkit.getSystemEventQueueImplPP(context).
-                postEvent(new InvocationEvent(Toolkit.getDefaultToolkit(),
-                                              processingRunnable));
+            Toolkit tk = Toolkit.getDefaultToolkit();
+            if (tk instanceof SunToolkit) {
+                SunToolkit.getSystemEventQueueImplPP(context).
+                  postEvent(new InvocationEvent(Toolkit.getDefaultToolkit(),
+                                                processingRunnable));
+            } else {
+                Toolkit.getDefaultToolkit().getSystemEventQueue().
+                      postEvent(new InvocationEvent(Toolkit.getDefaultToolkit(),
+                                                    processingRunnable));
+            }
         }
     }
 

From roman.kennke at aicas.com  Wed Sep 17 12:40:14 2008
From: roman.kennke at aicas.com (Roman Kennke)
Date: Wed, 17 Sep 2008 14:40:14 +0200
Subject: <Swing Dev> [PATCH] Make RepaintManager more portable
In-Reply-To: <1221555241.6579.5.camel@moonlight>
References: <1221555241.6579.5.camel@moonlight>
Message-ID: <1221655214.32395.0.camel@moonlight>

No opinions?

/Roman

Am Dienstag, den 16.09.2008, 10:54 +0200 schrieb Roman Kennke:
> Hello,
> 
> The attached patch fixes two problems in RepaintManager. The first one
> is a direct cast from Toolkit to SunToolkit, without checking for the
> actual type, the second is using a SunToolkit static method without
> checking if we are actually using a SunToolkit. This makes it impossible
> to use a non-SunToolkit as AWT backend. The solution in the first case
> is to check for SunToolkit (of course) and in the 2nd case to also check
> for SunToolkit, and using a different method to post event to the EQ.
> This patch was developed as part of the Caciocavallo project and it
> would be good to have it merged it into mainline. What do you think?
> 
> /Roman
> 
-- 
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com   * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Gesch?ftsf?hrer: Dr. James J. Hunt