アカウント名:
パスワード:
書き直すと、どんな御利益が有るの?
そこには.net上で元気に走り回るJavaVMが!
IKVMですね
.netもスタックマシンだがコレも止めるべきっすか?
// っていうかCPU非依存のバイトコードとしてはスタックマシンってかなり優秀な部類では?// どうせ指摘するならインタプリト前提のバイトコードはいい加減止めても良いくらいにしとくべきだと思う
横からですが。今は貴方のおっしゃる通り、JIT全盛で、javaコマンドは標準でJIT&HotSpotを使うでしょ。-Xintを指定して、動的コンパイルせずにインタープリタだけで走らすことは、ほとんどない。なら、いっそインタープリタもバイトコードも切り捨てて、ソースコードから動的コンパイルしちゃえばいいんじゃない?という話かと。インタープリタ前提のバイトコードは、ソースコードそのものを扱うのと大して変わらないしね。バイトコードから逆コンパイルしちゃえばほぼそのままのソースコードが出てくるし。
WORAは保てるし、一度実行すればJITコンパイラ
# それなんてPython。や、私はJavaプログラマであって、Pythonはほとんど使っていないのですが。
CPythonのpycバイトコードのことをおっしゃっているのでしたら、あれはネイティブコードではありませんよ。ホスト環境非依存の、Python Virtual Machineという仮想マシンの上で動くバイトコードです。CPythonには標準で逆アセンブラモジュール dis がついているので、どんなニーモニックにコンパイルされているのかを見ることも簡単です。例えば、
def f(x): return x**2
という関数を逆アセンブルしてみると、
2 0 LOAD_FAST 0 (x) 3 LOAD_CONST 1 (2) 6 BINARY_POWER 7 RETURN_VALUE
となります。Javaで言うと、javacとjavaが一体化されているようなものですね。
ソースコードとバイトコードは1対1ではないですね。そこにバイトコードのメリットがあるかと思います。バイトコードでは実装されているがソースでは分かりにくい機能とかを予約語として定義しなおしたり。
#バイナリからアセンブリ言語へ戻すことはできるけど、だからといって高級言語いらないよねという#話にならないのと一緒かと。
インタプリタで速度を稼ぐ手段が中間言語にコンパイルすることなんだが、分かっているんだろうか。実行時の字句解析や構文解析のコストは安くないよ。だから、環境異存ではないコードを配布するのにソースコードではなく、バイトコードを利用するのは理にかなっている。
実行時に関して言えば、ネイティブコードへのコンパイルはコスト次第なんじゃないかな。コンパイルの時間も然ることながら、メモリの消費もそれなりにある。今のPCの様に潤沢なメモリがある環境だったり、長時間プログラムを動かしたりするなら、インタプリタのメリットは少ないけど、必ずしもそうではない。
そんなことを言っている間に、どんどん計算機の性能は上がっていますよ。組み込みも含めて。バイトコードを生成するコストの比重は、下がり続けている。…これって、将来の展望のお話をしているんですよね?
そういえば、最近は-serverオプションが標準になりましたね。計算機の性能が全般的に上がったから。
君がPCしか見えていないのはよくわかった
将来性という点においても、少なくとも、字句・構文解析のフェーズと実行フェーズを分けておいた方が、拡張性の面で有利なんだから、コンパイラと仮想マシンを分けることは悪い選択ではない。そうしておけば、コンパイラを新たに書くだけで、別の言語で書かれたプログラムを処理することも可能になるし、逆に仮想マシンだけを置き換えることが容易なことは言うまでもない。
ハードウェアの性能向上するからと言って、開発の面でも処理速度の面でも効率的なものを捨てる理由にはならないよ。
> コンパイラを新たに書くだけで、別の言語で書かれたプログラムを処理することも可能になるし、そんな「ぼくのかんがえたさいきょうのさいりようかのうもじゅーる」だけど実際には一度も再利用されたことがない、の典型みたいな例を出されてもなあ。そもそもコンパイラだけ書きなおしたところでここんとこ連発してるVMの脆弱性には無力じゃん。
規模が大きくてハンドリングできないだろうから作り直せと漠然と言われてもね…。何の具体的な問題点の指摘や改善案があるでもないのに漠然と0から作ったとしてもせいぜい新しいぜい弱性を作りこむのがオチじゃないのかと…。
それはどうかな?今でも活発にJava(を使ったアプリ、あるいは言語そのもの)に携わっている人なら、みなそれぞれに改善すべきポイントのイメージは持っていると思うので、議論していけばちゃんと収束すると思うよ。うちの会社でも、Javaを使った業務に携わった人達で小集団活動を組んでブレストしたらけっきょく3〜4個ぐらいのポイントに集約された。もちろん、こまごまとしたことなら100個以上でも出るんだけど、「とにかくこれだけはキチンとさせないと」っていう絶対譲れない改善点というのはそんなに多くない。
で、けっきょく金のはなしに行き着くのですよ。改善すべき課題が間違いなくあって、でもその改善に取り組んでも自分に見返りが来るかどうかさっぱり分からないことに、資金を出す人がいるかどうか。コレ以外の問題はまったくないと思う。資金さえ提供されるなら、取り組みたい人はいくらでもいるはず。っていうか私が取り組みたい。
「あると思う」だけではクダンのセキュリティ専門家氏の言ってることとあんまり差はなくて実際にそう言う項目を調べ上げたり、それらをまとめたところに価値のある情報が生まれる訳で。
で、けっきょく金のはなしに行き着くのですよ。改善すべき課題が間違いなくあって、でもその改善に取り組んでも自分に見返りが来るかどうかさっぱり分からないことに、資金を出す人がいるかどうか。
情報をまとめるにも(人が生きていくのに必要な)金はかかるのですよ。価値のある情報が生まれるにも金はかかるのです。
だったら金にもならない話し合いなんかしてる暇があったら仕事しろよ。
「古いバージョンを使い続けるという選択肢を、奪う」というのはソフトウェアの進化に必要なんじゃないかと思うよ。
バージョンアップで定期的に金を取り続けるから、ソフトウェアは進化するという。新しいバージョンに無理矢理移行させないと、古いものをいつまでも使い続けてしまう。
その具体的なポイントが知りたいです。自分がやらなくても、関われる立場の人がやればいいわけだしね。
実装がまずいことが分かってほかのAPIを作り直したけど、古いAPIも一応残してあります(特にJava2以前の古いもの、あるいはもっと踏み込んでサポート終了したバージョンのもの)、などというのは切り捨てられるのだろうか。
万一えいやっ!と思いきってやれるとすれば、コアな部分をスリム化したり、ソースコードを整理したりできるかもしれない。
1.6 1.7ベースのものがきちんと動く...でいいんじゃないでしょうか。やっぱり1.3や1.4向けのとか動かないと発狂する人いっぱい居ます?そういう人は古いの共存させとけ。自己責任で。
CPUの能力が余ってることが多い昨今。互換性なんてのはVM任せ、みたいな方向に進んだ方が建設的かと。そうすりゃ開発の方向性や進み方なんて、過去に影響されずに済む。OSとか実行の土台が変われば、上のアプリも強制的に道連れという時代じゃなくなってきてるのだし。
それを切り捨てられるくらいだったらMSはとっくにWin32 APIから移行を果たしています。
横から見てるしかないのに勝手にイライラして極論を押し付ける人っていますよね。プロジェクトが少し滞ってくると、デザイナ上がりの役職者がよくこんな状態になってます。
どっちかというと、ここ最近のセキュリティホール Java 6以前のものは脆弱性が見つかっても、しっかりセキュリティーホール塞げていてJava 7に由来したものだけ、詰めが甘いような気がするんだ ・ω・
「Java 6を推奨版に戻して、Java 7 の追加コンポーネントは見直した方がいい」ってのならまだわかるんですが。
楽天が作り直される。或いは楽天のお勉強が無駄になる。
ブラウザに標準装備されます
もうFlashやHTML5があるんで。未署名のJavaアプレットが復権することはないよサイズ削減のためにJava VMを同梱しなくなったはずが同程度に(あるいはそれ以上)ブラウザが肥大化してるのは笑えるけど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
で? (スコア:2)
書き直すと、どんな御利益が有るの?
Re:で? (スコア:1)
そこには.net上で元気に走り回るJavaVMが!
Re:で? (スコア:1)
IKVMですね
Re: (スコア:0)
Re: (スコア:0)
.netもスタックマシンだがコレも止めるべきっすか?
// っていうかCPU非依存のバイトコードとしてはスタックマシンってかなり優秀な部類では?
// どうせ指摘するならインタプリト前提のバイトコードはいい加減止めても良いくらいにしとくべきだと思う
Re:で? (スコア:2)
僕はむしろ、バイトコード+JITに未来というか、現在進行形での良い世界を描いていたので、この意見には?なんですが、
具体的にはどういう話でしょうか?
Re: (スコア:0)
横からですが。
今は貴方のおっしゃる通り、JIT全盛で、javaコマンドは標準でJIT&HotSpotを使うでしょ。-Xintを指定して、動的コンパイルせずにインタープリタだけで走らすことは、ほとんどない。なら、いっそインタープリタもバイトコードも切り捨てて、ソースコードから動的コンパイルしちゃえばいいんじゃない?という話かと。インタープリタ前提のバイトコードは、ソースコードそのものを扱うのと大して変わらないしね。バイトコードから逆コンパイルしちゃえばほぼそのままのソースコードが出てくるし。
WORAは保てるし、一度実行すればJITコンパイラ
Re:で? (スコア:2)
CPythonのpycバイトコードのことをおっしゃっているのでしたら、あれはネイティブコードではありませんよ。
ホスト環境非依存の、Python Virtual Machineという仮想マシンの上で動くバイトコードです。
CPythonには標準で逆アセンブラモジュール dis がついているので、どんなニーモニックにコンパイルされているのかを見ることも簡単です。例えば、
という関数を逆アセンブルしてみると、
となります。
Javaで言うと、javacとjavaが一体化されているようなものですね。
Re: (スコア:0)
ソースコードとバイトコードは1対1ではないですね。そこにバイトコードのメリットがあるかと思います。
バイトコードでは実装されているがソースでは分かりにくい機能とかを予約語として定義しなおしたり。
#バイナリからアセンブリ言語へ戻すことはできるけど、だからといって高級言語いらないよねという
#話にならないのと一緒かと。
Re: (スコア:0)
インタプリタで速度を稼ぐ手段が中間言語にコンパイルすることなんだが、分かっているんだろうか。実行時の字句解析や構文解析のコストは安くないよ。だから、環境異存ではないコードを配布するのにソースコードではなく、バイトコードを利用するのは理にかなっている。
実行時に関して言えば、ネイティブコードへのコンパイルはコスト次第なんじゃないかな。コンパイルの時間も然ることながら、メモリの消費もそれなりにある。今のPCの様に潤沢なメモリがある環境だったり、長時間プログラムを動かしたりするなら、インタプリタのメリットは少ないけど、必ずしもそうではない。
Re: (スコア:0)
そんなことを言っている間に、どんどん計算機の性能は上がっていますよ。組み込みも含めて。
バイトコードを生成するコストの比重は、下がり続けている。
…これって、将来の展望のお話をしているんですよね?
そういえば、最近は-serverオプションが標準になりましたね。計算機の性能が全般的に上がったから。
Re: (スコア:0)
君がPCしか見えていないのはよくわかった
Re: (スコア:0)
将来性という点においても、少なくとも、字句・構文解析のフェーズと実行フェーズを分けておいた方が、拡張性の面で有利なんだから、コンパイラと仮想マシンを分けることは悪い選択ではない。そうしておけば、コンパイラを新たに書くだけで、別の言語で書かれたプログラムを処理することも可能になるし、逆に仮想マシンだけを置き換えることが容易なことは言うまでもない。
ハードウェアの性能向上するからと言って、開発の面でも処理速度の面でも効率的なものを捨てる理由にはならないよ。
Re: (スコア:0)
> コンパイラを新たに書くだけで、別の言語で書かれたプログラムを処理することも可能になるし、
そんな「ぼくのかんがえたさいきょうのさいりようかのうもじゅーる」だけど実際には一度も再利用されたことがない、の典型みたいな例を出されてもなあ。
そもそもコンパイラだけ書きなおしたところでここんとこ連発してるVMの脆弱性には無力じゃん。
御利益は別になさそう (スコア:1)
規模が大きくてハンドリングできないだろうから作り直せと漠然と言われてもね…。
何の具体的な問題点の指摘や改善案があるでもないのに漠然と0から作ったとしてもせいぜい新しいぜい弱性を作りこむのがオチじゃないのかと…。
Re:御利益は別になさそう (スコア:4, 興味深い)
それはどうかな?
今でも活発にJava(を使ったアプリ、あるいは言語そのもの)に携わっている人なら、みなそれぞれに
改善すべきポイントのイメージは持っていると思うので、議論していけばちゃんと収束すると思うよ。
うちの会社でも、Javaを使った業務に携わった人達で小集団活動を組んでブレストしたら
けっきょく3〜4個ぐらいのポイントに集約された。もちろん、こまごまとしたことなら100個以上でも出るんだけど、
「とにかくこれだけはキチンとさせないと」っていう絶対譲れない改善点というのはそんなに多くない。
で、けっきょく金のはなしに行き着くのですよ。改善すべき課題が間違いなくあって、でもその改善に
取り組んでも自分に見返りが来るかどうかさっぱり分からないことに、資金を出す人がいるかどうか。
コレ以外の問題はまったくないと思う。資金さえ提供されるなら、取り組みたい人はいくらでもいるはず。
っていうか私が取り組みたい。
Re:御利益は別になさそう (スコア:1)
「あると思う」だけではクダンのセキュリティ専門家氏の言ってることとあんまり差はなくて
実際にそう言う項目を調べ上げたり、それらをまとめたところに価値のある情報が生まれる訳で。
Re: (スコア:0)
で、けっきょく金のはなしに行き着くのですよ。改善すべき課題が間違いなくあって、でもその改善に
取り組んでも自分に見返りが来るかどうかさっぱり分からないことに、資金を出す人がいるかどうか。
情報をまとめるにも(人が生きていくのに必要な)金はかかるのですよ。
価値のある情報が生まれるにも金はかかるのです。
Re: (スコア:0)
だったら金にもならない話し合いなんかしてる暇があったら仕事しろよ。
Re: (スコア:0)
「古いバージョンを使い続けるという選択肢を、奪う」というのはソフトウェアの進化に必要なんじゃないかと思うよ。
バージョンアップで定期的に金を取り続けるから、ソフトウェアは進化するという。
新しいバージョンに無理矢理移行させないと、古いものをいつまでも使い続けてしまう。
Re: (スコア:0)
その具体的なポイントが知りたいです。
自分がやらなくても、関われる立場の人がやればいいわけだしね。
Re:御利益は別になさそう (スコア:3)
実装がまずいことが分かってほかのAPIを作り直したけど、古いAPIも一応残してあります(特にJava2以前の古いもの、あるいはもっと踏み込んでサポート終了したバージョンのもの)、などというのは切り捨てられるのだろうか。
万一えいやっ!と思いきってやれるとすれば、コアな部分をスリム化したり、ソースコードを整理したりできるかもしれない。
人生は七転び八起き、一日は早寝早起き
Re: (スコア:0)
1.6 1.7ベースのものがきちんと動く...でいいんじゃないでしょうか。
やっぱり1.3や1.4向けのとか動かないと発狂する人いっぱい居ます?そういう人は古いの共存させとけ。自己責任で。
Re: (スコア:0)
CPUの能力が余ってることが多い昨今。
互換性なんてのはVM任せ、みたいな方向に進んだ方が建設的かと。そうすりゃ開発の方向性や進み方なんて、過去に影響されずに済む。OSとか実行の土台が変われば、上のアプリも強制的に道連れという時代じゃなくなってきてるのだし。
Re: (スコア:0)
それを切り捨てられるくらいだったらMSはとっくにWin32 APIから移行を果たしています。
Re: (スコア:0)
横から見てるしかないのに勝手にイライラして極論を押し付ける人っていますよね。
プロジェクトが少し滞ってくると、デザイナ上がりの役職者がよくこんな状態になってます。
というよりは (スコア:0)
どっちかというと、ここ最近のセキュリティホール Java 6以前のものは脆弱性が見つかっても、しっかりセキュリティーホール塞げていて
Java 7に由来したものだけ、詰めが甘いような気がするんだ ・ω・
「Java 6を推奨版に戻して、Java 7 の追加コンポーネントは見直した方がいい」ってのならまだわかるんですが。
Re: (スコア:0)
楽天が作り直される。或いは楽天のお勉強が無駄になる。
Re: (スコア:0)
ブラウザに標準装備されます
Re: (スコア:0)
もうFlashやHTML5があるんで。
未署名のJavaアプレットが復権することはないよ
サイズ削減のためにJava VMを同梱しなくなったはずが同程度に(あるいはそれ以上)ブラウザが肥大化してるのは笑えるけど。