[OpenJDK 2D-Dev] [PATCH] SwingUtilities2.isLocalDisplay()

[Dmitri Trembovetski]

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