JavaはC,C++の後継言語となりうるのか

つーか1.4までと互換性あるんだからかまわんと思うが
互換性がないのならアレだが

Java5 で、Map< T, V > で受けようと思っても、
Java 1.4 は あくまで Map は Object,Object
結局ストイックに交ぜたければ、Object,Objectで受けてキャストするか、
例外記述になっちまう。

てか、Javaってキャスト大杉。
(型) によるキャストは、Ｃ言語と大差ない弊害の多い記述と思われ...
SUNも自覚したためgenerics(なんて御大層な名前で)実装したんだろうが...
そもそもJavaが持つ言語特性とあいいいれにくいと思うよ...
いまさらあんな言語拡張が、世のため人のためだろうか...

Java は、C++ や C# のまねなぞする必要ないのに...

いや、そういうときはコレクションそのままつかうのではなく自分で実装すればいいだけかと

混ぜる場合もそれらをパッケージングしたBeans作ってそれをいれるだけ

Objectありきで設計してる時点で間違ってるよ

どっちにしろGenericsは必須
テンプレートの真似事にみえるのは実装側だろうけど、そっちはたしかになくてもいい

genericsはどうも最初は頑なに拒んでたがC#の出現で渋々採用といった感じだよな
シンプルなOO言語であることにこだわる余りにキャストの嵐では本末転倒だからさっさと採用するべきだったんだろうけどなぁ

オートボクシングが採用されたからはじめて実用的になったともとれるからなぁ

Genericsなんて今までなかったのが不思議なくらい必須の機能。

Java(1.4以前)でもC#でも、たかがList使うだけでキャストの嵐になる。
馬鹿馬鹿しくてやってられない。
こんなことちょっと触ればすぐわかる。

つーか、コレクションの場合なんでもいれれるようにObject型にしてるだけだし
継承して使えというスタンスだったのでは？

>>311
もしそういうスタンスなあらC#用には普通にある
型限定のコレクションクラスを自動生成するツールが
Javaでは全く出てこなかったのが不思議なんだよな
コピペとはいえいちいち作らなきゃいけないのは問題外だと思うが
Javaプログラマはコレクションなんてどうでもよかったのかな？

クラス指向が強かっただけかと
プリミティブなものを直に入れるよりは多態で扱うとか
匿名クラスでイベント扱うのがデフォな時点で気がつけ

それにJavaプログラマと一括りにすな、C#厨

>>313
本当に見たことが無いんでみんなコレクションのキャスト問題なんてどうでもよかったんじゃないかと思ってさｗ

コレクション使ってないコードなんてあんまりきいたこともないが
新たに大量動員された業務プログラマの8割は多態理解しらなくて
困ったことはある

オブジェクト指向理解しているとかぬかすくせに

List list = new ArrayList();
がずっと理解できないやつがちらほらと

まぁ、今はgenerics導入で上記コードが警告でるのも便利

まぁ、Java の generics なんて、ただのシンタックス・シュガーでしかないがな

型の安全性が増えていい結果になったな＞じぇねりくす

>>316
Javaの思想からすればむしろそのほうが都合がいい

Javaにポインタとアドレスがあれば
もっと分かりやすい言語になるのにね

このスレ釣りばっかかよ

assertの実装に笑った

詳細希望

NIOのDirectByteBufferは明らかにCで確保した領域をJavaで扱うために作ったとしか思えない

NIOもVolatileImageも1.4からは割り切ってパフォーマンス追求する動きにでてるからな
安全性はそれなりに確保できるしわるくないのでは

C++で書いて移植したほうが遥かに現実的だという事実。

まだ習い始めたばっかだけど、equalsに一貫性がないのが気持ち悪い。

クラスごとに判断基準違うものをどうしろと

デフォの動作がインスタンス変数全部比べてくれるってのが良くない？
それで困るときだけ変えればいいし。
このクラスのequalsは〜とかいちいち面倒くさいし、混乱の元じゃん。
toStringもデフォでインスタンス全部出力すりゃいいのに。

＞toStringもデフォでインスタンス全部出力すりゃいいのに。
これどういうこと？

いや、toStringでオブジェクトの現在の状態を表す文字列が出力されるようにオーバーライドするだろ？
それをわざわざしなくても自動的にそうして欲しくない？
これもこれで困るときだけ変えればいいし。

その状態ってクラスごとじゃないと結局わからんだろうに
デフォはObjectの動作あるんだしこれ普通だろ

