Java适合不适合开发自动化软件

Java 从90年代初期,有人用applet写过写图形监视画面的东西,也仅限于某行业封闭式的项目中,applet也没了前途.,Java发展到2.0后,逐渐走向成熟,虚拟机中运行字节码,在今天的CPU等硬件环境条件下
也是可以胜任做写控制软件的,至少象组态软件这样的"慢速"家伙,Java是可以胜任的.那样,控制室里就没必要是青一色的windows了, 另用java的JNI写过些应用的朋友,给提出些建议,

我的结论是单从编程语言本身来看，Java是最适合开发上位机自动化软件的语言。
先说说为什么目前自动化行业java用得少。
下位机方面：由于单片机没有内存管理电路，不支持动态分配内存，而面向对象的编程语言都需要内存管理电路，致使下位机编程基本上是清一色的C语言。对于PLC开发，则是梯形图为主。下位机要想使用java或C++必须解决内存管理问题。但这样会使成本增加。单片机和PLC本来就是为了解决简单问题而设计的，不需要太高级的配置。
上位机方面：由于java出现得比C++晚，早期的自动化编程多用的C语言，C++可以无缝调用C语言的程序，所以C++出现后的自动化编程是C语言与C++共存的情况。1990年的java运行速率是C++的1/20，而当时的CPU主频还是以MHz为单位的，自动化程序对实时性要求较高，java的低速率使它无法完成任务。虽然java可通过JNI来调用C++程序，但是JNI的编程非常麻烦，不是任何IDE都能够编译JNI的。就算使用JNI，把现有的C++程序重新封装成JNI也是一件非常庞大工程。如果使用JNA，道理和JNI一样，因工程太过庞大而不现实。如果放弃C++的代码，把所有算法在java上重写，代价太高，工作量只会更大。
以上是java没有用在自动化软件的历史原因，但是如果抛开大量的现成算法，重点来看语言本身的特性，现在的局面就和以前大不相同了。
性能方面：目前的主流工控机的CPU是双核心的，主频达到1.8GHz，可以流畅地运行java。而且现在的java有动态编译技术，并不像最初版本那样以解释方式运行，对于高度优化的代码，java性能是C++的1/2，对于未优化的代码，java的性能有时会比C++更好。
工具集：java有大量用于网络通信、数据处理、线程管理的工具，这些是SUN和Oracle定义的的标准java工具集，具有很好的兼容性，也经过了专家的优化。java的用量在上位机程序语言中是最高的，所以java的工具集也经过了大量的实践测试，是可靠的工具集。而C++的现成代码很多并不是由正规的专业机构来设计的，C++的基础工具集太少是造成C++开发难的重要原因。
资源释放：java有垃圾回收器，内存资源会自动释放，不用担心忘记释放内存或引用了无效指针。不管是否忘记释放系统资源，jvm退出时都会统一释放。不像C++那样，如果程序卡死，某些系统资源必须等系统注销或重启才能被释放。
导出的程序文件大小：同样的功能，jar文件的大小比exe文件小得多了。
IDE：java的主流IDE是eclipse，比Visual Studio功能丰富。

数据库解决方案：java可以使用Map来作为数据库使用，虽然C++也有Map，但是C++的Map功能不够强大。大多数C++的电气类程序都用到了SQL数据库，SQL的操作比内存操作复杂，SQL的漏洞也会变成自动化软件的漏洞。而且数据库的性能不如内存。java提供了大量好用的数据结构，可以在内存中处理大量的开关量模拟量等数据。java不只提供数据结构，还提供了每种数据结构的单线程版本和多线程版本。如果确实要用SQL，java与SQL对接也很简单。
人机界面：这里仅讨论自动化程序常用的技术。C++的人机界面一般是MFC、QT及其它开源架构。java中最合适的是JavaFX，但是需要累积项目经验。没有经验又不想累积经验的开发者可以选择swing。swing的窗体设计器直接将设计图转换为java代码，它的好处是便于调试及个性化改造，容易入门。而JavaFX提供更先进的控件，使用SceneBuilder来设计人机界面并生成一个资源文件。资源文件需要在程序中导入，调试难度较swing高，个性化改造更复杂一点。在人机界面方面，很难说谁更有优势，只能说java也有很强的人机界面设计功能。