次世代Javaの動向　２

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にも組み込まれる予定。 116 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 03:48:27 ] いやいくらなんでもEJB2が複雑じゃないなんて話は聞いたことがない。 EJB2じゃないけど、Strutsだって「あれは壮大なネタだろ」とか言ってたくらいで、全般的に 冗長なフレームワークは嫌われてたように思うが。 genericsでは何度か見たが、一方でMapがタイプセーフでないことに苦しめられたって 意見もあったわけで、バランスは取れてただろ。 Java言語をシンプルなままにしておきたいという希望は俺にもある。一方で、書くのが楽に なって欲しいという希望もある。一人の中でもせめぎ合いがあるんだから、スレ内でどっちの 意見が出たって不思議には思わんがね。 117 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 03:56:09 ] >>96 ヒアドキュメントがあると、文脈自由文法じゃなくなってしまうからJavaCCとかのパーサージェネレータで作りにくくなるよ。 118 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 05:33:15 ] >>116 EJB2が複雑という意見はあった。しかし、それは一部の開発者のみ。EJBを推進する連中のほうがずっと多かった（理由は「それが標準だから」だとさ）。 Strutsだって同じだろ。雑誌記事みればわかるじゃん。どれもEJBマンセー、Strutsマンセー。 EJBやStrutsを明確に批判したのはRodやTateなどごく一部。日本じゃ皆無。 >>117 単純なヒアドキュメントは字句解析だけで実現できる。パーサはいじる必要ない。 つうかな、これだけ機能がごちゃごちゃ増えてるのに、ちょっと文法たすだけなのがなんで問題なんだ。 今のJavaはコンパイラ作るのがすごい面倒な言語になったけど、それは機能が増えたせいで構文解析よりあとが大変になったからだろ。 それにくらべたら、構文解析までなんて簡単。ヒアドキュメントの追加ぐらいわけない。 ほかにずっと大きな問題があるのを見ないふりして、「パーサジェネレータで作りにくくなる」なんてささいな問題をとりだすなよ。 119 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 06:11:10 ] >>118 少なくとも、ヒアドキュメントは「ずっと大きな問題」じゃないな。 120 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 06:38:50 ] >>118 つ ttps://mustang.dev.java.net/ 時代は貴方を求めています。言い出しっぺの法則ってことでﾖﾛﾋﾟｸ 121 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 08:04:10 ] 俺はforeachいらねーわ。 122 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 09:46:04 ] >>114 GoslingがGenericsをいらないと言っていたというのは、信じがたいのだが。ソース希望。 Java House MLのアーカイブやその他の場所で引用されていた過去のGoslingの発言を見る限りでは、 Genericsの導入には前向きだったように思える。 あと、世界狭すぎなのは自分の方なのかも、って考えは無いのかね。 123 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 09:53:24 ] >>118 Rubyにあるような、式を埋め込めるヒアドキュメントはパーザをいじる必要があるけどな。 実際のところ、ヒアドキュメントはあれば便利だろうし、使うだろうけど、そこまでこだわる 程の機能か？あと、そんなにヒアドキュメントが本当に欲しければ、こんなところで ぐちぐち言ってるよりも公式に提案した方が良いかと。Genericsやその他の言語拡張だって、 要望が多かったから取り入れられたわけだし、ヒアドキュメントも場合によっては取り入れられる こともあるかもしれん。 124 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 10:07:39 ] Goslingが否定的だったのは、 C++のtemplateの特殊化やC++,CLOSなどのgeneric functionだろ。 operator overloadはかなり初期から批判的。 Bill JoyとGoslingが"暴力沙汰"になりそうになったのは、 Billがgenericsはゆっくり考えることにして、generics抜きでJavaをshippingしようとしたから。 Goslingは、進行はJCP任せだけど、collectionのreliabilityを増すと積極的。 C/C++に対する大きなアドバンテージと考えているから。> reliability www.gotw.ca/publications/c_family_interview.htm 125 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 10:24:43 ] >>124 本題からはずれるのだが、C++のgeneric function(=テンプレート関数のことか？) とCLOSのそれ(=マルチメソッド)は全く意味合いが異なるのでは。前者は静的に 呼び出しが決定され、後者は動的に呼び出しが決定されるので。 126 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 10:44:44 ] 性的か童的か違うと「全く意味合いが異なる」のか? 「関数テンプレート」が正式名称な。C++03で間違っている部分も修正。 127 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 10:51:28 ] >>126 全くというと言いすぎだったかもしれんが、少なくとも意味が異なるのは事実。 Javaのメソッド **オーバーロード** とメソッド **オーバーライド** が異なるのと同じ。 関数テンプレートが正式名称というのは、知らんかった。すまん。 128 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 10:56:49 ] >>124は、わざわざ"generic function"って書いているんだから、 クラスに属さない多相型の関数のことを言っているのは自明だよ。 性的なw特殊化はわざわざ別に書いているし。 129 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 12:10:38 ] >>128 言いたいことがよくわからないのだが、C++には関数テンプレートとは 違う、"generic function"があって、それは、CLOSのように、実行時に オブジェクトの型に応じて、動的にディスパッチしてくれるのか？ 130 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 12:49:01 ] "generic function"をCLOSの意味に制限して、 意味不明って言っても仕方ないじゃないの? 一般名詞としての"generic function"は、C++のWGでも出ているよ。 例えば、www.research.att.com/~bs/evol-issues.html generic programmingで使うparametric polymorphismを持った関数が"generic function"。 知らないのはよっぽどうとい人だと思われ。 131 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 18:45:57 ] >>130 いや、"generic function"をCLOSの意味に制限したいわけ じゃなくて、CLOSのそれとC++のそれは意味が異なる機能なのに、 124が > C++,CLOSなどのgeneric function と、C++とCLOSのgeneric functionが同じ機能かのように言っていたので、 つっこんだだけ。 132 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 22:01:40 ] >>123 ヒアドキュメントはあくまで例のひとつ。 「そんな機能いらね」といってたくせにそれが実装されると意見を180度変えるJava屋さんが多すぎてうざいというのが主張内容。 JCPに提案しろとかポイントはずれてる。 133 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 22:29:35 ] >>131 > C++とCLOSのgeneric functionが同じ機能かのように言っていたので、 FUDかよw 134 名前：133 mailto:sage [2006/05/28(日) 22:52:36 ] お口直しに、 www.osl.iu.edu/publications/prints/2003/comparing_generic_programming03.pdf 結局propertyは>>86の言うように、JSR245なの? 135 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 23:22:33 ] >>133 132だが、いい加減しつこいかもしれんが、どの辺がFUDなんだ？ 136 名前：デフォルトの名無しさん mailto:sage [2006/05/28(日) 23:25:08 ] >>135 間違えた。「132だが」は、「131だが」ね。 137 名前：デフォルトの名無しさん mailto:sage [2006/05/29(月) 00:35:52 ] >>132 確かにポイントがずれてたかもしれん。 でも、結局、 > 「そんな機能いらね」といってたくせにそれが実装されると意見を180度変えるJava屋さんが多すぎて というのは、そんなに居るかなあとしか自分は思えない。あなたの 周りはそういう人ばっかりだったのかもしれんが、全体として どうだったかというのは、ソースが無い以上、わからんし。 138 名前：デフォルトの名無しさん mailto:sage [2006/05/29(月) 08:50:44 ] えーい、IDが無い板でそういう話題はやめーい。 技術の話でぶつかるならともかく！！！！ 139 名前：デフォルトの名無しさん mailto:sage [2006/05/29(月) 08:59:23 ] まあ、ヒアドキュメントは実装されても意見を180度変えるJava屋は少ないだろうな。 いらね。 140 名前：デフォルトの名無しさん mailto:sage [2006/05/29(月) 09:10:29 ] XMLで出来るんだから、プレインテキストはいらんだろ。 141 名前：デフォルトの名無しさん [2006/05/29(月) 12:41:52 ] >>134 JSR 245のexpression languageのところだけ、 つまり JSR-000245 JavaServer Pages 2.1 FR から抜き出された JavaServer Pages 2.1 Expression Language Specification だけ入るんじゃないのかな。property関係のところは。 1.6 Operator [] and . The EL follows ECMAScript in unifying the treatment of the . and [] opeartors. expr-a.idenfitifer-b is equivalent to expr-a["identifier-b"]; this is, the indentifier identifier-b is used to construct a literal whose value is the identififer, and then [] operator is used with that value. (以下、式を評価する時のルール;略) java.elのELResolver.getValue()辺りのインターフェースは どうなるのか知らないが。もともとJSPのproperty用だからさ。 142 名前：デフォルトの名無しさん mailto:sage [2006/05/29(月) 16:53:15 ] >>137 まさに、すぐ下にいるじゃん。>>139,140 今まで幾度となく同じことが繰り返されてきたし、これからもおんなじ。 143 名前：デフォルトの名無しさん mailto:sage [2006/05/29(月) 16:58:39 ] つまり、>>43 がXMLリテラルがあればヒアドキュメントいらね、って言い出すと予言してるわけね。 144 名前：デフォルトの名無しさん mailto:sage [2006/05/29(月) 17:34:37 ] ヒアドキュメントはもう話題としてはいいだろ。つまんねえし。 145 名前：デフォルトの名無しさん mailto:sage [2006/05/29(月) 17:49:01 ] >>142 ヒアドキュメントなど、間違いなく不要。 146 名前：デフォルトの名無しさん mailto:sage [2006/05/29(月) 23:48:08 ] あってもなくてもどうでもいいや。 自分ならヒアドキュメントで書きたくなるような文字列はコードと分離するけど。 147 名前：デフォルトの名無しさん mailto:sage [2006/05/30(火) 01:46:32 ] まあつまりさ、genericsにせよヒアドキュメントにせよ、あれば使うし無ければ 今を受け入れるか、Javaを使わないしかないだろ。 おれはヘタレなのでMapに想定していないオブジェクトをつっこんじゃって、 キャストで落ちるなんてことをよくやってたからGenericsはすごくありがたい けど、なけりゃないで、無いんだからどうしようもないから受け入れてただけ。 Genericsがないからまともなコードが書けません、なんて仕事では言えない んだし。 148 名前：デフォルトの名無しさん mailto:sage [2006/05/30(火) 02:42:09 ] いや、ヒアドキュメントは、あっても使う機会がない。 149 名前：デフォルトの名無しさん mailto:sage [2006/05/30(火) 05:26:34 ] Ruby並にいろいろできるなら欲しいな、便利だし 150 名前：デフォルトの名無しさん mailto:sage [2006/05/30(火) 06:57:54 ] スクリプト言語と比較されてもなあ… ま、俺も>>146と同じでどっちでもいいや。どうせ使わないだけだし。 151 名前：デフォルトの名無しさん mailto:sage [2006/05/30(火) 09:27:59 ] つうか、Ruby並にいろいろやりたいならJRuby使えばいいだけじゃん。 152 名前：デフォルトの名無しさん mailto:sage [2006/05/30(火) 09:31:37 ] 時々でいいのでGroovyのことも思い出してあげてください。。。 153 名前：デフォルトの名無しさん mailto:sage [2006/05/30(火) 09:32:36 ] あ、Groovyってヒアドキュメントなかったかも....orz 154 名前：デフォルトの名無しさん [2006/05/30(火) 09:34:55 ] >>147 List<Map<String,Object>>とかだとListとだけかかれるとソース追わないと中身確認できないのはきつい ドキュメントでしっかり書いてくれるところならいいがListとだけかいているとぶち殺したくなる もう1.4時代にはもどれんよな 155 名前：デフォルトの名無しさん mailto:sage [2006/05/30(火) 09:48:47 ] >>153 Groovyには、式を埋め込める複数行文字列リテラルがあるよ こんな感じ def i = 100 println """ Hello ${i} """ これをヒアドキュメントと言っていいかは正直わからんの だが、機能的には、文字列の終端となる記号を自由に指定 できないことを除いて、ほぼ同等だと思う 156 名前：デフォルトの名無しさん mailto:sage [2006/05/30(火) 15:45:10 ] ヒアドキュメントは*絶対*に入れて欲しくない こんなもの、保守やデバグを考えるとぞっとする チームで禁止しても絶対使う奴が出てくるから嫌だ 157 名前：デフォルトの名無しさん mailto:sage [2006/05/30(火) 16:54:31 ] どうせコンパイルして逆コンパイルしたら普通の文字列リテラルになるから問題なし。 158 名前：デフォルトの名無しさん mailto:sage [2006/05/30(火) 17:55:57 ] ヒアドキュメントいれただけで保守やデバッグができなくなる>>156のレベルに乾杯 159 名前：デフォルトの名無しさん [2006/05/30(火) 18:06:25 ] まぁお行儀の悪いプログラムを推奨してるかんじだしあまりいいものではないな 160 名前：デフォルトの名無しさん mailto:sage [2006/05/30(火) 20:21:24 ] コンパイラ機能とあわせて使うと意外と便利かもよ てかコンパイラ機能ってクラスキャッシュ直ぐ満杯になる欠点とかないの？ 161 名前：デフォルトの名無しさん mailto:sage [2006/05/30(火) 23:03:08 ] >>160 そんなことされると、さらにgkbr 162 名前：デフォルトの名無しさん mailto:sage [2006/06/02(金) 02:54:34 ] ヒアドキュメント入れるときの妥協点として コンパイルオプションでヒアドキュ封じができるようになればちょうどいい感じで導入できないかね？ プロジェクトで使う人もこまんないんじゃない？ 163 名前：デフォルトの名無しさん mailto:sage [2006/06/02(金) 07:44:25 ] そういう問題じゃない。 というかそこまでして導入するもんでもない。 164 名前：デフォルトの名無しさん mailto:sage [2006/06/02(金) 17:03:39 ] プロパティは、 言語として加わるのか、 XML対応としてXMLの属性にgetValue/setValueするAPIがJDKに加わるのかどっち? 関連JSRは、 JSR 227: A Standard Data Binding & Data Access Facility for J2EE(TM) JSR 245: JavaServer(TM) Pages 2.1 JSR 252: JavaServer Faces 1.2 JSR 295: Beans Binding あたり? Expression Language周辺 165 名前：デフォルトの名無しさん mailto:sage [2006/06/03(土) 22:35:13 ] >>40 なんだからPerlの q!文字列!やPHPの'文字列\n$変数'と'文字列$変数'との 違いを表してるブツみたいだな。 PHP的なものならまだしもPerlのq!文字列!みたいな 混乱するブツになるのは避けてもらいたいところだよな。 ダブルクォーテーションが無いだなんて、 あれ使う前に何か宣言でもするのかな 166 名前：デフォルトの名無しさん mailto:sage [2006/06/03(土) 22:37:29 ] >>46-47 そのまんま@Propertyアノテーションとして使えばいいやんか 167 名前：デフォルトの名無しさん mailto:sage [2006/06/03(土) 22:39:21 ] >>48 C#みたいな表向きは set/getと書くだけでプロパティが使えるが 実際には内部ではプロパティ変数名がたとえばtest のとき実際にはGet_test(), Set_test() というメソッドが定義されているとコンパイラに解釈されるという奴でどうにかなるんだろう。 ただし、このときGet_test(), Set_test()という名前のメソッドを定義するとC#ではエラーになるが。 168 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 01:52:45 ] >>167 そういう暗黙の定義が適用されるのは、 対XMLデータとか、シリアライゼーションとか、 定義をクラスライブラリ側が持っているケースでしょ? それは既にBeansやServer PagesのELであるよね。 JavaDocのtagもpropertyが増えてる。 Dolphinのは、言語がproperty採用するって事なんじゃないのかな? 要するに、setter/getterはプログラマが記述して、 フィールド参照がsetter/getterに置き換わるヤツ。 169 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 01:56:45 ] >>96 遅レスながら激しく同意。ほんとJavaには呆れる。 170 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 02:11:29 ] >>165 > >>40 > PHP的なものならまだしもPerlのq!文字列!みたいな > 混乱するブツになるのは避けてもらいたいところだよな。 例えばの話だが "<p id=\"hoge\" onmouseover=\"hige('fuga')\" class=\"hage\">"; q{<p id="hoge" onmouseover="hige('fuga')" class="hage">}; どっちが見易いかっつう話だ。 q{}とは違うが正規表現の場合も考えてみ。JavaよりC#の@の方がまだマシだろうに。 171 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 10:21:22 ] >>75 そんな書き方するのがいやだったら インクリメントできるメソッドを定義したほうがいいんじゃないのか？ 172 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 10:24:18 ] >>96 いっておくがC++のtemplateとJavaのgenericsとはまったく別もんだよ。 比較サイトでも似て非なるものであると書いてある。 よって全然手のひらを返したことにはならんよ 173 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 10:25:14 ] >>96 ヒアドキュメントは下手な奴が使うとソースコードを読みにくくするからな。 Perl厨が書いたコードみたいにな。 174 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 10:27:07 ] >>172 C++ templateの重要な特性である、コンパイル時プログラミング ができるという機能をJava genericsは持って無いし、別物と言って 良いだろうね。 175 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 10:27:51 ] >>114 だからC++のテンプレートはJavaのGenericsと全く 同じではないと何度言ったら(ry だからあれほど言ったものを 176 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 10:28:25 ] しかも今のJavaにも"foreach"なんてキーワード出て来ないし 177 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 10:30:19 ] >>122 >>114はGoslingが「C++Templateの機能すべてはいらない」と 言ったのを勝手に「Genericsはいらない」と誤認しているだけなんだよ。 恥ずかしい奴だから 178 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 10:32:21 ] for (型 変数名 : コレクション) 文 いらねーよ、こんなの。 179 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 10:34:18 ] >>139 ま、Perlそっくりそのままのヒアドキュメントが実装されたら あれだな。 XMLのCDATAセクションみたいなのがJavaソースコードに紛れるのかね だとしたらJavaソースコードがまるっきりXML文書の一部になる？ 180 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 10:38:02 ] >>178 お前らがforeachが無いんですけど(^^;;とか騒ぐから 181 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 10:38:10 ] >>178 便利だよ 182 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 10:38:44 ] >>170 そんなことをするんだったら別ファイルに書くか JSPやカスタムタブライブラリやJSFやApache Struts やJakarta Velocityを使うがな 183 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 10:40:42 ] >>174 もっと決定的な違いがあるよ。 C++厨がJava Genericsではこれができないと 愚痴を零している数々の機能。 多重継承ができないからといってブツブツ文句をいうＣ++厨が いるようにJava GenericsがC++Templateとはあまりにも 違うことに文句をつけている変な奴がまだまだいるのさ 184 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 10:48:11 ] >>182 JSFやApache Strutsはヒアドッキュメントの代替にならない件 185 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 10:48:59 ] 昔、ほんとにいらないのか、パクリを認めたくないのか 「いらねーよ、こんなの。」と言ってたものが 今までも、そしてこれからも追加されていくわけやね。 186 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 10:55:38 ] まあ、ヒアドキュメントが追加されることはないから心配するな。 187 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 10:55:58 ] そら便利ならそうなるわな。しないほうが馬鹿と言われる。 188 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 10:59:16 ] プロパティに関してはみんな欲しいと言ってたわけだしね。 XMLリテラルはいらねーともいるとも言ってない晴天の霹靂 189 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 11:00:13 ] J2EE方面の人の声が大きくなってきているね。 190 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 11:01:03 ] >>183 > Java GenericsがC++Templateとはあまりにも違うことに文句をつけている変な奴 ただ、Java Genericsは、Java仮想マシンの互換性を保つために、いろいろと 面倒な仕様になっているので、文句を付けられても仕方無いと思える部分もある。 特にC#のGenericsと比べると、その部分が際立つ。 191 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 11:01:35 ] 金をだすのはエンタープライズ方面 192 名前：デフォルトの名無しさん [2006/06/04(日) 11:05:46 ] いいかげんジョイスティックPureＪａｖａでさぽーとしてくれねぇかなぁ デスクトップに目を向けています！なんてよくいえたものだ＞5.0 1.4のほうがクライアントサイドで大幅によくなってたが、5.0ほとんどかわってねーし 6もほとんどかわってねーな グループレイアウトが標準になるくらいか 193 名前：デフォルトの名無しさん [2006/06/04(日) 11:06:46 ] ところでなんでこの時間だけいきなりレスふえたんだ？ しかも亀が多い 194 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:02:18 ] >>178 けっこうスッキリするけどね 195 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:03:07 ] >>193 日曜だけ見る奴とかいるんでね？ 196 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:03:54 ] >>180 foreachはないけどfor(;;)やfor(;)はあるってことで GenericsはあるけどC++Template相当のものはすべては無いってことで 「否定していた癖にJavaにforeachやGenericsが出た」と主張した奴は 馬鹿って事で 197 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:04:55 ] >>194 で、処理中にインデックスがいると分かり、for (int i = 0; i < に書き直したり。これがアホくさい。言語レベルで今何番目か 分かるようにしてほしい。 198 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:05:48 ] >>184 それでも今Perl臭いヒアドキュメントの必要性は 感じないな。 JSFやStrutsがヒアドキュメント代わりになるというより、 >>170のようなHTMLコードをいちいちJavaコードの中に 埋め込むというくだらないことをしなくて済むという観点から >>184の主張が現れている。 199 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:08:02 ] >>185 追加されるっていっても過去の言語にあるものとは 違うモノだから。 enumだってそうだし。 C/C++のenumはJavaのenumとは似て非なるものであって Genericsが登場したからこそ実現できたものであって C/C++のenumとくらべたら断然機能的で優れている。 よってC/C++のenumとJavaのenumとはまったく別のものである。 だから、かつてJavaにeumがいらないという発言があったのは 「Javaの新しいenumが要らない」というのではなく 「C/C++で実装されている仕様のenumが要らない」ということだったのだ。 200 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:08:33 ] >>188 みんなって誰？ あれの需要はそんなにあるとは思えないな 201 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:09:54 ] >>192 ハードウェア方面にまでPureJavaをサポートするのは まだまだ先だろ。 JiniやらJava Communication API をどうにかしないと 202 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:10:26 ] >>195 それはありうる。 >>193 >>195 というか偶然ともいえるだろう。 203 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:11:43 ] >>197 それはIteratorの意味が無いとちゃうか？ 何番目を知りたいかだなんて使い方が間違ってると思うぞ。 アルゴリズムや作りたいものによるが、 コレクションの分割とか考えるといいかと 204 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:17:10 ] そもそもコレクションの機能にランダムアクセスなんてないだろ interface RandomAccessとinterface Collectionは別の機能だ 205 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:18:04 ] >>203 間違ってるか？ というか、拡張 for 使いまくった？ えーと、そうだ、おまい今まで組んだものはループは全部 Iterator か？ 例えば、画面に行No出力する場合はどうする？ JSTL とかテンプレート言語が無い場合ね。 206 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:20:21 ] >>197 俺もインデックスが必要になるのがあとで必要になって書き直したりするよ でも、イテレータパターンであることを言語的に保証するものだからありでは？ インデックスだと中身まで見ないと流れが把握できない >>201 キーボードやマウスと同じ一般的な入力インターフェースなんだが ついでにMSXのようにキーボードもジョイスティック0番とかでつかえるようにしておけば コードを分ける必要もなくていいのだが 同人ソフトとかでJava製の物がほとんどない原因のひとつでは？ フルスクリーン等は1.4でサポート、じゃヴぁSoundは1.3でサポートされやっと使い物になってきたが インターフェースがないのではね 1.1時代＋JNIでなんでもできるということはなかったはずだし JNIも万能ではない（スタックサイズ制限で引っかかる）からね VM自体のリコンパイルが必要になるし、さすがにそれは現実的ではないだろう 207 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:25:27 ] > 同人ソフトとかで を例に示されてもワカラネw 分かるのが普通か？ 208 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:26:28 ] 「デスクトップ分野にも力を入れています」は口だけ 209 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:28:51 ] そんな大した手間じゃないと思うけどな＜パッド・スティック対応 PadListenerみたいな標準インタフェース用意して、メーカー側が対応するSPIをサイトに置いとけばいいじゃん 210 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:33:21 ] >>203 > 何番目を知りたいかだなんて使い方が間違ってると思うぞ。 それは言い過ぎだろw けどループ構造は代えずにカウンタ一つ用意すればいいだけだよな。 211 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:34:44 ] >>209 sourceforge.net/projects/javajoystick/ にあるが、 標準でサポートしろって事でしょ。 けどジョイスティックはそもそもインターフェースが統一されているとは言いがたいし… 212 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:38:53 ] >>210 カウンタを用意するとループのスコープの外に変数を作ることになる。 なんかいや。 213 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:43:47 ] カウンタ用意したらイテレータパターンの意味ないだろ 何番目か意識することなく取り出すのが目的なんだから カウンタ使いたければふつうにfor( ; ; )すればいいだけ >>211 2軸32ボタンまではOSレベルで標準サポートされてるはずだ 214 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:46:49 ] だから、Iterator パターンでも、必要であれば、カウンタが とれればいい。freemarker のように。 215 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:50:12 ] Iteratorのコード書くよりは拡張forの方がはるかに楽な件 Iteratorのコードの場合、カウンターが必要なら拡張for使わなくてもIteratorかカウンタ変数かどちらかがスコープの外に出る件 216 名前：デフォルトの名無しさん mailto:sage [2006/06/04(日) 12:54:04 ] ジョイスティックが「デスクトップがんばる」の範囲に入ってなくてもほとんどの人が困らない件

---

---

[ 続きを読む ] / [ 携帯版 ]

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