<AWT Dev> Reviewer needed - awt/FontClass/CreateFont/DeleteFont test correction

[Phil Race]

Pavel,

The font implementation and tests are 2D. Not AWT. Don't get thrown by 
package names.

I was a bit curious about the real reason for this failure.
I wrote this test a couple of years ago and its never failed before.
I don't see it failing on any 6-open build.
I see it failing only in JDK 7 from b90. That seems to be due to HS18b03 fix
6938627: Make temporary directory use property java.io.tmpdir when specified

I suppose the VM doesn't delete the directory on exit even if empty 
because it
could interfere with other VM instances.

I'm not sure what more the test can do than try to deal with any artifacts
created by some other part of the JRE. As it is, its making sure that 
the tmp
dir is private to its own private JRE invocation. But that doesn't mean the
test and the functionality its testing get exclusive rights to this 
directory.
So I don't think its worth trying to suppress the VM behaviour either.
If the VM or something else changes the name of this file or adds 
another one,
then that's going to require fix up such as this one. Just have to hope its
not a regular occurrence.

So I'm OK with the fix.

-phil.


On 11/9/2010 7:40 AM, Pavel Tisnovsky wrote:
> Hi all,
>
> could anybody please review correction of
> awt/FontClass/CreateFont/DeleteFont regression test?
>
> This test check, if the temporary file containing font is properly
> deleted when JVM finishes. The check is based on counting of files in
> temporary dir - if temporary font file is not deleted, the number of
> files before and after running the test differs.
>
> BUT JVM also creates hsperfdata_* subdirectory so the check described
> above always fails (presence of this subdirectory add +1 to number of
> files). I've added simple filter to resolve this issue. Another option
> is to disable the hsperfdata_* creation at all.
>
> Webrev is available at:
> http://cr.openjdk.java.net/~ptisnovs/DeleteFont_correction/
>
> PS: I'd also like to backport this correction to JDK6 if it is possible.
>
> Thank you in advance
> Pavel T.