【原创】记一个Java GUI程序（原目标OS是Windows）“移植”到Linux的过程

怕有些高手看到我的 Java+移植 关键词，立马走人，我特别说明一下：

我要移植的这个程序，原来是针对Windows开发的、有GUI界面的（Swing）、执行定时任务的单机程序，现在为了运行更稳定（Windows机器经常被人重启），要移植到Linux下，而且不再需要GUI界面。

下面是我的需求和思路：

1，理清程序的执行、调用主线（因为距离程序初次开发已经过去若干年了，需要回忆一下）；

2，理清UI之外的程序主线，程序主体功能与UI的交互；

3，将UI相关程序弃之不用，新写命令行程序调用程序主体功能；

4，修改后，在Windows上调试通过（因为当年开发时是XP时代，现在是Win7+的时代，有些小区别）；

5，在Linux上调试通过。

上述思路在实践过程中，还算比较顺利，毕竟理论上讲，Java程序是天生可“移植”的。所以在移植过程中，主要是一些与OS相关的细节问题处理，有一些事前想到的，有一些没有想到，通通罗列如下：

想到的：

1，路径问题。需要将硬编码的Windows下相对路径，使用File.separator替代；

2，资源释放问题。因为程序执行过程中会写日志，涉及日志文件的释放问题。

在Windows上，需要执行System.exit(0)，日志文件才会被释放，否则，即使程序的GUI界面被X掉，日志文件仍然被锁定（表现为：移不走，删不掉），查看资源管理器，可以看到程序对应的Java虚拟机（java.exe）实例还在。

在Linux下不存在这个问题，日志文件随时都可以从程序外部修改（甚至删除）——甚至程序正在运行中时，日志文件也可以删除。但这样做纯属蛋疼、自找麻烦，log4j不会重新建立日志文件，它直接摞挑子不写日志了——所以可以放心地kill掉程序对应的进程，不执行System.exit(0)没有（至少目前没发现）副作用。

没想到的：

3，DES解密，Windows与Linux不同；有兴趣可百度；

4，进程存在性检测。Linux下比Windows容易得多：假设我的程序叫abc。Windows下，如果你不将程序由abc.jar转为abc.exe（转为abc.exe后执行时，资源管理器会显示一条abc.exe的进程），而是直接执行abc.jar文件，那么它在资源管理器里永远是个java.exe进程，而看不到abc.jar——如果有多个java.exe进程的话，实在无法区分哪个是你的程序！Linux下就容易多了，如果你的程序是java -jar abc.jar启动的，那么它对应的进程就有abc.jar字样，一目了然。

5，本机IP检测，Windows与Linux不同，有兴趣可百度。