「はてな」で医療機器関係のエントリ書いてたら、なぜか限定公開になってしまった。
私よりもっと過激なこと書いているブロガーなんて山ほどいると思うのだが、なんでだ?
こういうことされると、さすがに、信用できなくなる。こちらのサイトの管理人さんのご厚意で、転載させてもたうことになった。感謝。
最近はソフト方面はさっぱりなのだが、Java にまつわる情報の錯綜は視野には入れていた。
Java の主要なステークホルダーも、さすがにこれはまずいと思ったのか、「正しい」情報発信と怪情報是正のためにどこかで Java警察 なる自警団的な組織をつくったとかつくらなかったとか。
でも、経験的にいって、こういう管理の仕方って上手くいかないと思うよ。
別に集中管理が絶対とは思っていないが、利害関係の甘さはそのまま管理の質の甘さにつながるのが世の常。破滅への道は善意で埋めつくされているとよくいうではないか。(さすがに、今、Java にいきなり破滅してもらっては困るわけだが)
実際のコミッターよりもインフルエンサー気取りの連中に変な称号与えちゃってる節があるのはどうかなーと思う。
だから、Java警察というより Java奉行みたいな言い方の方がいいんじゃない?と仲間内では盛り上がっていた。
この場合の『奉行』ってのは「鍋奉行」的な意味合いっす。
別にコミュニティ全体を馬鹿にしているわけではなく、こういうやり方だとどうしても滑稽に見える人が出てくるからだ。
ところで、私は、仕事としてはかつてサーバーサイドの Javaプロジェクトにかかわっていたことがある。たぶん、一番、Java が重宝がられていたとき。
その当時は、こういう状況になるとは誰も予想していなかったと思う。
私よりもっと過激なこと書いているブロガーなんて山ほどいると思うのだが、なんでだ?
こういうことされると、さすがに、信用できなくなる。こちらのサイトの管理人さんのご厚意で、転載させてもたうことになった。感謝。
BMI
最近はソフト方面はさっぱりなのだが、Java にまつわる情報の錯綜は視野には入れていた。
Java の主要なステークホルダーも、さすがにこれはまずいと思ったのか、「正しい」情報発信と怪情報是正のためにどこかで Java警察 なる自警団的な組織をつくったとかつくらなかったとか。
でも、経験的にいって、こういう管理の仕方って上手くいかないと思うよ。
別に集中管理が絶対とは思っていないが、利害関係の甘さはそのまま管理の質の甘さにつながるのが世の常。破滅への道は善意で埋めつくされているとよくいうではないか。(さすがに、今、Java にいきなり破滅してもらっては困るわけだが)
実際のコミッターよりもインフルエンサー気取りの連中に変な称号与えちゃってる節があるのはどうかなーと思う。
だから、Java警察というより Java奉行みたいな言い方の方がいいんじゃない?と仲間内では盛り上がっていた。
この場合の『奉行』ってのは「鍋奉行」的な意味合いっす。
別にコミュニティ全体を馬鹿にしているわけではなく、こういうやり方だとどうしても滑稽に見える人が出てくるからだ。
ところで、私は、仕事としてはかつてサーバーサイドの Javaプロジェクトにかかわっていたことがある。たぶん、一番、Java が重宝がられていたとき。
その当時は、こういう状況になるとは誰も予想していなかったと思う。
Java が栄華を極めていた頃の印象が強いせいなのか、「Java の公的な仕様に従っていれば、望む機能はすべて実現できる」と考えている人が意外に多くて、びっくりした。
で、こういう人たちが Java 警察っぽくなっている状況がなんかイヤっぽい。
最近の Java にはあてはまらないかもしれないが、私が経験した限り、使うのが難しいと感じた局面を挙げると・・・
・TimerTask クラスを用いるとき
・通信のタイムアウトを取り扱うとき
など。
サーバーは堅牢なマシンで常時稼働しておけばいいかもしれないが、クライアントはそういうわけにもいかず、例えば、クライアントPC がスリープ状態に陥った時、確立した通信路は当然破棄されているわけだが、このときの復帰動作は JVM からの戻り値(expired であったり null であったり...)によって何らかの工夫が必要で、これが意外に面倒だった記憶がある。
TimerTask にしても然り。
LAN にぶら下がっているクライアントがせいぜい十数台という程度なら、ここまで考える必要はないのかもしれないが(何食わぬ顔でクライアントを再起動するとかw)、不特定多数のクライアントと通信させなければいけないときなど、そういうわけにはいかないでしょう>新人 (^^)
最後、リアルでの不満がぽろっと出でしまったが、最初のお題はこんな感じにしてみました(笑)。
で、こういう人たちが Java 警察っぽくなっている状況がなんかイヤっぽい。
最近の Java にはあてはまらないかもしれないが、私が経験した限り、使うのが難しいと感じた局面を挙げると・・・
・TimerTask クラスを用いるとき
・通信のタイムアウトを取り扱うとき
など。
サーバーは堅牢なマシンで常時稼働しておけばいいかもしれないが、クライアントはそういうわけにもいかず、例えば、クライアントPC がスリープ状態に陥った時、確立した通信路は当然破棄されているわけだが、このときの復帰動作は JVM からの戻り値(expired であったり null であったり...)によって何らかの工夫が必要で、これが意外に面倒だった記憶がある。
TimerTask にしても然り。
LAN にぶら下がっているクライアントがせいぜい十数台という程度なら、ここまで考える必要はないのかもしれないが(何食わぬ顔でクライアントを再起動するとかw)、不特定多数のクライアントと通信させなければいけないときなど、そういうわけにはいかないでしょう>新人 (^^)
最後、リアルでの不満がぽろっと出でしまったが、最初のお題はこんな感じにしてみました(笑)。
BMI
(追記)その後、Java 信者みたいなのは息してない感じになっている。
最近(2021冬)だと、ロガーとしてよく使われているライブラリの log4j に脆弱性が見つかった。
「やばすぎる」 Javaライブラリ「Log4j」にゼロデイ脆弱性、
任意のリモートコードを実行可能
iCloudやSteam、Minecraftなど広範囲のJava製品に影響か
最近(2021冬)だと、ロガーとしてよく使われているライブラリの log4j に脆弱性が見つかった。
「やばすぎる」 Javaライブラリ「Log4j」にゼロデイ脆弱性、
任意のリモートコードを実行可能
iCloudやSteam、Minecraftなど広範囲のJava製品に影響か
当たり前だが、どんな言語でも実用レベルでバグのない完全な動作環境を提供することはできない。
なぜ「Java は絶対」みたいな雰囲気を無理してまで作ろうとしたのか理解に苦しむ。
なぜ「Java は絶対」みたいな雰囲気を無理してまで作ろうとしたのか理解に苦しむ。
(追記2)現在(2024春)だと Java はサーバーサイドでは生き延びれそうではある。
ただ、デスクトップアプリはオワコンだろう。
今では各種 JDK が公開されるようになったが、主要 OS への対応、特に MacOS (GUI)への対応はその SDK 開発陣のポリシーによる。
まったく配慮していないものもあれば、Arm Mac に対応しているものもある。
この状態で新規に Java デスクトップアプリのプロジェクトを起こすのはかなり無理がある。
コメント
コメントを投稿