[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2chのread.cgiへ]
Update time : 05/09 22:28 / Filesize : 289 KB / Number-of Response : 1002
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

次世代Javaの動向 2



1 名前:デフォルトの名無しさん mailto:sage [2006/05/18(木) 01:03:42 ]

前スレ
【Java】次世代Java・J2SE1.6の動向【Mustang】
pc8.2ch.net/test/read.cgi/tech/1081698555/

関連スレ
【JavaFive】C#からJ2SE5.xへ進化【TigerShot】
pc8.2ch.net/test/read.cgi/tech/1094891986/

www.itmedia.co.jp/news/articles/0404/07/news018.html


マルチタスク実現へJava言語改良
Sun幹部によると、2005年に一般リリース予定の「J2SE 1.6」には、
Javaバーチャルマシン(JVM)のアプリケーション共有を強化する「分離」機能が備わり、
ローカライズコンピューティング処理実行のための分離が可能になるという。

米Sun Microsystemsは、Javaバーチャルマシン(JVM)内部での
アプリケーションマルチタスク実現に向けてJava言語の改良に取り組んでいる。
カリフォルニア州サンノゼで開催のClusterWorld Conference & Expoで4月6日、同社幹部が明らかにした。

SunのJavaアーキテクト、ムラリ・カウンディンヤ氏によると、
今秋β版が登場し、2005年に一般リリース予定の「J2SE 1.6」には、
JVMのアプリケーション共有を強化する「分離」機能が備わる。
この機能によってローカライズコンピューティング処理実行のための分離が
可能になり、第2のJVMを要求することなくJVM内部でマルチタスクが行えるようになるという。

 またJ2SE 1.6では、Javaプログラム間の高速通信を可能にする
Sockets Direct Protocolのサポートが計画されている。カウンディンヤ氏によると、
J2SEに施された改良は、その後間もなくJ2EEにも組み込まれる予定。

653 名前:デフォルトの名無しさん mailto:sage [2006/08/26(土) 12:53:54 ]
Java SE 6 は、SwingにもJOGLの3Dレンダリングが使えるようになるんだろ。

654 名前:デフォルトの名無しさん mailto:sage [2006/08/26(土) 13:48:54 ]
>>653
それっていいの?
何がどう変わるのさ

655 名前:デフォルトの名無しさん mailto:sage [2006/08/26(土) 13:55:21 ]
今までは3Dを使う場合はAWTにする必要があった。
そのためSwingで使う場合AWTで作られたリソースをバイト配列にして再構築していた。
あとLinuxとかならSwingは高速化するんと違うかな

656 名前:デフォルトの名無しさん mailto:sage [2006/08/26(土) 22:39:37 ]
>>650
にしても、VBなんて開発環境と言語がわんせっとになった言語だよな


657 名前:デフォルトの名無しさん mailto:sage [2006/08/26(土) 22:41:07 ]
>>651
タスクトレイが追加されたりタブのスクロールや移動ができて
かつSWTよりも高速になった時代のSwingだよ。
C++で作られたGUIと比べてもパフォーマンスのほうは大差なくなってきたって事だね


658 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 02:14:20 ]
>>614
別に後追いばかりってわけじゃないぞ
プリミティブ型のboxing/unboxing、拡張for文、アノテーションあたりは後追い感が強いが
Genericsの仕様はC#のGenericsの仕様が決定するだいぶ前から検討されてたし、
今回の関数型およびクロージャの仕様はC#のデリゲートに比べるとかなり良い仕様に
なっていると思う

659 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 02:17:15 ]
Java 7のはっちゃけぶりを見るとJVMを残してJavaを捨てる気まんまんだな

660 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 12:41:57 ]
>>658
後追いといっても、C#とは仕様が異なる感じだな。
アノテーションもboxingも。

後追いのようになってしまったのは、
Java Community ProcessでC#のことをよく知ってる人が
Javaにもこういう機能つけてくれよって提案したからじゃないかな。


661 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 12:42:38 ]
>>659
Javaの何をすてるんかな。

JVMがどう進化するのか楽しみではあるが



662 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 13:45:50 ]
>>661
Javaの構文だけを整理したものが残ると思う

663 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 14:43:35 ]
>>662
何がいいたいのかよくわからないが、
構文を整理したものって一体どういうものを想像している?

気になるので挙げてみておくれ

664 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 14:57:22 ]
getter, setterとか、addListenerのデリゲート化とか。
あとはjava.ioとjava.nioの関係みたいに
互換性のために統合を避けた部分も整理して欲しいし
StackとかPropertiesみたいに設計に失敗した部分も直す。
Javaの資産はD言語みたいに別言語構文を解釈する制御を入れればいい。

665 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 16:54:38 ]
それより何より、配列まわりの型の腐りっぷりをさっさとどうにかして欲しい。

666 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 17:01:18 ]
>>664
> getter, setterとか、addListenerのデリゲート化とか。

たまにJavaスレに紛れ込むドトネト厨だかVB厨かよ。
getter,setterはどうでもいい。その程度ならdelegate化もどうでもいい。
どうせクロージャが追加されるならなおさらどうでもいい。

> あとはjava.ioとjava.nioの関係みたいに
> 互換性のために統合を避けた部分も整理して欲しいし

認識が甘い。そんなとこを統合してどうする。
それとも、整理する必要がどこにあるのか具体的に説明できるか?

> StackとかPropertiesみたいに設計に失敗した部分も直す。
初心者Java質問スレ見てた奴だな?
どう見直すというのか。放置か@Depricatedでいいだろ。


> Javaの資産はD言語みたいに別言語構文を解釈する制御を入れればいい。
Java6ではスクリプト言語を解釈するAPIがあるぞ。

667 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 17:02:20 ]
>>665
それも、Collectionがあれはどうでもいい。
多次元ジャグ配列なんて滅多に使わないし。
無闇に使う奴は設計能力センスが甘いやつだね。




668 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 17:07:32 ]
>>666
> getter,setterはどうでもいい。その程度ならdelegate化もどうでもいい。
おまえの主観だろ?多言語出身者は口をそろえて汚い仕様という

> それとも、整理する必要がどこにあるのか具体的に説明できるか?
現状でBufferを使いこなせる技術者は極端に少ない。
ファイルマップすら知らない奴ばっか。

> どう見直すというのか。放置か@Depricatedでいいだろ。
depricatedなクラスがシステムローダにロードされる時点でおかしい

> Java6ではスクリプト言語を解釈するAPIがあるぞ。
根本的な部分でアイタタタ

669 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 17:11:29 ]
>>668
> 現状でBufferを使いこなせる技術者は極端に少ない。
他は言語環境の改善要求っぽいのに、これは完全な愚痴だな。

670 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 17:12:55 ]
あちこちでdeprecated のスペル間違えているやつがいるな。
同一人物か

671 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 17:15:20 ]
>>669
コンセプト違いの重複した機能があちこちにある時点で要改善だろ



672 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 17:15:54 ]
>>668
> >>666
> > getter,setterはどうでもいい。その程度ならdelegate化もどうでもいい。
> おまえの主観だろ?多言語出身者は口をそろえて汚い仕様という
他言語出身者って、どうせC#やVB, Delphi言語出身者かドトネト厨である
おめえの主観だろw 綺麗な仕様とやらはC#やDelphiのget/set程度の仕様かw
あの程度で綺麗なら、演算子オーバーローディングやunsafeでソースコードが汚くなるのを
どうにかしようとは思わないのか。

> > それとも、整理する必要がどこにあるのか具体的に説明できるか?
> 現状でBufferを使いこなせる技術者は極端に少ない。
> ファイルマップすら知らない奴ばっか。

Bufferはまた別の話だろ。Bufferを使いこなせる奴が少ないのと
配列の型がどうだこうだと一体どう関係があるのか。
Bufferが何のためにあるのかわかって言ってるのか?

> > どう見直すというのか。放置か@Depricatedでいいだろ。
> depricatedなクラスがシステムローダにロードされる時点でおかしい

なにがどうおかしく、どう不具合が出るのか説明できるか?

> > Java6ではスクリプト言語を解釈するAPIがあるぞ。
> 根本的な部分でアイタタタ

お前が痛い。

673 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 17:16:29 ]
>>670
レス元コピって使っただけだ。単語をひらで書けないのは確かだがw

674 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 17:16:37 ]
>>671
> >>669
> コンセプト違いの重複した機能があちこちにある
たとえばどのあたりが?


675 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 17:17:58 ]
>>672
お前が.NET中心でしかものを考えられないことは良く分かった。
そのほかの点についてもお前が無知なだけ。調べろ。

676 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 17:24:23 ]
desktopアプリではflash player >>> JREなのになんでJREはあんなに巨大でなければいけないのか
Java DEとか駄目?1Mくらいのサイズ希望

677 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 17:29:46 ]
flash って desktopアプリ? webアプリじゃなくて?

678 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 17:38:38 ]
>>675
でた厨房にありがちな最後の負け惜しみ逃げ台詞


679 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 17:40:36 ]
>>678そのものがそれなんだけどなw

680 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 17:43:12 ]
はいはいドトネト厨乙

681 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 17:44:34 ]
説明の説明の説明を求められなきゃ分からん位の素人にJavaを擁護されてもな



682 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 17:50:48 ]
意味が分からんよそこ

683 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 19:26:02 ]
>>677
ブラウザーなくても動くし、おおよそのことはできると思うんだけど。
描画は早いし、ビデオやオーディオも強い
ソケットも使えるから、やろうと思えばDBにも直接接続できなくもない。

Java3dみたいのはないが。。。まだ。

684 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 21:46:29 ]
自分の理解が足りないことを棚に上げて.NET厨扱いかよw

685 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 22:00:09 ]
どどんとねっとじゃんぬねっと

686 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 22:09:04 ]
ここはゲイツが悪いということで収めてくれ

687 名前:デフォルトの名無しさん mailto:sage [2006/08/27(日) 23:58:56 ]
できればスティーブ・バルマーにしてくれないか?

688 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 00:11:17 ]
>>683
FlashはAS3で化けたが、描画が早いとかそんなことはない
Javaのほうがはるかに早い
機能が段違いすぎ

少なくともFlashでは単純なものしかロジックは書く気にはならないだろ

689 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 00:11:20 ]
もう、ゲイツには力は無いよ。

そしてマイクロソフトもGoogleに推されている。

いつかマイクロソフトがGoogleの力によって陥落するのも時間の問題。


690 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 00:32:22 ]
力がなくなろうがなにしようが悪いのがゲイツ

691 名前:デフォルトの名無しさん [2006/08/28(月) 01:50:37 ]
ウィリアムさまの悪口を言うなんて
なんて罰当たりな!w





692 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 02:57:40 ]
何でいきなりクソスレ化するんだよ

