Changeset: 479c14bec7f1
Author:prr
Date: 2009-11-30 14:39 -0800
URL: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/479c14bec7f1
6904962: GlyphVector.getVisualBounds should not be affected by leading or
trailing white space.
Reviewed-by: igor, dougfelt
! src/share/classes/sun/font/Sta
Roman Kennke wrote:
I added the (previously closed) testcase, keeping it in the same
relative directory location:
http://cr.openjdk.java.net/~rkennke/6888734/webrev.01/
Is this ok?
Almost. Reg tests don't have the classpath exception.
And probably the copyright year should be a range, sta
I added the (previously closed) testcase, keeping it in the same
relative directory location:
http://cr.openjdk.java.net/~rkennke/6888734/webrev.01/
Is this ok?
/Roman
Am Montag, den 30.11.2009, 11:19 -0800 schrieb Phil Race:
> The fix looks fine to me. One thing. The test is
> in closed just
sorry to sound like a broken record, fix looks fine,
regression test needed. In this case I don't think we
have one .. I suppose in this and the last case too it
could be that adding noreg-jck might be sufficient but
a regression test would be better for various reasons.
-phil.
Roman Kennke wro
I will add/open-existing regression test for that, just like I'll do for
the other fixes I sent today.
/Roman
Am Montag, den 30.11.2009, 20:52 +0100 schrieb Roman Kennke:
> This is a relatively simple fix for 6896335. When I did the change to
> GraphicsEnvironment initialization, I missed this s
Like the last one, this could use a regression test - even though
there's a JCK failure. FWIW a trivial one like this :-
import java.awt.*;
import java.io.File;
public class CreateFontSMTest {
public static void main(String[] args) throws Exception {
System.setSecurityManager(new Sec
This is a relatively simple fix for 6896335. When I did the change to
GraphicsEnvironment initialization, I missed this small line that's only
executed in headless mode, leading to weird exceptions...
http://cr.openjdk.java.net/~rkennke/6896335/webrev.00/
Ok to commit?
/Roman
> Could we agree on a slightly more formal reply like 'Go commit', 'Ok,
> but wait for one more review', or do we always stick to the 2 reviews
> rule?
I was assuming a second reviewer would pipe up, then you'd go commit.
In general I'd say that
- we do prefer two reviewers but there are cases
Hi Phil,
> The fix looks fine to me.
Good. :-)
> One thing. The test is
> in closed just because no one got round to moving it to open.
> At least I don't see any reason it can't be opened up.
> Now would be a good time and it can be included with this
> changeset.
I'll do that.
> Don't forge
The fix looks fine to me. One thing. The test is
in closed just because no one got round to moving it to open.
At least I don't see any reason it can't be opened up.
Now would be a good time and it can be included with this
changeset.
Don't forget to tag it with this additional bug ID.
-phil.
Ro
This patches fixes bug #6904882. As suggested by Phil it puts the whole
static initializer in a privileged block, grouping the existing 4
smaller blocks into one, and importantly including the offending
File.exists() call. This requires to make the static fields non-final.
http://cr.openjdk.java.n
Hi again,
is this ok for committing?
Thanks, Roman
Am Donnerstag, den 15.10.2009, 15:22 +0200 schrieb Roman Kennke:
> Hi there,
>
> Here's a fix for Bug#6888734. One regression test was failing with an
> AccessControlException in new FontManager code. We need to move
> Class.forName() and newIn
12 matches
Mail list logo
