未来型Javaへの布石

ついにJava1.5の時代へと突入した
そろそろJavaの言語仕様をフルスクラッチで変えても
いいのではなかろうか？

互換性は確かに重要だ。
しかし、互換性よりも生産性を多く求める人も多いだろう。

伝統に縛られるよりも
進歩へと目を向けようじゃないか。

互換性を保ったJavaをOldJavaと呼ぶ。
そして、それとは別に新しいJavaをFutureJavaと呼ぼう。

我々はFutureJavaについて話合おうじゃないか！！

('A`)>ヒロシです…
('A`)>２Ｇｅｔです…

志はまあいいとして
既に1.6が水面下で動いてるのにJavaでそれをやる意味は？

互換性にとらわれず
新しい言語を模索するってことでいいんでない？

実際にできはしないだろうけど、議論としてはいいんじゃない。
後方互換性の縛りがなく言語仕様を変えられるとしたら
どうなるといいかとか。

それって、C#やんか。

JavaじゃないけどD言語とかはどう？
Cのobjは使えるけどC++は捨てたよね
これはCも捨てるべきだったと思う？

C#にあってJavaにないのは
デリゲートとインデクサと演算子オーバーロードとプリプロセッサかな？

D言語はいいよね。
とりあえず、JavaとかC#とかDとか既存の物の
いいとこどりでベストな組合せを考えたいよね。

俺はJava＋genericsを使ってるけど
けっこういい感じ。

C#から今すぐとってきたいのは
やっぱりデリゲートというかイベントだね。
あとインデクサも欲しい。

じゃあ、C#使えばいいじゃんって言われそうだけど
やっぱりオープンなものを使いたいんだよね。
そっちの方がかっこいいからｗ

逆にC#に比べてJavaがいいのは
refとかoverrideとか書かなくていいところかも。

overrideって書くのはミスを防ぐにはいいと思うけど
コーディングする時はめんどくさい。

そっちの方がかっこいいからｗ

Visual Studio .NETの場合だけど、実はoverrideと打つ方が
TABキー一発で雛形を作ってくれるので、コード入力が
楽だったりする。

なるほど。
というか、言語仕様って
今は開発環境と一緒に考える必要があるっぽいね。
難しい。

進歩っていってるのに、シンタックスシュガーしか求めないのにわらった。

>>10
JavaのGenericsなんて制限だらけでなにに使えるんだ？
特定型用コンテナ以上の使い道あるか？

>>17
それだけで十分。

>>16
GCみたいなのは別として
言語機能ってシンタックスシュガーだろ・・・

>>19
継承もインターフェイスもシンタックスシュガーですか。

>ついにJava1.5の時代へと突入した
まだβじゃん

継承とかインターフェースを
C言語へ書き換えるのは難しくないけど。

>>22
えっと、それはちゃんとエラーの判別ができる形でだよね？
継承やらインターフェイスでできないことをやったら、ちゃんとコンパイル時にエラーが出る形でだよね？

もちろん

つーか、Javaコンパイラにできて
それよりネイティブな形でできないわけないでしょｗ

>>25
静的型保証のしくみは、低レベルでは難しいと思うのだが。

>>24
ちょっくら例示してくれ。

>>26-27
C++

>>28
C++でひし形の多重継承が起きてないことを保証するにはどうするの？

そんなの調べりゃわかるだろう・・・
呼び出しメソッドの一意性が保たれなくなるんだからさ。

>>30
コンパイラで自動的に判別できるんだよね？
class Aとclass Bを多重継承しても呼び出しメソッドの一意性を保たれることを保証するには、どういうコード書けばいいの？
言語機能としてのインターフェイスと同じことができるっていうのは、そういうことだよね。

知ったかぶりズの戯言会場

>>32
で、あんたの意見をひとこと。

うなぎパイって昼食べてもいいの？

>>30
ひし形の多重継承が起きてない、じゃなくてひし形の多重継承でメソッドの衝突が起きないことだね。
interfaceが保証するのは。
C++でできるのかねぇ。

>>34
だめ。勝負時に食べなさい。

object.mmethod()
という呼び出しをしたときに関数ポインタ（アドレス）に置き換えるわけだけど
これが一意に定まるかどうかは、コンパイルしてみりゃわかるでしょ。
シンボルが衝突するんだからさ・・・

>>37
で、ひし形の多重継承でメソッドの衝突が起きないことを保証するにはどうしたらいいの？

>>35
javaのinterfaceも
同じメソッド名にしたら、面倒な事が起きるよ

>>39
シグネチャが同じで戻り値が違う場合は問題だね。
少なくとも、ひし形の多重継承で同じメソッドを使うという問題はないはず。
で、C++で、それが起きないように保証する書き方はどうしたらいいの？

多重継承だけ避けたければ、
Javaと同じく、実装継承を１つに制限すればいいじゃん。
コンパイラでチェックする事は容易だね。

40は
構文エラーと
コンパイルエラーがごちゃまぜになってると思うんだけど
違う？

>>41
多重継承しているときに、両方が実装継承ではないことをどうやってチェックするの？

まぁ、こんな細かいことでどうこういってもアレだな。
「できないこと」を保証するのも言語の大切な機能だと思うんだけど。
Cでインターフェイスと同じ機能が実現できるって豪語してあったけど、俺にはどうやってもメソッドをオーバーライドしてないことを警告するしくみが思いつかない。

>>43
実装継承じゃないかは、純粋仮想関数だけを持っているのか
そうじゃないかをチェックすればできるよ。

>>44
メソッドをオーバーライドしていないことを・・・ってどういう意味？
関数の実装があるかどうかを調べるのは容易だけど。

つーか、C++知らないでしょｗ

C++のconst相当は欲しいな。オブジェクトを変化させないメソッドである保証があると安心して呼び出せる。

>>45
インターフェイスだと、
interface A{
　void M();
}
とあったときに
class C implements A{
　void m(){
　　some();
　}
}
としたら、メソッドをオーバーライドしてないことがコンパイラによって検出される。
おれはちょっとしかC++触ってないし、Cでオブジェクト指向をやったことがないから、よく知らない。
だから、こういうインターフェイスが保証してることをどうやってCで実現するかわからない。
>>24-25でできると書いてあるけど。
あと、
class A : public B, public C{
}
ってやったときにBとCが両方実装を持ってしまったときに警告を出す方法も知らない。
>>41でコンパイラでチェックできると言ってるけど。
純粋仮想関数だけをもってるかどうか、コンパイラにチェックしてもらうにはどうしたらいいの？

interface Immutable
コレを実装しているクラスは、コンストラクタ以外でインスタンスフィー
ルドへのwrite操作を行っていないこと、non privateなフィールドを
所有しないことを保証します、かな。

コンパイラではじけるね。アノテーションでもいいのかも。

>>1はアホ

【Java】次世代Java・J2SE1.6の動向【Mustang】
http://pc5.2ch.net/test/read.cgi/tech/1081698555/

一応、改めていっておくと、俺はCでinterfaceが実現したいわけではなくて>>19の「言語機能はシンタックスシュガーで、Cで同じことができる」ということに反論したいだけ。
Javaがやってる静的保証と同じことができるのか、と。

んじゃ、C++じゃできない。
C++をちょっと改良すればできる。
これでいいかな？

シンタックスシュガーって結局は
同じ機能が違う表現って意味なわけで、
別に多態なんてのは、C言語では関数ポインタ使って
昔からやられてるわけで・・・

そこら辺を理解できてないで
シンタックスシュガーじゃんって言われてもね。

そりゃデリゲートもインターフェース使えばできるけど、
デリゲートを使えば簡潔に表現できるわけで・・・

まあ、低レベルな部分をわかってないで使ってる人って多いからな。
よくそれで、使えるよ。（使えてないと言う説もある）
感心する。

>>50
ん？このレスは反論じゃなくて賛同にしか見えないのだが。

>>51
言語機能の大切なことは、やらないといけないことをやってないときにエラーを出す、やってはいけないことをやったときにエラーを出す、必ずやるべきことを自動的に行う、ということに意味があるわけだ。
シンタックスシュガーというのは、そういった保証をゆるめて記述を楽にする構文のことなんだよ。

>>52
え、どこが？
Cじゃ同じ型保証ができてないだろ、ってことを言ってるんだけど。

>>54
だからその型保証がシンタックスシュガーでしょ。
んで、そんなもん無くてもCで構造で実現できると。

俺からすれば何で同じ意見で争ってるのかと不思議に思うのだが。

×Cで構造で実現できると
○Cで同じような構造で実現できると

>>53
具体例よろしく

>>55
根本的にわかってないね。
ちょっと、ちゃんとシンタックスシュガーについて勉強してきて。
話にならん。

>>57
>>47のinterfaceの例でよかろう。

極端な言い方すれば言語仕様など結局はシンタックスシュガー
でCで実現できるという意見と
Cでは言語仕様上できないという意見
にわかれているということでよいのだろうか？
誰がだれやら・・ｗ

リフレクションつかわないとできないということでFA

シンタックスシュガーの捉え方が違うから話がこじれるのでは？
同じことしか言ってないよさっきから

>>60
っていうか、シンタックスシュガーの意味と、言語による静的な保証の意義をわかってないやつが１人いるということがわかった。
あぁいうの見ると、Cで低レベルやって、やろうと思えばなんでも実装できる、という考え方の恐ろしさがわかった。
品質の保証とコストについて、なんも考えんのな。

>>63
お前がひとりで暴走してるだけかと。
>>22あたりからどうしてこんな流れになってんだかｗ

>>64
それは認めるが、シンタックスシュガーの意味わかってないやつのせいにしておく。

>>65
>>19の発言は「例え」だろ
何が言いたいのか理解してれば普通に流れる事だと思うが

JavaとC/C++とを比べる時のポインタ議論と同じ流れ

>>66
いや、その後の流れで、シンタックスシュガーという意味をそもそも取り違えていることがわかった。
>>55とか。
型保証システムとか言語モデルをシンタックスシュガーと言われたら、言語設計者はたまらんだろう。

むしかえすようで悪いが、
Cで多重継承やらインターフェイスやらできないことはないよね？
見た目は他言語とは違うだろうし
スマートではないだろうけど。
やってみろ、とか勘弁してくださいね。ほほほ

>>69
Cのインタフェースは関数の仮宣言だと言ってみる

>>69
えっと、機能だけなら実装することはできる。
ここで問題にしてたのは、Interfaceが保証してることを実現することはできない、ということ。
Interfaceができないようにしてることもできてしまう、ということ。

なんつーか、昔CORBAの処理系でIDL書いてスケルトン吐き出して
しこしこCで実装してたときを思い出すよ。10年くらい前か?

Javaを良く知らない俺としては、純粋仮想関数とインタフェースの違いが分からない
空呼び出しを認めるか認めないかの違い？

俺はJavaしかしらないので純粋仮想関数がわからない。ぬるぽ

>>73
純粋仮想関数に対応するのは抽象メソッド
その抽象メソッドしか持たないクラスがインターフェイス

インターフェイスは、純粋仮想クラスとでも言おうか。

>>74
Javaだとあぶさんというキーワードで実装できる

インターフェイスとC++の純粋仮想関数しか持たないクラスとの違いは、インターフェイスが抽象メソッド(純粋仮想関数)以外のメソッド(関数)を持たないことを保証すること。
それによって、ひし形の多重継承によるメソッド呼び出しのあいまいさを排除している。

インタフェースはメンバ変数がないのね

純粋仮想関数は
vtableに関数ポインタのエントリーを作るような感じ。

インターフェースとか抽象クラスみたいなもんだ。

public static final変数なら有るけど

>ここで問題にしてたのは、Interfaceが保証してることを実現することはできない、ということ。
>Interfaceができないようにしてることもできてしまう、ということ。
それは例えばC言語でポインタを使わないようにできるか？
と言う事かな？
ポインタを使ってる場合は、コンパイルエラーにしろと・・・
それは無茶な注文だな。

>>1に戻るなら、こういうのを分かりやすく改善するべきだな

なんかおっそろしく面倒そうだけどできそうね（´Д｀;　ﾊｧﾊｧ
RubyかてCで書いてるわけだし（まぁそれ以外にもいろいろあるだろうけど）
できないことはないんだろうね。
ていうかCでオブジェクト指向とかやってた人いたんだろうから
できたんだろうよ。
そういう意味ではJavaはCのシンタッうわなにをするやめ

Javaは多重継承ができないだけで、禁止しているわけではない。
それはinterfaceの機能ではなく、extendsに制限をつけているから。

C++(あるいはCでも）プリプロセッサを使って制限をかければ
同じ事はできる。
ただし、コンパイルエラーではない。

>>81
ポインタというか、この場合たとえば
class C{
　virtual void M() = 0;
};
というクラスはOKで
class C{
　virtual void M();
};
はエラーになるような仕組みを、といことだ。
class C{
　virtual void M() = 0;
} = 0;
みたいな感じで。

ところで、シンタックスシュガーの定義ってあるわけ？
デリゲートはインターフェースのシンタックスシュガーなの？
どうなの？

>>85
意味不明・・・

>>83
だから、Cでは保証ができないのよ。
保証のしくみを実現するのはシンタックスシュガーとはいわない。

>>87
なんで？
純粋仮想関数以外をもってたらエラーにする仕組み、という話。
「= 0」がJavaのabstractの役割だから、クラスにつけてみたらどうよ、っていう話で。

Javaはポインタ操作ができない事を保証していると言えるのだろうか？
確かにCでは保証できないけど
ポインタを使っているかどうかをソースから検出する方法は容易だけど。

>>86
言語モデルとは関係なく、コーディングを楽にするための別記法、かな。
暗に、コードをあいまいにすることをにおわせる。

>>84
プリプロセッサってコンパイラにエラー吐くよう命令できなかったっけ？

>>90
できないし。
保証してるよ。

ポインタ議論は実装派と仕様派で対立が起きるから議論は勘弁。

言語にはない、VMにはある、で結論つくからOK

アルゴリズム上実装できないのと、
不要だから実装しないのを区別しようね。

class C{
　virtual void M();
};

はC++だとエラーでは？

>>95
なる。明解。

>>93
できない＝保障であれば
できる＝保障でない
という事になる。
C#のインデクサは[]という形でアクセスできない事を
保証できない
という事になるけどいいの？

ごめんC#と勘違いしてたっぽいｗ

論点がわからない。
Cで「どんな事」ができる/できない
の話をしてるんだい？

>>98
えっと、それは言語が保証するとかしないとか、そういう話とは別問題。

>>101
理由を書かないと・・・

>>100
簡単にいえば、Cではカプセル化はできるけど、カプセル化された中身がコーディングミスで破壊されないことの保証ができないとか、そういう話。
private指定ができないからね。

>>102
理由をって、言語による保証っていうのは、表記ができる/できないの話をするわけじゃないから。

C++Boostに多重継承禁止機能を実装しておくれ〜

新しい言語を作るっていう場合には、保証や責任の分離をどういうモデルで行うかということが大切な問題で、コーディングが楽とか楽じゃないとかは、そのあとの話。
未来型Javaっていうからには、まずどういうモデルにするかっていう話をしないといけないのに、シンタックスシュガーの話しかしてないな、と。
そしたら、保証や責任の分離のことをシンタックスシュガーと呼ぶやつが現れて、俺が暴走した。

終了のAA（ｒｙ
再開のAA（ｒｙ

↓次の話題どぞ

アンチ必死だなっと。
　　　　　　　　　　　　 ,　--- 　
　　　 , 　 ＿ ﾉ）　 γ =＝==　ヽ
　　 γ∞γ~ 　＼ | |_|||_||_||_| | | 　
　　　|　 /　从从) ）||ｰ.　ー |)　|　ナイス煽りですわ
　　 ヽ　| |　l　 l |〃人 ﾜ ~ノ|　.|
　　　｀从ﾊ~_ーノ） /　y ⌒i 　 |
　　　　／ヽ><ﾉ＼　　　　　 |　.|
　　　 /.　　 8/￣￣￣￣/　|
　 ＿_(__ﾆつ/.　VAIO.　/ .| .|＿＿＿＿
　 　　　 ＼/＿＿＿＿/　（u　⊃　

ガベージコレクションを仕様に含む言語はゲームに向かないという問題について語ってみないか？

>>109
スレ違いだし。
今のJavaなら世代別GCで、ゲームの1ステージ分くらいならどうにかなるんじゃない？
だめなのかな。

え？スレ違い？次世代Javaの話でしょ？
サーバーにしろフルコレクトが起きるのは問題じゃないかな

次世代Javaの話題はこっちで語れ

【Java】次世代Java・J2SE1.6の動向【Mustang】
http://pc5.2ch.net/test/read.cgi/tech/1081698555/

これでスレ違い扱いされるならここで語ること何もないじゃん

>>113
最適化程度の話は1.6で、という感じじゃないかと。
言語仕様をフルスクラッチで変えるというからには、まず言語モデルについて考えないと。
無責任にネ。

俺が望む言語について抽象的に書いてみる。
（具体的にどうすればいいかは不明）

1.初心者がどうなろうがかまわない。上級者にとって最高の言語
2.メモリ管理はGCでいい。delete出すのはめんどくさいし、それで遅くなっても
それは構わない
3.保守は重要な課題である。抽象度の高い構造化が必要
4.タイピング量が多いのは問題である。見やすいソースが高速に生成できて欲しい。

最近思うのは、JSP->Javaのような変換を持った言語がいいのではないかと
思っている。（直感）
例えば、GUIを作るには別のインターフェースでコードを生成した後に、
ソースコードを直接いじる。

ソースコードを直接いじる前に、もうひとつメタな階層を作るといいのではなかろうか？
具体的なアイディアはないけど。

|1.初心者がどうなろうがかまわない。上級者にとって最高の言語

せんせい！ これでは115には使えなくなってしまいます！！

>>115みたいなのは、JSP+ELみたいなプリプロセッサ与えておけばいいのでほっといて。

今から言語を設計するとしたら、MDAを意識する必要があるね。
アスペクトなんかはMDAの一環として取り込めると思う。
つまりは、メタデータの強力化という方向になるのかな。

で、1.6で十分というオチがまっている、と。

何らかのネイティブコンパイラと、Tcl/Tkのようなインタプリタがセットになってると嬉しい
VBSがAPIを呼び出すのと逆で、プログラムがスクリプトを呼び出す形

って言語としての仕様とは違うねｗ

>>115
>JSP->Javaのような変換を持った言語がいいのではないかと

ASP.NET

全然未来を見てないね。
現在の隣の芝を見てるだけ。

>>117
> >>115みたいなのは、JSP+ELみたいなプリプロセッサ与えておけばいいのでほっといて。

どうせなら、Jakarta Velocityを使った方がまし

Java自体に未来が無いよ

>>119
そこでASP.NETを出すくらいならJakarta Tapestry, Jakarta Strutsを
出したほうが賢い。

もしくは、JSF

なんでフレームワークが出てくるんだ？
プリプロセッサだろ？

Velocityがあればプリプロセッサは要らない

しかもVelocityはフレームワークじゃないし

サン、Javaの一部をオープンソースに
Sun Microsystemsは米国時間28日に、Javaのソースコードの一部を
オープンソース化するとの発表を行う予定だ。
今回オープンソースとして共有されるのは、
Looking GlassプロジェクトというデスクトップPC向けの実験的な
ユーザーインターフェースのコードだが、この動きはプログラムの
オープンソース化に向けた活動の影響力が高まっていることを
反映したものといえる。

http://www.itmedia.co.jp/news/articles/0406/28/news044.html

Java3Dネタが目立つじゃないか

>>109
やねうらおにでも弟子入りしる。

ほかはどうでもいいからwxWidgets使えるようにしてほしい。

>>131
あんじゃん。
http://www.wx4j.org/

>>132
俺は>>131でないことを誓う。


そいつがインストールできなかった。

javaが言語仕様としてスレッドを持っていたのには「なるほど」と
思った。あとは永続化、分散オブジェクト、プロパティなんかも
言語仕様レベルで持っていて良いように思う。
reflectionとか無理してるし。

・永続オブジェクト(や、どのオブジェクトからも参照されていない
　オブジェクトを含めて)存在するオブジェクトを検索する機能を
　言語レベルで持たせる
・当然ガベージコレクションやめ
・生存期間を共有する参照とそれ以外の参照を区別する
　(合成集約とそれ以外の集約の区別)
・1つのオブジェクトは複数の合成集約参照にセットされない
・プロパティは欲しい
・main()なくても良いんじゃない？

>>134
> 永続オブジェクトを言語仕様で

そんなもんが仕様になっても、だれもそれ使わずにRDBMS使うから無駄。

> 分散オブジェクト

RMIでよかろう。それにたいして言語サポートが欲しいなら、どんなものになるんだ？

> プロパティは欲しい

シンタックスシュガーはあとまわし。

> mainはなくても

javaコマンドの都合であって、言語とは関係ない。
実際、アプレットやiアプリ、サーブレットなどにはない。

永続化機構そのものにRDBMSを使うかどうかってのはこの場合
関係なくて。つかRDBを使わないって話じゃなくて、逆にRDBを
使う前提で言語仕様に取り込んで欲しいという話なんだがな。

要は永続化されていたりどこか別のVMあるいはおなじVMの中に
ある、明示的に参照を持っていないオブジェクトを何らかの条件で
探し出すことができて、そのメソッドを呼ぶことができる機能を統一
的に扱いたいということ。
どちらかというとO-Rマッパー的なものの取り込みが念頭にあって、
クラス定義に選択性を保証する制約の記述が要るだろうとか
考えているが。
＃データベース上のレコードとメモリに展開されたオブジェクトを
＃どこまで同一視するかという問題はあるけど。

あぁ忘れてた。あとトランザクションも欲しいな。

>javaコマンドの都合であって、言語とは関係ない。

なるほど。言われてみればそうか。
javaコマンドの話なら、APサーバーなんて大げさなもんじゃなくて
いいから、実行中のVMにクラスをロードして任意のメソッドを
呼ぶことが簡単にできるインターフェースが欲しいかも。

>>136
RDBの使い方が多種多様なので、言語仕様で決められても、ほとんどの人には微妙に使えない可能性が高い。
で、こういう仕組みの場合は、微妙に使えないものは全く使えない。

メタデータで十分な気がする。
あとは、いろんなフレームワーク任せ。

JCPでORマッピングやってるからJ2EE1．5あたりに入るだろ。

immediate finalizerを寄越せ。

Java1.6 でJVMを標準ライブラリに持ち込めるのかな。
ローカル、リモート両方のVMを透過的に扱えるなら嬉しい。Gridやユビキタスを標準にする方向で。

>>140
> JVMを標準ライブラリに持ち込めるのかな。

意味がわからんです。

> ローカル、リモート両方のVMを透過的に扱えるなら嬉しい。

RMIじゃだめなのか、と。

永続オブジェクト? RDBMS に Serialized Bean 保存
すんな八ゲ。それから、安易に RMI 使うな。
おまいらのシステムはクラス修正ごときで DB まで停止
さすのか? クラスタ化してるサーバも全面停止? 関連
サーバも全面停止? 安っすい設計だなオイ。

Java の Serialize とそれを基盤にした RMI などの技術は
システム変更に弱すぎ。せいぜいセッションの退避か
自宅鯖用途程度にとどめとけ。ここは机上アーキテクト
気取りの雑魚プ口グラマのすくつかョ

んじゃあさあRMIのかわりにJxta使うのはどうかな？

>>142
じゃ、やりとりはXMLで。

>>144
うーんちょっと口が悪かったな ｽﾏｿ。
XML ならまだ良いかな。まぁ所詮フォーマットなんで何でも良いんだけど。確かにシステム間
インターフェース変更による全体への影響はどうやってもでかくなるんだけど、設計者が下位
互換性への考慮を行えるマージンがあれば良い。通信上のデータ形式に手を入れる余地が
ないと後々の拡張やメンテナンスで逃げ道を失うことになってしまう。

まぁこんなん言うのも以前に正規化すべきデータを Bean シリアライズ on BLOB で手抜き
しようとした奴がいてさ、Bean へのプロパティ追加や削除、変更する必要が出たときにいままで
蓄積した Serialized Bean どうやって新しい形式に移行すんだ、キー項目設定する必要が
出たらどうすんだ、ということで危うく止めさせたのよ。serialver でお茶を濁しても完全下位互換
は保障できないし、そもそも DB 運用者にデータ移行のための Java のスキルが必要ってのも
普通受け入れられないし。

分散システムの設計って好きだけど、後々の機能修正やメンテナンス、運用考えたら現場では
課題山積なんだよねぇ。Serialized Bean クラス変更の話は氷山の一角、これ悲しい現実。
でもまぁ、クライアント側も Web Start 使って常に鯖側とバージョン一致できるなら、ちょっとした
蔵鯖に RMI 使うのは非常に魅力的だと思う。

Java前提でいいんなら、Jiniのほうがよっぽど簡単でダウンに強いだろ。

タワシに強い？

>>145
そこでJAX-RPCですよ。

5.0ってどういうことじゃ

>>149
だから 5.0 だろ。
Sun は Solaris の時にもやっている (w

っつーか、JDK1.5っつーかJ2SE5.0っつーかで
どのみちバイナリ互換性ないなら、ちゃんとしたGenerics入れろヴォケが！
あんな半端もん使えるのか？

結局バイナリ互換性なくなったねぇ。
なんだったんだろ。

え！　バイナリ互換無くなったの？
すまんソース教えて....

>>153
どこだったかなぁ。
Genericsで、なんか付加情報が邪魔になるんじゃなかったかな。
とりあえずSunの1.5でコンパイルしたコードは、バージョンチェックに引っかかってSunの1.4のVMで動かない。

バイナリ互換だよ。

いや、以前バイナリ互換がないというレスがどこかのスレであった。

確か最初はバイナリ互換だったけど、β1はバイナリ互換でなかった。
最終的にバイナリ互換になるのかどうかわからない。

というような話だったと思う。

Genericsでバイナリ互換が無くなった？
バイナリ互換のために、あんな半端な仕様にしたんだからそれはあるまい。
犯人はMetaInfoじゃねーの？

コンパイラフロントエンドでチェックしろ。

Groovyってどうなん？
どんな使い道がありそうなのかわからん

>>159
寂しいときに。
ttp://dh-groovy.com/

利用規約が普通におもしろい。

使い道以前にわざわざ新言語である意味が輪下欄。言語機能としてなんか特に優れたところあるの？
ネイティブ？バイトコードだけが売りなら、JavaScriptのコンパイラ作ればいいじゃん。

互換性チェックしてみたけど
問題無いですよ

http://www5.airnet.ne.jp/sakuraba/java/laboratory/J2SE1.5/LangSpec/Generics/Generics.html

チェックって、何したの？

無数にある既存のJava製ライブラリを、スクリプト言語から使えるわけだ。

そんなのGroovy以外にいくらでもあるが？
もちろんJavaScriptの実装も。

>>163
genericsがんがん使ってるコードを1.5でコンパイルして
1.4で実行してみた。

GenericsのRIでコンパイルしたクラスを見てみたが
確かに、CAFEBABEの後が00000030のままだわ。
GenericsのRIじゃなくてJDK1.5でもそうなのか？

互換性ないってデマは一体どこから。。。

にしても、1.5コンパイル→1.4実行って、SUNのサポートはないよな、確か。

>>167
活字で見た気がするんだけどねぇ。
見当たらない。

>>167
いやたしか1.5（いや、J2SE 5.0でしたね...）は1.4とバイナリ互換性が
ある、という話だったと思うので、1.5でコンパイルしたものが1.4と
バイナリ互換性があるということだとおもうんだが....

なんか誤解しているだろうか？

いや、俺が確認したのはGenericsのRIというかEAを1.4で使った場合なんだが、
JDK1.5でも、クラスファイルのバージョンは48.0なんだろかと。