693 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 04:12:03 ]
必要な機能なら誰かが外部ライブラリで作ってくれるさ
本当に標準に必要なのは何かもうすぐコアライブラリのシュリンクが
入ってもいいんじゃないかと思う
SEが肥大化しすぎていると感じる今日この頃

Jakartaでいいじゃん、っていう機能がコアに
取り込まれてる気がしてなぁ・・・・
まぁ使う側からいえば、ライブラリ追加しなくて楽なんだが
それよりむしろ外部ライブラリを簡単に利用できる
仕組みの方が欲しいかな、JWSのライブラリ取得の仕組みを
もっと積極的に活用してもいいような気がする

694 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 05:31:07 ]
言語仕様で縛って遅くする+ライブラリを肥大化させて互換環境を作りにくくする、
ってのがお日様の戦略なんだろ

695 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 08:57:30 ]
特定の言語が腐ってるとかAPIが腐ってるとか言う奴がよくいるが、
お前が言うところのその程度の腐れが、仕事上でダメージを与えるシーンが
あったのか?そういうことが影響を与えるほど、センシティブな職場で働い
てみたいよw

今まで困ったことの例:
・馬鹿なプログラマが意図不明な長大コードを混入させ、そこにバグが
 あったため解析と修正を任された…
・頭の悪い上司から仕様不明目的不明イミフメイの処理の実装を指示された…
・自社の自称エリート技術者ドモが、利用者側の要求と全く合致しない
 フレームワークの利用を押し付けてきた…
・どこぞの営業が経歴詐称して素人をプロジェクトに押し込んできた…

問題は全部、人依存でした…orz

696 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 09:14:54 ]
問題は人なんだとしたら、Javaだと開発効率が良くバグも少ないというのは妄想。

697 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 10:11:18 ]
>>694
そこまで斜めに見なくてもいいんじゃない?
じゃ、ばっさり互換性切り捨てるのがいいってわけでもないと思うが
バージョン変わったら名前は同じだが、まったく違う言語になるよりいいかと。。。

698 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 13:05:21 ]
>>697
何でもかんでもコアに入れたがるのは、
俺たちにコントロールさせろ、って宣言だ。

SWT見たいな外圧がないと、
まともな高速化をしようともしないくせに、
ベンチマークのでっち上げだけはうまいんだから。

699 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 14:13:15 ]
次世代のDesktop javaに必要なのは、SWT並みのLAFと、
Swing並みのプログラムしやすさを持ったツールキット。
Windows FormsをJavaから使えるようにできんもんか。

700 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 18:47:54 ]
>>691
ゲイツはウィリアムテルでもなければ
フランスからイギリスを征服したウィリアム獅子親王でもリチャード王の十字軍でもない。

701 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 18:48:39 ]
>>694
そりゃお前の脳内で描かれた陳腐な戦略。



702 名前:デフォルトの名無しさん [2006/08/28(月) 18:49:34 ]
>>698
でっちあげ?たとえばどんなふうに?

703 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 18:50:54 ]
>>699
やっぱりJavaスレにたまに現れるドトネト忠だ。

っていうか、逆にドトネト関連スレにもこういう
イチャモンつけてくるアホって
湧いてこないよね。

まるでドトネト忠は日本にイチャモンつける韓国人や中国人みたいだ。


704 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 20:42:36 ]
>>703
お前はたから見ててひたすら痛いんだけど気づかない?

705 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 22:03:46 ]
誰でもどっぷり浸かると周りが見えなくなるということなのかなぁ

706 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 22:54:35 ]
>>704
イタイのはお前だよドトネト忠w

707 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 23:00:30 ]
救いようが無いなw

708 名前:デフォルトの名無しさん mailto:sage [2006/08/28(月) 23:02:04 ]
>>688
デスクトップでGUI以外そんなにロジックを組む事もないんじゃないか?
逆にswingでこったGUIを作る気になるか?(例えばOS Xのexposeとか)
swingはHTMLのFormの代わりくらいが限度じゃないか?

速度ではアニメーションや透明度を使う場合、圧倒的にFlash > swingだとおもうけど。
いつか実証してみよう。

709 名前:デフォルトの名無しさん [2006/08/28(月) 23:32:37 ]
同じ穴の狢(むじな)

710 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 00:13:52 ]
「〜だと思う」で勝手な持論を展開する人は、何処にでもいるもんだな

711 名前:708 mailto:sage [2006/08/29(火) 00:48:08 ]
でもあれだ、eclipseとかは到底無理だなflashじゃ。
iTunesくらいだったらflashでもいけるかな。



712 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 01:02:30 ]
Javaじゃ60fpsは無理だしな。16.6秒の世界でsleepの分解能が15msて。

713 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 01:04:13 ]
>>712
sleepなんてものつかうなよ

714 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 01:48:30 ]
>>702
どっかのスレで散々議論されてたんじゃないか。
・JITが効果的に利くオブジェクトをほとんど生成しない
ベンチマークでC/C++と同等のパフォーマンスであると主張。
・Java[Runtime]は低レベルのアクセスしまくりでパフォーマンスを改善。
・上記2つをもって、Java[言語]で書かれたコードはC/C++と同等の
パフォーマンスであると主張。
それを信じて(?)Pure Javaでがりがり書かれたEJBのパフォーマンスときたら

715 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 02:48:24 ]
しかしEJBのパフォーマンス問題はJavaだからというよりも
シリアライズが噛むからではあるまいか?

716 名前:903 mailto:sage [2006/08/29(火) 03:00:52 ]
>>713
何を使えと?

717 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 03:19:40 ]
>>716
PC は知らないが少なくともケータイだと一番分解能があるのは Object#wait だよ

718 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 03:56:43 ]
>>714
話途中から変わってない?

JDKのパッケージングの問題(>>698)が、
JavaコンパイラのSunの自慢話に変わって、
そのSunの自慢を原因としてEJBの実装を叩いている。

でっちあげじゃなくて、JavaがC/C++より速い領域は結構あるよ。

719 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 09:14:24 ]
>>714
言っていることが意味不明

> ・JITが効果的に利くオブジェクトをほとんど生成しない
> ベンチマークでC/C++と同等のパフォーマンスであると主張。

JITが効果的に効くオブジェクトをほとんど生成しないなら、
パフォーマンスはむしろ劣化するはずだが、それをもってベンチマーク
でC/C++と同等のパフォーマンスであるとは、どういうこと?

> ・Java[Runtime]は低レベルのアクセスしまくりでパフォーマンスを改善

何の話?ネットワーク、IO、GUIなどの箇所は、確かにネイティブコード(C言語)で書いてあるが、
それ以外のライブラリはほとんどPure Javaのはずだが。あと、そもそも低レベルアクセス
(OSのAPIを直接叩くことか?)すれば、パフォーマンスが改善するってもん
でもない。何故ならJavaからネイティブコードを呼び出すのは、かなりのオーバーヘッドが
かかるから。

720 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 09:33:01 ]
>>718
> でっちあげじゃなくて、JavaがC/C++より速い領域は結構あるよ。
具体例をどうぞ。

Javaの方がパフォーマンスがいいなんて妄想もいいところ。
JVMがCでできてるんだから、CでJVM(もしくはサブセット)を実装して
その上で実行すればJavaより遅くなるわけが無い。


721 名前:デフォルトの名無しさん mailto:age [2006/08/29(火) 10:02:10 ]
>>720
ハハハ・・・・



722 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 10:29:00 ]
>>716
Timer関係+wait関係でおけ
ポーリングしたいのならナノ秒取得するやつ使え

Winだとちゃんと高精度タイマで実装されているぞ
Linuxだとミリ秒の1000*1000倍が返されてたきがした
このへんの制度はVM依存だが、まったく動かないわけではないのでおけ

アクションゲーム関係で60fpsだしたいのなら垂直同期使うわけだし問題なし


723 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 10:56:44 ]
>>710
アメリカにいけば著名人ですらそうだぞ。

I thinkI thinkI thinkI thinkI thinkI thinkI think


 ア イ シ ン ク ッ  !




だ。

論文でもそうだ。さもないと他人の意見をパクった韓国人や中国人
と同等に扱われる。


724 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 11:00:47 ]
>>723
猿真似は日本人のお家芸。

725 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 11:02:47 ]
>>711
Flashは4まではJavaのほうが圧倒的に早かった。
今はしらない。

Javaと違い、Flashでできることは限られている。
あれは時系列で開発してゆくからな。
Javaとは畑も開発スタイルも違う。
Flashは簡単なアニメーションなら高速で処理できる。
だが、三角関数や対数関数、指数関数などを徹底的に
駆使した幾何学模様の描画はどうだろう。
是非とも検証してみてくれ。

ActionScriptを使ってちゃんと三角関数などを使って計算してな。

726 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 11:05:35 ]
>>714
そのEJBのバージョン、
それからプログラムのソースコードや
マシンのスペック、測定データをここに公開する気はないのかね。

まさか古いバージョンのJavaで作られたPetStoreを
例に挙げるわけではあるまい。
もう古くて参考にはならんぞ。

EJBを使ってるところは本当に少ないがな。
多くはEJBの変わりにPOJOを使ってるところばかりだし。
Seasar2とかSping Frameworkとかな。もしくはStruts + Tomcatオンリーとか。
StrtusやJSFすら使わないところも未だにあるが。

727 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 11:07:27 ]
> Javaの方がパフォーマンスがいいなんて妄想もいいところ。
> JVMがCでできてるんだから、CでJVM(もしくはサブセット)を実装して
> その上で実行すればJavaより遅くなるわけが無い。


こういいきる奴は何度も見てきたが。浅はかで何も解って無いというか、
騙されているというか。Javaの進化に乗り遅れて古い知識しか持っていない
オッサンに多いんだな。

728 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 11:08:09 ]
>>722
ナノ秒なら
Java5からも実装されたぞ。

System.nanoTime()

729 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 11:25:25 ]
>>727
そういう小僧は盗んだコードで走る馬鹿だろう?
なんでもおっさん扱いしないでくれよ


730 名前:デフォルトの名無しさん [2006/08/29(火) 11:38:05 ]
みんな自分の信ずる言語・環境を支持すればいいだろ
どうしてJavaスレには他の奴らが荒らしにくるんだ?
他の言語・環境がどんなに素晴らしいのかしらんがスレ違いだ
巣に帰れ!

731 名前:デフォルトの名無しさん [2006/08/29(火) 12:23:15 ]
次世代を語るところだから、どうしても他の言語と比べた改善点とか要望が出るんじゃない?



732 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 13:08:47 ]
>>728
言葉が足りなかったかな
すでに実装されている話なんだし次世代の話題じゃないだろうということ

>>716は細かい制御したいのに5.0のコンカレントAPIすらさわってないんだろうなーとかおもっちまう


733 名前:デフォルトの名無しさん [2006/08/29(火) 13:53:56 ]
>>731
お前はネイディブコンパイラとのパフォーマンス比較を改善点や要望とでも言うのか?
だたの攻撃だろ?違うのか?

