私の仕事では、最近、最大遅延が約1〜2秒の制御アプリケーションのシステムアーキテクチャを完成させました。これは、IPLANを介して通信する小さなARMオンチップボックスに配布されます。
CまたはC++は古典的な制御システム言語であるため、最初はCまたはC++を使用することを想定しています。アプリケーションの実装方法について話し合った後、C ++にはライブラリの数が非常に限られており、内省がなく、開発を遅らせる可能性のある他のいくつかのプロパティがあることがわかりました。それから私の同僚は、Javaがその仕事に向いているかもしれないと提案しました。
コントロールアプリでGCを実行するまでの待ち時間が本当に怖いです。また、アプリが多くの外部リソース（ソケット、ファイルハンドル、外部ライブラリからのハンドルなど）を使用するため、RAIIを削除することにも消極的です。
賛否両論のリストは現在次のとおりです。
C++
+ RAII - Easy resource management - it will be a complex system
+ System language - speed if we cant't find a JIT VM for our ARM
+ No GC - no big worst case latencies from the GC
+ Easy to integrate with some shared mem libs that we have to interface with
- Fewer free as in beer libs
- Lacks introspection - Mapping classes to DB and external data formats (XML)
would benefit from this (ORM /JAXB) approach
- Easy to shoot one self in the foot - hard and expensive to find programmers
which don't make big mistakes
- Memory fragmentation - needs tuning and workarounds
Java
+ Huge amount of libs
+ Introspection - serialization becomes a breeze (see C++ section)
+ Easier to find 'good enough' programmers
- No RAII - Client has to remember finally or you leak
resources. IMO Java programmers tend to ignore this
problem unless they have server app background.
- No System Language - possibly slower although ARMj could alleviate this
- GC - latency might go up (don't know if parallel GC will work - seems that
you might get fragmentation, see note below).
- Need to write JNI for the shared mem libs that we interface with
- Maybe ORACLE will eat us
パラレルGCによるメモリの断片化は、このAMDの記事で言及されています
GCのレイテンシーが問題でなく、RAIIを取得できれば、Javaを使用したいと思います。したがって、RAIIがあり、優れた代替手段として役立つ可能性のある他の言語も調べました。これまでのところ、D、Ada、VB、Perl、Python（C）、PHP、tcl、およびLuaには何らかの種類があるようです。範囲外のコールバックの。おそらくD、Python、ADAがコントロールアプリに適している可能性があるという私の自発的な反応。DとADAが私のお気に入りです。
だから、私の質問は：これについて何かアドバイスはありますか？Javaは実行可能なオプションであり、任意の言語を選択できるとしたら、それは何でしょうか。