For Path2D, it seems silly to suppress some warnings just to save a
single line of code duplication (which the compiler may detect anyway).
I'd support duplicating the "lineTo(...); break;" in both cases so
that we can have clean unsuppressed code...
...jim
On 12/1/20
For GraphicsPrimitive, can't we determine a decent specific type for the
traceMap to avoid having to suppress the warnings?
And looking through the rest of the changes, I think I'd support an
SG2D.* static import in any of the pipelines and loops as well...
...jim
On
Would it be better to import statics from SG2D for SurfaceData? For at
least that one file (and some of its subclasses), they are so closely
tied that they should be able to just refer to the same set of static
constants without having to qualify.
I'm thinking that might make the code more re
http://cr.openjdk.java.net/~prr/7117199/
Lots of rawtypes warnings fixed.
-phil.
On 12/1/2011 3:41 PM, Mario Torre wrote:
Il giorno 02/dic/2011, alle ore 00:31, Phil Race ha scritto:
I'm not sure if the right strategy is to use @SuppressWarnings so much.
Did you think they were justified, or was it too risky to change ? If the
latter might be better to leave the warnings. J
Il giorno 02/dic/2011, alle ore 00:31, Phil Race ha scritto:
> I'm not sure if the right strategy is to use @SuppressWarnings so much.
> Did you think they were justified, or was it too risky to change ? If the
> latter might be better to leave the warnings. Judgement call here.
Hi Phil,
Yeah, I
I'm not sure if the right strategy is to use @SuppressWarnings so much.
Did you think they were justified, or was it too risky to change ? If the
latter might be better to leave the warnings. Judgement call here.
28 import static
sun.java2d.opengl.OGLContext.OGLContextCaps.CAPS_EXT_GRAD_SHADER;
Looks fine ChrisOn Dec 1, 2011, at 11:09 AM, Chris Hegarty wrote:This is a follow up to an issue that came up during discussion of another fix. Essentially, JDK classes should use j.u.ServiceLoader rather than sun.misc.Service.http://cr.openjdk.java.net/~chegar/7116946/webrev.00/webrev/And a few wa
Il giorno 01/dic/2011, alle ore 00:29, Roman Kennke ha scritto:
>> Btw, on the other mailing lists they are also discussing about the warnings
>> day, so I guess I'm not so early ;)
>
> Congratulations, it's probably the first time in your life that you're
> early ;-) Seriously, maybe this comes
Il giorno 01/dic/2011, alle ore 18:32, Phil Race ha scritto:
> Do you mean they are now using a new library which now inappropriately
> uses the moved internal API, and they consider that problem solved ?
>
> -phil.
>
I'm also a bit confused to be honest, especially since I don't understand
the
Looks good to me. I thought we'd squished all the uses of this internal
class
a long time ago.
-phil.
On 12/1/11 8:09 AM, Chris Hegarty wrote:
This is a follow up to an issue that came up during discussion of
another fix. Essentially, JDK classes should use j.u.ServiceLoader
rather than sun
Do you mean they are now using a new library which now inappropriately
uses the moved internal API, and they consider that problem solved ?
-phil.
On 12/1/11 8:00 AM, Martijn Verburg wrote:
Hi Roman,
Exactly :-), yes they want to avoid using the internal APIs. After
your hint they were quickly
This is a follow up to an issue that came up during discussion of
another fix. Essentially, JDK classes should use j.u.ServiceLoader
rather than sun.misc.Service.
http://cr.openjdk.java.net/~chegar/7116946/webrev.00/webrev/
And a few warning cleanups, given the date that's in it ;-) Since
g
Hi Roman,
Exactly :-), yes they want to avoid using the internal APIs. After
your hint they were quickly able to find a library that wraps the
internal API, problem solved.
Cheers,
Martijn
On 1 December 2011 15:49, Roman Kennke wrote:
> Ah and of course... maybe you should try to avoid using in
Ah and of course... maybe you should try to avoid using internal APIs to
begin with. What exactly are you trying to do with this?
Regards, Roman
Am Donnerstag, den 01.12.2011, 15:30 + schrieb Martijn Verburg:
> Thanks, that helps a bunch!
>
> On 1 December 2011 15:21, Roman Kennke wrote:
>
Thanks, that helps a bunch!
On 1 December 2011 15:21, Roman Kennke wrote:
> Hi Martijn,
>
> we refactored the FontManager internal API, it's now:
>
> FontManagerFactory.getInstance().getNewComposite() (or whatever other
> FontManager static method it was before). There are a few methods that
> ha
Hi Martijn,
we refactored the FontManager internal API, it's now:
FontManagerFactory.getInstance().getNewComposite() (or whatever other
FontManager static method it was before). There are a few methods that
have been moved to other classes, but this one is still available in the
FontManager inter
Hi all,
I'm dealing with a 3rd party-lib that is sadly using
sun.font.FontManager (getNewComposite in particular). When moving to
Java 7 this breaks (not unexpectedly) and so they'd like some advice
on what would be an appropriate OpenJDK package to use instead of the
internal sun one.
Any ideas
18 matches
Mail list logo