734 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 14:04:44 ]
>>730
昔懐かしい「C#って死滅しちゃうの?」シリーズスレで
大暴れしていた例のM$厨では?


735 名前:716 mailto:sage [2006/08/29(火) 14:10:20 ]
>>732

nanoTimeだけじゃアニメーションできなくない?
nanoTimeはsleepの分解能チェックや誤差の補正に使うものかと
結局sleep使わなきゃだめなんじゃないか?
それかObject.waitか。

J2SE6ではDoubleBuffer関係で何らかの改良があると聞いたかが。

そうそうConcurrentは使ってないな。まだ。そんなに必要性も感じてないが。

736 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 15:08:29 ]
>>727
> > JVMがCでできてるんだから、CでJVM(もしくはサブセット)を実装して
> > その上で実行すればJavaより遅くなるわけが無い。
> こういいきる奴は何度も見てきたが。浅はかで何も解って無いというか、
> 騙されているというか。Javaの進化に乗り遅れて古い知識しか持っていない

進化とか古いとか関係ないだろう。CでJavaコンパイラを実装してclassコードを実行するという話をしているのだから
「Javaの方が速い」とならないことは自明なのだが。
恐らく「Javaは実行中にコードの最適化するから速い」とか言いたいんだろうが、
その実装自体はCでできているんだから、どんなにがんばっても「Javaの方が速い」という事態には絶対にならない。
ただ、CでわざわざJVMを再実装するのはコストがかかるから現実的ではないというだけ。

別にそこを認めてもJavaの優位性は変わらないと思うんだけどね。
いつものことだが、JavaしかできないやつはJavaを否定されると自分自身も否定されたような被害妄想を抱くよな。
どっかの宗教団体みたいで嫌だ。いろんな言語触れよ。次世代Javaの議論にも役立つぞ。


737 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 15:32:33 ]
とんでもない勘違いをしている奴がいるぞw

738 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 15:40:53 ]
痛い子が居るなぁ。


739 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 15:43:39 ]
>>736 → 737,738

740 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 15:48:26 ]
>その実装自体はCでできているんだから、どんなにがんばっても「Javaの方が速い」という事態には絶対にならない。

この意味が分からない。絶対と言い切れる根拠はなんなんだろ?

741 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 15:51:25 ]
Javaで作ってスーパーコンピュータで動かせば速い。




742 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 15:54:16 ]
>>740
馬鹿には つ き あ う な

743 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 15:57:28 ]
>>740
> その実装自体はCでできているんだから、どんなにがんばっても「Javaの方が速い」という事態には絶対にならない。
> この意味が分からない。絶対と言い切れる根拠はなんなんだろ?
極論を言えば、
int main(){JavaVM *jvm;JNI_CreateJavaVM(&jvm);jvm->DestroyJavaVM();}
と書けば少なくとも速度は同じになるというだけのこと。
そんなにややこしいことは言ってない。
「JVMがCで書かれている」というのをもうちょっと考えろよ。


744 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 15:59:54 ]
>>741
JVMの役割を知っていれば、わざわざスーパーコンピューターでJavaを使おうなんて考えないよ。

745 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 16:01:56 ]
>743の続き
で、JVMのソースコード中から、実行に不要な部分を削除していけば、
JVMをいじれないJavaよりも、Cの方が速くなる。誰でも分かる話だと思うんだがな。
実際にはそんなところに開発コストをかけるのは無駄だから現実的ではないと言ってるだけ。

頭が悪いのか、それとも宗教にはまってるからなのか。。。

746 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 16:05:00 ]
>>735
nanotimeはポーリング用

定期実行にはTimer方面つかえといっておろう


747 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 16:06:08 ]
> JVMをいじれないJavaよりも、Cの方が速くなる。誰でも分かる話だと思うんだがな。

JVMはCのライブラリィではないよ(笑)

748 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 16:46:20 ]
>>742
あい、了解したw

749 名前:716 mailto:sage [2006/08/29(火) 17:51:39 ]
>>746
アニメーションとかの20msecとかそういう間隔の話をしているつもりだったんだけど、
Timer? ありえなくないか?

750 名前:デフォルトの名無しさん mailto:age [2006/08/29(火) 17:54:46 ]
 

751 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 17:55:17 ]
747はとても親切だ。
暴れてるやつは声を出して読むように。



752 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 18:00:01 ]
>>749
どういう動きかわかってないんじゃない?
基本から勉強したほうがいいよ

753 名前:716 mailto:sage [2006/08/29(火) 18:07:25 ]
>>752
教えてくれ。
Timerも結局waitを使っているとドキュメントされているが、
waitは正確性を欠く、それをnanoTimeとかで確認してスケジュールを補正するのが教科書とおりなのだが、
Timerを使ってしまうと補正ができなくないのではないか?

次世代になってもwaitとかの精度はそんなに変わらないんだろうな

754 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 18:15:40 ]
そこまでわかってるなら問題あるまい


垂直同期にこだわらなければ60fpsにする必要もあるまい
垂直同期にしたら自動的にリフレッシュレートであわせられる

Win32ネイティブでやってるのと状況はかわらんよ

755 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 19:20:49 ]
Windowsのマルチメディアタイマーは1msで寝れたと思うが

756 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 19:50:44 ]
malloc/freeはどうした?>最速厨
JVMは都合のいいタイミングまでガベコレを遅延できる。
これをやると、特にSMPで差が開く。

757 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 20:03:09 ]
蒸し返すな

758 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 20:09:11 ]
>>756
性能を重視するならmalloc/freeをそのまま使ったりなんてせず、
普通は独自アロケータを定義するでしょ。

759 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 20:54:34 ]
>>720は、ぐぐってみたところ、
Javaの方が実行速度が速い例がたくさん見つかったので、
>>736>>743でごまかそうと必死w


760 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 22:55:04 ]
Javaがなんでもかんでも速いというつもりは全然無いんだが、Cで組んだっ
て結局実装の仕方次第だろ。malloc/freeを何度も繰り返すような素のCの
組み方したら、JVMの「そもそもメモリ解放自体めったにしないで確保してる
メモリを使い回す」ような実装より遅くてあたりまえ。

例えばObjective-CはCのサブセットで、コンパイルすれば完全なバイナリに
なるわけだが、メソッド呼び出し速度とメモリ取得・解放速度でJavaのほうが上回る。
これはオブジェクト周りの実装の仕方の差だろ。

そこを意識して力技なパフォーマンスチューニングを組み込んでCでゼロから
作れば、速くなるのも当たり前。

JavaがCより速いとかいう話は、「Cで普通に組んだものより、Javaで普通に
組んだものの方が速いことがある。なぜなら、JVM自体にすでにパフォーマン
ス・チューニングがされているから」という意味だってことがわからないのだろうか。

普通に組んだ時のパフォーマンスの差には意味があると思うけどねえ。

761 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 22:55:23 ]
>>736
C言語原理主義者の言い訳ごくろう。
また「Javaしかできない奴」とステレオタイプ貼り付けとは。
Javaで飯食ってきたかったらJavaしかできないなんてありえんからね。






762 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 22:57:39 ]
>>758
その独自アロケータとやらは、Javaの世代別GCを超えられるのか?
ヒープアロケーションやデアロケーションに、凝った戦略(実行は超高速)
とってるよ、あれ。フリーリスト管理独自実装とか、ショボイことしてい
る間は越えられんでしょ。

763 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 23:03:03 ]
コンパイラやVMの性能次第で、幾らでも早い言語・遅い言語になるわけだが。

言語の特性とコンパイラ最適化技術辺りは最低限踏まえて議論しような。

764 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 23:10:49 ]
マイクロベンチしにくい言語だなぁと思うことはよくある。
例えばN秒間の実行回数が4400〜5200とか異常な数値を出すこともしばしば。
ヒープサイズは-Xms -Xmxともに同じサイズにしても起こすから原因がつかめない

765 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 23:12:15 ]
結局、学生とかによくある卓上理論ってやつじゃないのか?

766 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 23:22:36 ]
机上だと思う。

767 名前:758 mailto:sage [2006/08/29(火) 23:46:35 ]
> その独自アロケータとやらは、Javaの世代別GCを超えられるのか?
越えられるよ。
つーか、JavaのGCとかboehmGCとか、そういう汎用的なメモリ管理実装に
満足できないから独自実装するわけで。

> ヒープアロケーションやデアロケーションに、凝った戦略(実行は超高速)
> とってるよ
それは独自アロケータでも同じ。
そもそも、あるサブシステムでは特定のサイズのメモリを大量にアロケートするとか、
そういうプログラム固有の事情も考慮した上で最適なアロケータを設計するんだよ。

一般道から高速道までいろいろな状況でもそれなりに速く燃費の良いエンジンを作るのと、
サーキット上での速さの極限を目指したエンジン作りとを比較するようなもの。
そもそも設計方針から全く違う。

768 名前:デフォルトの名無しさん mailto:sage [2006/08/29(火) 23:52:47 ]
いずれにしても現実にあるjavaのOOなプログラムは速度の最適化は難しいんじゃないか?
javaだからっていうか、OOだから。

例えば、java3dとか、hibernateとか、

769 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 00:04:22 ]
じゃあ、比較すんなよ。

770 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 00:06:31 ]
>>767はなんかすごそうな職人さんのようですね。
必要に迫られて独自にそういうすごいのを作ったのでしょうが、
凡人・汎用ではjava vmぐらいでいいです。ruby gc thread とか遅くても
ちゃんと答えを出してくれればいいです。

771 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 00:07:08 ]
>> その独自アロケータとやらは、Javaの世代別GCを超えられるのか?
>越えられるよ。
>つーか、JavaのGCとかboehmGCとか、そういう汎用的なメモリ管理実装に
>満足できないから独自実装するわけで。

このように、独自実装厨はチューニングが重ねられた汎用アルゴリズムに
劣る糞コードを生成するわけだ。乙



772 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 00:08:40 ]
Javaの利点はCPUにあわせた動的コンパイルなんじゃないのかねえ。
Cだとターゲットにあわせて自分でコンパイルオプションを指定しないといけないけど
Javaならある意味JVMが勝手にチューニングしてくれるし。

773 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 00:09:33 ]
生産性を意識すりゃなんだって「それなり」の速度だっての。
うざいから他所でやってくれ、マ板でやることじゃないだろ。

774 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 00:23:50 ]
>>768-774 みんなから一斉にツッコミのあらし。なんか知らないけど、笑いが止まらねー

775 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 00:30:06 ]
次世代Javaに速度は強くもとめないということで。

おもいらそれよりSE 6のどこが素敵なのかまとめてくれんか?

776 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 00:38:07 ]
ヒープ共有とタスクトレイはツール促進に繋がると思う。

