[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/ 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 を使えないのって、本当に使いやすいかも結構問題のような？

---

---

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

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