&lt;plugin&gt;
  &lt;groupId&gt;com.zenjava&lt;/groupId&gt;
  &lt;artifactId&gt;javafx-maven-plugin&lt;/artifactId&gt;
  &lt;version&gt;8.1.2&lt;/version&gt;
  &lt;configuration&gt;
    &lt;mainClass&gt;[main method class]&lt;/mainClass&gt;
    &lt;vendor&gt;[Vendor Name]&lt;/vendor&gt;
  &lt;/configuration&gt;
&lt;/plugin&gt;

あとはそのままビルドすればよい。

maven clean jfx:native

ビルドが終わると target/jfx/native 以下に、ビルドしたOS/distributionに合わせて msi, exe, deb, rpm, dmg ができあがります。

本当であればクロスビルドできてしかるべきなのですが、まだ実現はされていないようです。

これらのパッケージは Widonws であれば Program Files(x86) に、Linux系であれば /opt/ の下にインストールされるようです。

/opt/app-name/ の下には app と runtime の2つのディレクトリがあります。

app の下にはビルドした jar ファイルや依存ライブラリが置かれています。

runtime の下には実行用の jre が配備されています。

実行ファイルにそのまま引数を渡せば jar 実行時の引数としてそのまま渡されます。(-Xmxなどはまだ未検証です）

課題

インストーラーで含めることのできる実行環境は jre なので jdk が必要とされるアプリは実行できない
- 問題になるのは jsp 。jsp のコンパイルに javac が必要なので。
- 切り捨てるのが一番だとは思いますが。
サーバー系のアプリの場合は init script を用意しなければいけない
- 今後の検討課題ですね。

各OS毎の注意点

rpm系
- rpmを作成するときに使われる rpmbuild コマンドのバージョンを確認処理に萎える系のバグがあります。
- LANG=C mvn clean jfx:native などのように、LANGを変更してやればビルドできます。
- http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/ee31427caf20
Windows系
- WiX インストール後、PATHにWiXをインストールしたパスを含めておく必要があります。
Mac系
- Mac持ってないのでこの記事ではそもそも検証していません。

Permalink | 記事への反応(0) | 16:52

2015-01-31

■プログラマの力量は認定試験で判定する世の中になればいいのに

情報処理だけじゃなくて、JavaとかPHPとかオブジェクト指向とかWeb プログラミングとか細かく細分化して、このプロジェクトはC#認定試験とWindows 認定試験をもってるプログラマしか採用しませんとか。

ペーパーテストで分かるのかって言われるかもしれんけど、今の経験年数で測るやり方に比べたら格段にマシになると思うわ。

経験年数10年だから技術力があるってことになっているけど、実際は初心者レベルだとかゴロゴロいるし。

Javaの入門書さえまとに読んだことないだろってレベルの人が飲み会で「Javaに関しては任せられる新人が育ってなくてね」とかドヤ顔で語っていて、サラリーマンだから形だけ顔を立てられるって認識でなくて本人もマジで技術力あるつもりなのかってビックリしたことあるわ。

で、そういう人がプロジェクトの技術的な方針を決めてるから、本当にぐちゃぐちゃで効率悪い。

プロジェクトに応じた各種認定試験に通ってないと、コーディングさせないとか設計させないとかっていうのが常識になったら、最低でも水準に達してないような人がプロジェクトにかかわることは避けられるからね。

まあこれやると、日本のプログラマやSEの60万人のうち、3割とかへたすると半分くらいは仕事できなくなっちゃうんじゃないかって気がするから、実行は無理だろうけど。

このまえJavascriptをコピペだけで10年やっていて初めてまともに勉強したってエントリが何百もブクマを集めてるのをみて、モヤモヤっと思ったから書いた。

Permalink | 記事への反応(2) | 20:06

2015-01-29

■初めてじゃなかったCの思い出

今やプログラミングといえば、Webなどで使われるような高水準スクリプト系言語中心のアプリケーションプログラミングが主流だ。

そんなこともあり、もはや以前の低レベル言語によるシステムプログラミングの苦労など、タダの昔話である。

そこに来て、実際は齧った程度の分際で、性懲りもなくそんな昔話を書いてみる。

今も昔も、基本的に難しい仕事は無茶振りから始まるものだ。

少なくとも10年位前に自分が手がけた(押し付けられた)仕事はそうだった。

大学で初めて触ったC言語しかもポインタ分からないで止まっているような奴に、電文の再配信プログラムを任せたのだから。

客は「遅延が絶対許されないシステムなのでJavaとかPerlとかはやめてねー」とにこやかな笑顔かつ笑ってない目で注文してきた。

そうなるとC/C++くらいしか事実上選択肢がない。

このうちC++は、Java 経験がある自分からしても仕様が膨大かつ複雑すぎて、とても手に負えないと感じ、必然的にCで書くことに。

勿論Cの言語仕様がKR本一冊で収まるほどコンパクトであっても、それが簡単であることを全く意味していないというのを開発早々に思い知らされたのだが。

あ、Cと言えば電文提供側の機関が受信用のスケルトンプログラムを一応は用意してくれていたが、どう見ても電文受信中に接続が切れた時のことを考慮していない内容で、全く参考にならなかった。

その時点で相当ヤバい話である。

コード書きにおいては、例え一人屋台の俺ルールであろうが、コーディング規約のようなものは絶対に必要である。

その時のルールは「gccのオプションに"-Wall"を入れた状態で、Warning ゼロになること」にしてみたが、その途端、日付変更線をまたがない限り退社できない生活が始まった。

というかオブジェクトを使えないだけでも地味に辛いのに、更にCの言語仕様はコンパクトである以上に原始的と言っていい代物で(だから Warningは基本無視できないのだ)、しかも言語仕様以外の環境依存要素が山積していると来たもんだ。

そんな言語でシステムコールだらけのコードかつ複数のファイルディスクリプタの同時監視(即ち非同期でノンブロッキング)しかもマルチプロセスでシグナルもあるよ！とか、お客さんは俺を殺す気か、そもそも完成させる気無いだろとか、今だったら思う(当時はそう思う余裕もなかった)。

仕方なく最初のKRに加えて「UNIX ネットワークプログラミング」をわざわざ東京に出かけてまで買って読み漁った。

後にも先にも、古今東西の名著と呼ばれるような本を、泣きながら読んだのはこの時だけだったりする。

そこまで凄い良書なのになんで絶版になったんだか。

いかし、それでも「子供を殺しても死なない」、かなり前の処理での領域破壊のせいで突然プログラムが止まっちゃうなどなど、やればやるほど問題が出る。

シグナルを受信し、仕様のとおりに処理するのがこんなに難しいのか！と途方に暮れたこともあった。

そして途方に暮れても解決の手段になるような便利なツールもなければライブラリもない。

結局、「ある程度正しく動いたら、あとは出来た所まで」で勘弁してもらってようやく開放されたが、今でも当時の自分の仕事ぶりには全く満足していない。

無駄に頑張ったというか、頑張っただけの仕事であり、折角低レベル実装というCの本領発揮分野の案件でありながら、スレッド、malloc()、可変長引数は遂に習得できなかった。

こういうプログラムって、どうやったら正しく動かせるんだろ。

このような経験を経て、後年、Cやシステムプログラミングを指してギークな人々が

Cはとても高効率ですし、マシンのリソースもドカ食いしません。残念ながら、Cがそれだけの効率性を実現するには、あなた自身が低レベルのリソース管理（たとえばメモリ管理）を手作業でやってあげなくてはならないのです。それだけ低レベルコードがあると、複雑でバグも起こりやすいし、デバッグですさまじい時間をとられることになります。今日のマシンはずいぶん強力になっているので、これは通常は悪いトレードオフです――マシンの時間を少し非効率に使っても、あなたの時間をずっと効率的に使う言語を使うほうが賢明でしょう。