Review request for JDK-8016760: failure of regression test langtools/tools/javac/T6725036.java
chris.hegarty at oracle.com
Tue Jun 25 19:56:48 UTC 2013
On 06/25/2013 08:45 PM, Xueming Shen wrote:
> The proposed change for 8015666 is supposed to stop this test failure.
> But as I said
> last time that it may take a while for it to get into the repo. I will
> start the CCC process
> shortly, if there is no objection.
There is no problem here. If 8015666 will resolve the test failure, then
we can simply use 8016760 to add the test to the ProblemList.txt. It can
then be removed along with the other changes for 8015666.
> On 06/25/2013 12:27 PM, Eric McCorkle wrote:
>> Does the fix for 8015666 stop the error from happening? If so, then
>> I'll withdraw this RFR.
>> On 06/25/13 13:50, Xueming Shen wrote:
>>> This is fine to be a workaround for the test case for now. It probably
>>> will need to be
>>> undo-ed after the propose change for #8015666 get integrated.
>>> The proposal for #8015666 is to keep the "existing" behavior of
>>> to return a LastModifiedTime converted from the zip entry's
>>> ms-dos-formatted date/time
>>> field by using the "default" timezone. A new pair
>>> will be added to access the "real" UTC time stored in the zip entry, if
>>> The API doc will be updated accordingly as well to explicitly explain
>>> the source of the
>>> date/time and the its timezone sensitive conversion.
>>> On 06/25/2013 07:03 AM, Eric McCorkle wrote:
>>>> Please review this simple patch which updates regression test
>>>> langtools/tools/javac/T6725036.java to offset the time returned by
>>>> JavaFileObject.getLastModified() with the local time to UTC delta.
>>>> Please note that this patch is intended to address the test failures,
>>>> and that I will be immediately opening a new bug to investigate and
>>>> address deeper issues, and also to properly document the API.
>>>> The webrev is here:
>>>> The bug report is here:
More information about the core-libs-dev