RFR [8055915]: (ch) FileDispatcherImpl.truncate0 should use SetFileInformationByHandle [win]
Ivan Gerasimov
ivan.gerasimov at oracle.com
Mon Aug 25 21:34:19 UTC 2014
Thank you Alan!
On 26.08.2014 0:15, Alan Bateman wrote:
> On 25/08/2014 15:37, Ivan Gerasimov wrote:
>> Hello!
>>
>> It is a proposal to reimplement FileDispatcherImpl.truncate0 with a
>> single call to SetFileInformationByHandle().
>> The later is available on Windows starting with Vista & Server 2008 [1].
>> The code should be buildable on XP & Server 2003.
>>
>> The existing test
>> java/nio/channels/AsynchronousFileChannel/Basic.java was used to
>> verify the functionality isn't broken.
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8055915
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8055915/0/webrev/
>
> I think this okay although I think I think a reminder about the size
> of LARGE_INTEGER to be confident that the conversion from jlong is
> correct.
>
According to MSDN [1], LARGE_INTEGER::QuadPart is a signed 64-bit
integer, so it is compatible with jlong.
We already have a few places where QuadPart is assigned from jlong
without any explicit casting.
On the other hand, the long_to_jlong macro is used in some places for
the opposite conversion from QuadPart to jlong, but I don't really see
why it was needed.
[1]
http://msdn.microsoft.com/en-us/library/windows/desktop/aa383713(v=vs.85).aspx
> AsynchronousFileChannel/Basic.java just happens to exercise it so I
> won't update it's @bug.
>
Alright, I'll remove the test from the changeset.
> Best to run the :jdk_nio tests on Windows 32-bit and 64-bit to check
> the change.
>
I've done a control build on all the platforms and made JPRT run all
jdk_nio tests - no single failure.
Sincerely yours,
Ivan
More information about the nio-dev
mailing list