平台差异 ： 穿着Java外衣的Native Command

兄弟自认为对软件开发中平台差异的考虑还是有一定sense，没想到一不留神今天在阴沟里翻了次船，把几个不该有的Defects漏给了下家。

兄弟最近的开发主要使用Java和Script（Windows bat， Unix/Linux Shell）。在UT的过程中，我想Script的code一定要在一个Windows上和一个Linux做UT，而Java code则只需要在Windows上跑一次就行了，因为Java号称跨平台吗。客观来讲，这种想法在大多时候是work的，不过当编写对OS操作较多的程序的时候一定要小心了，不要重蹈我的覆辙。

 

我是写了一个Java程序，去解压一个zip包，解压之前检查一下磁盘剩余空间是否充足，结果在平台差异上犯了两个错误。

1 查磁盘空间

我用的是apache的commons-io-1.4.jar中的org.apache.commons.io.FileSystemUtils.freeSpaceKb(path)去查的磁盘空间。可是，由于我的code问题，我传给这个函数的path值是一个不存在的路径。这个错误在Windows上没有任何不良影响，可是在linux上就抛出了异常。

估计这个函数对于Windows上磁盘空间的查询只要盘符对就ok了。 可是在linux上，这个函数调用了Linux的Native command， "df -k path"去查询磁盘空间，当path不存在的时候，df 返回null， Java Code的解析就出了问题。

 

2 解压ZIP

我是用的java.util.zip.*来解压zip包的。ZIP包里的文件都有很多Entry，Entry都是路径格式的。如a/b/c.txt.

我直接把每个entry写到磁盘上，在Windows上还是好好的，大概由于Entry的分隔符和Windows路径的分隔符是一样的。可是linux上又挂了，解压后的文件变成了/root/a/b/c.txt。a和b都不再是文件夹了，而是，a/b/c.txt整体变成了c.txt的名字。

为了解决这个问题，我在解压的时候特意做了Entry的分隔符做了转换，并且对文件夹Entry，直接用Java创建路径，最后再直接解压文件类型的Entry到已经建好的文件夹里边去。

 

综上，很多Java code，第三方Java 工具，都是披着羊皮的狼，里边说不好就Call了什么Native Command。所以，建议朋友们使用的时候留个心眼，不要忘记做跨平台的UT和FVT。