Java が栄華を極めていた頃の印象が強いせいなのか、「Java の公的な仕様に従っていれば、望む機能はすべて実現できる」と考えている人が意外に多くて、びっくりした。
最近の Java にはあてはまらないかもしれないが、私が経験した限り、使うのが難しいと感じた局面を挙げると・・・
・TimerTask クラスを用いるとき
・通信のタイムアウトを取り扱うとき
など。
サーバーは堅牢なマシンで常時稼働しておけばいいかもしれないが、クライアントはそういうわけにもいかず、例えば、クライアントPC がスリープ状態に陥った時、確立した通信路は当然破棄されているわけだが、このときの復帰動作は JVM からの戻り値(expired であったり null であったり...)によって何らかの工夫が必要で、これが意外に面倒だった記憶がある。
TimerTask にしても然り。
LAN にぶら下がっているクライアントがせいぜい十数台という程度なら、ここまで考える必要はないのかもしれないが(何食わぬ顔でクライアントを再起動するとかw)、不特定多数のクライアントと通信させなければいけないときなど、そういうわけにはいかないでしょう>新人 (^^)
最後、リアルでの不満がぽろっと出でしまったが、最初のお題はこんな感じにしてみました(笑)。
最近の Java にはあてはまらないかもしれないが、私が経験した限り、使うのが難しいと感じた局面を挙げると・・・
・TimerTask クラスを用いるとき
・通信のタイムアウトを取り扱うとき
など。
サーバーは堅牢なマシンで常時稼働しておけばいいかもしれないが、クライアントはそういうわけにもいかず、例えば、クライアントPC がスリープ状態に陥った時、確立した通信路は当然破棄されているわけだが、このときの復帰動作は JVM からの戻り値(expired であったり null であったり...)によって何らかの工夫が必要で、これが意外に面倒だった記憶がある。
TimerTask にしても然り。
LAN にぶら下がっているクライアントがせいぜい十数台という程度なら、ここまで考える必要はないのかもしれないが(何食わぬ顔でクライアントを再起動するとかw)、不特定多数のクライアントと通信させなければいけないときなど、そういうわけにはいかないでしょう>新人 (^^)
最後、リアルでの不満がぽろっと出でしまったが、最初のお題はこんな感じにしてみました(笑)。
BMI
コメント
コメントを投稿