777 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 00:48:00 ]
Java 5.0 で既に十分高速なので議論しても仕方が無い。
それより、Java 6.0 Java 7.0 に予定されている言語拡張・ライブラリについて語ろうぜ。

778 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 01:08:56 ]
>>11
>プロパティのサポート
>メソッドリファレンスのレポート
>クロージャのサポート
>言語レベルでのXMLのサポート
>JVM上で動作する動的言語のサポート
>スクリプト言語サポートの拡張
>モジュール化のサポート
>Swingアプリケーション開発のためのツールの充実

のうち、今回出てきたのは「メソッドリファレンス(たぶんローカル・ファンクションのこと
だろう)」と「クロージャのサポート」なわけだが、
「プロパティのサポート」はまだ具体例が出てきてないね。

最後のSwingアプリケーション開発のためのツールって
のは、たしかSwingをベースにしたアプリケーション・フレー
ムワークを作るとかだったっけ。

779 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 01:17:25 ]
最後のはただのNetBeansプラットフォームだったりしてな


780 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 01:27:48 ]
# クラスパスのワイルドカード指定

これなw これが一番重要な更新だったりしてw

781 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 01:48:38 ]
ttp://weblogs.java.net/blog/hansmuller/archive/2006/06/jsr_296_bows_sw.html
ttp://weblogs.java.net/blog/hansmuller/archive/ts-3399-final.pdf



782 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 02:59:33 ]
つ ttp://pc8.2ch.net/test/read.cgi/tech/1150286189/

783 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 03:04:55 ]
Swing Application Frameworkって具体的にはどんなの?

784 名前:デフォルトの名無しさん [2006/08/30(水) 03:25:08 ]
>>758,>>767 その経験は選ばし者のみ体験できることぞよ。そこから習得した業をこれからも存分に発揮するが良い。わははははは

785 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 04:34:32 ]
まずJavaをCたらしめているcloseメソッドをなんとかしろよ
まず名前をdeleteに変えてバカに気づかせろ

786 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 06:11:40 ]
>>781
ktkr
いったいここまでたどり着くのに何年かけてんだ?
こんなのNEXTSTEPをSolarisにポートした連中なら最初に気が付いてるだろ

787 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 08:30:02 ]
いやー、これなかなかいい設計だぞ?
今の基準でみると糞みたいなNEXTSTEPのフレームワークと違ってw

788 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 09:15:32 ]
>>756
> malloc/freeはどうした?>最速厨
> JVMは都合のいいタイミングまでガベコレを遅延できる。
分からん奴だな。そのガベコレをCで実装すればいい。
>>759
> >>720は、ぐぐってみたところ、
> Javaの方が実行速度が速い例がたくさん見つかったので、
Javaの方が速いっていうのは、C側ベンチでJavaと同じ事をしていないだけのこと。
Javaの挙動全てをCで実装すればJavaと同じ速度になるのは当たり前だと言ってるだけだ。
>>772
> Javaの利点はCPUにあわせた動的コンパイルなんじゃないのかねえ。
> Cだとターゲットにあわせて自分でコンパイルオプションを指定しないといけないけど
そんなもの不要。CPUにあわせた動的コンパイルをCで書けばいいだけ。
.classファイルを読み込んでJVM上で実行(もちろんJIT付き)するようなCプログラムを書けば、
Javaの方が速くなるなんてことは無いと言ってるだけなのに何で分からんかな。

789 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 09:18:19 ]
必死だな。

790 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 09:22:30 ]
こんなに頭悪い奴だとは思わなかった。

791 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 09:24:23 ]
>>788
いいたいことはなんとなく分かったが、それを言うことで
あんたが何をしたいのかがさっぱり分からん。



792 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 09:28:24 ]
自分の無知の隠蔽

793 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 09:34:40 ]
痛い子が粘着してるな
明日までの辛抱かの


794 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 10:08:05 ]
>>775
しかし、バージョンアップするたびに高速化してるみたいなんだけど。
次期バージョンJava6もPreJITによってかなり高速化が期待できるんでない?
二回目以降のアクセスからはCのネイティブと同じ扱いになってかなり高速化する、みたいな。

795 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 10:10:16 ]
>>792
面白すぎる。
マ板で必死にJava叩きしてるおっさんどもを思い出すw

796 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 11:11:25 ]
>>791
> >>788
> いいたいことはなんとなく分かったが、それを言うことで
このスレで頭がいいのはあんただけのようだな。
> あんたが何をしたいのかがさっぱり分からん。
>>720を理解できない奴が多かったから説明しただけ。
あんたみたいに理解力のある奴ばかりだったらいいんだがな。
>>736に書いた通り、Javaをけなそうとしているわけではないし、Cが素晴らしいなんて言うつもりも全く無い。


797 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 11:16:38 ]
JVMはCで実装しなきゃいけない決まりでもあるの?
Javaチップ上でベンチ比較する場合についてはどう考えてるの?
この場合Cの処理系をまず用意しないとダメだけど…

798 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 11:45:08 ]
>>796
どっかの宗教団体みたいなのはお前のほう。
お前の主張がいったい何になるのか説明できんだろ。
お前の意見が何もプラスにもならないならどっかの宗教団体と変わらない。



799 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 12:46:01 ]
わかったから、アセンブラで書くと最強!
Cはその次!
で良いだろ
実の無い議論しても無駄だろ

800 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 13:19:58 ]
こいつら一体何なんだ・・・

801 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 13:34:54 ]
> JVMはCで実装しなきゃいけない決まりでもあるの?
> Javaチップ上でベンチ比較する場合についてはどう考えてるの?
はいはい、机上の仮説はどうでもいいから、
まずはC,C++で実装された現行のJVMにも性能面でひけを取らない
Javaチップを開発してからまた来てね。



802 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 13:36:25 ]
>>800
Cで1からjvmもどきを書くと現行のJITより高性能をたたき出せる天才プログラマ様らしいよ


803 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 13:37:01 ]
もうお前等来なくていいよ!

804 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 13:41:37 ]
>>720 が悪い。

805 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 13:51:17 ]
> > Javaの利点はCPUにあわせた動的コンパイルなんじゃないのかねえ。
> > Cだとターゲットにあわせて自分でコンパイルオプションを指定しないといけないけど
> そんなもの不要。CPUにあわせた動的コンパイルをCで書けばいいだけ。
まあ、CPUのサポートする命令セットに合わせて実行時に自己書換する、なんて
テクニックは大昔からあるよね。
今だって、多くの動画コーデックはSSE等の拡張命令の有無を実行時に調べて
動的に実行コードを生成したりしてるし。

そういう古くからあるテクニックの一部がJVM実装にも取り込まれるように
なってきた、ってだけの話。

806 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 14:06:40 ]
俺よー、JVMの仕組みよく知らないんだけどJavaって実行時に
何度も実行される箇所はコンパイルしてネイティブコード生成するんだよな?

だから

コンパイル時間 + (CPU最適化コード実行時間 * n) > 386バイナリ実行時間

この式が成り立つ可能性は十分あると思ってる。( n が増加するほどJava有利)

なんかJavaはCを越えられないと言ってる奴はどうも
ネイティブコード生成後もJVMで解釈して実行してると思ってそうなんだが…?

CでもIntelMacのユニバーサルバイナリみたいに全CPUに最適されたコードを含んだ
バイナリを持てばJavaを上回るのは明らかだけど、そんな事してる奴いないよね。

807 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 14:23:54 ]
> コンパイル時間 + (CPU最適化コード実行時間 * n) > 386バイナリ実行時間
>
> この式が成り立つ可能性は十分あると思ってる。( n が増加するほどJava有利)

だから、nが大きくて、CPU毎に最適化したコードによる恩恵が十分得られる場合は、
>805のような動的実行コード生成をC, C++でもやればいいだけの話。
で、こういう手法は机上の空論じゃなく、多くの動画コーデックや
OSカーネル(ページクリアに使うmovntiとか)など、多くの場所で用いられているんだよ。

808 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 14:32:31 ]
>>807
>> >805のような動的実行コード生成をC, C++でもやればいいだけの話。

必ず同じ事ができるとは限らない。

809 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 14:34:51 ]
「JavaがCより速い場合がある」ってのは、同じようなアルゴリズムでコードを書いた場合ってことだろ。
そりゃ、最適化したコードで比べればどんな場合でもCの方が速くなるだろうよ。
でも、その最適化したコードをCで書くのは、コストや能力を考えると現実的に不可能だ。

810 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 14:37:58 ]
> >> >805のような動的実行コード生成をC, C++でもやればいいだけの話。
>
> 必ず同じ事ができるとは限らない。

その理由は?
Cで書かれたJVMにできて、Cで直接書かれたプログラムにできないことって何?
それともJavaチップのことでも言ってるの?(笑

811 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 14:51:14 ]
>>806

コンパイル時間 << ε

ならば、誤差の範囲内として無視できる。

すると、JavaとCとでは速度はさほど変わらなくなる。


また、
Java実行速度 - C実行速度 << ε

なら、ますます無視できる。

ここでεとは非常に小さな値を表し、 <<は<よりもうんと大きな差があることを意味する。
つまりうんと小さくなるという意味。



812 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 14:55:54 ]
で、Cでできるからなんだよ?

813 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 14:57:04 ]
>>810

実例を出すと、ベクトル型スパコン。
Cで書かれたプログラムより、FORTRANプログラムの方が速いとされる。
コンパイラはどちらもCで作られている。

これは、ソースレベルでは同じアルゴリズムであっても、FORTRANで記述
されたプログラムの方が、Cよりも最適なベクトル化できるからである。

コンパイラを同じCで作っても、どこまで最適化できるかは、各言語仕様も
関係してくる。


814 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 15:48:19 ]
あれ、いつの間にここはFORTRANスレになったのかな?

815 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 15:49:14 ]
>>813
だから、{Cで書かれたFORTRANコンパイラ+.Fのソースファイル}を合わせて、
一つのCで書かれたソフトウェアと見なすって話が延々と続いているわけだ。

論理的には正しいが、実効的な意味はない。
ってのが>>736の最後のパラグラフの意味だと思われ。

816 名前:602 mailto:sage [2006/08/30(水) 16:04:51 ]
>>778
メソッドリファレンスって俺待望の >>602 で書いたようなことじゃないのかね?

だとしたら、あと5年はjavaを使おうかと思うな

でもSE7からなのか。。。

817 名前:デフォルトの名無しさん mailto:age [2006/08/30(水) 17:09:12 ]
>>788
> >>756
> > malloc/freeはどうした?>最速厨
> > JVMは都合のいいタイミングまでガベコレを遅延できる。
> 分からん奴だな。そのガベコレをCで実装すればいい。

不可能。メモリ関数の使用を禁止せず、ガベコレを実装できない。
メモリ関数の使用を禁止すれば、ソースを書き直さなければならず、
もはやCのプログラムではなくなる。だから、JavaやC#のような新しい
言語ができたことを理解しろ。

