Previously discovered Java bugs (JDK 9 and previously unrepaired)

The article was reproduced from the public number: Talking about software testing Author: Jiang Liheng

background

In 15 years of continuous integration at Citic Bank, the platform itself implemented incremental and thermal deployment based on Ant Purchase Java Configuration Development Platform, which was then based on a three-way procurement.

Several of these projects often find that after a successful deployment of Linux platform Windows does not appear, Linux is an occasional phenomenon), the new version of the code does not take effect (decompiling class).

At first I was tracking and debugging Ant plug-in-based code on local windows but I never reproduced it (the final test found that Windows didn't have this bug).

Later, by analyzing the code logic, where the segment logic is determined by the last modification time of the file File.lastModified() to override the deployment, and finally, by single-test discovery, because Java File.lastModified() method in Windows and Linux/Unix platforms get different precision, Windows accuracy is milliseconds, and Linux/Unix can only go to seconds (JDK Bug: JDK-817809).

So it also explains why it is an occasional phenomenon, if the file modification time if the two values are judged to be exactly across seconds, the deployment is successful, otherwise it fails.

Bug reproduction

Test code: FileTest .java

import java.io.File;
import java.io.IOException;
import java.nio.file.Files;
import java.text.SimpleDateFormat;


public class FileTest {
    private static final long LM = 1599276952718L;


    public static void main(String[] args) throws IOException {
        // java版本号
        System.out.println("Java Version：" + System.getProperty("java.version"));


        File f = new File("test.txt");
        f.createNewFile();


        // 设置最后修改时间
        f.setLastModified(LM);


        // 获取修改时间，存在 bug
        System.out.printf("Test f.lastModified [%s]: %b\n",
f.lastModified(), f.lastModified() == LM);
        // 格式化输出，正确不存在 bug
        System.out.printf("Test f.lastModified DateFormat [%s]\n",new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.sss").format(f.lastModified()));


        // Files.getLastModifiedTime() 获取修改时间，同样存在 bug
        System.out.printf("Test Files.getLastModifiedTime [%s]: %b\n",
Files.getLastModifiedTime(f.toPath()).toMillis(),
(Files.getLastModifiedTime(f.toPath()).toMillis() == LM));
        // 格式化输出，正确不存在 bug
        System.out.printf("Test Files.getLastModifiedTime DateFormat [%s]\n",new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.sss").format(f.lastModified()));


        f.delete();
    }
}

Compile and execute from the command line:

# 编译执行
$ javac FileTest.java && java FileTest 

Windows executes the results

This bug does not exist on the Windows platform.

# 编译执行
$ javac FileTest.java && java FileTest
Java Version：1.8.0_202
Test f.lastModified [1599276952718]: true
Test f.lastModified DateFormat [2020-09-05 11:35:52.052]
Test Files.getLastModifiedTime [1599276952718]: true
Test Files.getLastModifiedTime DateFormat [2020-09-05 11:35:52.052]

Mac execution results

The latest version of JDK 8 is still not fixed.

# 编译执行
$ javac FileTest.java && java FileTest
Java Version：1.8.0_261
Test f.lastModified [1599276952000]: false
Test f.lastModified DateFormat [2020-09-05 11:35:52.052]
Test Files.getLastModifiedTime [1599276952000]: false
Test Files.getLastModifiedTime DateFormat [2020-09-05 11:35:52.052]

Linux executes the results

# 编译执行
$ javac FileTest.java && java FileTest
Java Version：1.8.0_171
Test f.lastModified [1599276952000]: false
Test f.lastModified DateFormat [2020-09-05 11:35:52.052]
Test Files.getLastModifiedTime [1599276952000]: false
Test Files.getLastModifiedTime DateFormat [2020-09-05 11:35:52.052]

Official bug link

JDK10 has been fixed, but the previous version is still not fixed.

• bugs.openjdk.java.net/browse/JDK-8177809

The above is a description of the previously discovered Java Bug (JDK 9 and previously unrepaired) by W3Cschool编程狮 which I hope will help you.