[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/ 445 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 16:32:00 ] >>444 System.GCしか今のところコントロールする方法はない。 あとはVMの実行時パラメータでヒープやアルゴリズムの調整でカバー。 ただ、System.GCはほとんどの実装でFullGC動くので実質使っちゃダメ。 System.newGCとかがあればかなり変わるんだろうけど。 ゲームとかにしろ常にシビアなタイミングがあるわけじゃなくて、今は100μsも遅れるとまずいけど このタイミングなら10msは大丈夫とかあるからね。 1フレームに1回殿堂入りさせない新世代GCが指定できればそれでおけ。 どうもsunはここ数年リアルタイムJavaに力を入れてるんだけれども、 常にリアルタイム性が必要な用途ってのは少ないと理解してないっぽい。 446 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 17:33:20 ] > 所でJavaってGCが勝手にメモリガリガリやってるから > メモリの断片化をプログラマで制御出来ないよな？ ↑出来る処理系ってあるの？ 447 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 17:47:52 ] >>446 C/C++だとメモリ管理は自分でするから確保も解放も 自分のタイミングで出来るって程度の意味だ。 勝手なタイミングでガンガンGCされるより断片化起こらないよねって話な。 448 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 18:01:42 ] >>447 それはおかしい 断片化と解放とは別の話だろ それにC++だってアロケートしなおししないと同じだし JavaのGCはそのタイミングをコントロールできないという点だけが問題 449 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 20:44:23 ] >>445 -XX:+ExplicitGCInvokesConcurrent で、Java6なら完全停止は回避できる、のかな？ ttp://java.sun.com/javase/ja/6/docs/ja/technotes/guides/vm/cms-6.html 450 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 23:45:23 ] >>448 mallocなりOS依存のシステムコールで、でかいメモリとってきて、その中に placed newでオブジェクト作れば、制御できると思う。 制御できるだけで、断片化しないメモリ確保戦略はプログラマ任せになるが。 451 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 23:50:06 ] >>444 GC でコンパクションが発生するのに断片化って??? 452 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 23:53:01 ] なんか、全然次世代じゃない話で盛り上がってるな。 453 名前：デフォルトの名無しさん mailto:sage [2007/02/21(水) 23:57:03 ] >>452 いつもの事だ。 454 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 00:01:05 ] >>445 > >>444 > System.GCしか今のところコントロールする方法はない。 java.lang.ref.SoftReferenceを使えば間接的にコントロールすることもできる。 455 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 00:02:05 ] >>445 > >>444 > どうもsunはここ数年リアルタイムJavaに力を入れてるんだけれども、 > 常にリアルタイム性が必要な用途ってのは少ないと理解してないっぽい。 彼らがJavaを作った目的は家電制御なんだけどな。 彼らはサーバを発電所のように使うものを想定している。 456 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 00:04:13 ] >>446 Bufferインタフェースを使って 巨大な配列を確保すれば 擬似的に管理できないこともないぞｗ C/C++はメモリ全体を巨大な配列として扱えるようになっているのだから。 Javaでも巨大な配列をBufferで作れば似たようなことはできなくもないw 457 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 00:05:52 ] java.lang.refでオブジェクトの「到達可能性」をコントロールできる 香具師はいないのね 458 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 00:14:10 ] >>457 そりゃ、居ないだろ。 あれは到達可能でなくなった事を知るためのもので、 到達可能でなくす事を可能にしてくれるわけじゃない。 459 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 01:27:33 ] >>454 それ定期的に出てくるけどぜんぜんコントロールできねーよ 460 名前：デフォルトの名無しさん mailto:sage [2007/02/22(木) 13:56:01 ] いつの世代でもGCは永遠の謎なのだ。 461 名前：デフォルトの名無しさん [2007/02/22(木) 21:22:26 ] GCなしの方がよかったかもな〜 462 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 00:09:49 ] GCなしなんていまさらありえんだろ 463 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 00:26:43 ] C++に逆戻りか？ 464 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 00:27:32 ] C++0xの使用をみたが、期待はずれだった。 あんな仕様では当分Javaには勝てないことがわかった。 D言語やC#のほうが全然魅力的だった。 465 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 00:31:08 ] もう使用されているとは 466 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 01:51:35 ] なんで、C++はそんなに使用を拡張していくんだろうねぇ…。今でも十分じゃん。 467 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 01:57:48 ] そうだよな。 チンコの仕様に優れていても、使用に優れてない奴とかいるし。 468 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 02:01:08 ] チョンの仕様かと思ったw チョンのチンコの仕様は9cmで世界一ミクロ 469 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 02:06:38 ] 仕様も使用もダメな例だな 470 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 04:24:39 ] JDK7 build08 download.java.net/jdk7/changes/jdk7-b08.html download.java.net/jdk7/binaries/ サマリが何も出来ていない 変わってないのかっ と疑問も持ちつつUpdateする俺でした 471 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 05:02:19 ] マネージド○○って完全にわすｒｙ 472 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 06:35:41 ] CompilerAPIとRhino入れちゃったらこのノリでant入れそうで怖い。 最近標準化連中は仕様作り過ぎｗ C++のexportみたいにry コンパイル→テスト→ビルドの流れが全てプログラミング出来ます！ みたいにさ。 マジレスするとunsignedが欲しい。 static final unsigned byte の範囲の定数が欲しいのにって度々思う #Java書いてるとshortの存在を忘れてint使っちゃう俺 473 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 07:56:31 ] >>472 >static final unsigned byte の範囲の定数が欲しいのにって度々思う short や int じゃだめってこと？ ケータイJavaかなんかかな。 474 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 08:57:09 ] マイナス、負の値を使えばいい。 475 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 10:10:27 ] >>473 そうJ2MEなんかで何かのパーサ書いてるとステータス操作に丁度0-128を使うことがあったりして。 ビット操作中心なんで負数は使えんし、 そもそもMEで使わんディスクスペースとヒープを確保する余裕はない！ そもそもstatic finalなフィールドすら宣言する余裕なんて無いんだよ。 文字列定数の長さを気にする様な世界だ。 ややこしい・・・ 476 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 11:16:49 ] >丁度0-128を使う 嫌がらせだなｗ 477 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 11:19:44 ] >>475 ビット操作でも負数は使えるはずだが 478 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 12:33:58 ] まあ、負数使いたくないのは個人的理由でもあるｗ どうせ作ってたらサイズでかくなって定数をプリプロセッサやエディタの置換なんかで マジックナンバーに展開して定数フィールド排除、 クラス名・メソッド名・フィールド名・インターフェイス名何かをAとかBとかにして長さ短くしてそもそもOOP何か無視して設計して 昔はそれでもダメなんでバイナリエディタで無駄なバイトコード手作業で最適化してサイズ落としたよ。 （まあ、今は難読化だけで間に合うが） そんなんでshortとかintとかlongなんて無駄に使ってられませんｗ 少数も勿論固定少数点数ですｗ XML1.0とXML in Namespace 仕様フルサポートしたライブラリ書いてjarサイズが50K台じゃでか過ぎるって世界だぜ・・・orz 一般的にはCLDC用のXMLパーサって10K台だよ。 ＃つくづく趣味グラマで良かったと思うこの頃。 よくopera mini何て出来たもんだ 479 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 13:38:05 ] >>472 > CompilerAPIとRhino入れちゃったらこのノリでant入れそうで怖い。 > 最近標準化連中は仕様作り過ぎｗ > C++のexportみたいにry > コンパイル→テスト→ビルドの流れが全てプログラミング出来ます！ > みたいにさ。 > マジレスするとunsignedが欲しい。 > static final unsigned byte の範囲の定数が欲しいのにって度々思う > #Java書いてるとshortの存在を忘れてint使っちゃう俺 ラッパークラス作れ 480 名前：デフォルトの名無しさん [2007/02/23(金) 13:54:21 ] >>475 > >>473 > そうJ2MEなんかで何かのパーサ書いてるとステータス操作に丁度0-128を使うことがあったりして。 今はJ2MEではなくJava ME。 つうか、もうそろそろ、スペック問題解決してもいいのでは。 昔と比べ、容量は10倍以上になったんじゃないのか？ S!アプリももう何年か前から1MBアプリを作れるようになったし iアプリも903iからDoja5.0になって1MBにもなったし、今やダウンロード、スクラッチパッドの境界が 無くなって外部メモリも使えるようになって1MB以上のアプリも作れるようになったろ。 昔の10kB時代と比べたら全然気にしなくても良いようになってきたんではないのか？ 481 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 13:55:32 ] >>476 0-127に加えて-1か128を128替わり使えばいいのではと 482 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 13:56:13 ] >>478 とりあえず新たにデータ型作るってのはどうよ 483 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 13:57:12 ] >>478 jarsで圧縮率を上げればjarサイズが半分になるぜ 484 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 21:57:02 ] static final は普通に、コンパイラでインライン展開することが 言語仕様で決まってなかったっけ。 485 名前：デフォルトの名無しさん [2007/02/23(金) 22:04:07 ] 今のJava MEではGenericsやアノテーションは 使えるのか？ 486 名前：デフォルトの名無しさん mailto:sage [2007/02/23(金) 22:05:35 ] >>484 決まってない。final で修飾されて、確実に定数式で初期化される変数だけ。 それに、ME とかの場合は static final な変数自体も節約したいんでしょ。 487 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 03:48:32 ] >>845 使えない。VM仕様がJITがオプション扱いでブートストラップクラスローダしかない1.4か1.3時代程度だったとオモ。 けどジェネリックスなんて使うケースないと思う。 MEじゃあるべき処理を平気でとっぱらうからアルゴリズムの使い回しとか不要。 他にも汎用データクラス作るんじゃなくて一つのクラスに全てのデータと処理をぶち込むからジェネリックスの立場がない・・・。 インターフェイスすら排除する世界だぜｗ ところでこんなリスト見つけた。VM仕様関連の情報らしい。 ttp://www.ingrid.org/java/vm/ 488 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 12:23:48 ] >>487 ジェネリクスはコレクションを手軽に扱うためだけとおもっても十分な効果が出るよ 489 名前：デフォルトの名無しさん [2007/02/24(土) 12:59:51 ] Java SE 5になってから大分高速化したのに携帯電話には まだ搭載できないでいるのか・・・ しかもまたまた1.3レベルとは。assertも使えぬのか。 アノテーションくらいはつかえたほうがいいとは思うのだが。 コンパイル時には無視できるタイプのアノテーションはとくにあったほうが便利だろう？ それに、いくつかクラスやメソッドが増えているし。 制約上全部は使えないとは思うけど、利便性を考えると、1.3レベルってつらそう。 490 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 13:32:37 ] >>487 > ttp://www.ingrid.org/java/vm/ 古いね。デッドリンク多いし。 491 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 15:42:08 ] >>489 高速化したのはSunのJava SE 5の実装で、Javaっていう規格じゃないだろ。 ケータイって、SunのJVMが主流なの？ 492 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 17:23:16 ] >>488 コレクションFWないよ？レガシーしか。 java.util.*はDataとCalenderが端末依存でGMTすら禄に扱えない。 端末毎に返ってくる値が違う事があるし端末の時計とは 別にＶＭが時計持ってて端末と時間違うし時計アプリなんて信頼できんよ？ UTCなんてない。 これでもちゃんとした仕様の範囲だから困りもんだ。 >>491 主流はアプレックスのJBlend。 一応どこもsunのRI参照してるけど遅いとか理由付けてとことん独自実装＋JITが無いんでベンダー独自のインタプリタ高速化技術なるものを実装してRIとは別物。 KDDIとかSBM専用のオプションパッケージの実体はcom.jblend.*パッケージが主でリンク用のスタブクラスとJavaDocをCPに公開してるだけ。 最近のSEの仕様の恩恵が受けられないのが保守性が悪い悪い・・・ ドコモキャリア仕様の端末以外例外投げると問答無用でVM落とすしエラー出力ないから酷い酷い・・・ クラスローダーがブートストラップのしかないんで動的リンクできんしJarサイズがデカクなるって言うんで汎用のFWは作れんから 再開発部分が多いだろうねぇ。 プリベリファイがSEに取り込まれたんだからMEに何かくれよｗ 493 名前：デフォルトの名無しさん mailto:sage [2007/02/24(土) 17:52:22 ] >>492 CLDC 1.1 なら java.util.TimeZone が GMT をサポートするのは義務じゃなかったっけ？ TimeZone は GMT をサポートするけど、それを使っても GMT な時間が返ってくるとは限らないってオチはあるかもなー、とか思った。 そーいや、JSR-310 で Date and Time API ってのがあったような。 あれって、JDK7 の contents だっけか？ 494 名前：デフォルトの名無しさん [2007/02/24(土) 18:28:20 ] >>492 System.currentTimeMills()の値を引数にして DateやCalenderを作っても正確にならない？ 495 名前：デフォルトの名無しさん [2007/02/24(土) 18:31:30 ] >>492 > >>491 > 主流はアプレックスのJBlend。 > 一応どこもsunのRI参照してるけど遅いとか理由付けてとことん独自実装＋JITが無いんでベンダー独自のインタプリタ高速化技術なるものを実装してRIとは別物。 遅いとかではなく、かれらがハードウェアリソースをケチっているだけだと いってみたかったりする。 携帯電話をもう少し大型化して、JVMの部分を物理的に大きく専有するようにして、電池も 巨大化させれば携帯電話でも十分早くなるはずだ、と言ってみる。 ハードディスク搭載、とバッテリ寿命さえ延びれば、さらにその理屈もとおるはずだ、と言ってみる。 そして、連中は、独自実装で市場を独占したいだけに過ぎないのだ、 かつてのSonyがやってたような、独自製品で覆い尽くし、ライバル製品との 互換性をわざと奪うために標準Java実装から逃げているだけなのだ、と言ってみせる。 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 コンパイラが区別できないって意味なんだけど。 人間が区別しないとか、区別を意識させるべきでないってのとは別の話だよ。 597 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 22:11:17 ] >>596 まぁ互換性を維持してのプロパティの導入には実装上の困難を 解決できていないというのはいいんだが、だからといって 「できる方法で実装しちゃおう」となるとしたら賛成できないなぁ。 互換性の面から考えた場合、方法は大きく3種類に分類できて、 1.JavaBeansと相互に互換性のある方法 2.JavaBeansとは互換性がないが、バイトコードレベルでの 　仕様変更を伴わない方法 3.バイトコードレベルで拡張する方法 このうち、3.を採用すると何でもありだから議論から除外するとして、 個人的には1.には拘らないから2.でうまいことやってくれないかなと 思うんだが。 598 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 23:05:53 ] >>597 1 の場合はともかく、2 や 3 の場合は コンパイラ実装するとか言語仕様追加する、 とかってのは一番楽な部分だからね。 JavaBeans を切り捨てるってのは、技術的というより政治的な問題だから、 ハッカー気質が強い人ほど、自分でコード書いたりする時間がなくなって 政治的な問題に時間を取られる、って予感があるので手を引きたがる。 2 の場合は機能を欲しがる人は居るかもしれんけど、 （2 をやれるだけの政治的立場とか確保してる人の中で） やりたがる人は居ないと俺は思うから、たぶん実現できないと思う。 599 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 23:18:49 ] > JavaBeans を切り捨てるってのは 切り捨てるわけじゃないか…… でもまぁ、標準API とかで setter/getterと新プロパティ共存させるとか 標準API とかの setter/getter を新プロパティで置き換えるとかってなれば 厄介な政治的問題だってのは予想できるでしょ。 言語として 2 のプロパティ持ってても、 標準API は 2 のプロパティをサポートしませんとかなったら間抜けだし。 600 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 23:26:45 ] > でもまぁ、標準API とかで setter/getterと新プロパティ共存させるとか こんな決定したら 袋叩きにあうような気もする。 メンテ面倒くさいし。 enum でも、似たような事やってたけどさ。 enum だと、自前の enum を定義するクラスが比較的少ないから メンテが面倒って不満がそれほど大きくならんかっただけだと思うし。 601 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 23:30:42 ] XMLEncoderがenumに対応してないと気づいたときに、Javaは終わったと思った。 602 名前：デフォルトの名無しさん mailto:sage [2007/03/12(月) 23:34:54 ] これ? bugs.sun.com/bugdatabase/view_bug.do?bug_id=5015403 603 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 08:40:52 ] >>592 >それやったらコンパイルが通らん。 だから具体的に説明してくれって。頭の悪い俺でも分かるように。 >フィールドでプロパティを上書きできるようになるけど、それで良いんか？ これが問題になるのって、フィールドがnon privateのときだけだよね。 フィールドもアクセッサもpublicというのはちょっと考えにくいから、これでも別にいいと思うけど。 >>594 >例えば >> public boolean isDesignTime(){ return designTime; } >は public boolean isDesignTime(){ return isDesignTime(); } >に展開されるから実行時に StackOverflowError 吐いて死ぬ。 これ、展開させたらだめだよ。インスタンス変数に全くアクセスできなくなる。 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。 これなら大丈夫じゃない？ 604 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 09:35:33 ] >>603 > これが問題になるのって、フィールドがnon privateのときだけだよね。 違う。例えば class A{ public int field = 0; } class B extends A{ private int field = 1; } class C { public static void main(String[] args){ 　System.out.println( new B().field ); } } とかだと A の field にアクセスできんでしょ？ つまり、private なフィールドでも public なプロパティを覆い隠せる。 ってか、言語仕様読んでも、なんで Ａ の field にアクセスできないのか 俺には良くわからんのだが…… 覆い隠しって単純名だけに作用するんじゃないんかな？ > これ、展開させたらだめだよ。インスタンス変数に全くアクセスできなくなる。 そうだよ。だから無理だって言ってるじゃん。 > 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。 そんな無茶な。現行の言語仕様では foo.bar と this.bar は区別してないし。 605 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 09:38:13 ] >>603 > 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。 > これなら大丈夫じゃない？ package-private もしくは protected な フィールドと、 public なプロパティで問題起こるから解決になってない。 606 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 10:13:00 ] >>604 > 覆い隠しって単純名だけに作用するんじゃないんかな？ 違うか。覆い隠しじゃなくて、隠蔽されたフィールドは継承されないから、 B のインスタンスからは A の field にはアクセスできないのか。 名前の章ばっかし見てたら理解できんかった。 607 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 10:17:35 ] どっちにしろ、今更プロパティを言語仕様に導入しようなんて考えるのが間違ってる。 608 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 12:25:26 ] 間違い、とまでは思わないけどね。 609 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 13:47:17 ] >>603 > 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。 これだと、他にも穴があるか。 class A implements Compareble<A>{ 　private int field; public long getField(){ return field; } 　public int compareTo(A another){ return this.field - another.field; } } とかがコンパイルエラーになる、と。 610 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 15:00:26 ] > 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく。 (this).bar とかだと どうすんだろ？ 611 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 16:53:37 ] ってか、そーゆールールなら ・フィールドが可視ならフィールドアクセス ・そうでなければ、プロパティがあるならプロパティアクセス とかの方が良いような気もする。 それでも static なプロパティを許したりすると、同名のメンバークラスと衝突するし。 ってか、同名のフィールドが可視なら shorthand syntax for accessing properties を使えないのって、本当に使いやすいかも結構問題のような？ 612 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 19:42:20 ] 何か激しく壊れてない？ ttp://download.java.net/jdk7/binaries/ 613 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 19:42:27 ] >>604 >違う というのは勘違いということでいいのかな？ >そうだよ。だから無理だって言ってるじゃん。 だから『 展開させるのは foo.bar 形式だけ。ただし this.bar はのぞく』といっているんだけど。 >そんな無茶な。現行の言語仕様では foo.bar と this.bar は区別してないし。 なんで無茶なの？区別してないなら区別すればいいじゃん。thisは予約語なんだから簡単じゃん。 614 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 19:48:30 ] >>613 ＞なんで無茶なの？区別してないなら区別すればいいじゃん。thisは予約語なんだから簡単じゃん。 汚い設計。 わかりにくいです。 あとマルチスレッド周りで問題がでそうだな。 615 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 20:05:41 ] >>613 > というのは勘違いということでいいのかな？ いや、覆い隠しは勘違いだったけど、 private フィールドで public なプロパティを隠蔽できるから問題になるのは変わらない。 > 区別してないなら区別すればいいじゃん。 区別しても、 >>605、>>609、>>610 みたいな穴があるから、やるだけ無駄。 616 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 20:44:57 ] >>611 どっちかっつーと dot でプロパティアクセス許す場合、 フィールドと同名のプロパティを作れるってのが混乱の元だとか認識されてんのかも？ 617 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 20:51:03 ] > あとマルチスレッド周りで問題がでそうだな。 問題でるかな？ 618 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 20:53:23 ] >>613 > なんで無茶なの？ 根本に近い方のルールを書き直すってのは、 既存のコンパイラを改変する時に多くの労力がかかりそうだってのは分かるでしょ？ だから無茶なの。 619 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 21:20:36 ] >>571 > ${classInstance.propertyName} みたいに ${} で括った部分では > 式言語使えるようにすりゃええやん、ってのも出てるけど…… ksl の 課題追跡にあった https://ksl.dev.java.net/issues/show_bug.cgi?id=2 に似てるっちゃ似てるかも。 でも、ecmascript みたいに Java と同じく } でブロック終了する言語だと 対応とるの大変そうだなとか思った。その辺は EL だと楽だけど。 620 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 21:34:43 ] ヒアドキュメント＋式言語ってのが良さそう Velocityが標準になるみたいな感じだが。 621 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 22:29:53 ] >>616 要は、今の仕様で private int xxx; というフィールドと public int getXxx() というメソッドが混在できる以上、フィールドの延長上のプロパティと getter/setterの延長上のプロパティとは相容れないわけだ。 いまのキモいJavaBeansのgetter/setterはプロパティとはなんの 関係もないことにすりゃ、それで解決すると思うんだけどね。 622 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 22:49:49 ] >>621 > いまのキモいJavaBeansのgetter/setterはプロパティとはなんの > 関係もないことにすりゃ、それで解決すると思うんだけどね。 仮に、それをやっても「解決する」のは言語仕様の問題だけで、 ライブラリ＆フレームワーク＆ユーザーコードの方に問題を押し付けてるのような。 それなら、ぶっちゃけ新しい言語作っちゃった方が速いと思う。 623 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 23:18:12 ] >>622 上の方でだれか言ってたけど、フレームワークのプロパティとは無関係な「Java言語プロパティ」 を作ってもいいんじゃないか。紛らわしいなら名前は変えてもいいけど。 そもそもなんでプロパティ構文が欲しいんだ。ドットネットが羨ましいんだろうか。 624 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 23:24:53 ] >>622 「問題」って、どんな問題かな？ 別に既存コードの変更が迫られるわけじゃないっしょ？ 625 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 00:09:08 ] >>623 むしろstructが羨ましいんじゃないか？ 626 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 02:48:40 ] >>624 互換性を確保しつつ新プロパティを使おうと思ったら、 既存のプロパティと、新プロパティの両方管理しなきゃいけなくなる。 二重のコストを払う必要が出るんだから、普通は問題になる。 おまけに、フレームワークやライブラリが二重のコストに耐えかねて 既存のプロパティを捨てたら、やっぱり既存のコードを書き換える必要が出る。 直接コードの変更を迫ってないだけで、間接的にコードの変更を迫ってる。 627 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 07:18:35 ] >>626 プロパティが導入されたからといって、既存のコードを無理に 対応させることはないでしょ？別物なんだから。 それに例えば、ジェネリクスが導入されたとき、それに対応して 書き換えられたフレームワークはあったし、もちろんそれを利用 しているユーザーコードも書き換えられることがあったけど、 それは別に変更を余儀なくされて行ったわけじゃないよね？ 628 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 07:52:01 ] >>627 > それに例えば、ジェネリクスが導入されたとき、それに対応して Generics の場合は「JavaBeans とは無関係なプロパティ」導入と違って、 例えば Collection フレームワークを Generics対応に書き換えたら、 互換性が完全に無くなるってわけではなかったけど、 「JavaBeans とは無関係なプロパティ」の場合は、 「JavaBeansのプロパティ」のサポートをうちきれば互換性が無くなるし。 例えるなら enum の方が近いな。int enum と typesafe enum の両方を提供してるAPIがあって。 それにはコストがかかる。int enum だけ、typesafe enum だけを提供してるAPIもあるけど、 プロパティの場合は影響範囲も、統一的に扱う必要性も enum の時より大きいから 両方の提供がより大規模に起こるのは容易に想像できる。 「JavaBeansのプロパティ」と「JavaBeans とは無関係なプロパティ」は共存可能って話なんだろう？ 互換性維持のためには「JavaBeansのプロパティ」が必要で、 新機能対応のためには「JavaBeans とは無関係なプロパティ」が必要で、 それを両方管理しようとすりゃコストはかかる。問題になるだろ、普通は。 629 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 08:10:26 ] 定義はgetter/setterで行って、呼び出すときだけプロパティみたいにも使えるようにするのじゃダメ？ 例えば、p=a.getXxx()をp=a.xxx、a.setXxx(p)を a.xxx=pとか。 630 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 08:37:50 ] >>629 それだと dot でやるのが面倒。 既存の getter/setter に使われてる「プロパティの名前」と 同名のフィールドが存在可能だから。 631 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 08:39:25 ] >>628 そのコストってのもフレームワークの作者とかはともかく開発者は関係ないね 632 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 08:44:16 ] >>631 何より、無駄にバグのリスクが増えるし、 標準APIとかでドキュメントの翻訳に時間がかかるようになるとも考えられるね。 633 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 08:45:07 ] >>631 開発者というより、末端ユーザだな 634 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 09:10:34 ] >>629 a.xxx と同名のフィールド a.xxx があった場合、扱いが面倒。 互換性を考えるなら >>611 あたりのルールが落としどころかとも思うけど、 public な同名のフィールド使えば、プロパティに触れなくする事ができたりするし、 完璧とはいいがたい。 言語仕様に書く文言も相当慎重に選ばないと、 デフォルトパッケージのクラスが import 出来なくなったみたいに、 言語仕様の文言から副作用がでる可能性も…… もっとも、import の方は意図しない副作用なのか意図的なものか、 ちゃんと知らんのだけど。 635 名前：デフォルトの名無しさん [2007/03/14(水) 12:24:27 ] マルチコア対応は言語に乗っかるのか、VMに乗っかるのか・・・ 636 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 12:37:32 ] >>627 Genericsは、既存の一般コードに関しては意味の変更なく使えたぞ >>632 さすがにそのコストを考えるのは臆病すぎｗｗｗ >>635 マルチコア対応って一体何なのか分からない。 なぁ、何でみんなdotにこだわるの？ 別の記号にして、定義も全く別にすればスッキリ導入なんだけど？ バイトコードは拡張しないと駄目だろうけど。 637 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 12:48:08 ] >>636 > 別の記号にして、 dot 以外の記号はキモイから嫌らしい。 > 定義も全く別にすれば 既存の資産と協調して使えないので、導入しても嬉しさ半減。 > バイトコードは拡張しないと駄目だろうけど。 バイトコード拡張は必要ないでしょ。 クラスファイル仕様は弄るかもしらんけど。 638 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 12:50:02 ] >>635 マルチCPU対応のVMだったら、マルチコアも そのまま使えるんじゃない？ ってか、マルチコア対応を言語にのっけるってどーやるんだ…… 639 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 13:13:07 ] そういやRhinoのLiveConnectは実装側で拡張されててJavaObjectのゲッタ(getXxx)・セッタ(setXxx)にJavaScriptObjectのプロパティ(xxx)からアクセス出来たな。 JavaBeans使ってたんだろうか？ 結局JavaScriptObjectのプロパティからアクセスしようとした時JavaObject側にxxxってフィールドがあると衝突して使い物にならないから LiveConnectには元々ない後付けされた機能なんて不完全だって言われてたな・・・。 オライリーのサイ本にも指摘されてたような。 640 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 13:39:56 ] >>626 阿呆だな。もっと簡単な問題があるよ。 >>624 JavaBenas のプロパティと別のプロパティなわけでしょ？ 標準API とかの既存の interface に abstract な property を追加したら 既存のコードの中で、そのinterface を実装してて JavaBeans とは別のプロパティを 実装してないクラスがあれば、互換性に問題が出る。 互換性に配慮したら interface に迂闊にプロパティ追加できない。 それだと、たぶん使い物にならない。 641 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 13:48:02 ] >>627 具体的に言えば java.beans.DesignMode にプロパティ追加して interface DesignMode { 　public static final String PROPERTYNAME = "designTime"; 　boolean isDesignTime(); void setDesignTime(boolean f); 　public abstract property designTime; } とかすると、既存の class MyComponent implements java.beans.DesignMode { 　private boolean designTime; 　public boolean isDesignTime(){ return designTime; } 　public void setDesignTime(boolean f){ designTime = f; } } みたいなコードを書き直す必要がある。 DesignTime とかだけならともかく、他の interface も property の追加に関しては慎重にならざるをえない。 よって interface で property にアクセスできない事が多くなる。 JavaBeans のプロパティと別の新プロパティを導入しても、 あんまし使い勝手がよくないだろうね。 642 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 14:10:45 ] なるほどいろいろ問題があるな。 結局 ->案が一番妥当だろう。 プロパティを定義する側はこれまでどおりgetXXX/setXXXを使用する。 プロパティを使用する側はgetXXX/setXXXと->XXXの両方が使える。 フィールドにXXXがあっても問題なし。 しかし、この程度のものならいらないな。 643 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 15:29:22 ] >>642 だよな。 いらないと思うよな。 644 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 15:41:27 ] あとはgetとsetを対にした定義文もほしいな 645 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 15:47:49 ] >>641 今Beansで「プロパティ」と呼んでいるものと別物として新プロパティシステムを導入するのだったらその書き換えはいらないよね？ 646 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 16:03:21 ] >>645 だから、>>641 は > 今Beansで「プロパティ」と呼んでいるものと別物として新プロパティシステムを導入 した場合に発生する問題だってば。 今Beansで「プロパティ」と呼んでいるもの、 要するに setter/getter呼び出す syntax sugar として accessing properties な構文を入れるなら、>>641 の問題は発生しない。 647 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 16:36:28 ] >>646 なんで書き換えようとするの？そのままにしとけばいいじゃん。 648 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 16:56:32 ] >>647 >>641 をちゃんと読め。 649 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 17:45:12 ] >>648 ちゃんと読んでもわからないです。 何故 interface DesignMode に property designTime を追加してるの？ ひょっとして俺ｽｹﾞｰアホなこと訊いてる？ 650 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 18:38:36 ] > ひょっとして俺ｽｹﾞｰアホなこと訊いてる？ うん。 651 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 22:27:50 ] >>641 あきれる。 isXXX()/getXXX()をgetterのインターフェースに用いたままプロパティを 実現しようとすることに問題があるから別のインターフェースを採用 しようという話なんだから、その例でinterfaceの方にisDesignTime()を 追加するという仮定自体がそもそもありえないし、仮に追加しても 何の影響もない。 652 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 22:35:24 ] dot以外の記号がキモイならdot二つのx..hogeでもいいよ。 653 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 23:25:14 ] >>652 孔明あらわる 654 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 23:56:34 ] >>651 俺もそんな気がしたんだけど、>>650 だそうです。 655 名前：デフォルトの名無しさん [2007/03/14(水) 23:57:20 ] 記号でわざわざ入力二回って耐えられなくない？ 656 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 00:00:24 ] 耐えられないなら++も--も使わずにプログラムを書いてくれ。 657 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 00:45:46 ] // << >> == && || ↑これらも つか==なしとか縛りきつくね？ 658 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 00:47:52 ] VBのプロパティとかdotだし、コード上で分かりにくいってことはなかった。 FlashのActionScript(ECMAScript派生)もread onlyプロパティがあったが、dotだね。 dot以外を選択するのは、正直コンパイラ屋の都合でしかないと感じる。 メンバ変数に@PropertyFieldアノテーションを施す程度で妥協して欲しい。 659 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 01:30:43 ] ちょっと待てECMAScriptは全部プロパティだ 660 名前：デフォルトの名無しさん [2007/03/15(木) 01:32:16 ] >>656-657 2chらしい模範解答だなｗ 661 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 01:52:21 ] IDEやJava用エディタならテンプレート機能が充実しているし そんな構文糖は要らないってのも意見として尊重してほすぃ。 662 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 02:15:35 ] >>661 どうなんだろ、セマンティクスがハッキリするから getter,setterが分かりやすくなるという点ではIDEも歓迎なのでは？ 実現方法はともかく。 663 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 04:06:26 ] >>661 コードの読みやすさが上がるのであれば、新しい構文糖の導入も大いに結構じゃないかい？ 664 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 07:43:28 ] >>651 あきれる。 > 仮に追加しても何の影響もない。 そんなは事ない。 665 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 07:47:20 ] >>651 >仮に追加しても何の影響もない。 追加したら、java.beans.DesignTime を実装している既存のクラスを書き換えなきゃいけなくなるだろう。 影響がないって、馬鹿じゃないのか？ 666 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 07:48:08 ] >>665 × java.beans.DesignTime ○ java.beans.DesignMode 667 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 08:18:45 ] >>661 java.net/pub/pq/142 とか見ると、 property構文は、XML構文に次いで人気がないんだよね。 java.net/pub/pq/141 とかだと、 very important と、somewhat important をあわせても 1/4 ぐらいだったりする。 まぁ、この手の投票がちゃんと機能してるかはわからんし、 構文糖なら要らないってのと、重要度が低いってのは同じ意見じゃないんだけど。 668 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 08:34:05 ] >>658 > VBのプロパティとかdotだし、コード上で分かりにくいってことはなかった。 もし問題がないなら dot を使うのに反対の人はあんまし居ないと思うんだが。 同じクラスでフィールドと同名のプロパティが持てる言語を出してきて わかりにくくないって言うんならともかく。 > メンバ変数に@PropertyFieldアノテーションを施す程度で妥協して欲しい。 それって、何か改善する？ 669 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 09:09:07 ] >>668 > 同じクラスでフィールドと同名のプロパティが持てる言語を出してきて > わかりにくくないって言うんならともかく。 それなら、同名のフィールドとプロパティが共存できて、 さらにフィールドもプロパティも dot でアクセスする言語がわかりにくくないって言わないと。 （dotじゃなくても良いけど同じ記号でアクセスする言語） 670 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 09:17:17 ] >>651 > その例でinterfaceの方にisDesignTime()を > 追加するという仮定自体がそもそもありえないし ……。 isDesignTime() は元からあるメソッドですが。 671 名前：649 mailto:sage [2007/03/15(木) 10:23:39 ] >>670 おまえ逃げてないで俺の質問に答えろよ。 672 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 10:26:26 ] >>671 質問になってない。 673 名前：649 mailto:sage [2007/03/15(木) 10:31:39 ] >>672 答えになってない。 674 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 10:36:21 ] >>621 それだけじゃ解決しないね。 新プロパティ(dotでアクセス)と同名のフィールドが作れるなら setter/getterのプロパティと同じ問題が起こるし、 C#みたく新プロパティと同名のフィールドが作れなくするなら、 標準APIが新プロパティを追加したらユーザコードの書き換えが必要になる可能性がある。 これ以降は >>640 >>641 と同じ路線だな。 上記の書き換えを最小限に抑えようとすれば、 標準APIは極力 新プロパティを追加しない方向になるだろうから、 新プロパティの構文は言語仕様に定義されたが、 標準APIで 新プロパティが使えない、という本末転倒な事態が予測される。 つまり、使い勝手が悪い。 675 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 10:39:07 ] >標準APIが新プロパティを追加したらユーザコードの書き換えが必要になる可能性がある。 標準APIが新プロパティを追加したら、 そのclass/interfaceを継承/実装して同名のフィールドを使っていたユーザコードの書き換えが必要になる。 676 名前：649 mailto:sage [2007/03/15(木) 10:42:44 ] やっとわかったよ。お互い説明が下手だと苦労するなｗ 677 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 11:02:59 ] >>675 まぁ、interface に「新プロパティ」を追加したら、 どっちみち そのinterface を実装しているクラスの書き換えが必要になる。 既存のコードは setter/getter は実装してても、 「新プロパティ」まで実装してて書き換えの必要がないってのは考えにくいから。 この書き換えを最小限に抑えようとすれば、 標準API は、極力 abstract な新プロパティを追加しない方向になるだろうから 以下、>>674 と同文、と。 678 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 11:15:13 ] > 標準API は、極力 abstract な新プロパティを追加しない方向になるだろうから 標準API は、既存の setter/getter を置き換えるものも含めて、 極力 abstract な新プロパティを追加しない方向になるだろうから うーむ。既存の setter/getter は互換性のために残す事を想定してるから 置き換える、じゃないんな。まぁ、setter/getter を残しても残さなくても、 標準API に abstract な新プロパティを追加すれば同じだけど。 679 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 20:13:04 ] ゲーム関係に力を入れてけば自然とデスクトップ周りが強化されるからそっち系だな OSを選ばないUDIライブラリとか、BGM周りはネイティブにディスパッチとかね。 標準であるかどうかってのがここらへんは大きい。 680 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 22:34:05 ] まずジョイパットか 681 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 23:05:33 ] ジョイパッドサポートは地味に大きいな って10年前からいわれてるが あとはJOGLも標準ではいってくれるといいのだが 今はプラットフォームごとに用意してあげないといかんからWindows以外はめんどくさい 本当は新世代専用GCコールもほしい タイミングコントロールできて殿堂入りしないやつならアクション系もバリバリ使える 682 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 00:05:01 ] >>677 interfaceに追加したらそれを実装するクラスに影響があるのは、 「プロパティ」に限らず抽象メソッドでも同じだわな。 既存のinterfaceに「抽象メソッド」を追加したら他のクラスに影響が出る ↓ だから標準APIに「抽象メソッド」は追加できない ↓ 「抽象メソッド」は標準APIに使えないから無意味 あほか。 683 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 00:22:54 ] >>682 > 既存のinterfaceに「抽象メソッド」を追加したら他のクラスに影響が出る 普通は、既存の interface に抽象メソッド追加するのは慎重にする。 逆に、 今までにない interface を作る時は自由に抽象メソッドを定義できる。 > 「抽象メソッド」は標準APIに使えないから無意味 安易に追加できないが、「使えない」とか「無意味」とはならない。 abstract な新プロパティも、抽象メソッドと同じで、 今までにない interface を作る場合は自由に定義できるだろうけど、 既存の interface に追加する場合は慎重にならざるを得ないだろう。 既存の interface 経由で使えない事が予想される新プロパティは 「使えない」とか「使い勝手が悪い」と言える。 684 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 00:26:00 ] >>683 △既存の interface -> ○標準APIの既存の interface 685 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 01:10:18 ] java.sql.Connectionなんか増えまくりだった気がするが。 古い実装のを呼ぼうとするとErrorでも出るかな 686 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 01:11:37 ] >>683 既存のinterfaceを安易に拡張できないってのは当然だね。 >既存の interface 経由で使えない事が予想される新プロパティは なんで新プロパティに限って既存のinterface経由で使われることを 期待されなければならないんだろう？ 687 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 01:16:08 ] >>682 > だから標準APIに「抽象メソッド」は追加できない > ↓ > 「抽象メソッド」は標準APIに使えないから無意味 ここで飛躍してる。基本的には「追加できない」==「使えない」とはならない。 で、setter/getter とは無関係な新プロパティシステムを導入したとして、 その新プロパティを、標準APIの既存の interface で使いたいと言う場合は ・新プロパティを追加すれば、その interface を実装していたコードを変更する必要が出る。 ・逆に新プロパティを追加しなければ、標準APIの既存の interface では新プロパティは使えない で、俺は標準APIの管理者は後者を選択すると予想するので、 その場合は新プロパティは「標準APIの既存の interface経由では使えない」ので 使えないとか、使い勝手が悪いと言えるだろう。 仮に前者を選んだとしても、コードの変更を迫られるので無問題とはならない。 688 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 01:23:35 ] >>686 > なんで新プロパティに限って既存のinterface経由で使われることを > 期待されなければならないんだろう？ 限って？ 他では期待されてないんだっけか？ 689 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 01:27:18 ] >>688 限ってないよな。Closure だって、Closure Conversion とかで abstract なメソッドが一つだけの既存の interface に変換する事を考えてたりするし。 690 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 01:48:55 ] blogs.sun.com/ahe/entry/java_se_7_wish_list のリストとかを見るに、 たいてい inteface と関係ないか、既存の interface との協調にも配慮してあるよーな。 691 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 05:18:23 ] >>681 新世代・・・・ああああNewGeneration用のGCってことか。 いや、殿堂入りが無いというより、tenureの32をいじれるようになった方がいいかな。 ある程度、コア数が増えて並行処理が速くなると、OldGenerationを少なくして Newgenerationのtenureを32回より多くして、NewGenerationで運用したほうが 効率いいと思うんよねぇ。 昔、24CPUのマシン使った時、10GB程度のNewGenerationをParNewGCかけてたけど 確か0.5s程、ホンの一瞬だった。 692 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 07:42:00 ] >>688 class定義に影響する新機能としては例えばfunction-typeなんかがあるけど、 じゃあこれは既存のinterfaceに追加されて使われることを期待されてるの？ 693 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 08:53:05 ] >>688 対抗馬である setter/getter の syntax sugar なプロパティなら 既存の interface経由で使えるしな。 それと比較しても 「使い勝手が悪い」といえるだろうね。 694 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 08:53:44 ] >>692 具体的に、どんな問題が出るんだ？ 695 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 12:35:00 ] >>691 並列GCはデフォの状態よりスループットはいいけどレスポンスが大幅に悪化するぞ あとGC稼動のタイミングをコントロールできる10msのGCとコントロールできない0.1msのGCだと前者のほうがいいわけで 696 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 13:50:53 ] >>695 今のマシンスペックならGCに0.1msもかからんよ。 ゲームならヒープサイズとスタックサイズの調整で2Dまでならストレスなく遊べる。 やっぱメモリ食いは収まらないけど。 取り合えずただのデスクトップツールとしては実用的じゃない？ ジョイパッド拾えるようになると同じ方向性で障害者用の入力補助装置の入力拾えそうでアクセシビリティ周りが格段に良くなって良いと思うけどな。 697 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 14:15:04 ] >>686 GCの時間はヒープサイズに綺麗に比例するのでなんともいえないよ 最近のマシン持っているけど0.5msきることは実際にゲームつくっていてまずない 新世代領域を少なくしてやっと0.2mくらいか インクリメンタルGC（現在の実装は並列GC）だとレスポンス悪化してるし、 デフォのGCだとFullGCがいつかは必ず起きるし、おきたら使い物にならない そもそもJava2DやJOGLなどライブラリによるGCはコントロールできなから 自分のコードでの調整は何も意味がない 0.1mが0.05mであっても同じこと リアルタイム性ってのは早いかどうかじゃなく、コントロールできること、把握できることだから 698 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 15:41:40 ] >>571 まるでApache Antの記法だな 699 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 15:42:31 ] >>572 四項演算子か。 Checkstyleプラグインが警告しそうだな 700 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 19:54:46 ] >>693 既存のinterfaceに public int getHoge(); なんて追加したら おんなじように「問題」は発生するが？ >>694 何の問題も出ないだろう。既存のinterfaceに追加したりしなけりゃ。 701 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 20:14:48 ] >>700 setter/getter の syntax sugar なプロパティであれば、 既存の interface で、既に宣言されている setter/getter で プロパティにアクセスする分には問題は発生しない。 setter/getter と関係のない新プロパティシステムを導入した場合、 既存の interface で、既に宣言されている setter/getter ではプロパティにアクセスできない。 で、標準API みたいに変更すると影響範囲が大きい既存の interface は安易に変更できないから 新プロパティを追加したくても既存の interface には追加できず、 既存の interface からは、この新プロパティは使用できない可能性が高い。 故に setter/getter の syntax sugar よりも 「使い勝手が悪い」といえる。 702 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 21:11:41 ] 相変わらず説明が下手だな。 703 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 21:19:01 ] さすがに読解力に問題があるだろう。 704 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 22:07:53 ] >>701 >既存の interface で、既に宣言されている setter/getter ではプロパティにアクセスできない。 既存の「getter/setter」と関係ないプロパティが前提なら、当然既存のinterfaceにも 存在しているわけがないだろう。ここでアクセスしようとしている「プロパティ」ってのは 何のことを言っているんだ？ もし「getter/setter」のことならば、それはプロパティとは関係のない単なるメソッドだから、 普通にメソッドとしてアクセスすればよい。 もし新たにプロパティを追加することを想定しているのならば、それはインターフェースの 拡張に他ならないから、他に影響が出るのは当然。それは別にプロパティに限らない。 705 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 22:18:48 ] >>704 > ここでアクセスしようとしている「プロパティ」ってのは 当然、setter/getter と関係ない新プロパティシステムのプロパティ。 で、プロパティの持つものは、既存の setter/getter で表わされるのと同じもの。 プロパティ導入の大きな動機の一つに、setter/getter を宣言するのも、 呼び出すのも冗長だという不満を解消するというものがある。 setter/gettter とは別の新プロパティシステムを使えば、 既存の interface にある、既存の JavaBeans のプロパティに対して、 setter/getter を呼び出すのが冗長だという不満を解消できない。 仮に Tiger で追加された Generics が、もし仮に既存の Collection API と協調できず、 List でも Map でもパラメタ型を取れなければ、使い勝手が悪いと評価されるだろう。 それと同じ。 706 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 23:00:03 ] あはははは。 foo.getBar()がfoo->barになっただけでどんな不満が解消するんだよ。 707 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 23:07:26 ] 流れぶったぎるがJSR-296使ってみた奴居る？ 708 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 23:08:42 ] >>706 なら、なんでプロパティが必要なんだ？ それに、最初出てきた案は setter/getter の syntax sugar なんだぜ？ 709 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 23:18:32 ] >>703 わかってもらえない場合は、別の角度からの説明を試みるべきだと思う。 >>706 だよな。いらねーよな、こんなプロパティもどき。初心者が混乱するだけ。 710 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 23:22:40 ] >>709 普通は説明されなくてもわかるだろ。あんなの。 気づかない方が頭がおかしいんだよ。 711 名前：デフォルトの名無しさん mailto:sage [2007/03/16(金) 23:35:01 ] >>710 「普通」とか言うけど、「使い勝手が悪い」っていう結論は主観が入り込んでるだろ？ 712 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 00:10:42 ] ->で全然問題なし 713 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 00:25:29 ] JavaBeans のプロパティと同名のフィールドを持てる事が問題ってところから >>621 で > いまのキモいJavaBeansのgetter/setterはプロパティとはなんの > 関係もないことにすりゃ、それで解決する という意見が出た。 新プロパティシステムを作れば、フィールドと同名のプロパティを禁止できるからって話なんだろうけど、 >>674 のような問題も予想されるため、完全な解決とはならない。 結局、限定名のルールとかフィールドアクセスのルールが ぎちぎちに詰め込まれているので dot でフィールドにアクセスする事と、 dot でプロパティにアクセスする事が相容れないと考えた方が良いみたい。 それとは別に、>>640、>>641 で言ったように setter/getter とは別の新プロパティシステムを導入する場合、 setter/getter の syntax sugar ならプロパティとしてアクセスできた情報の一部に プロパティシステムを使ってアクセスできない事が予想される。 結局、「setter/getter とは別の新プロパティシステム」を導入しても setter/getter のsyntax sugar で問題とされた事を解決できず、 さらに setter/getter の syntax sugar では出なかった問題も発生する。 まぁ、「setter/getter とは別の新プロパティシステム」の詳細を見ての評価じゃないけど 現在の情報からなら setter/getter の syntax sugar より「使い勝手が悪い」と言える。 714 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 00:28:20 ] >>713 どうでもいーけど長文ウザイ 715 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 10:20:14 ] 説明が下手なんだからしょうがないよ。 716 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 10:22:41 ] 説明されなくたって、既存のプログラムに新機能を追加して、 どんな影響が出るかを予見できないってのは技術者として拙いだろ。 717 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 10:30:57 ] じゃあレスする必要ないじゃんｗ なんで一生懸命説明してんの？ 718 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 10:33:03 ] >>716-717 次世代Javaと関係ない話題だな。 続きは他所行ってやれ。 719 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 12:59:19 ] >>718 たった2レス程度で…気が短いな 720 名前：デフォルトの名無しさん mailto:sage [2007/03/17(土) 16:16:28 ] >>713 結局、getHoge()/setHoge()を使わない新プロパティシステムを導入しても、 既存のgetHoge()/setHoge()を使えないから使い勝手が悪いということかw 721 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 00:14:19 ] ふー、びっくりした。でも、反対派の意見はほぼ一点に集中している。 プロパティは既存の言語機能と干渉するから、導入の必要はないというもの。 それ、ほんとなのかなあ（ｒｙ 722 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 00:44:26 ] サイレントマジョリティの声を尊重してプロパティを導入することにしました。 当然のことだよね 723 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 00:51:13 ] >>721 既存の言語機能と干渉とかいう以前に、そもそも「そんなに必要な物なのか」って ことがまずあるんじゃないか？ プロパティの仕組み導入の話が出てるのは、 「定義するのも使うのも既存のgetter/setterの仕組みだとめんどくさい」 という要望から来てるんだろうけど、 「めんどくさい」っていう理由だけで言語仕様変えてったらとんでもないことになる気がする。 相当面倒、ってのが、すごく簡単ってなるならまだ納得できなくもないけど、 IDE使ってる人の中にはgetter/setterがそこまで面倒とは思わない人もいるんじゃないかとも思う ちなみに個人的にはgetter/setterの使用側は今のままで十分。 ただ、定義するのが面倒だから、アノテーションとかで自動でデフォルトのgetter/setterが 作成される仕組みができるぐらいでも満足だよ。 724 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 02:14:53 ] a = obj get foo; obj set foo = 1; 725 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 08:54:34 ] >>722 >>667 の結果を見るに、 プロパティ要らないって意見の方が サイレントマジョリティで、 プロパティ欲しいと言ってる方が、声の大きい少数派。 726 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 11:47:22 ] >>721-722はネタなんで相手しなくていいです 727 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 12:23:09 ] >>724 はネタじゃないのか…… 728 名前：724 mailto:sage [2007/03/19(月) 20:34:17 ] >>727 ネタです。 729 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 23:15:19 ] >>723 うむ。 プロパティ自体は特にそんなに欲しいものでもないが、自分で開発していて コードの半分以上が意味のないgetter/setterで占められているクラスが 山のようにあるのを見ると、何かが間違ってる気がしてならない.。 730 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 23:21:52 ] あるBeanのプロパティ値ともうひとつのプロパティ値を足し算してその結果を格納とかめんどくさすぎ 同様にBigDecimalの演算もきっつい 731 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 00:51:51 ] >>730 プロパティに足し算して格納とかってそんなに使う？ 俺、WEB開発系がメインだけど、プロパティに対して加算とかって ほとんどしたことないし、BigDecimalも使ったことない。 きっとプロパティが必要な分野と、たいして必要とされない分野があるんだろうな。 732 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 01:17:10 ] getHoge()がめんどくさいから->でやらせろって言ってる人は、 やっぱりadd()がめんどくさいから演算子オーバーロード使わせろ とか言うのかな。 733 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 02:00:33 ] BigDecimalは業務系はこれしか使わないというくらい使う BigDecimalだけはStringのようにシンタックスシュガーとしてaddとかやってほしいな プロパティの足し算引き算ってのは普通にあるっしょ 金額とか在庫とかいくらでも 特にO/RマッパやBeanBinding関係使うと頻発 734 名前：しろうと mailto:sage [2007/03/20(火) 09:36:43 ] public class Foo { 　　public int bar; } じゃだめなん？ 735 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 10:15:22 ] セット時やゲット時に加工が出来ないからダメ それに定義のほうはどうにでもなるためたぶん問題になってない 736 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 22:24:23 ] VMがグリッドコンピュータに対応するのはいつだ？ 737 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 22:34:18 ] VMがグリッドコンピュータのネイティブな基盤になればいいのに。 738 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 22:38:44 ] 設定がないと動かないJVMは面倒だな。 グリッドとかは、アプリケーションの下で何らかのグリッド制御部が 動いていて、JVMのリソースとしてグリッドが見えるって前提だろうから MVMが実現して、アプリケーションの起動とJVMの起動が分離するまでは あんまり興味がないね。 739 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 23:23:42 ] クラスタ用OSとしてのJVMなら BEAだかが仮想化技術として構想を発表してたはず 740 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 23:27:12 ] >>738 グリッドが見えるのを前提にする必要はないでしょう。 HotSpotが全自動で動的最適化を行うように グリッド制御部が全自動でスレッド分散を行うのが あるべき姿だと思います。 741 名前：デフォルトの名無しさん mailto:sage [2007/03/24(土) 22:20:18 ] JDK7 build10 download.java.net/jdk7/changes/jdk7-b10.html download.java.net/jdk7/binaries/ NewFeatureは地味なパフォーマンス向上と getAsText,setAsTextか。これはちょっと嬉しいな。 742 名前：デフォルトの名無しさん mailto:sage [2007/03/25(日) 05:37:51 ] グリッドより先にjavacがメニーコアをフルに使用するための中間コード を生成することになることが重要。 PGがthreadを手書きしてでしか対応できないというのではコストがかかりすぎる。 743 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 13:15:00 ] プロパティの話に戻りますが、 やっぱ、何か明示的にプロパティを示す構文がほしい。 と思ったのは、eclipseでリファクタリングするとき。 getter側をリネームしたら、setter側も変わってほしいし、名前の定数も変わってほしい。 public static final string PROPNAME_XXX = "XXX"; public Object getXXX() { ... } public void setXXX() { ... } の三者の一貫性を、自動的に保ちたい。 なんか、アノテーションつけとくと、eclipseが、それをヒントに一括リネームしてくれる だけでもいいんだけど。 744 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 14:16:16 ] それはプロパティ構文あってもなくてもあんまり変わらないのでは。 745 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 14:25:33 ] >>743 getter/setter はまだしも、 > public static final string PROPNAME_XXX = "XXX"; の必要性が良く分からん。 746 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 14:42:25 ] 俺もその部分が？だな 名前だけで型がないし、そもそも型が要らないならenumでいいし まさか、文字列の中身がクラス名とか 747 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 15:40:52 ] >>745 >>746 プロパティ名を変えるときに、プロパティ名の文字列リテラルがソース中に散らばってると、 修正がめんどくさいから。 IDEの完全一致文字列リテラルの置換でできなくはないけど、"item"、"count"なんてプロパティ名 だと、無関係な文字列に誤爆するかもしれん。 748 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 17:01:43 ] >>747 ＞修正がめんどくさいから。 得てしてこういう理由で出てくるワークアラウンドは 引きずらない方がいい悪習慣である可能性が高い 749 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 18:19:33 ] >>748 いや、一つの識別子をソース中に書くのは1回で、あとは参照に置き換えるってのは、 コードのメンテナンス性を保つ上で、ものすごく基本的なことだと思うが。 getXXX, setXXXというメソッド名は、XXXというプロパティ名に従属する識別子なんだから、 ソース中の1箇所の変更で、全てが整合性を保った状態で変更されるのが理想。 C#では、それを文法で強制している。javaでは、整合性の保持はプログラマ任せ。 プロパティ名変更する度に、getXXX、setXXX、firePropertyChangeの引数、全て変更って、 バカバカし過ぎる。せめて、IDEに面倒みてもらいたい。 YYYListener、addYYYListener、removeYYYListenerも、相互に関連する名前なんだから、 ソース1箇所の変更で全てが修正される方が望ましい。 これも、C#ではeventで実現できるが、javaはプログラマ任せ。 javaは保たれるべき一貫性の保持を、文法で強制するんじゃなくて、守るべき ルールとして与えてるだけなんで、そのルールが守られることのチェックを、アノテーションでできてほしい。 addYYYListenerにしても、 @AddListenerMethodFor(YYYListener.class) void addYYYListener(YYYListener listener) {} みたいにして、名前の整合性がなかったら、コンパイラで検出できるようにすべきだと思う。 IDEではYYYListenerをリファクタリングでリネームしたら、addもremoveもリネームできて、ほしい。 javaは、識別子の命名ルール関係で、コンパイラでは検出できないけど、 守られていないと正しく動作しない決め事が結構ある。 そのあたり、アノテーションでバンバン検出できるようになると良いんだけど。 750 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 19:16:31 ] C#は詳しくないが、プロパティ名を変更したとき、 そのプロパティを実際に使用している箇所の変更は不要なの？ 751 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 19:26:01 ] private int myVar; public int MyProperty { get { return myVar; } set { myVar = value; } } 752 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 21:00:03 ] >>749 > getXXX, setXXXというメソッド名は、XXXというプロパティ名に従属する識別子なんだから、 これも別の概念なんだよね。BeanInfo や PropertyDescriptor を自分で書いてる人は hoge って名前のプロパティで、void hoge(Object) を setter に、Object hoge() を getter に指定する事も出来るし。 もっとも、真面目に BeanInfo 見てないフレームワークだとプロパティと認識してくれないかもしれんけど。 > バカバカし過ぎる。せめて、IDEに面倒みてもらいたい。 ここは同意なんだけど、IDEで吸収するのか、言語/コンパイラで吸収するのかってのもあるし。 とりあえず、現状だと言語/コンパイラのレベルで BeanInfo 扱うのは面倒っぽい。 例えば、今コンパイルしようとしてる Hoge.java の BeanInfo を扱うのが面倒。 PropertyDescriptor の getWriteMethod とか getReadMethod とかで、 まだコンパイルされてない Hoge.class の java.lang.reflect.Method 取るっても取れないだろうし。 これがないと、プロパティ名を getter/setter に変換できないし。 753 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 23:03:02 ] >>747 それはわかるが>>743のコードはカス >>751のようにすべきかと 754 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 23:15:07 ] >>743 PROPNAME_XXX って firePropertyChange 関連以外で使う？ 755 名前：デフォルトの名無しさん mailto:sage [2007/03/26(月) 23:48:38 ] >>751 C#構文をそのまま持ち込んだらこうなるな。 欲を言えば、myVarとMyPropertyの関係(というか変数実体についての記述)を 何らかの形で示すことができて、省略時はデフォルトsetter/getterが呼ばれる ようにできたらとC#より便利になると思うんだけどね。 つまり、アクセスをフックしたり禁止したりする場合だけ明示的に記述する。 ＃C#の場合はgetter/setterを省略した場合はアクセス不可 756 名前：デフォルトの名無しさん mailto:sage [2007/03/27(火) 00:42:52 ] プロパティと変数なんて一対一になるとは限らないじゃん。 757 名前：デフォルトの名無しさん mailto:sage [2007/03/27(火) 01:14:48 ] もちろん絶対必要というわけじゃなくて、プロパティの型と同じ、実体となる フィールドを指定すること*も*できるってんならいいんじゃない？ 758 名前：デフォルトの名無しさん mailto:sage [2007/03/27(火) 08:18:58 ] プロパティなんぞいらん。糖文増やしてどうすんだよ。 759 名前：デフォルトの名無しさん mailto:sage [2007/03/27(火) 12:29:55 ] >>751みたいなので普通にいいんじゃね？ getとsetのメソッドやら先頭を大文字推奨、プロパティとしては小文字扱いとか 現状のほうがややこしいだろ getとsetがばらばらにおかれることによって見通しが悪くなる場合もあるし リファクタリングの問題もある プロパティ名としてマルチバイトキャラ埋め込んだ場合の話とかもあるし 現状のままが最悪だよ 760 名前：デフォルトの名無しさん mailto:sage [2007/03/27(火) 13:44:08 ] >>751 そっから .NET に倣って、 set_プロパティ名 get_プロパティ名 ってメソッドに展開される、と？ 761 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 02:49:13 ] private int myVar; public get int myProperty() {return myVar;} public set void myProperty(int value) {myVar = value;} JavaScriptライクにこれでおｋ。 762 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 05:11:32 ] getとsetを予約語にせずに実現できるならね。 763 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 05:31:48 ] 予約語にしたらまずいん? 764 名前：デフォルトの名無しさん [2007/03/30(金) 05:45:23 ] getやsetを変数名とかに使ってたらどうするんだよ？ 765 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 05:49:20 ] そんなに互換が大事ならシンタックスシュガーなんていらないだろｗ むしろIDEに機能として組み込めよ 766 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 07:07:49 ] >>764 5.0になったときも非互換変更あったじゃん そのためにコンパイラの文法バージョンを指定するオプションがあるんでしょ 767 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 07:33:32 ] @prop(setter="on",getter="on") private String str; で XX.setStr("A"); XX.getStr(); がコンパイルとおる、でなにがいかんのかと（ry 768 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 09:52:12 ] >>764 @Set、@Getにすればいいよ。 769 名前：デフォルトの名無しさん [2007/03/30(金) 11:45:38 ] ブロックにアノテーションつけられないんじゃないっけ 770 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 11:54:29 ] @getter("getValue"); @setter("setValue"); private String value; これでいーよ。 771 名前：デフォルトの名無しさん [2007/03/30(金) 11:56:08 ] ブロックとは？ 772 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 12:12:16 ] objective-pascal 方式 @setter("__value") @getter("__value") public String value; private String __value; 773 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 14:36:20 ] >>761 に一票。 assertだって使ってた奴いたんだから構わんよ。 というか、get、setっていう変数はなさそうだし、あとに何も付かないset,getメソッドも そんなに無いだろうからいいよ、それで。 774 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 14:55:04 ] >>763 予約語にしたら set get が変数名、フィールド名、メソッド名、クラス名等々に使えなくなる。 >>773 java.util.List#get(int) java.util.List#set(int, E) java.util.Map#get(Object) これだけあれば影響力十分だよなぁ…… いくら互換性を軽視したって言っても、流石にシャレにならんと思うぞ。 俺なら >>761 の文法なら予約語にしない方を選ぶけど。 ってか、そもそも >>761 って set get つける必要あるのか？ 775 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 19:29:56 ] >>751 のほうがまとまってていいな 776 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 19:35:36 ] 新記法のプロパティ定義は使い勝手が良くないから駄目だって、 説明の下手なおじさんが上の方で散々教えてくれてるのに。 777 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 21:55:01 ] >>751みたいなC#方式はvalueが予約語になるのが個人的には嫌だ。 778 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 22:12:44 ] >>777 C# みたいな文脈依存の予約語なら、value が使えないのは set {} 内だけだし。 779 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 22:32:27 ] 別にそのままにしてなくてもいいだろ private int myVar; public int MyProperty(value) { get { return myVar; } set { myVar = value; } } とか 780 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 22:45:47 ] > public int MyProperty(value) { ……。そっちに付けるか 781 名前：デフォルトの名無しさん mailto:sage [2007/03/30(金) 23:50:18 ] こんな案もあるんだから、もっとアノテーション使いまくりでいいんじゃねぇの？ 今のアノテーション仕様にとらわれる必要はないよ。 journal.mycom.co.jp/articles/2006/11/01/jsr308/ 782 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 00:02:40 ] アノテーションでコンパイル制御できるようにならんかのう。 ディレクティブは邪道だから駄目か 783 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 00:50:04 ] >>776 説明だけが下手なんだったら良かったが、論理展開も おそらく頭の中も下手だったからな。 784 名前：デフォルトの名無しさん [2007/03/31(土) 06:33:25 ] 日本語でおｋ 785 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 10:08:46 ] >>779 これ今の文法だとgetの後に;が無いって怒られるじゃない 普通のメソッドの中でも {}　でスコープを制限する記法があるから やっぱ普通のメソッドじゃないという何らかの記述は必要。 >>751 に加えてsetの後に引数記述付けたらいいんじゃないか？ で、この書き方の場合はアノテーションじゃなくて propertyとかいう新しい予約語使うのがいいな。 メソッドは文法が違うんだから。 アノテーションは、あくまで付加的な情報であって 文法の指定であって欲しくはない。 786 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 11:32:15 ] >>782 コンパイル制御させたら地獄のIFDEFの復活になりそうなんだが…。 787 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 12:43:15 ] >>786 でも C# には ConditionalAttribute あるよ 788 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 13:54:10 ] >>785 プロパティ構文実装しようとしてる時点で 現行の文法でとおらないというのは意味のないことだな propertyの予約語に関しては影響範囲はたぶんenumよりは少ないと思う enumはつかわれまくってたからなぁ 789 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 16:09:44 ] >>787 過去の言語を十分に研究して作成した言語でも言語設計の失敗はある。 790 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 16:13:51 ] C♯には #if もあるわけで 791 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 16:55:34 ] >>785 >>788 ちっとは勉強した方が…… blogs.sun.com/ahe/entry/java_se_7_wish_list の Shorthand syntax for declaring properties のところに、 この構文なら property はキーワードにする必要が無いって書いてある。 weblogs.java.net/blog/forax/archive/2007/01/a_property_prop_1.html の prototype-1.7-b05.jar 試してみれば分かるけど property を言語全体に影響する予約語にする事無く、property でプロパティの定義させてる。 常に予約語にする必要がないってわけじゃないけど、 導入する構文によっては予約語にする必要はない。 もしくは、予約語にしないように導入する構文を慎重に決める必要がある。 792 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 17:00:14 ] 予約語にしたほうが構文解析が楽とか紛らわしいのがなくなるとかメリットもあるから 単純にはいえんよ 793 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 17:17:48 ] >>789 なんか一言で失敗作呼ばわりされてしまったなぁｗ 794 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 17:40:08 ] >>792 「property を予約語にしない」ってのを選択肢として持ってないのは不勉強。 795 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 17:58:51 ] 勉強厨か 上のほうのget　setも構文解析からだけ考えれば予約語にする必要はないべ gotoだって使わないが予約語だし、newだって予約語にしなくても本当は使えることは使える 796 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 18:01:38 ] > 上のほうのget　setも構文解析からだけ考えれば予約語にする必要はないべ 既出。 797 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 20:18:57 ] >>796 「既出。」だけのレスは2ch不勉強 798 名前：デフォルトの名無しさん mailto:sage [2007/03/31(土) 23:32:26 ] propertyっていう変数は、結構使われてると思うけどな。 799 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 11:57:31 ] >>792 紛らわしさって？ property を予約語にしない場合の紛らわしさって言っても せいぜい property property が出来るぐらいだと思うが。 800 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 12:05:25 ] ×property property が出来る ○class property がある時に property property property が出来る もっとも、>>785 も >>788 も具体的な構文規則も例も書いてないから、 >>785 >>788 の脳内構文で出来るのかは知らんけど。 801 名前：デフォルトの名無しさん [2007/04/01(日) 15:41:45 ] >>781 前にGenerics使うと長くなるからtypedefいるだろとか言ってたC++信者がいたが これはほんとに可読性に問題起こしそうだな…… どうにかならんもんか 802 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 15:52:49 ] >>801 blogs.sun.com/ahe/entry/java_se_7_wish_list Type aliasing Shorthand syntax for declaring local variables 803 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 16:57:04 ] >>802 結局は、独自定義があるとそれによって可読性が落ちるかもしれないから 適用範囲に十分注意ってとこだな 804 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 18:00:26 ] Ada風に別名を付けるときに元の型から値の有効範囲縛れるように出来ると良いな。 新しい型の有効範囲外だとエラー投げてほしい。 typedef month byte 1...12; aliasでも良いね。...は->でも良いかも。 alias day byte 1->31; typedef leapsecond byte 1->60; キャストは値の範囲が大きい方から小さい方の場合は代入されている値が小さい方で表せる範囲の場合のみ、または小さい方から大きい方。 805 名前：デフォルトの名無しさん [2007/04/01(日) 18:12:17 ] >>804 それこそアノテーションでいいんじゃないか？ 806 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 18:34:49 ] >804 飽和演算もほしくなるな 807 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 18:52:21 ] JavaBeansのフィールドやセッターにアノテーションってのが現実的だな 範囲外がきたとき例外出すのか、飽和させるのか、値を変えないのかの判断もいれればグッド ついでに一番面倒なプロパティリスナのfireも自動でやってほしい 808 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 21:53:14 ] >>807 その情報を元にWebアプリ側で自動でバリデートやエラーメッセージ出してくれたら最高に楽だな。 809 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 22:05:41 ] >>808 なんかライブラリとNetBeansでプラグイン作りたくなってきた GUIとのバインディングでもかなり効率よさそうだしな 810 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 22:41:26 ] プロパティなど要らぬ！ 構文糖・即・悪こそが我々Java厨の共有する唯一の正義ではなかったのか！ それを捨てるというならば、まずtypedefを導入しやがれ 811 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 23:14:33 ] Genericsは構文糖じゃねーのかよ 生成されるバイトコードはキャスト使いまくりのものと同じだろ 812 名前：デフォルトの名無しさん mailto:sage [2007/04/01(日) 23:28:04 ] >>810 そんなもん、EoD とか言って autoboxing みたいな構文糖が入った時点で捨てとるような。 813 名前：デフォルトの名無しさん mailto:sage [2007/04/02(月) 00:10:56 ] >>811 乙 814 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 11:11:13 ] >>810 何かいまいち語呂が悪いな というかtyprdefはねえよwww 815 名前：デフォルトの名無しさん [2007/04/03(火) 19:05:07 ] そろそろCloneable（何故かスペルミス）が@SafeCloneアノテーションになったりしないかな ある程度どのように実装しているか表現できればコードチェックのときに便利だと思う。 copy(Cloneable obj)とかif(obj instanceof Cloneable){/*処理*/}とかそういうことは出来なくなるけど…… 816 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 19:40:24 ] いやtypedefは欲しい。 Javaで導入されていないのは、sourceが読みにくくなるという理由だろうけど。 817 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 21:04:57 ] typedef String MyString; みたいなのは同じ型の別名を作るだけだから有害だが、 typedef Map<String, List<MyClass<Integer, String>>> MyType; みたいなのは特別な組み合わせに特別な名前をつけているから有用だと思う。 だから、Genericsありの場合のみtypedefを許すというのはどうだろうか。 818 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 21:12:11 ] class MyType extends Map<String, List<MyClass<Integer, String>>>{} 819 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 21:31:09 ] >>816 実態が変わるのならきっついのでは？ Javaはすべてダイナミックリンクなわけで Stringからchar[]への変更とかIntegerからLongへの変更とか現実的ではないし 820 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 21:38:01 ] これさー typedef String MyString; MyString abc = "sample"; これ、OK にするん？　NG にするん？ 821 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 21:44:12 ] >>818 それでいけるかー typedefのためだけにファイルいっこつくるのが許容できるかどうかだな 822 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 21:51:09 ] >>821 逆にファイル一個作らない場合、どのソースファイルに記述するか迷わないか？ ひとつのクラス内でのみ使用するというならいいが。 823 名前：デフォルトの名無しさん [2007/04/03(火) 21:53:30 ] >>818 擬似Typedefアンチパターン www-06.ibm.com/jp/developerworks/java/060310/j_j-jtp02216.shtml 824 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 22:27:37 ] extendsに関してはあまり的を得ているとはいえない批判だな。 公開APIで使うべきではないけど、内部処理で使うには問題はなかろう。 「大規模では・・・」というのも、モジュール境界で使わなければいいだろう。 825 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 22:33:36 ] >> 820 OKだろ。 826 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 22:59:03 ] >824 当を得る、的を射ると書こうと思ったが "的を得る"もあながち間違いとはいえないらしい 827 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 23:09:14 ] >>820 そんなん言語仕様作ってる連中が居るところで聞かなきゃ意味がない。 どーせやるなら generics のパラメタ型だけじゃなくて JSR 308 の型へのアノテーションも含めて欲しいけど。 828 名前：デフォルトの名無しさん mailto:sage [2007/04/03(火) 23:35:42 ] typedef派の諸君！ Java7で何かが変わると思ったら大間違いだ！ 所詮dolphinなんか、property派のお祭に過ぎない！ 我々typedef派にとってdolphinほど馬鹿馬鹿しいものはない！ 多数決で決めれば、property派が勝つに決まってるじゃないか！ 829 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 00:16:01 ] 俺は言語使用云々よりもMVMが最も重要だと思う。 MVMさえ実現されれば、デスクトップJavaもサーバJavaもかなりの勢いで道が開ける。 830 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 00:44:35 ] 俺もそうは思うが、MVMって実装される予定はあるのか？ 831 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 01:12:55 ] >>828 俺はビビらない もうちょっと上手くやってください >>830 俺がずっとヲチしてるとこは年単位で動きナス ttp://research.sun.com/projects/barcelona/ ttp://java.sun.com/developer/technicalArticles/Programming/mvm/ 唯一怪しげな情報として引っかかってきたのが ttps://jvmcomm.stage.dev.java.net/ ここによると、MVMは作られた、とのこと。 もしかして、通常権限だとアクセスできない ttps://mvm.dev.java.net/ に何らかの情報が？誰か触った事のある奴居ないっすか？ 832 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 08:41:27 ] >>823 いい記事を知った �d 833 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 09:33:04 ] >>828 クロージャー祭りなワケですが。 834 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 11:59:58 ] 諸君！この言語は最悪だ！ プログラミングだとかコンピュータだとか、 私はそんなことには一切興味がない！ あれこれ改変して問題が解決するような、 もはやそんな甘っちょろい段階にはない！ こんな言語はもう見捨てるしかないんだ、 こんな言語はもう滅ぼせ！ 私には、建設的な提案なんか一つもない！ 今はただ、スクラッチ＆スクラッチ、0から書き直すことだ！ 835 名前：デフォルトの名無しさん [2007/04/04(水) 13:45:51 ] MS儲おつかれさまです。 836 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 20:03:09 ] MVMなんかいくら待ったって無駄だっ！ 837 名前：デフォルトの名無しさん mailto:sage [2007/04/05(木) 01:17:46 ] >>835 うん、MSは儲かるよ 838 名前：デフォルトの名無しさん mailto:sage [2007/04/05(木) 07:55:41 ] 外山ゲイツ 839 名前：デフォルトの名無しさん mailto:sage [2007/04/12(木) 20:20:00 ] JDK7 build11 download.java.net/jdk7/changes/jdk7-b11.html download.java.net/jdk7/binaries/ 何か地味なビルド。 OpenJDKでのビルド修正に関するFixばかり。 840 名前：デフォルトの名無しさん mailto:sage [2007/04/13(金) 15:01:43 ] NIO2 の草案できたらしい。 d.hatena.ne.jp/kazama/20070413 より。 841 名前：デフォルトの名無しさん mailto:sage [2007/04/13(金) 21:03:32 ] すげー 日本語版が用意されているという趣向が ちょっと見てみようかという気になる 842 名前：デフォルトの名無しさん [2007/04/18(水) 12:27:47 ] 進歩してるなｧ journal.mycom.co.jp/articles/2007/04/11/openterracotta/index.html 843 名前：デフォルトの名無しさん mailto:sage [2007/04/18(水) 20:17:38 ] JRE仮想化はBEAみたいなハードウェアよりなのが勝つんじゃないかな 844 名前：デフォルトの名無しさん mailto:sage [2007/04/18(水) 20:53:59 ] ところでJavaでCPUのコア数って取得できましたっけ？ 845 名前：デフォルトの名無しさん mailto:sage [2007/04/18(水) 21:06:02 ] >>844 次世代関係ないな。初心者質問スレいけ。 846 名前：デフォルトの名無しさん mailto:sage [2007/04/19(木) 08:13:46 ] 知らないなら知らないって言えばいいのにｗ 847 名前：デフォルトの名無しさん mailto:sage [2007/04/19(木) 21:58:33 ] JOGLがSEに組み込まれることと、 Uniform Driver Interface対応がされれば Javaクライアントの未来もあるんだが、 今だサーバ関係ばっかサポートしてるな。 848 名前：デフォルトの名無しさん mailto:sage [2007/04/19(木) 22:03:55 ] JavaSE6でJOGLとの融合する予定だったけど不安定でとめたからな 今のバージョンでOpenGLレンダリングでGLJPanel使うとよくおちる 5.0はまともにレンダリングされなかったけどな なんかリペイントマネージャがおかしかった模様 JOGL＋GLCanvas自体は安定してるのでゲームでは問題ないけど、 GLJPanelが動くようにならないと復権無理だな あとは入力インターフェースとして2軸2ボタンでいいのでジョイパッドの正式サポートを 849 名前：デフォルトの名無しさん mailto:sage [2007/04/19(木) 23:13:54 ] 「New」IO「2」か。。。どれだけ計画性のないネーミングだっつーの 850 名前：デフォルトの名無しさん mailto:sage [2007/04/19(木) 23:31:50 ] >>849 NIO2は別名なんだろ？ 統合か名前が変わるかするだろう 851 名前：デフォルトの名無しさん mailto:sage [2007/04/20(金) 10:36:48 ] >>849 サントリー New Old 852 名前：デフォルトの名無しさん mailto:sage [2007/04/20(金) 12:39:51 ] >>851 あれはわざとやったらしいよ 853 名前：デフォルトの名無しさん mailto:sage [2007/04/20(金) 23:37:33 ] マトリックスの奴の名前だっけか 854 名前：デフォルトの名無しさん mailto:sage [2007/04/21(土) 00:43:10 ] >>853 仁王？ 855 名前：デフォルトの名無しさん [2007/04/28(土) 06:15:28 ] 言語レベルでの複素数型のサポートっていつやるの？ 856 名前：デフォルトの名無しさん mailto:sage [2007/04/28(土) 09:15:37 ] >>851 そうなのか。Sunってなんか変なところでマーケティングが変なこと言い出す気がする。 1.1→1.2→1.3→1.4→5.0→6.0 なバージョニングといい J2SE→Java SE といい。 857 名前：デフォルトの名無しさん mailto:sage [2007/04/28(土) 09:42:56 ] いや、たんに世の中のバージョンとあわせただけだよ sunの文化として0.1がメジャーバージョンアップなんだよ でもマイナーバージョンアップにしか見えない だから製品名と内部バージョンとをわけるという他の会社と同じものにあわせた あと6.0はない、6だ Java2登場前はただのJavaがあったし、SDKはJDKという名前でまたJDKに戻った Java2という名前を入れるときに製品名としては2.0にすべきだったのさ ただそれだけのこと 858 名前：デフォルトの名無しさん mailto:sage [2007/04/28(土) 11:14:04 ] マーケティング周りで散々分かり辛かったから一般消費者向けに分かりやすい製品名にしただけ。 ブランド名はずっとJavaの4文字だし。 JDKに戻ったのもsun内部ではずっとJDKと呼ばれ続け、開発者側もJDKで十分慣れ親しんだため。 そして何より、今はゲイツの相手せずに済むから・・・ J/Directなんて禁句だぜ？ アゝ、なつかしの*7・・・ 859 名前：デフォルトの名無しさん [2007/04/28(土) 16:05:42 ] ♪ア・ソ〜レ ア・チョン！ ア・チョン！ ア・チョン！ チョン！ チョン！ バカ！ 860 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 00:11:38 ] XMLリテラルよりヒアドキュメントに対応して欲しいのは俺だけ？ String sql = <<END_OF_SQL update USER_TBL set name = ?, age = ? where id = ? END_OF_SQL 861 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 00:14:26 ] IDE使っていれば改行を気にすることないから俺は要らんな 862 名前：デフォルトの名無しさん [2007/04/29(日) 00:34:43 ] 複素数なんていらないじゃん。 commonsにライブラリあるからそれで十分。 863 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 08:52:50 ] >>860 ヒアドキュメントは確かに欲しい あと、ヒアドキュメント中にJavaの式を埋め込むこともできたらいいな 864 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 09:17:28 ] 言語でサポートされるなら複素数型は欲しいな・・ 865 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 09:57:06 ] そういえばCSV(TSV, etc.)を読み書きするためのライブラリが標準でないのが気になった 866 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 10:20:46 ] TSVやCSVは環境依存しまくりだからな ほとんどの場合Excel準拠でいいのだろうが H2のライブラリを使うという手もある だが、まずはファイルのコピー等を実装するのが先じゃね？ 867 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 10:47:04 ] 仕様通りのCSVって見た事ないんだが。 カンマで区切る以外はメチャクチャだろ。 868 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 11:05:13 ] >>867 仕様ってrfc4180？ 869 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 11:53:46 ] >>868 4180って後付けだし他のシステムで吐き出したCSVを扱う ときには全く意味ないよね。 870 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 12:37:17 ] 後付の規格にあわせていたら過去のソフトとの互換性が取れんからな どうせやるなら文字コードやどのソフトで出力したかなどメタ情報がほしいね そのへんつっこんでいくとXMLになるから意味がないのだけれども 871 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 12:55:08 ] 後付規格以外では、独自規格乱立してんだから互換性取るなんて無理。 RFC準拠の標準ライブラリとかならともかく、 自分とこの独自規格に合ったのが欲しいなら 自前の CSVライブラリ作った方が楽だし簡単。 872 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 13:07:50 ] ttp://opencsv.sourceforge.net/ これ使ってる。別に困った事はない。というか、ＣＳＶ使うのは止めて欲しい。 問題が解決するわけじゃないが、タブ区切りの方が好み。 カンマより、タブの方が文章中で出てくる頻度が少ない。 というか、明確に項目を区切るための制御文字があってそれを入力できる方がいいなぁ 873 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 13:08:18 ] ちょうどCSVってかテキストデータのライブラリ作ってる。 MIMEにあるかIANAに見に行って、RFCも日本語訳参考にしてるから たぶん仕様的には正確だと思う。 RFC4180についてだけど、セル内改行を LF にすればExcel CSVに対応できる。 しかしAccess CSVは CRLF で、RFC4180と仕様が同じという困ったちゃん。 読み込みは柔軟に、書き出しは目的に合わせて厳密にという対応が必要だね。 874 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 13:28:53 ] 後付けでもECMA-262とW3C DOMはうまい事まとめてるのにね。 相変わらずMSはオープン標準に従う気はないし。 テキストフォーマットの読み書きといえばODFなんかの文書フォーマット読み書きライブラリが標準拡張くらいであっても良いのにね。 やるとしたらテキストコンポーネントのプラグイン扱いかな。 変なところで妙に充実してるのがjavaのクラスライブラリなんだし。 875 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 13:29:04 ] >>873 おれもそのAccessとの対応を対数ヶ月前やった ダブルクォーテーションの中はあらゆる改行タイプをゆるせばいいだけだったっぽい 動きとしてはAccessのほうが納得しやすい 876 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 13:35:53 ] >>874 javaってinterface作るのは好きだけど SPIを作るのは嫌いって人が多すぎるんだよね。 MP3とかOGGとかSound APIにちょこっとしか準拠してないしｗ 877 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 13:54:41 ] >>876 インターフェース作る＝自分でAPI定義 SPIの実装＝定義にあわせて作る だからまったく別の話じゃね？ 878 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 14:00:48 ] このルールにあわせろっていうのは好きだが、 ルールに従うくらいなら俺仕様でって奴が多いってこと。 879 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 21:31:55 ] >>878 うわ、激烈耳が痛てぇ。 orz 880 名前：デフォルトの名無しさん mailto:sage [2007/04/29(日) 23:46:40 ] >>878 それじゃMSがやってることと同じじゃんか。 881 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 00:08:54 ] まぁ、大抵の奴はそう思うんじゃね？ 882 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 00:36:26 ] >>876 例えば標準のプラグインがヘボいので上書きしたい場合みたいに 他のプラグインと衝突する場合のガイドラインがなかったりするし。 いざ作ろうとすると、SPIまわりはドキュメントが不足してる。 他にも、Sun の標準プラグインに必要なインターフェイスだけしかないとか java.net.URLStreamHandlerFactory はなんで SPIになってねーんだとか SPI自体がテキトーに作られてる感が無きにしも非ず。 883 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 10:26:19 ] C99では複素数もとっくにサポートされてるのにJavaはダメだね。 コンパイラに実装するのは難しくないだろ。 いろんなComplexクラスとか見ると、また車輪の最発明なのかと思って悲しくなる。 884 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 10:55:57 ] ここは・・・ C99なんて仕様だけだろﾌﾟｷﾞｬｰm9 って言えばいいのか？ マジレスもしとくか、複素数を普通の演算子で扱いたいって事なんだろうけど Javaの流れとしてはXMLリテラルの方が先じゃない？ 俺としてはどっちも要らんが。 885 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 11:42:39 ] >>883 確かに人それぞれの複素数クラスがあるよね。 886 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 12:50:02 ] 複数のライブラリを横断的に使ってて、 複素数型がライブラリ毎に違うのが面倒くさいとか そーゆーケースでもない限り標準APIに拘る必要も無いような。 複素数型入れても今更感が強いし、 下手すると独自規格乱立したCSVに後付標準規格(?)ができたのと同じで それほど意味がないものになるような気もする。 887 名前：デフォルトの名無しさん [2007/04/30(月) 12:55:54 ] >>884 gccのC99じゃだめなのか？ Javaも無料のコンパイラ使ってるくせに… 888 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 15:30:34 ] そんなにCがいいならC使ってればいいんでは？ 889 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 15:56:36 ] >>883 Complexクラスが標準になればいいだけの話か。 890 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 16:45:23 ] 複素数リテラルのまえに、BigIntegerリテラルだろ。 891 名前：デフォルトの名無しさん [2007/04/30(月) 17:05:27 ] Wikipediaをwikiって略すな！ 同時にWikipedia以外のWikiも盛り上げよう！ 892 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 17:17:46 ] >>891 携帯するものなんて電話以外にもいくらでもあるのに 携帯電話を携帯って略すのもやめよう 893 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 17:29:32 ] >>890 リテラルは知らんけど、BigInteger BigDecimal の演算子オーバーロードは dolphin で追加されそうな気配はある。>>132 のスライドに入ってるし。 もっとも、目玉は closure と erase erasure だろうけど。 closure というか、function type の実装には java.lang.function パッケージに引数型+戻り値型を名前にした interface を使うみたいだけど （ {int=>int} なら java.lang.function.II みたいな名前で int invoke(int) だけを持つ interface） これ、実行時に生成するなら同じ仕組みで List<String> とかも生成するんじゃないかな。 と妄想中。VM（厳密には ClassLoader？）に手を入れる事になるけど。 で、そっちに時間取られると演算子オーバーロードとかは漏れる可能性もあるもしんない。 894 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 17:57:08 ] >>891 seasarスレにカエレ(・∀・) ま、どうせこのスレとあっちのスレ、中の人は同じだがな。 895 名前：デフォルトの名無しさん [2007/04/30(月) 18:23:11 ] MVMは次に乗らないのか？ スレッドはネイティブ対応しないのか？ あーらんに負けるぞ。 896 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 18:28:56 ] > スレッドはネイティブ対応しないのか？ ？？？ 897 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 19:25:00 ] いまだにグリーンスレッドと勘違いしてるんだろう. 898 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 19:34:54 ] 一瞬Rubyスレかと思ったわい。 899 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 19:46:22 ] >>898 ﾉｼ おれもれも。 ところでRuby処理系のネイティヴスレッド化って完了したの？ YARV Ruby でぐぐってみたけど、ささだ先生のところは0.4.1くらいで更新が 止まってるみたいで、最新の状況がよくわからん。 あ、スレちがいか。すまん。 900 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 20:17:55 ] >>893 目玉はBigIntegerとBigDecimalだと思うよ 業務アプリだとこの辺頻繁に使うし 901 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 20:19:27 ] >>899 そういうときはJRubyに関連付けするのだ 0.9.9がでたのでもうすぐ正式版が登場 つまりJavaVM上でRubyは動かすのが正解 VM起動時間なんてJavaSE6なら2回目以降は0.5秒だから問題ないし 902 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 20:46:47 ] >>900 っても、closureの話は聞こえてくるけどBigDecimalの話はあんまし聞こえてこないんだよね。 903 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 20:53:57 ] >>902 仕事に絡まないプログラムならそうかもしれんが 仕事では使わないという場面はほとんどないからなぁ。 そして仕事で組んでる場合、次の技術というのに目が行く人は少ない。 目をつけていても発言する場が日本語でできないのなら誰もしないだろうさ。 904 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 21:24:54 ] >>903 いや、Sunがどーゆー実装にするとか、JCPでどーゆー提案が出たとか そーゆー話が聞こえてこないって事なんだけど。 905 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 21:37:14 ] JCPとかリードスペックとか現時的に業務に絡んでないやつらが多すぎなんじゃ？ 906 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 21:42:30 ] >そして仕事で組んでる場合、次の技術というのに目が行く人は少ない。 >目をつけていても発言する場が日本語でできないのなら誰もしないだろうさ。 技術者として終わってるな 907 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 21:51:54 ] >>906 じゃぁ始まってるアンタが変えてよ 908 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 21:56:07 ] >>905 愚痴たれるんならマ板に行ってやれ。 909 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 22:04:35 ] >>906 たとえ真実でも、言ってはいけない事ってのがあってだな…… 910 名前：デフォルトの名無しさん mailto:sage [2007/04/30(月) 22:28:02 ] >>906-909 PGが絶対口にしてはいけない一言 pc11.2ch.net/test/read.cgi/tech/1176001986/l50 911 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 01:55:23 ] >>889 ライブラリにクラスを追加するとか、演算子オーバーロードが出来るようにするとか よりも、プリミティブな複素数型を言語に追加してくれってこと。 複素数は機種依存するもんじゃないし、 たとえばFFTや平面座標上の点の計算に活躍する。 912 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 02:00:43 ] 小数点演算すらソフトウェア実装なのに面倒なことさせるな。 913 名前：デフォルトの名無しさん [2007/05/01(火) 07:17:37 ] > 現時的に業務に絡んでないやつらが多すぎなんじゃ？ 現実的に国内で業務システムに絡んでる奴は 頭弱すぎて割り込めないだけ。 914 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 07:49:23 ] >>911 > たとえばFFTや平面座標上の点の計算に活躍する。 の用途のために、何故 > プリミティブな複素数型を言語に追加してくれってこと。 が必要なのかわからん。クラスじゃ何でダメなんだ？ あと「プリミティブな」ってVM変更（バイトコードインストラクションを拡張）しろって話？ たぶん、そんな要求してもマトモに相手にされないと思うけど。 915 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 08:19:29 ] この人は、単に複素数リテラルと演算子のオーバロードが欲しいだけだと思う。 言葉が不自由なので、自分の要求を正しく伝えられないのでは？ 916 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 08:35:19 ] >VM変更（バイトコードインストラクションを拡張）しろって話？ 言語仕様の追加みたいだけど、どこからVM仕様追加の話になるんだ？ C99のようにゴニョゴニョっとまねして、チャチャッ実装しちゃってくれってことじゃないのか。 まあ、あれば便利だし、有難く使わせてもらうけど。 917 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 08:42:26 ] 自分で実装してJCPに提案しろｗ 918 名前：デフォルトの名無しさん [2007/05/01(火) 08:54:09 ] 演算子をオーバーロードして、BigDecimalの割り算はどうやって丸め指定を表現するんだろ 919 名前：デフォルトの名無しさん [2007/05/01(火) 08:56:26 ] Javaの複素数演算用クラスって、どっかになかったか？ いちいち、引数をとらないといけないし、Fortranなどマシン語レベルの ライブラリ充実している言語と比べると、スピードが出ないだろうけど、 だからといって、VM仕様から変更は影響が大きすぎるだろ。 920 名前：デフォルトの名無しさん [2007/05/01(火) 09:06:24 ] >VM仕様から変更 だからどうしてVM仕様変更の話になるんだと小一時間（ｒｙ 921 名前：デフォルトの名無しさん [2007/05/01(火) 09:14:02 ] >>920 java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html#19511 922 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 09:36:30 ] >>912 strictfpで宣言しない限り結局はFPUに計算させてない？ 923 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 10:37:21 ] >>916 >>911 の > ライブラリにクラスを追加するとか、演算子オーバーロードが出来るようにするとか > よりも、プリミティブな複素数型を言語に追加してくれってこと。 から。 クラスもダメで、演算子オーバーロードもダメで（たぶんリテラルもダメ）、 プリミティブな型を追加と言われたらバイトコード拡張なのか？ ってのは至極当然。 924 名前：デフォルトの名無しさん mailto:sage [2007/05/01(火) 11:13:54 ] 意味なしリクエストは却下 925 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 04:33:33 ] >>916 >>921 >>923 それがどうやって実装されるかということを君達がアレコレ妄想する必要はない。 それがあればどう世界が変わるかだけを考えろ！ 926 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 07:43:02 ] まったく変わらない。 以上 927 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 08:46:01 ] >>915 複素数リテラルって何？ 3.1i 1 + 2i "3 + 4i" とかのことか それと演算子オーバーロードは、 Complex,Matrixクラスの話題とよくセットで出てくるが、 その程度で演算子オーバーロードを実装するのはコストが 高いなどの論点とは今回は関係ないようだ。 おまえは思い込みが激しいようだな。 928 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 08:57:25 ] 言語不明瞭意図不明。 929 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 09:03:14 ] >>927 >>928 おまえ誰だよ。早く消えちまいな。 930 名前：デフォルトの名無しさん [2007/05/02(水) 09:35:38 ] 野次と荒らしは2chの花 931 名前：デフォルトの名無しさん mailto:sage [2007/05/02(水) 11:39:25 ] >>930 ｦﾀとDQNが抜けてるぞ 932 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 06:00:15 ] >>925 どう実装されるかはしらんが、プリミティブ型を追加するという時点でVMに手をいれないといけないのは決定だろ。 933 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 09:20:31 ] C99だと struct complex {double real, imag;} struct complex {double z[2];} とかで実装されてるんじゃないか。 だからコンパイラの拡張のみでマシーン（VM)の方に手を入れることはない。 というか、一般人が実装のことを考える事自体が意味ないじゃん。 934 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 09:32:36 ] 配列で大量に計算する用途だとクラスよりC#の値型のようなものがあるとベターだな。 935 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 09:58:40 ] >>933 えーと。 結局、プリミティブな複素数型は特に必要がなくてクラスでやってもOKって話かな？ 本当に複素数型欲しいなら 現時点でGPLで配布されてる javac に複素数型導入して公開したり、 そのパッチを ksl に投稿してみるとか、 BugDatabaseに行って、RFE出すとか既存のRFEに投票するとか、 その bugID 晒して、皆に投票呼びかけたりとか、 もちっと前向きな行動した方が良いと思うよ。 ここで複素数追加みたいなネタ振られたって、 皆でどーゆー実装するのか妄想して遊ぶぐらいしかできないでしょ。 936 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 10:09:09 ] 座標上の点の計算には便利そうだ。特に回転とか。 複素数クラスがあってもnewしまくるから遠慮してたけど、 言語に追加されるなら便利そうだけどな。 今のトレンドは言語に複素数を追加することなんじゃないか。 C,D,Pythonは既に言語レベルでサポートしてるし。 937 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 10:25:59 ] トレンドってほど支持する流れも否定する流れも大きくないと思うが…… 938 名前：デフォルトの名無しさん [2007/05/03(木) 10:37:45 ] >>933 頭悪そう C99を使ってろ 939 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 10:53:07 ] >>936 ちなみに、何を作りたくて複素数型が必要なんだ？ 940 名前：デフォルトの名無しさん [2007/05/03(木) 10:57:23 ] >>934 C#の値型は、クラスと比べてどんなメリットがあるの？ コンパイル時に最適化されて ランタイム負荷が小さいとか？ 941 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 12:34:41 ] >>940 クラスのオブジェクトに比べ生成と削除のコストが低い。 値型は参照を介せずにスタックに直接値が格納されたり、 配列やクラスのメンバーとして直接その領域に値が格納されるので ボクシングが発生しない限りGCの必要な実体が作られることがない。 このためプリミティブ型に近いパフォーマンスを発揮する。 942 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 12:45:20 ] >>939 必要ないんでしょ。 ってか、実際に複素数型が必要な分野のプログラム組んでる人間が 「演算子オーバーロードよりもプリミティブな複素数型」なんて言うとは考えられないし。 943 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 14:50:30 ] >>941 値型ってのが広い範囲を表すからいいたいことがあいまいだぞ 944 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 15:00:41 ] 下手に構造体チックなものが登場されてもBeanの文化が壊れるから ByteBufferで我慢が出来ないなら諦めてくれって方針で十分。 945 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 19:32:28 ] >>933 だから、それはプリミティブ型じゃないだろ。 946 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 20:49:44 ] Ｃ＃の値型みたいなのがほすぃ って言いたかっただけなんじゃないか、と。 947 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 21:32:14 ] >>946 Java に C# の値型みたいなの導入すると コンパイラ弄るだけじゃすまなくて、それこそ VMの変更が必要なりそうだし。 メソッドの戻り値で値型を使う場合とか。 それに、C# は最初から値型があったから良いけど、 Java の場合は generics 導入しちゃった後だからねぇ。 今から C# の値型みたいなものを追加したとしても 現時点でのプリミティブ型みたいに generics で使えなさそうだし。 948 名前：デフォルトの名無しさん [2007/05/03(木) 21:52:46 ] Javaも遅かれ早かれVMの拡張は必要になると思うのだがいつごろ来ると思う？ 949 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 22:05:05 ] >>948 おいおい…… バイトコードインストラクションの話ならJSR-292のinvokedynamic追加の検討中。 後は>>893がfunction type関連でVM拡張とか言ってる。 950 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 22:13:31 ] >>949 さんくす。複素数の議論でVM拡張は避けるべき的な話が出てたので確認してみた。 別にVM拡張前提で話をしてもかまわないわけだよね。 951 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 22:21:32 ] >>950 ここは「次世代Javaの動向」をヲチるスレだから、 新機能追加の要望とか、単なる妄想オナニーなら他所でやってくれ。 952 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 22:24:40 ] だれもVM拡張は避けろといってなくて、プリミティブ型を追加するならVM変更という話と、そんな無意味な要求は却下されるよという話が同時進行してただけかと。 953 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 22:28:41 ] >>951 ヲチするだけとはどこにも書いてないわけで。 しかも、最初から要望とか妄想オナニーばかりのスレで、950も過ぎてから言ったところで説得力ない。 954 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 22:32:05 ] >>953 今回ので言えば、既に >>935 で他所行けって出てるし。 他の話題でも他所行けってのは散々出てるし。 955 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 22:38:34 ] つまり、スレの流れについていけなくてわめいてるってわけか。 956 名前：デフォルトの名無しさん mailto:sage [2007/05/03(木) 22:41:32 ] >>953 便所に落書きしても要望だとは思われないよな。普通は。 957 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 01:17:58 ] 複素数を扱うライブラリがあれば便利だと思うが 言語仕様に含めるのはやり過ぎです。 ところで値型って、VBのByValを指しているの？ 958 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 01:45:44 ] >>957 ここは予想や感想を述べる場所じゃないとのことなので、 そういう動向は今のところ無いということでおしまいらしい。 値型はVB.NET以降では、ユーザー定義型（Structure）、Enum、クラスを除くVBの基本データ型をさす。 VBのデータ型と.NET(CLR)のプリミティブ型は若干違うから注意。 ここではユーザー定義型（Structure）の意味で使ってる。 .NET(CLR)ではValueType C#ではstruct。 Javaだと参照型以外の型＝プリミティブ型＝値型という理解でいいのかな？（自信は無いが） あとは質問か雑談スレへとかいわれそうだ。 959 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 03:50:43 ] >>956 「普通は。」ってなんだよ 9m(^x^ 960 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 09:51:42 ] C#：全部ヒープに置いたら遅いだろ！struct導入する！ Java：エスケープ分析で自動的にスタックに置くｳﾏｰ 961 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 12:14:58 ] どうもsturct(値型）の話になってるようだけど、なんなら typedef double complex[2]; でいいじゃん。どう実装されるかなんかはベンダ任せなんだけどね。 962 名前：デフォルトの名無しさん mailto:sage [2007/05/04(金) 19:07:54 ] ベンダ任せなわけがない 963 名前：デフォルトの名無しさん [2007/05/04(金) 20:59:25 ] Hさん、居るよね。 964 名前：デフォルトの名無しさん mailto:sage [2007/05/05(土) 21:03:27 ] MさんとKさんもいるよね。

---

---

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

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