818 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 17:15:04 ]
>>817
へー、Boehm GCを使ったCプログラムはCのプログラムではないんだ。

819 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 17:25:20 ]
>>818
ベタベタなコードにコンサバなGCで体裁繕ったらパフォーマンスでないぞ
いい加減みっともないまね続けるなよな



820 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 17:31:01 ]
>>817
> 不可能。メモリ関数の使用を禁止せず、ガベコレを実装できない。
JVMはどうやってガベコレを実装してるの?

821 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 17:33:30 ]
>>807
つまり、普通の人はそんなの作らない&作れないから、
凡人が高速なプログラムを作ろうとしたらJavaで書いて実装した方がいいって事だよね。

理論的にCオンリーの方が早くなるっていうのは別に、誰も否定しないと思うけど
現実的にJavaの方が早くなる【場合がある】っていうのを認められないのは厨房だと思うな。



822 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 17:34:27 ]
>>820
メモリ関数使ってるに決まってるだろ。馬鹿じゃねぇの?

823 名前:デフォルトの名無しさん [2006/08/30(水) 17:38:48 ]
Javaの人は、Cはほどほどに教養程度なんじゃない?
詳しかったらJavaの環境に居ないで、Cの環境(Win32やUnix)に行ってるでしょ。

せいぜい jni 程度でゴニョゴニョで、gc 実装とかそんなディープ話題は
次世代Java環境が気になるJava使いの人はついて来れないと思う。

824 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 17:42:27 ]
>>823つまり冷やかしもほどほど程度にしとけってことかな?

825 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 17:47:11 ]
言語仕様も関係するが、それよりも実行形式の抽象度の違いによるんだよ。

826 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 17:50:09 ]
>>823
当然、おまいはGCの実装経験がある or 実装できるのだな。
各種GCアルゴリズムについて語らないか?

827 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 17:54:35 ]
>>822は叩かれてる人?泣きそうになってるみたいだけど

828 名前:デフォルトの名無しさん [2006/08/30(水) 18:09:04 ]
>>807
>だから、nが大きくて、CPU毎に最適化したコードによる恩恵が十分得られる場合は、
>>805のような動的実行コード生成をC, C++でもやればいいだけの話。
>で、こういう手法は机上の空論じゃなく、多くの動画コーデックや
>OSカーネル(ページクリアに使うmovntiとか)など、多くの場所で用いられているんだよ。

if(SSE2命令が利用可能か?) {
// SSE2命令を利用したインラインアセンブラによるコード
}
else {
// SSE2命令を利用しないインラインアセンブラによるコード
}

これのどの辺りが動的実行コード生成になるのか説明してくれんか?
無知は怖いね。

829 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 18:52:56 ]
高速化高速化いうてるけど
1.4.2のが5.0より速いらしいぞ
SUNのベンチ鵜呑みにするなや

830 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 18:56:32 ]
>>828
ほらよ。
ttp://mkosaki.blog46.fc2.com/blog-entry-104.html

831 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 19:08:15 ]
> せいぜい jni 程度でゴニョゴニョで、gc 実装とかそんなディープ話題は
> 次世代Java環境が気になるJava使いの人はついて来れないと思う。

だろうね。
というか、そういう話をこのスレでやるのがそもそも間違い。
パフォーマンス厨は↓へ行ってくれ。
pc8.2ch.net/test/read.cgi/prog/1153547716/




832 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 19:41:39 ]
>>823
いまどきそうやってCはJavaよりも凄く、
「Cを知っていればJavaを知らなくても偉いんだ!」
と勘違いしてCしか知らず、Javaのことろくに勉強しないのも、恥ずかしいことなのだが。


833 名前:デフォルトの名無しさん mailto:sage お約束 [2006/08/30(水) 19:49:41 ]
いまどきそうやってJavaはCよりも凄く、
「Javaを知っていればCを知らなくても偉いんだ!」
と勘違いしてJavaしか知らず、Cのことろくに勉強しないのも、恥ずかしいことなのだが。

834 名前:デフォルトの名無しさん [2006/08/30(水) 20:04:14 ]
いまどきそうやって技術は一般常識よりも凄く、
「技術を知っていれば一般常識を知らなくても偉いんだ!」
と勘違いして技術しか知らず、一般常識のことろくに勉強しないのも、恥ずかしいことなのだが。

835 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 20:08:04 ]
>>833
お前よ、餓鬼みたいに>>832のコピペしてるのどっかで見たことがあるぞ。
C#死滅スレのVBとC#を崇拝する、継承嫌いの餓鬼だろw


836 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 20:08:49 ]
>>834
まてまて技術は一般常識の範疇に入るぞ

837 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 20:12:42 ]
いつまでたっても馬鹿が釣られまくっとるな
ガキが相手するから正常化せんのだが能無しには分からんか

838 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 20:29:39 ]
>>828
プ
無知は怖いね。

839 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 20:54:06 ]
嵐が過ぎた後は誰もいなくなっている悪寒。

お前らCがJavaより早くJavaはCより早いのは分かったから
メソッドリファレンスが何なのか情報提供してくれ。

840 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 21:01:00 ]
>>837
奴はVBとC#に詳しいアホだよ。
昔、語尾に「嘲笑激藁」「ププ」「ゲラ」「ワラ」「大爆笑」
をつけてた奴、ハンドルが「255」とかつけてた奴に
非常にそっくり。

結局あそこまでC#を持ち上げても、全然はやらなかったな。
どうせ奴は鬱憤晴らしにスレを荒らしてるだけだろう。


841 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 21:03:33 ]
>>807
つーか、動的生成云々うるさいけど、それってモジュール切り替えでええんじゃないん?
実行時生成なんてしなくても、コンパイルしたモジュールも含めればいいだけの話。

C使いでもめったに使わない技術を得意げに語るのは哀れですらある。

Java厨だってバイトコードの自力生成なんて滅多にしない。



842 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 21:04:55 ]
レスすんなカス
どこまで脳みそゆるいんだ

843 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 21:07:33 ]
>>787
いやー盛り上がってるとこ悪いが、20年経ってその台詞恥ずかしくないかw

844 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 21:13:58 ]
ところでJavaCardって何に使うの?
Java OneとSUNのシンクライアントでつかうくらいしか聞いたこと無い。
Edyのがすごいよ、コンビニ清算最速ってすごくね?

845 名前:デフォルトの名無しさん [2006/08/30(水) 21:15:41 ]
ココの住人には>>823は図星なのか?
みんなずいぶん喰らったみたいけど大丈夫か?

846 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 21:16:00 ]
>>813
C言語にポインタがあるために、ベクトル化による十分な最適化ができないが、
FORTRAN言語にはそのポインタがないので、十分にベクトル化できると聞いた
ことがある。

Java言語が出たとき、JavaもポインタがないのでFORTRAN並に最適化できる
のではないかという極端な記事が、Cマガジンに載っていたような覚えがある。


今となってはJavaの仕様では、FORTRAN並に最適化は無理なのは自明だが・・。

847 名前:デフォルトの名無しさん [2006/08/30(水) 21:17:28 ]
>>841
バイトコードの自力生成ってできたの?しらなkった。
ところで、どうやってやるの

848 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 21:19:42 ]
図星ってのもあるが正直どうでもいい
特定環境に最適化されたGCなんて興味ないなって感じ

849 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 21:20:32 ]
>>830
オイオイ、必死に何か探してきたと思ったらコレだ。
自己書き換えと動的実行コード生成は似て非なるものなんだが。

850 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 21:32:51 ]
>>847
適当なバイト列を作ってClassLoader#defineClass()を呼ぶだけだ。
そのバイト列はJavaVM仕様に合わせて作ればいい。
BCELやasmなどのバイトコード作成用ライブラリもある。

Java5からはClassLoader側で細工しなくてもバイトコード変換ができるように
java.lang.instrumentパッケージ以下のクラスが追加された。

851 名前:デフォルトの名無しさん [2006/08/30(水) 21:54:51 ]
>>850 しらなかった、あんがと。Jakarta BCELを読んでみる。



852 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 21:59:14 ]
>>851
正直言って、BCELは設計が古いというか微妙に使いにくいので、
新規ならASMかJavassist使った方が良いかと
他言語 -> Javaバイトコードのコンパイラ作るなら、Javassistはちょっと使いにくいが

853 名前:デフォルトの名無しさん [2006/08/30(水) 22:09:50 ]
今BCEL読んでる最中だけど、これってすげーな。
この技術と言うか概念というか、次のリリースでスクリプト言語を
java vmに取り込むとか言うのより、さらに高次元の話じゃん。

854 名前:デフォルトの名無しさん [2006/08/30(水) 22:32:11 ]
大体概要は分かったけど、すごかった。こういうツールが整備されて
徐々に万人向けに使いやすくなっていくと、これからも OSに依存しな
い Java の環境がより強固なものになっていく予感がする。
昔Sunが目指していたNetworkがどうのというやつなのかな。

> 他言語 -> Javaバイトコードのコンパイラ作るなら
>>852さんはこういう系の人なのでしょうか?
そうとは知らずに、言葉遣いが足らず失礼しました。

855 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 22:50:38 ]
>>854
852だけど、一応そういう系の人です。Java VM上で動作する
とあるスクリプト言語開発してます。超マイナーな言語ですが
一応どんな言語かというと、Javaに似たセマンティクスに
スクリプト言語っぽいシンタックスシュガーをふりかけました
みたいな言語です

> 言葉遣いが足らず失礼しました

?別に特に>>854さんが失礼な言動をしたとは思わなかったけど

856 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 22:54:35 ]
あ、ひょっとしたら誤解してるかもしれないんで一応いっておくと
>>850さんと>>852(= >>855)は別人なんで

857 名前:デフォルトの名無しさん [2006/08/30(水) 23:31:46 ]
   いや〜、やっぱりここにはいろんな人が来てるね〜
\_____ _______________
         ∨ | 
           | まいど、まいど!繁盛、繁盛!!
           \_ ___________
  __          ∨
/  /|       ∧_∧       
| ̄ ̄|/|       (・∀・ ) (   
| ̄ ̄| | ̄ ̄ ̄|\_(_   )_ (・∀・: )Java は さいきょう じゃ
| ̄ ̄| |___| ∧_∧  ̄ ̄ ̄ ////|
| ̄ ̄| |___|(    )____| ̄ ̄ ̄|/|
| ̄ ̄      ( ○  )      ̄ ̄ ̄|  |
|         | | |          |  |
|           (_(_)          |/


858 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 23:44:50 ]
ここで思ったんだが、JVM用のC言語を書くってのはどう?

859 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 23:47:50 ]
>>858
JVMしか作成できない言語を作るの?
どんなメリットがあるの?