＞その状態ってクラスごとじゃないと結局わからんだろうに
そりゃ分かんないよ。
ただJavaが元々そういう機能をサポートしてたら大丈夫じゃん。
機能って言うかただのコンパイル時のコードの補完？
全然難しくないでしょ。インスタンス変数読み取って、決まった形式の文字列作るくらい。
だって毎回
"[name="+name+〜+"]"
みたいなわかりきってること書くのだるくないの？
リフレクションで簡略化できるだろうけど、デフォでやってくれた方が楽だし。
これのデメリットが見つからない。

それが状態を表すと思ってるの？
Beansならそれなりにやれるけど、それ以外はムリ

＞それが状態を表すと思ってるの？
そう思ってるけど、もしかして違うの？

違う

だからBeans以外は[〜]って表記してないと思うが

マジ？俺の読んでるCoreJava2って本で推奨されてるよ。
普通はどうやるの？

toStringの使い方は異なる
［〜］と表記しなければならないってことはない

Swing使っていればtoString大量に出てくるからどう使えばいいか分かりそうだが

んー、常にこう使うって訳じゃないのはわかるよ。
でも基本はデバッグに便利なようにインスタンス変数の状態を[〜]みたいに書くんじゃない？
＞Swing使っていればtoString大量に出てくるからどう使えばいいか分かりそうだが
良く分かんないけど、例えば、JLabelのtoStringはこうだったよ。
javax.swing.JLabel[,0,0,0x0,invalid,alignmentX=0.0,alignmentY=0.0,〜省略〜,verticalTextPosition=CENTER]
見当違いなことしてたらわりぃ。

いや、リストとかテーブルとかのセルや各項目の表示方法などね
toStringを使うようになってるから

それにその表記はbeansだから可能な

意味も無くage

長寿スレだなｗ
10/24付近のは、言語でやるんじゃなくてRefactoringの機能とかで
持ってればいんじゃね？
setter,getterを作るような感じで。

少なくともtoStringは決まった形式に言語で縛るのは危険。

Java はプリミティブ型で参照を渡せないのがしんどい。
Tiger で踏み込んで欲しかったけど
C# の真似と言われたくなかったんだろうか。
ボクシング・アンボクシングなんて瑣末なものは後回しにして欲しかった。
(瑣末どころか曖昧さが増えてむしろ迷惑だ。)

なんでプリミティブ型もObjectの派生物にしなかったんだろう

そこだけはパフォーマンス上妥協したとのと
生成コスト短縮したと見た。

プリミティブ型の参照渡しをサポートしなかったのって何故？
type* 相当はまぁ分からんでもないが
type& 相当あったところで、混乱起こすとは思えないんだが。
オブジェクト型は type& 相当のことやってるわけだし。

>プリミティブ型の参照渡しをサポートしなかったのって何故？

ラッパークラスがあるタメに不要だから。

リフレクションのときの面倒を減らす効果があるから。
リファクタリングしやすいから。

>346
プリミティブ型のラッパークラスは不変オブジェクトになってて
参照渡し的な使い方は一切出来ないんですが。。

>347
なるほど。

mallocの本質はフリーチェーンと呼ばれる使用可能メモリブロックの長い連結リストだ。
mallocのパフォーマンスは決して速くなく、しかも、クリーンアップのために
ときどき予期できないタイミングで非常に遅くなる

Javaはガベージコレクションがあるから・・・なんてしたり顔で話すC++プログラマが、
デフォルトのメモリアロケータを平然と使っているなんてことは良くある。

頭のいいプログラマは、mallocによる処理の中断の可能性を最小化するために、
いつも2の累乗のサイズでメモリブロックを割り当てる。
この方法はフリーチェーンの中のヘンな断片化の量を最小化するのだ。
…尤も、Javaの世代別GCに比べれば余りに原始的だがな。

時給１０００円でＪａｖａ教えてくださるかたを募集します
場所　所沢（池袋・高田馬場から直通）

ｉ−ｗａｎｔ−ｔｏ−ｓｔｕｄｙ−ｊａｖａ＠ｈｏｔｍａｉｌ．ｃｏ．ｊｐ
（アドレスは全角で書いてあるので半角に直してください）
よろしくおねがいします

とりあえずc++0xがどうなるか様子見。

（永遠に様子見してしまいそうだが…）

>>2
Cocoa-Javaならインタープリタじゃないけど
Cocoaは仕様違うし・・・
どっかでネイティブコンパイルできるJavaコンパイラとかない？

GCJ

ランタイム入れないと動かないとかカンベンシテくださいよ