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

Reply via email to