860 名前:デフォルトの名無しさん [2006/08/30(水) 23:53:53 ]
ちょっとだけスレを読んでみたけど、
ガベコレ実装しそうな職人とか、
サーバー用ツールと次世代Javaの関係が気になる人とか、
クライアント用(携帯アプリ)の開発者とか、
コンパイラ作る人とか、
CマンセーなのにJavaが気になる人とか、
JVM上で動作するスクリプト開発者とか、
いっぱい居て楽しそうだね〜♪

861 名前:デフォルトの名無しさん mailto:sage [2006/08/30(水) 23:55:09 ]
>>859
ごめん言葉足らずだったね
JVM上で動くバイナリを吐くC言語だ



862 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 00:10:41 ]
>>861
> JVM上で動くバイナリを吐くC言語だ

Cのソースからクラスファイルを作るということ?

863 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 00:20:12 ]
>>855
ちょいと質問なんだが、JRubyやJPyton、GroovyやJavaScriptじゃだめだったの?
独自スクリプト言語を新規開発するに至る動機はナンデスカ?

864 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 00:54:34 ]
「独自スクリプト言語を新規開発する」どころか、
「独自スクリプト言語を新規開発するためのフレームワーク」が出て来ているのに、
そんな質問するに至る動機はナンデスカ?

せめてどんな特徴があるんですか?くらいにしてくれよ


865 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 00:56:48 ]
>>862
そんな感じ
それなら単純にJava言語とC言語の比較が出来るだろ

866 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 01:01:57 ]
>>861
そんな無意味なものを誰が使うんでしょうか。

性能上の要求が高くて、高級アセンブラを使うリスクを拾わなきゃいかん場合に、
仕方なくCを使うのであって、要求が低くてJavaなり何なり使って手抜きできるな
ら、手抜き言語使うんじゃないの。

867 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 01:02:58 ]
> それなら単純にJava言語とC言語の比較が出来るだろ

言語仕様そのものを比較するわけじゃないから、意味なくない?

868 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 01:07:26 ]
>>863 私の野生の勘ですが、javascript かjrubyの開発関係の人ですよ、きっと。もしくは学者先生。だからそそうのないように・・

869 名前:sage [2006/08/31(木) 01:18:44 ]
>>868
なんで2chで書きこみのリアル人生に気を使う必要があるんだと小一時間(ry
大体、そんなエライ人がこんなところでクダまくかいな。

870 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 01:20:32 ]
>>855
JVM系のスクリプト言語は多くが動的型で、パフォーマンスがJavaに比べて劣るから、
静的型でJavaと同等のパフォーマンスを保ちつつ、手軽に書ける言語が欲しかった
というところ
実際、簡単なベンチマークとってみたら、Javaとほとんど同等の速度が出てた
まあ、セマンティクスがJavaに極めて近いから、速度出るのは当たり前なんだが
とはいえ、予定していた言語仕様はそれなりに実装できたものの、ライブラリをまだ
全然作ってないので、Javaのライブラリを使うしかないという情けない状態になってるが

871 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 01:27:29 ]
>>870
よくわかりませんが、それって、例えばGroovyみたいな言語
→JVMバイトコードのコンパイラ作ったってことですか?



872 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 01:27:45 ]
>>858,>>861-862,>>865-867
現時点での実用性で考えると、いらない、意味無いというのは当たり前だと思う。

現状の、Java VMが各OS上のの単なる1サービスや1アプリケーションと考えると
無意味だけど、これとは逆に各OSはJava VM上の1アプリ・1コンテンツと考えると、
状況は変わってくるんじゃないかな?
よく言うところの、ネットワークをでかいプラットホーム見立てて各OSはJavaの環境
で統一って言うやつ。

ちなみに私は>>858じゃないよ。


873 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 01:28:06 ]
>>869

855だけど

> 大体、そんなエライ人がこんなところでクダまくかいな。

まあ、そりゃそうだわなw
リアルではただの大学院生です
ただ、エライ人でも興味ある分野のスレ見てる人は結構居るみたいですが

874 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 01:29:30 ]
>>871
そういうことです
しかし、自分が言えたセリフじゃないが書き込みのペースが早いなw

875 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 01:31:55 ]
>>867
だって、JavaとCの比較ならおかしくないだろ
JITとAOTのどっちが早いってだけの話なのか?


876 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 01:36:29 ]
なんか知ってるかもと思ったので質問。

Java6のHotSpotコンパイラでエスケープ解析が入るのが売りの一つらしい
けど、スタックにオブジェクトが積めるようになるとそんなに性能上がるの?

世代別GCならヒープへのオブジェクトの確保解放はたいしたコストじ
ゃないし、どうせ短寿命なら初回MinorGCでedenからさようなら〜なので、
なんかイメージつかないんだけど、ナニがどう軽くなるんでしょう?

877 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 01:43:02 ]
ところで、JVMで動作するC言語の処理系だけど、既にあるよ
JVMで動作するっていうか、C言語 -> Java言語のプログラムへの
トランスレータだけど。C2Jでぐぐってみるといいと思う

878 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 01:45:47 ]
>>875
静的コンパイルとHotSpotでどっちが早いというのがテーマなのかねえ…
「HotSpotコンパイル」の中身がどんな最適かなのかわからないことには、
なんともかんとも。

879 名前:デフォルトの名無しさん [2006/08/31(木) 01:49:48 ]
もしスクリプト言語作るなら、
個人的には数式処理・代数処理程度で、
それをevelする程度で十分なんですけど。

複素数や行列の独自表記ができたり、(a+b)^2と書けたり
多項式展開や因数分解できたりとかです。

Java VMで動くバイトコードコンパイラ、スクリプトコンパイ
ラ?を作る意義・動機と言うのは、そういう特定用途に特化し
た言語を作るのでもありということだと思うんですけど・・


880 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 03:49:03 ]
C言語厨である>>841はなぜJava似のC++も使いこなせ
なかったんでしょう


881 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 03:50:11 ]
>>844
Javaカードは、
住民基本台帳カード、
大日本印刷が作ったカード、
海外の国民健康保険カードに使われているよ





882 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 04:24:32 ]
>>876
そりゃヒープに取らないで済めば、その分処理が軽くなるでしょう。
ヒープはGC含めてなんだかんだで競合が多いので、
C10Kな時なんかには効いてくる。object poolもしないで済む。


883 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 05:56:41 ]
>>877

そのトランスレータ使える? たった一行のCのプログラムもとんでもない量のJavaになるし、
ポインタ演算している所なんか、酷すぎる。

884 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 07:12:58 ]
>>787
ちょw
まだアプリ間連携もまともにできないJavaなのにw
どうみてもやっと「アプリケーション構成を考えるようになりました」ってレベルだろ?
docs.sun.com/app/docs/doc/802-2112/6i63mn60p?l=ja&a=view
のデリゲートとか
docs.sun.com/app/docs/doc/802-2112/6i63mn62q?l=ja&a=view
のサービスにいつ追いつくのやらw
20年前のフレームワークに負けてるってはずかしくね?

885 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 09:15:02 ]
>>828
> >>807
> >だから、nが大きくて、CPU毎に最適化したコードによる恩恵が十分得られる場合は、
> >>805のような動的実行コード生成をC, C++でもやればいいだけの話。
> >で、こういう手法は机上の空論じゃなく、多くの動画コーデックや
> >OSカーネル(ページクリアに使うmovntiとか)など、多くの場所で用いられているんだよ。
> if(SSE2命令が利用可能か?) {
> // SSE2命令を利用したインラインアセンブラによるコード
> }
> else {
> // SSE2命令を利用しないインラインアセンブラによるコード
> }
> これのどの辺りが動的実行コード生成になるのか説明してくれんか?
> 無知は怖いね。

無知晒し上げ

886 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 09:31:54 ]
最近、各種OSは、
securityがらみでdata領域を実行出来なくする方向だけど、
JIT/HotSpotはそれじゃ困るやね。

887 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 10:01:01 ]
>>883
.いや、たぶん実用にはならないだろうなあとは試してみて俺も思ったけど
まだそういう処理系は無いという前提で話が進んでいるように見えたので、
一応そういうものはあるということが言いたかっただけ

888 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 11:34:40 ]
>>884
なんかcocoaとかで見る名前だね。
あたりまえか。

何でこれがSunにおいてあんだ?

889 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 11:44:02 ]
>>885
ドトネト厨笑えるw

890 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 11:59:42 ]
>>888
OPENSTEP

891 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 12:44:51 ]
>>886
デフォルトが実行不可になるってだけで、
別途実行可能な領域を確保する方法は用意されている。
たとえばUNIX系ではmmap()にPROT_EXECフラグを付けて領域を確保すればいい。

というか、IA32アーキテクチャではNXビットがサポートされるようになったごく最近まで
PROT_EXECフラグの有無にかかわらず常に実行可能になっていたってだけで、
他のアーキテクチャでプログラムしていた連中にとっては今更って話だろうね。



892 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 15:09:33 ]
Java6.0っていつリリースされるの?

893 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 19:36:00 ]
>>888
これSunがSolarisにポートした幻のOPENSTEPのやつだな
俺リアルで使ってたけど、、

894 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 19:56:15 ]
>>1の「分離」とかSockets Direct Protocol
はMustangで実現してなくないか?

dolphinで?

895 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 19:58:30 ]
>>892
そのうち

896 名前:デフォルトの名無しさん [2006/08/31(木) 20:45:38 ]
That house?

897 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 21:11:58 ]
次のjavaではインライン・アセンブラが出来るようなる
らしい・・・

898 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 21:49:05 ]
>>892
Java6.0はリリースされない
リリースされるのはJava6

899 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 22:14:09 ]
>>897
ネタだろうけど、あえて反応してみる。こんな感じか?

public class HelloWorld {
 public static void main(String[] args){
  asm("getstatic java/lang/System.out:Ljava/io/PrintStream;");
  asm("ldc \"Hello, World\"");
  asm("invokevirtual java/io/PrintStream.println:(Ljava/lang/String;)V");
 }
}

しかし、もし仮に本当にJavaにインラインアセンブラが搭載されたとしても、goto
使えるくらいしか利点が無さそう…
バイトコードレベルでは、大した最適化もできんし、JITコンパイラの最適化を阻害する危険もあるしな

900 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 22:45:40 ]
>>899

>>897はネタの匂いがするけど

それだったらJava標準でなくてもすでに誰かが
作ってそうだ。
Java 6ではそれと似たような方式でスクリプト言語をサポートしていたし。
結局、Jakarata OROと同じように文字列のエスケープは避けられないというわけで。
外部ファイルに置いた場合だけエスケープしなくて済むってほうが言語としてまともだね。


901 名前:デフォルトの名無しさん mailto:sage [2006/08/31(木) 23:43:59 ]
コンパイラサポートすんだから普通にやるんじゃないか。



