[mustang/Java SE 6] 次世代Javaの動向 4 [dolphin]

1 名前：デフォルトの名無しさん mailto:sage [2006/11/20(月) 10:38:16 ] 前スレ [mustang] 次世代Javaの動向 3 [dolphin] pc8.2ch.net/test/read.cgi/tech/1157227790/ 次世代Javaの動向　２ pc8.2ch.net/test/read.cgi/tech/1147881822/ 【Java】次世代Java・J2SE1.6の動向【Mustang】 pc8.2ch.net/test/read.cgi/tech/1081698555/ 2006年12月にMustang Java SE 6がリリース予定 Mustangの掲げる主な目標は以下の点にある。 * 互換性と安定性および品質の向上 * Easy of Developmentの実現 * WebサービスおよびXMLサポート機能の拡張 * リソース管理や診断機能の強化 * デスクトップ環境の強化 Java SE 6 じゃじゃ馬ならし www.javainthebox.net/laboratory/JavaSE6/ 496 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 19:48:51 ] >>492 いやVectorとかでいいんだよ それでも十分使い勝手がいい 中に何を格納するべきなのかをドキュメントに書かないとわからないってのは面倒だったりする そういやJavaME用HotspotVMを開発したとかどっかのニュースみたな 携帯の用途だとhotspotよりはアーカイブ単位での丸ごとコンパイルのほうがよさそうだが 497 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 20:10:36 ] >>489 IBMのJavaME向けコンパイラ/オプティマイザみたいな商用系使ってると かなりのレベルまでstaticメソッドのインライン展開するし、 アサーションってMEの言語仕様で定めなくてもいいかなって気がするんだよね。 それよりも言語仕様のほうはシンプルにしてアプリケーションプログラマ のほうで適切にアサーションのutilクラスを書いた方が全体としてシンプルで融通効くと思う。 というかコンパイル時にstaticメソッドのインライン展開なくても >static final boolean DEBUG = false; >public void assert(...){ > if(DEBUG){ > System.err.println(...); > ... > } >} みたいなコードが書けるように1.3でも言語仕様上ifブロックでの到達不能性チェックに 例外が設けられていて、かつ実装系の方でもSunとかIBMとか大体のコンパイラは DEBUG=falseのときこの部分ごっそり削除してくれるし。 498 名前：497 mailto:sage [2007/02/24(土) 20:36:05 ] アサーションだから >static final boolean DEBUG = false; >public void assert(boolean flag, ...){ > if(DEBUG){ > if(!flag){ > ... > } > } >} みたいな感じか。細かいことだけど。 499 名前：デフォルトの名無しさん [2007/02/24(土) 20:52:52 ] なるほどー。 今ならAspectJでもっと効率よくできるかな？ 500 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 22:31:51 ] >>493 確か仕様上はGMTサポートしろゴルァだけどオチは >GMT な時間が返ってくるとは限らないってオチはあるかもなー だったかと・・・ >>495 仕様上は130K程度の不揮発性メモリ（KVM用）と30K程度の揮発性メモリ（コンフィグレーションライブラリロード用） と16/32bit CPU及び何らかの方法でのネットワーク接続方法。 結局はプロファイルとオプションのライブラリロードが居るんでSUNは160~500K程度のメモリ（揮発・不揮発問わず）を想定してるんだけど。 が仕様上の要求だけどねぇ。携帯電話はそれでもリソースケチるからな・・・。 >>496 いやジェネリックスが便利なのは認めてるんだけどMEだとVector使うかテストしまくって確実に足りる最小の固定長配列使うか悩むんだよ。 ホットスポットVMなら仕様上はCDC HIとCLDC Hotspotて感じのが一応ある。 CDC用はネフロのVMが実装してたな。 >>497 良いねそれ。eclipseのjavacで試してみよう。 まあ、MEも仕様上はEcmaScript並みに互換性あるけどベンダーの実装が変な事やってんだよね。 MS VMとネスケVMとSUN VMで互換性が無かった時代のように （厳密にはMS VMがネスケVMとSUN VMに互換性なかったんだけど。ライブラリのサポートも屑だったし） 学習能力が無いね日本の企業は。ブラウザ戦争とpureJava騒動であれだけカオスったのに。 501 名前：497 mailto:sage [2007/02/24(土) 22:46:46 ] >>500 IBMがつくったコンパイラは例えば 1. VisualAge for Java 2. j9c(後期型は4と同等) + jxelink 3. IBM JDKのjavac 4. Eclipse/JDT(ecj.jar) 5. jikes が挙げられる。497でstaticメソッドの展開が...って言ったのは 1のjxelink。厳密にはポストプロセッサ。 >良いねそれ。eclipseのjavacで試してみよう。 これが4のことを言っているのなら、1のjxelinkとは別物だよ。 502 名前：デフォルトの名無しさん [2007/02/24(土) 23:54:51 ] >>500 もうさ、メガアプリ限定にしてしまえばいいよ。 俺たちが作りたいソフトはこういうものだから、 ハードウェアをもっと強化しろ！ とハード屋に圧力をかけてさ。 マイクロソフトみたいに力がないと Vistaみたいな激重Windowsを開発してハードウェア屋が それに追従するってこと難しいかな。 今はハード基準で携帯電話開発を強いられているみたいだけど、 ソフト屋からハード屋になんとかして圧力かけられないかねえ。 「お前らハード屋がだらしないから携帯電話開発がしづらいんだ！ ハードのスペックを高めることを要求する！」 みたいにさ 503 名前：デフォルトの名無しさん [2007/02/24(土) 23:58:12 ] >>500 > >>496 > いやジェネリックスが便利なのは認めてるんだけどMEだとVector使うかテストしまくって確実に足りる最小の固定長配列使うか悩むんだよ。 java.nio.Bufferを実装したクラスを配列代わりに扱えば高速化するのでは？ と思ったら、あれJ2SE1.4からのものだった。 > >>497 > 学習能力が無いね日本の企業は。ブラウザ戦争とpureJava騒動であれだけカオスったのに。 SoftBankもまともじゃないし、KDDIもまともじゃないし、Docomoもどいつもこいつも 独占欲だけは高いからねえ。 ハードウェア重視でソフトウェアをなめてかかっているところが、だらしないよ。 日本の有名な大手家電メーカーがインターネット産業ろくに力を注がず、Web2.0に 乗り遅れたことをも証明しているし。 504 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 00:04:27 ] >>502 とは言え、行き過ぎると Vista や PS3 の二の舞になると思うよ。 505 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 00:42:46 ] 国内だとキャリア（←こいつが一番無関係ｗ）、世界的にはハード屋が頂点か。 どちらにしてもオープン標準のJava仕様がないがしろにされてるな。 まあ、ソフト屋ですら飼いならされてる現状じゃ仕方ないか。 仕様の地位をもっとこうW3C勧告の仕様並みに出来んかねぇ？（IEの糞実装さえなくなれば平和だからなアッチは） ハードの方は十分にパワフルだと思うけどな・・・ 翌々考えたら昔はメモリ以外今の携帯以下のハードと糞ＯＳでJavaが動いてたんだから。 win95よりce5のが安定してるしｗ 国内携帯は無駄な機能に溢れ返ってるからそれにシステムリソースとコストと 開発期間が圧迫されて一ソフトウェアどころじゃないだろうな。 またしても仕様の地位不足か・・・ SUNの苦労体質全部をJavaが担ってる気がするｗ 506 名前：デフォルトの名無しさん [2007/02/25(日) 01:02:42 ] >>505 パワフルな割には容量が足りないってどういう事なんだろうなあと思うよ。 メモリもっと増やすべき。でないととてもパワフルじゃないな。 現実問題として電力消費が激しいと言う問題があるそうだ。 しかし省エネ型DRAMのようなメモリがもっと普及すれば解決できるんだとか。 つうか、携帯電話会社は、余計な機能にエネルギーを無駄に費やさず Javaの部分にエネルギーを費やして欲しいな。 あらゆる機能をJavaを中心に動かせるようにすれば水平ポータビリティを 維持できるし、どの携帯電話でも同じように動くアプリを簡単に作れるようになる。 507 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 01:23:02 ] KDDIがBREWで水平ポータビリィティやろうとしてソフト屋・消費者から大ブーイング受けた結果 建前上JBlend on BREW（サービス名オープンアプリ/どこがオープン何だと小一時間・・・）のっけましたが？ Javaで水平ポータビリティ実現すればsunの当初の目的が実現するな。 その為にはベンダーに協力してもらわんとダメだが。 その前に日本の携帯ビジネスモデルを破壊しないと受け入れられないだろう。 4G携帯なんて出したらドコモが死守してソフトバンクが 嘘ばら蒔いてイーモバとウィルが歓迎するんだろうな。 KDDIはBREW動いて音楽と動画DL出来れば何でも良さそうだが。 ネイティブ開発は個人には不可能か敷居高いだろうしJava（MIDP）流行らんもんかね 508 名前：デフォルトの名無しさん [2007/02/25(日) 01:38:36 ] つかネイティブ開発はCPの審査がウザイよ。 審査に金かかるわ時間もかかるわ。 509 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 06:56:24 ] 今のケータイでJavaをやろうとすること自体が間違いなことに気づけ。 510 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 07:12:43 ] て事は昔の、今の携帯以下のスペックで動かしてたJava自体間違いだったって事か 511 名前：デフォルトの名無しさん [2007/02/25(日) 10:59:44 ] Javaで何をするかが問題。 今の技術では、携帯に望みすぎ。 512 名前：デフォルトの名無しさん [2007/02/25(日) 12:55:29 ] >>509 燃料電池またはＨＤＤが搭載されるもしくは PDAなどもっと大型の携帯端末なら、 Javaをやる価値は少しはあるのではないかと言ってみる。 携帯キャリアメーカーもJavaに自分たちの収入源を 奪われるのを恐れて、わざとJavaの機能を制限して Write Once, Run Anywhereの妨害をしているとおもうけどな。 彼らの、Javaの普及を妨害するやり方はつくづく陰湿だと思う。 513 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 13:37:18 ] >>510 CPUのクロックだけで比べても意味がないぞ 514 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 21:46:09 ] まあ、VMはハードウェアとＯＳを仮想化してるから下にパワーが無いとVMも非力になるな。 515 名前：デフォルトの名無しさん mailto:sage [2007/02/25(日) 22:17:51 ] >>510 すごく間違いだと思うなあ。Java熱に浮かされてただけじゃないかな。 516 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 03:24:52 ] >>510 今に間違いじゃない日が来るって おまいのPCのメモリに4GBのせなきゃVistaが・・・とか悩む日が来る事を ５年前に予想してたか？ >>512 わざとっていうか、自由はセキュリティリスクを持っているからな。 徐々に拡大してけばいいだろう 何でも出来る穴だらけの何かがデファクトになるのが怖いよ 517 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 04:23:39 ] >>516 >今に間違いじゃない日が来るって それって、今は間違いってことじゃん。 間違いじゃない日がきてから実用化すればいいのに。 なんでJava以外の選択肢を考えないのかね。 Collectionも使えないなんて、そんなんJavaじゃねーよ。 道具は適材適所。そこまでしてJavaにこだわるのが分からん。 518 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 06:53:19 ] *7の頃から追っかけてるがあの頃の方が見向きもされなかったぞ。 それどころかボロクソに言われてた 昔はAWTすら使いもんにならなかった気がする。もっとスリムだったし。 519 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 08:18:20 ] Avalon・Quartz・Cairoて出そろったのになんでJavaだけJava2Dなんだよ。 新型レンダラまだー？ 520 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 09:07:33 ] JOGLがあるよ。 521 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 10:50:29 ] 3DはJOGLが1.0になったので使い物になった ただ、フルスクリーン時にGLCanvasが描画されないプラットフォームがあるとかが気になる GLJPanelは遅くてゲームなどでは実用にならないし あと日本語ドキュメントが皆無なのがきついな OpenGL部分はどうでもなるがそこ以外が追うのがきつい JOGLがコアAPIになればJOGL自体の機能も充実してくると思われ 522 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 16:20:42 ] JOGLのコア化ってありえるか？ あるとしたら現行Java2Dのハードウェア支援コードとの統合くらいじゃない？ どちらにせよいつの時代もOpenGLはデスクトップ向けVGAのドライバ対応が中途半端だからな。 ワークステーション向けは知らんが。 523 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 16:59:41 ] >>516 > >>510 > 今に間違いじゃない日が来るって > おまいのPCのメモリに4GBのせなきゃVistaが・・・とか悩む日が来る事を > ５年前に予想してたか？ > >>512 > わざとっていうか、自由はセキュリティリスクを持っているからな。 > 徐々に拡大してけばいいだろう > 何でも出来る穴だらけの何かがデファクトになるのが怖いよ 多重継承も演算子オーバーロードも何でもできますよとPRする C++言語仕様じゃあるまいし。それはちょっと違うだろう。 Javaでできることはいっぱいあるのに、あえて彼らがそれをやらないのは 彼らが己の既得権益が破壊されるのを恐れているから。 日本企業はハードウェアに強い企業は多いけどソフトウェアには弱い 企業ばかりだからね。ソフト屋にハード屋をつぶされるのを恐れている。 その構図は、テレビ局などのメディアがインターネットを嫌っている理由に非常に良く似ている。 彼らがインターネットやGoogle、Web2.0を嫌っているのは、 彼らが苦労して長い時間をかけて培ってきたノウハウを破壊されるのを恐れているから。 彼らは小泉純一郎のような「痛みを伴う改革」や「格差社会」に自分たちが巻き込まれる ことをひどく嫌い、ひどく恐れている。 524 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 17:06:04 ] >>517 Javaでもこういうことができるよってことで、 とりあえず宣伝だけしておいただけだと思うがな。 いや「だけ」ってことはないな。 Sunが目指していることを実現するための 前準備としての実験でもあったわけだし 一般人にも、Javaというものがどういうものか、 これで理解してもらえたかもしれないね。 最近じゃauの勢力が拡大してどうなるかわからないけど、 一応、BREWの上でJavaも動かせると言われているし。 それに携帯Javaアプリは使えるものはいくつもある。 SuicaのアプリだってＦｅｌｉＣａチップと入出力するところを除き、 アプリケーションはJavaでできている。 なんだかんだいって、燃料電池のような大容量電池を携帯電話に搭載し、 チップが小型化すれば携帯電話Javaもますます良い方向に進んでゆくと 思うけどね。 そこで、Java以外の選択肢を出すと、結局ベンダ依存になってしまう。 今でさえ、JavaアプリはSoftBankとDocomoとでは異なるAPIを使用しているとはいえ、 基本的なAPIはベンダ依存していない。Java以外の選択肢で、 複数のキャリアに対応したアプリを作ることは、そう簡単なことではなかったはず。 BREW開発なんてCPに検査してもらうコストも時間もかかるし、メモリリークの 心配ばかりしないといけないし、容量は相変わらずS!アプリやiアプリの半分くらいでとっても地獄じゃないか。 そう考えると、Java以外の選択肢は、いまのところ、ろくなものがないと思うけどね。 525 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 17:21:02 ] >>523-524 マ板行け。 526 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 17:30:02 ] マ板ネタも含まれているかもしれないけどJava MEの将来に対する 要望も含まれているから、ここでもいいのではないかと 527 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 17:35:53 ] >>526 要望なら要望聞いてくれるところで言わんと意味無かろうが。 動機からして現状を変えたいというものではなく、 単なる現状の愚痴なわけだし、完全にマ板ネタだろ。 >>523-524 は技術的な話ですらないし。 528 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 22:03:34 ] 表題みるかぎりSE専門かと 529 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 23:23:01 ] 技術的な話も含まれているがのう。 要望ねえ。JCPか？ 530 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 23:26:20 ] >>529 含まれてないよ。マ板池。 531 名前：デフォルトの名無しさん mailto:sage [2007/02/26(月) 23:29:54 ] >>530 営業やってる連中とか、プログラマ卒業した連中とかだと >>523-524 が技術的に見えるのかもしらん。 532 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 03:14:34 ] むしろBREW上のJAVAで話を広げて欲しかった。 というか、そろそろ携帯でJavaSE動かすことできそうなんだけど・・・ Mysaifuの取り組みには期待している 533 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 06:00:49 ] >>524 >今でさえ、JavaアプリはSoftBankとDocomoとでは異なるAPIを使用しているとはいえ、 >基本的なAPIはベンダ依存していない。Java以外の選択肢で、 >複数のキャリアに対応したアプリを作ることは、そう簡単なことではなかったはず。 ダウト。Write once Run anywhere はケータイでは全然できていない。 APIも仕様も違うのに、簡単とかいうな。お前、じつは作ったことないだろ。 ＃何だよ、scratch padって。 #if #else #endif が使えるC++のほうがまだケータイ向き。 でもauの審査がクソ遅いのはなんとかしてほしい。マジで。 > そう考えると、Java以外の選択肢は、いまのところ、ろくなものがないと思うけどね。 それこそお前が知らんだけじゃん。Pythonが使える機種があるんだけど、これなかなかいいよ。 つうかPalmOSが載ってくれれば一番よかったんだよ。なんでJavaなんだ？ 534 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 07:00:15 ] >>532 phoneME Advancedのどこが不満なんだ！ｗ Mysaifu JVMは俺も入れてるけど・・・。 だって〜かんきょうなくてびるど出来なかったんだも〜んｗｗ まあ、冗談は置いといてphoneME AdvancedならRIだし全部入りだしHotoSpotあるし、phoneMEベースのプロジェクトを見かけた事ないのが不思議だ。 てかBREW自体流行ってないし国内じゃあうのせいでBREWの印象悪いし、正直実装さえしてくれたらKJNIの方が良いな。 もうちょっとJBlendがRI通りに実装してくれたら・・・ MIDPにMMAPIのprotocolパッケージ入れてくれたら・・・ WavPlyer実装してくれたら・・・ 後はデコードくらい自分でするのに・・・ ところでMEにnioパッケージ実装しても端末の物理メモリが足りませんって落ちになるんだろうか？ 535 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 07:09:12 ] >>533 M1000ってPalmじゃなかったけ？ MIDPが使えるからkjavaじゃなくてMIDP for Palm OSなんだろうか。 536 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 12:07:15 ] >>532-535 キミら、次世代と関係ない話題は他所でやってくれんかね？ 次世代っても、勝手な妄想とか勝手な要望とかは愚痴と変わらんのよ。 便所に「税金安くしてくれ」って書いて要望とか言わんでしょ。 537 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 19:04:27 ] て言ってもSE7って情報少ないな 538 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 20:21:12 ] これがSDKに内包されてjavaguiが広まないかなぁ journal.mycom.co.jp/articles/2007/02/26/jsr296/ 539 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 21:17:25 ] それSwing普通に使える人にとってメリットがほとんどないぞ フレームワークがはやったから作っただけというのが近い struts以上に薄いラッパだし、SwingWorerとダブるところも多いし これほどメリットがないフレームワークってのも珍しい 540 名前：デフォルトの名無しさん mailto:sage [2007/02/27(火) 21:33:51 ] ポトペタツールが対応するか次第のよーな。 541 名前：デフォルトの名無しさん [2007/02/28(水) 09:38:38 ] >>533 > >>524 > #if #else #endif が使えるC++のほうがまだケータイ向き。 > でもauの審査がクソ遅いのはなんとかしてほしい。マジで。 プリ糞セッサに依存している時点で設計が全然駄目じゃん。 > > そう考えると、Java以外の選択肢は、いまのところ、ろくなものがないと思うけどね。 > それこそお前が知らんだけじゃん。Pythonが使える機種があるんだけど、これなかなかいいよ。 Python載せられることのどこがいいの理解できない。 542 名前：デフォルトの名無しさん mailto:sage [2007/02/28(水) 22:01:15 ] どこかで見たような・・ 543 名前：デフォルトの名無しさん mailto:sage [2007/02/28(水) 22:22:37 ] >>533 んー、まえもimodeスレかMIDPスレで書いたけど、#ifdefのような条件 コンパイルがデメリットなく出来るようJavaの言語仕様はうまくできているん だよね。C/C++の後追いだからちゃんと考えられてる。仕様書よんでごらん。 そのほかJavaME向けにインライン展開がんがんつかうようなコンパイラ 併用してクラス設計すると携帯向けでもプリプロセッサって必要ない。まあ マクロはないから文法ひっくりかえすような表記でコードは書けないけど、 それはC/C++でも行儀良くないからな。 544 名前：543 mailto:sage [2007/02/28(水) 22:31:04 ] スレ違いの話だけだとあれなんでSEの話もふっとく。 techon.nikkeibp.co.jp/article/HONSHI/20070220/127928/ ↑ OSGi(JSR232)はJavaMEの分野では静かに着々と浸透しているのに SEへの導入(JSR291)は及び腰なんだよな、Sun。自分で旗振って OSGi始めたのにいまさら梯子外すのはないよなあ。 545 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 09:21:12 ] >>543 >#ifdefのような条件 >コンパイルがデメリットなく出来るようJavaの言語仕様はうまくできているん だからそれはJ2SEのような環境が統一されている場合の話であって、 機種依存が激しい携帯ではなりたたないって。 VMですら機能やバージョンが違うのに。 >そのほかJavaME向けにインライン展開がんがんつかうようなコンパイラ >併用してクラス設計すると携帯向けでもプリプロセッサって必要ない。 インライン展開があればプリプロセッサは必要ないという根拠が分からん。説明よろしく。 546 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 10:02:45 ] >>543 >#ifdefのような条件 >コンパイルがデメリットなく出来るようJavaの言語仕様はうまくできているん MEで一つのソースの中に複数ターゲット向けのコード混ぜたら絶望的なソースになるよ？ 最低プロファイル・機種毎にソース分けんと確実に死ねる。 jadも分けんとたまにハマるから油断できん！ 547 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 10:13:36 ] あー言い忘れたeclipseでリファクタリングしただけでエミュでは動いて実機では動かなくなるのがMEの世界だ。 システムが勝手に走らせる特定のスレッドの実行が一定時間以内に終わらないと強制終了とか。 実行時例外catchしてcatch節でコード実行すると問答無用で落とすとか（catchしても何もしなければ良かったり、ときにはcatchすら許してくれない） あと実機じゃ機嫌悪いと動くコードもマジで動かん。 MEでプリプロセッサ使ったソースなんて保守以前の問題。 548 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 10:58:01 ] >>545 >だからそれはJ2SEのような環境が統一されている場合の話であって、 >機種依存が激しい携帯ではなりたたないって。 >VMですら機能やバージョンが違うのに。 つーか、J2SEでも、Sun/IBM VM間のクセの違いの吸収や、 Sun VMでもSwingの1.4, 5, 6での差を吸収させるのに、#ifdefは欲しい。 549 名前：デフォルトの名無しさん mailto:sage [2007/03/01(木) 11:39:58 ] いやだからそういう次元じゃないとｒｙ MEやれ 550 名前：デフォルトの名無しさん mailto:sage [2007/03/02(金) 00:07:56 ] >>548 SEで、ifdefは勘弁して欲しい。 それなら、せめて其処のコードは別クラスに分けて設計してくれよ・・・ 551 名前：デフォルトの名無しさん mailto:sage [2007/03/02(金) 20:50:21 ] JDK7 build09 download.java.net/jdk7/changes/jdk7-b09.html download.java.net/jdk7/binaries/ 何だろう？2回続けてサマリがないビルドだ・・・ まあ今回もupdateするけど〜 552 名前：デフォルトの名無しさん mailto:sage [2007/03/02(金) 21:32:24 ] >>551 >>470 のリンク先見たら前回のは出てる。 ビルド方法でトラブってて changes が自動生成できてないから、 後から手動で生成してるとか？ それとも単に怠慢で遅れてるだけ？ 553 名前：デフォルトの名無しさん [2007/03/03(土) 07:27:48 ] フィールドのgenericTypeを取りたいんだが方法はある？ 例：List<Integer> listのInteger 554 名前：デフォルトの名無しさん [2007/03/03(土) 08:19:37 ] >>544 べつに無理にJava標準に含めることを早めなくても問題なかろ。 早めることよりもむしろ、理にかなってこそ導入すべきだが。 Javaを駄目にするおそれがあるとしてJavaに導入することをまだ認めていないだけだと思うぞ。 JCPは少なくとも、Java SE 1.3以降からの上位互換性をもの凄く気にしているようだから 下手にほいほいと導入するわけにはいかんでしょうや。 そう考えると、enum型の導入が遅くなった理由もなんとなくわかる。 OSGiはなぜかEclipse Communityががんばっているようだし。 Eclipseのプラグインフレームワークに導入されているが、 SunとIBMだもんね。そういうところでは決して仲がよいとはいえないしねえ。 SWTを巡る技術的な問題もあるし。Swingは遅いからSWTを作ったと主張してきたIBM に不信感を抱いているのではないかな？ 555 名前：デフォルトの名無しさん [2007/03/03(土) 08:22:53 ] >>548 駄目だお前。 ソフトウェア工学をなめとる。 修行が足りんぞ。 556 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 08:24:07 ] >>553 get(i) 557 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 08:28:45 ] >>553 download.java.net/jdk/jdk-api-localizations/jdk-api-ja/builds/latest/html/ja/api/java/lang/reflect/ParameterizedType.html 558 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 08:50:51 ] >>557 $ cat Test.java import java.util.List; import java.util.ArrayList; import java.lang.reflect.ParameterizedType; import java.lang.reflect.Type; public class Test { public static void main(String[] args) { ArrayList<Integer> l = new ArrayList<Integer>(); Type type = l.getClass().getGenericSuperclass(); ParameterizedType pt = (ParameterizedType)type; for (Type t: pt.getActualTypeArguments()) { System.out.println(t); } } } $ java Test E ありゃ。 559 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 09:02:20 ] class IntegerList extends ArrayList<Integer> {} public class Test { public static void main(String[] args) { Type type = IntegerList.class.getGenericSuperclass(); for (Type t: ((ParameterizedType)type).getActualTypeArguments()) { System.out.println(t); } } } とすると class java.lang.Integer となるな。 560 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 11:03:18 ] >>553 List<Integer> の Integer はコンパイル時に情報消えるよ。 >>559 みたいなのは特殊な例。 561 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 11:15:54 ] って、ローカル変数じゃなくてフィールドの宣言についてか。 public class test {     public List<Integer> sample;     public static void main(String[] args) throws Exception {         for (Type t: ((ParameterizedType)test.class.getField("sample").getGenericType()).getActualTypeArguments()) {             System.out.println(t);         }     } } >java test class java.lang.Integer 562 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 11:21:52 ] >>558はgetClassしてる時点でどうなるかをかんがえればよろし 563 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 14:24:41 ] >>553 初心者質問スレ行けよ。 564 名前：デフォルトの名無しさん [2007/03/03(土) 15:28:47 ] >>556-563 �d 565 名前：デフォルトの名無しさん mailto:sage [2007/03/04(日) 09:29:05 ] >>551 追記： 見た目で大きく変わるところ発見。 Javaのウィンドウのデフォルトアイコンがデュークのアイコンになってる！！ 可愛いです。 デュークのライセンス変更で、こういう事になったのね わかりにくいカップよりコレはいいな 566 名前：デフォルトの名無しさん mailto:sage [2007/03/05(月) 16:02:11 ] invokedynamic 使えるかどうかプログラム側から判断するのって、どうすれば良いですか？ 567 名前：デフォルトの名無しさん mailto:sage [2007/03/05(月) 16:44:34 ] >>566 実行時に動的でも静的でも良いから invokedynamic 使ったクラス読み込んで、 エラー出たら使えないんじゃね？ そーいや、invokedynamic って今どーなってんだろ？ invokedynamic のオペランドとかの詳細あったっけか？ 568 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 15:34:36 ] 某スレの 288 へレス。 > クロージャよりは揉めずに入りそうな気がしてる。 ウソはいかん。javac の人なんかはイラネって言ってるし。 blogs.sun.com/ahe/entry/java_se_7_wish_list 要は、プロパティに dot でアクセスしようとすると、 既存のフィールドアクセスと区別つかなくなるので、後付の面倒なルールを加える必要があるから嫌だそうで。 例えばフィールド宣言したコンパイル単位ではフィールドアクセスで それ以外ではプロパティアクセスとか、 プロパティと同名のフィールド持てないとか、そんな感じのルール。 どんなルールで対処するにせよ、完全な互換性維持は無理だろうし。 もしくは "->" とかでプロパティにアクセスする とかだけど、これはこれでキモイから嫌なんだそうで。 weblogs.java.net/blog/forax/archive/2007/01/property_reload.html ksl でプロパティの試験実装してた人とかも、 Access to property は setter getter で、って意見変えてるし。 569 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 17:20:57 ] >>568 そうか、キモイか・・・うん、キモイなぁ dotを使うのは、駄目と言う点は全く賛成だが 表記方法さえ、決まればOKだと思ってるんだけどなぁ 俺は、個人的な好みは->はキモイけど、 : ならOKです。 570 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 17:41:54 ] :: . .* -> ->* いろんな言語のaccessor。あと何があったっけ？ 571 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 17:48:11 ] >>569 オレ自身は "->" でもいいじゃん、とか思ってたりする。 他の人が "->" がキモイって言うのも理解できるんだけど。 jroller.com/page/scolebourne?entry=property_access_is_it_an ${classInstance.propertyName} みたいに ${} で括った部分では 式言語使えるようにすりゃええやん、ってのも出てるけど…… そこまでして dot に拘らんでも、と思わなくもない。 572 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 18:14:36 ] >>569 :: じゃなくて : なの？ class A { property Object b; } class B { property Object c; } class Hoge { 　A a; B b; Object c; 　boolean flag; 　Object method(){ 　　return flag ? a : b : c; 　} } とかされると分かりにくくなるよーな気もする。 構文解析自体は結合順位とかがあるから出来ると思うけど。 573 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 18:15:17 ] dot人気ないね。 フィールドアクセスとプロパティのインターフェースを別のものにしたら、 単なるgetter/setterの省略表記になってしまってあまりうまみがないと 思うのは俺だけかな？ 574 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 18:42:44 ] >>573 皆が納得できる上手いルールが作れれば dot でも良いと思うけど。 人気がないって言うよりも、>>568 のような追加ルールを決める部分を 誰もやりたがらないような気もする。 簡単なルールで互換性壊したりすれば既存のソース使えなくなった人から嫌われるだろうし、 なるべく互換性維持しようとすると、ルールが複雑になって 今度はコンパイラの作者とかから嫌われるだろうし。 >>132 のリンク先が紹介された後、"->" はキモい、dot が良いって言ってた連中の blog 見た感じだと、>>568 みたいな問題を小さく考えてるか、 もしくは問題自体を理解してないような。 C# みたく最初から言語機能としてプロパティを持ってる言語ならともかく、 Javaの場合は既存のJavaBeansのプロパティがあって後付けしようとしてるんだから getter/setter の省略表記と割り切った方が現実的じゃないかな？ 575 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 22:38:47 ] >>572 あ、いや、: ←コロンを使うという意味だった。 Perl、Pnutsなんかで親しんでいる例からいくと、 :: で使うのを想定してた。 一つだと、 hogehoge==null？a : b; とか、switchが混乱するから。 >>573 いや、むしろそれがいい。 見たら裏で何をしているかがよく分かる。 別に、dotではなくて :: でも可読性は落ちないと思う。 -> は、演算記号と紛らわしくて、嫌。 576 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 23:03:00 ] プロパティなんてそもそも本質的には冗長な機能なんだから、 どうせ使えるようにするならマイクロソフト系の言語と同じ記法でいいと思うんだがなあ。 577 名前：デフォルトの名無しさん mailto:sage [2007/03/11(日) 23:08:52 ] > マイクロソフト系の言語と同じ記法でいいと思うんだがなあ。 具体的には？ 578 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 03:22:06 ] C++で->使ってるから、->でいいや。 579 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 04:10:14 ] >>576 VBだとdotじゃなかったっけ？ 580 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 08:32:28 ] >>577,579 VB,C#ともどっとだね。 仕様策定してる連中がドットを嫌う理由がよくわかんない。 どうせ現存するソースコードにはプロパティ使ってるものなんて無いんだから 新しくプロパティの意味を持たせても別にいいと思うんだが。 581 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 08:50:48 ] >>580 C# だと、同名のプロパティとフィールドは同時に宣言できないんだっけか？ まぁ、そーゆー後付けのルール追加すりゃ出来るかもしれんけどさ。 Javaに、そんなルール後付けしたら互換性無くなるし。 なんでこんな簡単な事が理解できないのかわかんない。 582 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 08:55:00 ] >>581 プロパティ自体後付けじゃん…て思ったんだけど、 setter/getterペアにアクセスする演算子のことなのか。 プロパティ定義の構文も新しく作るのかと思ったよ。 C#の Property Hoge { 〜 } みたいにさ。 だったら「そんなもんｲﾗﾈ」に一票だなあ 583 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 09:19:05 ] >>582 > プロパティ自体後付けじゃん…て思ったんだけど、 JavaBeans のプロパティ自体はあって、その構文糖を追加しなければならない。 だから、完全に後付けってわけでもない。 JavaBeansのプロパティや、それを使ってる既存のフレームワーク捨てるなら別だけど。 あとプロパティ定義の構文を新しく作っても、プロパティアクセスに dot 使えば問題は出る。 例えば、 class MyComponent implements java.beans.DesignMode { 　private boolean designTime; 　public boolean isDesignTime(){ return designTime; } 　public void setDesignTime(boolean f){ designTime = f; } } みたいな既存のコードがあるとする。 プロパティが追加されて java.beans.DesignMode が interface DesignMode { 　public static final String PROPERTYNAME = "designTime"; 　public abstract property designTime; } みたいに変更された場合に、MyComponent をコンパイルする（＝互換性を持つ）のが難しい。 584 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 09:57:09 ] >>580 > 仕様策定してる連中がドットを嫌う理由がよくわかんない。 dot 使ったらフィールドアクセスとプロパティアクセスの区別がつかなくなると何度言えば…… 585 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 10:02:47 ] >>580 > どうせ現存するソースコードにはプロパティ使ってるものなんて無いんだから ひょっとして、現存するソースコードに Beans のプロパティ持ってるものが 大量にあるって事がわかってない？ 586 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 11:37:56 ] だからさ、プロパティってのはgetter/setterペアのことじゃなくて それとは別に新しい概念を持ち込むのかと思ってたって>>582に書いたでしょう。 何嬉しそうにツッコミいれてんだよ。 587 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 11:41:08 ] > 何嬉しそうにツッコミいれてんだよ。 いや、無知だなぁ、と思って。 588 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 11:51:08 ] >>587 どの辺が無知だったか教えてちょ。勉強するから。 589 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 11:56:57 ] >>588 このスレに出てるのだけでも、プロパティに関するリンク先読んでれば beans と関係のない新しいプロパティを導入するとか思わんでしょ。普通。 590 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 13:21:21 ] >>589 そうだな。すまんかった。 591 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 20:35:44 ] >>583 >みたいに変更された場合に、MyComponent をコンパイルする（＝互換性を持つ）のが難しい。 ここがよくわかんないんだけど、誰か解説して。 アクセッサがあればそちらを優先的に使う（あるいは逆にフィールドアクセスを優先する）というルールを決めればすむ話じゃないの？ で、583みたいな状況になったらコンパイラが警告を出してくれればそれでいいと思うんだけど。 592 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 20:47:38 ] >>591 > アクセッサがあればそちらを優先的に使う それやったらコンパイルが通らん。 > フィールドアクセスを優先する フィールドでプロパティを上書きできるようになるけど、それで良いんか？ 593 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 20:56:24 ] × フィールドでプロパティを上書き ○ フィールドでプロパティを覆い隠し 594 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 21:00:25 ] >>592 > > アクセッサがあればそちらを優先的に使う > それやったらコンパイルが通らん。 いや、コンパイルは通るかもしれんが…… 例えば > public boolean isDesignTime(){ return designTime; } は public boolean isDesignTime(){ return isDesignTime(); } に展開されるから実行時に StackOverflowError 吐いて死ぬ。 595 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 21:20:38 ] >>584 区別させないのがプロパティだろうに。 596 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 21:24:32 ] >>595 コンパイラが区別できないって意味なんだけど。 人間が区別しないとか、区別を意識させるべきでないってのとは別の話だよ。

---

---

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

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