902 名前:デフォルトの名無しさん [2006/09/01(金) 00:06:39 ]
>>892
2006年10月以降?
journal.mycom.co.jp/news/2006/08/31/340.html

903 名前:デフォルトの名無しさん mailto:sage [2006/09/01(金) 06:18:20 ]
>>902
ありがとう!


904 名前:デフォルトの名無しさん mailto:sage [2006/09/01(金) 09:52:57 ]
この秋といってたけど、11月以降が濃厚だな。

905 名前:デフォルトの名無しさん mailto:sage [2006/09/01(金) 11:13:19 ]
Java6の魅力はGUIまわりの強化くらいかね。

アノテーションが増えたって言うけど、どんなもんが増えた?

新たにGenerics対応したクラスも出る?


906 名前:デフォルトの名無しさん [2006/09/01(金) 14:30:24 ]
> JVMはどうやってガベコレを実装してるの?

JVMにはJava言語用に作られたGCがあるだけで、C言語には使えないよ。

907 名前:デフォルトの名無しさん [2006/09/01(金) 14:41:41 ]
>>906あんまり正確じゃないなその表現は。

908 名前:デフォルトの名無しさん [2006/09/01(金) 15:37:41 ]
いつになったら.NET並の速度になるん?

909 名前:デフォルトの名無しさん [2006/09/01(金) 16:00:38 ]
javaと.netは目指しているものが違うから同じように比べてもねぇ

910 名前:デフォルトの名無しさん [2006/09/01(金) 18:50:50 ]
>>908
CLR の仮想関数呼び出しは遅すぎで使い物にならないわけだが。

Pure Java と Pure C# なライブラリを比較すると
明らかに JVM >>>>>>>>>>>> CLR であることがわかる。

911 名前:デフォルトの名無しさん mailto:sage [2006/09/01(金) 19:32:29 ]
>>908
ドトネト並みっていってるが、
ドトネトだってJavaより遅いのは遅いぞ。
どっちもVM上で動いているんだから。

どっちも遅いんだし。

比べるならC/C++とのほうが重みがある。
ドトネトだとVMの性質がJavaと異なるし
得意分野、得意分野が微妙にことなる。



912 名前:デフォルトの名無しさん mailto:sage [2006/09/01(金) 19:39:22 ]
Java6 mustang = null;
Java5 tiger = new Java5();
tiger.swing++;
tiger+=derby;
tiger+=webServer;
Java6 mustang = (Java6) tiger;

こんな感じかな?

913 名前:912 mailto:sage [2006/09/01(金) 19:40:07 ]
最初の一行いらないね。失礼。

914 名前:デフォルトの名無しさん mailto:sagw [2006/09/01(金) 20:48:22 ]
NETが日本で最も普及しているプログラム言語
pc8.2ch.net/test/read.cgi/tech/1156986942/

915 名前:デフォルトの名無しさん mailto:sage [2006/09/01(金) 21:17:57 ]
>>912
Java5型はオブジェクトの型なのか文字列型なのか数値なのか

どっちみちString型の猿まねはできないし++や+=を使えるのは
Stringオブジェクトか数値型だけなのでエラーになるわな。

916 名前:デフォルトの名無しさん mailto:sage [2006/09/01(金) 21:18:20 ]
>>914
つまらんし、根拠がない

917 名前:デフォルトの名無しさん mailto:sage [2006/09/01(金) 21:28:45 ]
>>915
オペレータオーバロードキタ━━━━━━(゚∀゚)━━━━━━!!!!

918 名前:デフォルトの名無しさん [2006/09/01(金) 21:51:25 ]
>>911
わからないでもないが、同じバーチャル・マシンという環境で比べた方が公平だと思うぞ
Cはネイティブ・マシンだろ
またガベコレがどうしたこうしたとかなのか?

919 名前:デフォルトの名無しさん mailto:sage [2006/09/01(金) 21:52:39 ]
ネイティブ・マシン……

920 名前:デフォルトの名無しさん mailto:sage [2006/09/01(金) 22:02:58 ]
そういや、Stringには++使えないんだった。
つーかJavaに演算子オーバーロードなんて期待すべきでないし
勧めるべきじゃない。
C++の二の舞になったC#と同じ道を歩む。
あれは大失敗だった。

921 名前:デフォルトの名無しさん mailto:sage [2006/09/01(金) 22:05:07 ]
>>918
同じVMといってもな、VMは各種ベンダによって速度が異なるし。
IBMが作ったのとSunが作ったのとではJVMの速度やライブラリによる速度も変わってくる。

その辺りも厳密に考えないと逝けない。

そう考えると、面倒だし議論するだけ無駄だと思うんだが。


そういう比較は、こだわると、FFとドラクエとを比較するくらい実にくだらない議論になると思うよ。





922 名前:デフォルトの名無しさん [2006/09/01(金) 22:20:11 ]
>>921わかってるじゃん。

923 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 00:26:08 ]
>>905
1.2〜1.4のようにデスクトップアプリが大幅にパワーアップするようなのはあんまりなさそうだ

5.0以降デスクトップに力入れてますといってるけど、小粒なのが多くて
むしろ力入れてないのではと思いたくなる

924 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 02:48:50 ]
public class Java6 extends Java5{

Swing swing = getSwing().add(new AntiAlias());

DB db = new Derby();

public Java6() throws NotReleasedException{
try{
openSource();
}catch(Exception e){
log.error("やっぱり無理だった");
}
throw new NotReleasedException("もうちょっとまって");
}

}

925 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 03:40:53 ]
しかし.NETのCLRが「速い」というのは初めて聞く意見なんだが、
なんか速くなったのか? ずっと「遅い遅い」と言われ続けてたと
思うんだが。

926 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 10:27:07 ]
>>920
演算子のオーバーロードは便利だよ。演算子オーバーロードじゃなくても、
クラスごとに演算子の動作を定義できるのは便利。
C++のはいけてないけど、pythonのように、演算子ごとに対応するメソッドを
用意する方法ならわかりやすいし、実装も簡単(コンパイラに手を入れるだけで済む)。

Javaユーザは、Javaにない機能はすぐに「あんなものイラネ」とかいいだすから嫌い。

927 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 10:38:16 ]
>>926
> Javaユーザは、Javaにない機能はすぐに「あんなものイラネ」とかいいだすから嫌い。
激同
で、いらないっていいながらJavaに実装されるといきなりマンセーし始めるからもっと嫌い。
Javaは好きだがJavaをまともに使えるのはほんの一握り。大抵は基礎の無い阿呆ばっかだ。厨の割合が高過ぎる。

928 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 10:40:06 ]
少なくともBigなんちゃらや日付時間関係は演算子使いたいよな
文字列だけ砂糖付きはずるいぞ

929 名前:デフォルトの名無しさん [2006/09/02(土) 11:06:01 ]
> 厨の割合が高過ぎる。

そういう業界だろw


930 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 11:30:59 ]
>>928
BigDecimalが対応されたらクライアント用でも業務系での地位は確定するな


931 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 12:11:19 ]
>>926
>>927
そんなもの別にJavaユーザに限った話じゃないでしょ。なんですぐにそういう話になるかなあ
C++ユーザだってよく、Javaに対して、GCなんてイラネとか言っているのは耳にする
ある程度普及した言語には、厨や信者が一定割合でつくというだけの話だと思う



932 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 12:17:23 ]
>>926
演算子っつーと、[] も演算子だよな。
数値計算しないから + や - のオーバーライドはできなくても個人的には困らんけど
MapやListで list.get(0) や map.get("key”) が list[0] や map["key"] と書けるようになるとうれしいなあ。

933 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 12:30:06 ]
listのほうは難しい気がするがmapのほうは現行の構文とかさならないからできそうな気がするんだけどね

とおもったけどキーがIntegerとかでintわたしてオートボクシングとかされると配列とみわけがつかんか

934 名前:デフォルトの名無しさん [2006/09/02(土) 13:41:26 ]
>>926-927
大丈夫か?MSや.Netマンセーなのか?
例えば、そんなのオレは面倒とかを除けば、
やってる事は同じなんだけど、そういうの気がつかないのかな。
プロパティとかインデグザとか。
delegate, eventはいいね。なんともMSらしい。

935 名前:デフォルトの名無しさん [2006/09/02(土) 13:45:56 ]
コンパイラをいじれば、
いつでもできるんじゃないの。
ただ実質同じことだし、
そういう要求をかなえてまで、
面倒くさいぞー系の蛆が溢れると、
Javaの品質が下がるからまだ今もやらないってこと。

936 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 17:43:09 ]
>>926
Genericsは、「あんなものイラネ」と言われたことないよ。


937 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 17:46:46 ]
>>936
Genericsイラネ

938 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 17:50:21 ]
>>937
C厨

939 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 17:58:10 ]
>>933
なんでlistだと難しいのかくわしく。

940 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 17:58:15 ]
JavaもtoStringは演算子オーバーロードできるしな

例えばインタフェースベースの演算子オーバーロードなら
interface Calculateableみたいなのを用意して
Numberと同じメソッド定義しておけば、目的を見失うことも無いだろう。

941 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 18:04:28 ]
>>939
配列と区別がつかないからだろ



942 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 18:33:17 ]
個人的には言語仕様の拡張はしなくてもいいから
VMの性能とデスクトップ周りの強化をしてほしいな・・・

943 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 18:36:08 ]
>>942
それは着々と進んでるだろ。

944 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 20:03:27 ]
>>941
区別はつくよ。むしろなんで区別がつかないと思うのか聞きたいところだ

945 名前:デフォルトの名無しさん [2006/09/02(土) 20:26:27 ]
128bit Java

946 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 20:45:46 ]
>>926
おまえは何も解ってない。
ストラウストラップが警告した事項を

947 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 20:45:57 ]
>>944
もちろんコード全体を見りゃ区別はつくさ
objs[i]と書いてあるときにobjsは配列かListか
すぐには判断できない場面があるわけだ
両者が共通の性質やAPIを持つなら区別できなくても問題ないけどな
実際には配列は固定長だし、APIもlengthでサイズを知るなど異なるわけ
配列を廃止するならともかく両立させるのは混乱の元

948 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 20:47:03 ]
>>926-927は同一人物による書き込みだよな

949 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 20:48:17 ]
>>932
[]は単項演算子みたいなもんだからいいんだよ
+や-となると2項演算子なので
演算子の優先順位を意識するのが大変になるんだよ。
それに他人が作った奴の演算子が混ざったらどうなると
思ってるのか。

950 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 20:49:15 ]
>>932
> MapやListで list.get(0) や map.get("key”) が list[0] や map["key"] と書けるようになるとうれしいなあ。
その程度のことのためだけにそんな演算子を付加するのか。
C#のget/setと変わらないくだらん機能だな

951 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 20:52:14 ]
>>940のやり方なら間違った演算子定義は出来ないからいい。
問題があるとすれば右辺値の一番左の値がプリミティブじゃなかったときくらい。



952 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 21:28:30 ]
>>942
俺的には、Java3Dの強化をなんとかして欲しいな。

953 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 21:29:01 ]
>>947に激しく同意できる。
C++の二の舞になったら終わりだ

954 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 21:30:17 ]
統合アーカイバプロジェクト並みの圧縮ファイル対応とか
デスクトップ周りでやらなきゃいけないことは、まだまだ沢山あると思う
デスクトップ周り専門のApacheみたいなグループが登場しないと無理だが

955 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 21:33:18 ]
BigDecimalで演算子を使えるようにしてくれって要望は、
BigDecimalクラスをラッパークラスとするプリミティブなbigdecimal型を
用意するっていうC#のdecimal型でどうにかするって手もあるが、
あれは、128bits限定だからな。

BigDecimalのコンストラクタにMathContext.DECIMAL128を設定した
精度しか得られないしな。


956 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 21:34:11 ]
>>954
圧縮ファイルで一体何をしたいんだ?
つか、Jakarta Commonsにそれっぽいのないか?
もしくはSourceForgeにありそうだが

957 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 21:39:17 ]
何がしたいって聞くようなことか?

958 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 21:41:01 ]
Commons Compressだったかがβすら出ずに存在したような気がする

959 名前:デフォルトの名無しさん mailto:sage [2006/09/02(土) 22:24:20 ]
>C#のget/setと変わらないくだらん機能だな
Java7の拡張の候補にプロパティが入っているのだけどな。


960 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 00:04:24 ]
入ってたとしても、C#と全く同じってことはなかろうと予測

961 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 00:27:08 ]
>>959それどこの記事でわかるの?



962 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 00:32:42 ]
>>959がデマだったりすることはよくある。
あの文体は、いつものJavaスレを荒らしてるドトネト厨だから。
3年も4年も前からJavaスレや死滅スレで大暴れしてる変態。


963 名前:デフォルトの名無しさん [2006/09/03(日) 00:35:56 ]
やっぱりドトネト棒ってハズレだったんだね。
コーヒーの方が大人だね。

964 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 00:42:45 ]
>>961-963
まずこのスレを「プロパティ」で検索してみたらどうなんだ?

965 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 00:45:38 ]
ttp://journal.mycom.co.jp/articles/2006/05/18/javaone3/
にしっかりと「プロパティのサポート」が発表されたと書いてあるんだが。。。

プロパティサポートといっても、それがget/set生成みたいなもの
なのか、式言語みたいに「obj.property」というようにアクセスできる
ようにする、という意味なのか、groovyの「@Property」みたいに

@Property size

とか宣言できるようにするのか、といった具体的な話はまったくない
わけだけど。

966 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 00:48:13 ]
>>962
>>963
こういうやつらっていつになったらJavaの世界から消えてくれるんだろ

967 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 01:05:16 ]
>>963
ドトネト棒って語呂と名前がウケルw


968 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 01:08:17 ]
>>965
その、アノテーションっぽい気がした。
@Propertyならいいねえ。
get/setはねえちょっと。
getter.setterに相当するメソッドに
@Propertyアノテーションをつけるのが妥当って感じだね。

969 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 03:11:05 ]
>>967それも棒の先には「おまえらは、ハズレ」って書いてあるんだろうだしwww

970 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 10:27:31 ]
>>946
「ストラウストラップが警告した事項」って具体的に何?

>>947
おいおい、Javaは静的な型があるんだから、別にコード全体を見るまでもなく、変数の宣言部分をみれば配列かListかはすぐに判断できるし、別に混乱なんかしないだろ。
この程度で混乱なんかしないでくれよ。

>>949
[]は単項演算子じゃなくて、+や-と同じ2項演算子だよ。
それに演算子の動作を自分で定義できることと、演算子の優先順位は関係ないよ。
PythonもRubyも演算子の動作を自分で変えられるけど、優先順位は変えられない。だから別に混乱しない。

>>950
でもELでは[]でアクセスできるようになってるよね。「その程度」のことであれば、
ELでも[]でなくてgetter/setter使えばいいはずだし、もっといえばEL自体必要ない。
Javaユーザは「[]なんてイラネ」といっておきながら、ELの[]は便利とかぬかすから嫌い。


971 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 10:39:13 ]
>>970
言っている事自体はだいたいまともだが

> Javaユーザは「[]なんてイラネ」といっておきながら、ELの[]は便利とかぬかすから嫌い。

とJavaユーザを一緒くたにして煽るのはやめてくれ。ELの[]が便利と言っている層とJavaには[]は
イラネと言っている層がどれくらい重なっているのか調べたわけでもないだろう?



972 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 10:43:14 ]
そもそもJSP上でaddなんてしないんだから[]で何の問題も無いだろ
粘着にレスすんなよ

973 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 11:30:35 ]
>>970
いっとくが、JavaとELとは全く別の言語だ。
Javaユーザが[]はイラネといってるのはJavaの文法にいらねといってるだけで
ELの文法に[]がいらねといっとるわけではなかろう。

そんなこともわからないでJavaエンタープライズアーキテクトを侮辱するとは
身の程知らずもいいところだ。


974 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 11:50:25 ]
JavaとELとが別言語なんてのはだれだってわかってる。
だからなんでわざわざELなんて用意されたかを考えろや。
Javaそのままだと書きにくいからELが用意されたんじゃないの。
Javaの書きにくさのひとつとして list.get(1) や map.get("key") があり、
これが list[1] や map["key"] とかけたらいいなといってるだけ。
ほんとうにlist.get(1)やmap.get("key")が書きやすい/読みやすいなら
ELでもそれをつかえばいいだけ(ELにはメソッド呼び出しないけど)。
「JavaとELとが別言語」なんて話がずれるだけじゃん。


975 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 12:13:34 ]
>>971
> とJavaユーザを一緒くたにして煽るのはやめてくれ。

一緒くたにしている馬鹿には馬の耳に念仏では?



976 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 13:45:49 ]
pc8.2ch.net/test/read.cgi/tech/1157227790/

次スレ

977 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 14:06:08 ]
>>970
ストラウとラップは演算子のオーバーロードを
誤った使い方をするとろくなことがないぞってことを言ってるんだよ。
誤った使い方をしなければいいといっても
誤った使い方をする奴は腐るほどいるし。
それで複数の会社組織が独自に演算子を定義して
デスマって酷いことになるわけだ。


978 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 14:07:23 ]
>>974
じゃあさ、お前にはなんでJakarta Velocityみたいなのが
用意されたのかわかるの?

プリプロセッサではなくVelocityが用意された理由を。

979 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 15:24:48 ]
[]のオーバーロードは欲しいな。

980 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 15:35:42 ]
ListだったらどうせIterator経由でアクセスしない?
List.getなんて滅多に使わなくないか?

981 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 17:07:07 ]
んだな



982 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 17:47:33 ]
しかもIteratorにはfor(:)の砂糖が既に入ってるしな

983 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 19:27:06 ]
うむ、そうだ

984 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 20:02:49 ]
次世代は無糖でw

985 名前:デフォルトの名無しさん [2006/09/03(日) 20:23:27 ]
new ArrayList=("あああ","いいい","ううう");
みたいに出来んかな。

public ArrayList(String... varArgs);
こんな感じのコンストラクタで。

986 名前:デフォルトの名無しさん [2006/09/03(日) 21:05:54 ]
>>985
それもだけど、
ArrayList#addAll(Collection<? extends E> c);も、
c.toArray();で配列に直してから使ってる。
ArrayList#addAll(E[] c);がないのはもったいない。



987 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 21:46:14 ]
>985
Arrays.asListでいいんでないの?


988 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 21:55:40 ]
あーたしかにコレクションをパっとつくりたいと思ったことはあるな。
とくにテストコードで。
今だと
List strList = Arrays.asList( new String[]{"test1", "test2"});
とかやっててくどいとは思う。

一方で、Javaの、文法はシンプルに、機能はクラスライブラリで、という
スタンスは嫌いじゃない。文法拡張するときは「そんな砂糖いらね」という
抵抗があったほうがちょうどいいと思うぞ。やたら拡張するよりはね。

989 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 23:11:48 ]
>>987
確かに5.0のArrays.asListは
 public static <T> List<T> asList(T... a)
だからまあ悪くないんだが、返ってくるのが変更不能リストなのがイマイチ
変更可能リストを返すメソッドが欲しいな。コードはこんな感じで
public class ListUtil {
 public static <T> List<T> list(T... a){
  List<T> newList = new ArrayList<T>();
  for(T t : a) newList.add(t);
  return newList;
 }
}
使うときはstatic import使えば、
list("A", "B", "C", "D")
のようにするだけで変更可能なリストが作れるので便利

990 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 23:21:03 ]
>>985
まるでPerlやPHPまんまだな

991 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 23:24:05 ]
>>989
それもPHPまんまやないか



992 名前:デフォルトの名無しさん mailto:sage [2006/09/03(日) 23:32:02 ]
>>991
意味不明。PHPで、array(...)などとして配列が作れることを言っているつもり?
そんなもん別にPHP(やPerl)独特のものでもなんでも無い。
なんで厨はすぐに自分の知っている(好きな)言語の機能のパクリかのように言いたがるかなあ

993 名前:デフォルトの名無しさん mailto:sage [2006/09/04(月) 00:30:14 ]
なになに、どっちにしろ型の概念が曖昧な
スクリプト言語に共通する書き方だよな


994 名前:デフォルトの名無しさん mailto:sage [2006/09/04(月) 00:52:40 ]
>>980
for( : )使うことが多いけど速度の差も結構あるし
何番目かを意識したりループの中で挿入とか削除とかもある
for( : ) 使うのが80%くらいかな


995 名前:デフォルトの名無しさん mailto:sage [2006/09/04(月) 01:05:58 ]
O'Camlなみに型推論しる!

996 名前:デフォルトの名無しさん mailto:sage [2006/09/04(月) 03:09:08 ]
あのー・・・

997 名前:デフォルトの名無しさん mailto:sage [2006/09/04(月) 07:23:57 ]
>>989
Arrays.asListってlistの様に振る舞うけど、
結局は配列のままのwrapper返すんじゃないの?

998 名前:デフォルトの名無しさん mailto:sage [2006/09/04(月) 07:32:05 ]
>>997
確かそう。
これをArrayListに追加するときは、>>986のようにまた配列にもどして使うのでもったいない。

999 名前:デフォルトの名無しさん mailto:sage [2006/09/04(月) 08:09:13 ]
>>989
new LinkedList(asList(a, b, c, d))
でいいやん。

1000 名前:デフォルトの名無しさん mailto:sage [2006/09/04(月) 08:17:59 ]
asXxxはビュー(実態は変わらず見方を変えたもの)を返す、ってことだな。

1001 名前:1001 [Over 1000 Thread]
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。








[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<289KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef