[Java SE 7] 次世代Ja ..
596:デフォルトの名無しさん
08/03/13 23:59:35
>>595
それ言っちゃおしまいでしょ。
java.lang.Math とか java.util.Collections とか、
クラス外にメソッド置いとけるんならクラス外に置きたいようなのは標準APIにも多いし。
Java でやるなら >>594 みたいなやり方しかないと思うけどね。
597:デフォルトの名無しさん
08/03/14 00:01:58
>>562
> 型推論と似てるけど、型推論は動的にやるでしょｗ
MLなどの型推論はコンパイル時に静的にやるよ。
動的だったら、型を推論するまでもなくチェックすればいい。
>>567が言っているような、
generics使って汎用に書かれたクラスに、
具体的なクラスを与えて、新たなクラスとしてpublicにする、
って機能は必須だと思う。
ただconcept(C++), type class(haskell)のような形の方が
より汎用でスマートだと思う。単なるエイリアスじゃなくて
両クラスのグルーとなるコードも加えられるし。
598:デフォルトの名無しさん
08/03/14 00:05:28
>>596
クラス外メソッド定義とクラスエイリアスは別件。
599:デフォルトの名無しさん
08/03/14 00:15:29
>>598
クラス外メソッド定義したいって言ってるんじゃなくて
言語仕様が許すなら必ずしもクラス内に置く必要ないエイリアスやメソッドを
クラス内に置かなきゃいけないのは等しくアレだって事
600:デフォルトの名無しさん
08/03/14 02:39:52
アノテーションでいいよ。機能的には違うけど、本質的に同じだし。
601:デフォルトの名無しさん
08/03/14 03:01:16
クロージャーなんて既存機能で十分まかなえるものの焼き直しなんかより
もっと AOP 的設計が出来るようなアプローチしろよ。インスタンスフィールドへの
アクセスもトラップできるようにすればそもそもプロパティ拡張もいらんだろが。
602:デフォルトの名無しさん
08/03/14 03:44:37
クロージャで演算子オーバーロードもとラップできるといいけどな
603:デフォルトの名無しさん
08/03/14 05:49:16
> インスタンスフィールドへのアクセスもトラップできるようにすれば
フィールドアクセスがめちゃくちゃ遅くなりそうだな
604:デフォルトの名無しさん
08/03/14 06:29:16
final 宣言されてない getter/setter と同等にできるだろ。めちゃくちゃの根拠が不明。
まぁプロパティアクセスに関しては「後で」「静的に」「他のソースを修正せずに」アクセサを
追加できれば十分だが。
605:デフォルトの名無しさん
08/03/14 06:51:54
また変な奴が常任してしまったな。
606:デフォルトの名無しさん
08/03/14 06:54:17
ＪＳ乙
607:デフォルトの名無しさん
08/03/14 07:11:52
C#厨房よりはましｗ
608:デフォルトの名無しさん
08/03/14 07:28:45
というかおまえ誰だよ
609:デフォルトの名無しさん
08/03/14 07:33:04
俺ビルジョイ
610:デフォルトの名無しさん
08/03/14 07:58:33
ＪＳじゃイニシャル違うじゃんかよ
611:デフォルトの名無しさん
08/03/14 10:58:17
>>604
そか？ 隠蔽されたフィールドに対するアクセスとかも考えたら
プロパティモドキじゃ対応できないし馬鹿みたいにでかい仕組みが必要になると思うが。
612:デフォルトの名無しさん
08/03/14 12:18:31
JKが女子高生なんだからJSは・・・
613:デフォルトの名無しさん
08/03/14 12:22:35
専門学校生だよね
614:デフォルトの名無しさん
08/03/14 12:30:48
>>611
それだけなら何とかなると思うが……
もっとも、リフレクション対応までして「インスタンスフィールドアクセスのトラップ」
できるようにするより他の事にエネルギー使って欲しいぞ。
615:デフォルトの名無しさん
08/03/14 15:49:59
J 常識的に
S ｾｯｸﾙして
616:デフォルトの名無しさん
08/03/14 16:03:51
>>611
現時点でも少なくともリフレクション程度は確保できる。
まぁフィールドアクセスはそれも包含できるという意味で引き合いに出しただけで本意は別。
ゴリゴリ書くしかなかったのを簡素化したいのはもっともだが、なら無名内部クラスより
DI の標準様式一つでも考慮しろと。
617:デフォルトの名無しさん
08/03/14 16:14:40
> DI の標準様式一つでも考慮しろと。
？
618:デフォルトの名無しさん
08/03/15 01:41:01
あれ？JFileChooserが遅いバグって6u5までのどこかで修正入った？
619:デフォルトの名無しさん
08/03/15 10:17:10
>>541
つーか選択肢は二つくらい(?)あって
・クロージャから抜けるのみ ・・ >>540のコードなら、doSomething() が実行されないだけで for each は続く
・for each の置かれているメソッドから抜ける
「JavaのクロージャはこれまでのListenerの構文糖衣だぜ」ってんなら
前者が選ばれるだろうなと思ってさ。
620:デフォルトの名無しさん
08/03/15 10:19:34
>>619
> 「JavaのクロージャはこれまでのListenerの構文糖衣だぜ」ってんなら
違う。
621:デフォルトの名無しさん
08/03/15 10:32:19
匿名クラスの構文糖って言いたかったんかな
622:デフォルトの名無しさん
08/03/15 11:45:56
クロージャのreturn周りはどうなるのかホントわかんないな。
ECMAScript風になるのか、ruby風になるのか。
623:デフォルトの名無しさん
08/03/15 11:54:42
C#風に、内容に expression しか書けないクロージャ（ラムダ式）と、
statements が書けるクロージャの2種類作るってのもアリだと思うんだけど。
624:デフォルトの名無しさん
08/03/15 11:54:49
どっちでもない
625:デフォルトの名無しさん
08/03/15 12:41:25
ruby風はありえないだろ
何がどこに抜けるんだかバージョンによって変わるだなんて
626:デフォルトの名無しさん
08/03/15 13:29:50
returnで脱出する最外レベルはメソッドであって、
クロージャやブロックではない。
詳しくは URLﾘﾝｸ(www.javac.info) を読め。
627:デフォルトの名無しさん
08/03/31 04:07:09
Listenerを登録するという設計自体がクロージャと相性が悪いわけか
なんでこんな設計にしたんだ
628:デフォルトの名無しさん
08/03/31 04:15:55
他に手がないからだろ
629:デフォルトの名無しさん
08/04/01 08:58:11
>>627
てか他に手は無いだろ
630:デフォルトの名無しさん
08/04/02 02:03:03
>>627
相性が悪いって程でもないと思うが
確かBGGAでは、function typeをListenerに暗黙に変換するための
仕掛けが用意されるんじゃなかったっけか
631:デフォルトの名無しさん
08/04/02 09:54:37
>>630
ActionListenerみたいにメソッド一個しか無い場合は変換できるけど、
BGGAには、MouseListenerみたいにメソッドいっぱいある場合の変換の仕掛けはないよ。
named inner methodがあるFCM と比べると、BGGAとXxxListenerは相性悪い。
632:デフォルトの名無しさん
08/04/02 10:02:50
URLﾘﾝｸ(tronicek.blogspot.com)
method reference だそーです。
method reference に '#' 使うのが平気な感覚もってるのに
accessing property に '.' 以外の演算子使うのってダメなんかねぇ…… と思ったり。
633:デフォルトの名無しさん
08/04/02 10:50:41
listOfArgumentTypesは必要かね?
継承に絡まない型推論はしない主義だから必要になるのかな。
文脈は常に強く型付けされているはずだが。
634:デフォルトの名無しさん
08/04/02 10:59:04
もう Method の静的解決 (Foo.class みたいな) でええやん。関数ポインタみたく使えりゃええんじゃろ。
635:デフォルトの名無しさん
08/04/02 11:00:07
static import で listOfArgumentTypes 書けるようにしてくれませんかね？
636:デフォルトの名無しさん
08/04/02 19:35:24
>>633
本来なら通常は要らんと思うけど、同名のメソッドがオーバーロードされてる
場合必要になるから、必須にしてるんじゃないかな？
637:デフォルトの名無しさん
08/04/02 19:41:39
それは型情報で分かるから。
638:デフォルトの名無しさん
08/04/02 20:49:02
>>634
ちがうよ。変数スコープが重要
639:デフォルトの名無しさん
08/04/02 21:46:47
>>637
contravariant な変換許すなら、型情報だけから必ず判るわけじゃないから
listOfArgumentTypes 省略しないタイプも必要だと思うぞ。
省略できても良いと思うけど。
640:デフォルトの名無しさん
08/04/02 23:01:51
>>637
(System.out#println(String)).invoke("Foo")
みたいな場合を考えると必要なケースもあるよってこと
もちろん、必要じゃないケースもあるから省略はできてもいいと思う
もちろん、上のような式を実際に書く必要はないだろうけど、文法上
書けるなら対策は必要になるわけだ
641:デフォルトの名無しさん
08/04/09 23:28:18
そろそろjdk1.7はリリースされるの？
642:デフォルトの名無しさん
08/04/10 00:19:26
来年の始め頃じゃないか
643:デフォルトの名無しさん
08/04/10 00:27:41
1.6updateN が出てから 1年ぐらいは必要じゃないかと思うが
644:デフォルトの名無しさん
08/04/10 09:45:57
なんだ。まだか。
645:デフォルトの名無しさん
08/04/10 21:34:28
Java7からと思ってたが、Java KernelはUpdate Nから入るのね。
JMFあたりも自動ダウンロードしてくれるならありがたい限りだけどどうだろ。
646:デフォルトの名無しさん
08/04/18 12:48:24
JDK7 build25
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
647:デフォルトの名無しさん
08/04/19 06:58:13
クロージャーなんかよりも、入出力ストリームや Lock 使った try-finally 使いまくりのコードを
きれいに書ける構文考えてくれよ。synchronized と違和感ないような (これもブロック抜けるときに
モニタ開放するし)。
try(Writer out = new FileWriter("foo.txt")){
...
} catch(IOException ex){...}
↓みたいな。二重tryでもいいや。
Writer out;
try{
out = new FileWriter("foo.txt")){
...
} catch(IOException ex){
...
} finally{
try{ if(out != null) out.close(); } catch(IOException ex){throw new RuntimeException(ex);}
}
648:デフォルトの名無しさん
08/04/19 08:59:28
それは既に入る予定だが?
しかもクロージャを使って。
649:デフォルトの名無しさん
08/04/19 09:30:50
>>647
つ control invocation syntax
650:デフォルトの名無しさん
08/04/24 14:22:07
次のjava7でクロージャ以外で主要な目玉機能ってなんですか？
651:デフォルトの名無しさん
08/04/24 16:03:13
俺はダグ・リー先生のjsr166y.forkjoinがどうなるかが最大の関心事
素晴らしすぎ。
652:デフォルトの名無しさん
08/04/24 16:21:19
今度の JavaOne で dolphin の進捗も発表されんじゃね？
653:デフォルトの名無しさん
08/04/24 17:00:32
クロージャ以外は特にないよ
654:デフォルトの名無しさん
08/04/24 20:05:44
fork-joinはメニーコア時代の必需品になるだろうし重要だと思う。
そんな時代だと永続性ユニットとしてRDBMSだけじゃなく、
これとMemoryMappedFileあたりと組み合わせたやつとか使いそう。
655:デフォルトの名無しさん
08/04/24 21:35:45
FileじゃなくてOODBください ＞＜；
656:デフォルトの名無しさん
08/04/27 15:47:45
いつまでも実現しないMVMは？
657:デフォルトの名無しさん
08/04/29 15:06:35
JDK7 build26
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
658:デフォルトの名無しさん
08/05/04 23:56:54
LINQみたいなのは、はいらんの？
quaereのような式言語っぽいやつじゃなくて言語実装として組み込まれてるのがほしい。
659:デフォルトの名無しさん
08/05/05 00:12:37
スクリプト関連ほんとに追加されるのかな〜
660:デフォルトの名無しさん
08/05/13 03:23:42
スクリプト関連は、やるだろうね。
Java一本が難しくなった今、他言語のサポートは急務
LINQみたいなのは、能力的に無理そう。
661:デフォルトの名無しさん
08/05/16 19:50:57
method refarenceなかなかいいんじゃないの？
Integer#parseInt(String);のやつ
662:デフォルトの名無しさん
08/05/20 00:41:53
JavaFXをプッシュしてるけどSunは、まともなオーサリングツール作る気あるのか？
どう考えても負け戦な気がするんだけど。
663:デフォルトの名無しさん
08/05/20 01:24:56
君にはまだ早すぎる。できる開発者だけの楽しみだしｗ
664:デフォルトの名無しさん
08/05/20 23:38:25
負け戦は確定でしょ
ただでさえ中心人物がどんどんやめていってるのに
665:デフォルトの名無しさん
08/05/21 15:16:25
SUNは、開発者ごとJavaFXをGoogleにあげればいいと思うよ。
開発者のやる気も出るし、Android標準搭載になっていい事だらけだと思うぞ。
まあもらってくれないだろうが・・・
666:デフォルトの名無しさん
08/05/21 23:37:07
JavaFXって結局ブラウザの中でも実行できるんだっけ？
デモサイトを見てもブラウザ内で実行できるのが無いんだけど単にJavaFXのブラウザプラグインがまだ無いだけ？
667:デフォルトの名無しさん
08/05/21 23:43:12
全部javaで書いてあります。> JavaFX
668:デフォルトの名無しさん
08/05/21 23:47:01
えーとね、スクリプトをサポートする順番は、sunの発表では、rubyとかはあるけどFXは全く予定にないってところだった。
まだ熟してないんだよ。そーあせるなってｗ
669:デフォルトの名無しさん
08/05/22 00:18:10
熟すときは来るのか？ｗ
670:デフォルトの名無しさん
08/05/22 07:10:25
SM次第でSMのシルバーなんとkがが市場を開拓すればおのずと、
知らないだろうけど、フォトランのsun風味とかもあるし、
671:デフォルトの名無しさん
08/05/23 11:09:35
JDK7 build27
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
672:デフォルトの名無しさん
08/05/26 12:02:22
JDK6でせっかく入れたTools APIはjava7のリッチクライアントプロファイルでは外されるんだな。
Tools APIってJDK6で入っただけでまだ標準ライブラリ化してないんだっけ？
673:デフォルトの名無しさん
08/05/26 12:09:04
>>672
リッチクライアントプロファイルからはjavacとか削るつもりなんだろ。
プロファイルによってはAWT/Swingみたいな標準ライブラリも削られる。
だからTools APIが削られる事と標準かどうかは関係ない。
674:デフォルトの名無しさん
08/05/26 13:47:38
プロファイルはJREの話だからjavacがないのは元からだ。
toolsAPIはJREのrt.jarに入ってるから削られる。
675:デフォルトの名無しさん
08/05/26 14:18:04
>>674
このスレの主だから。こいつは、なんつーか傲慢で非常にひねくれた性格なのよｗ
確かageたりすると、こいつ、すぐ発狂するからｗｗ
676:デフォルトの名無しさん
08/05/26 14:20:08
＞プロファイルによってはAWT/Swingみたいな標準ライブラリも削られる。
だからTools APIが削られる事と標準かどうかは関係ない。
この「だから」ってのはどうつながっていて、標準ライブラリとTools APIとどういう風に「関係がない」のかちゃんと説明できるの？
偉そうに適当な事ばかり言ってないでさ
677:デフォルトの名無しさん
08/05/26 14:39:12
AWT/Swingが削られるのはヘッドレスプロファイルだろ。サーバーサイド向け。
けどjava2Dの一部ってAWTだよな・・・。
678:デフォルトの名無しさん
08/05/26 14:54:49
headless はマジで助かる。
Ubuntuにheadlessのopenjdkが入って助かった。
でないとサーバ用途なのに、画面周りが必要だったり困りもの。
679:デフォルトの名無しさん
08/05/26 14:59:42
1.4以降なら -Djava.awt.headless=true つけりゃヘッドレスモードになったような。
680:デフォルトの名無しさん
08/05/26 15:00:26
Ubuntuはもうjdk6u10入ってるのか。
新java-pluginって単にJavaFXでブラウザからドッカブルにしたかっただけだよね。
J++が吐いた糞バイトコード食ってブラウザ毎VMおとされる心配がなくなったから良いが。
681:デフォルトの名無しさん
08/05/26 15:09:12
>>679
ん、そうなんだけど、インストール時はdependencyの関係上画面周りの
インストールが必要だったのよ。使わないのに。
682:デフォルトの名無しさん
08/05/27 19:24:21
このスレにもageると発狂する奴がいるのか？
683:デフォルトの名無しさん
08/05/27 20:13:57
研究室も貧乏臭くて真っ暗なんじゃね？図星だろうｗｗ
684:デフォルトの名無しさん
08/05/28 19:35:25
研究室にテロでも仕掛けるのか？
自分でまねいた種だし、いっちょやっつけちゃってよｗｗ
685:デフォルトの名無しさん
08/06/01 16:29:28
研究室にテコを仕掛けてきますた。
見事に釣り合っております。
686:デフォルトの名無しさん
08/06/06 19:12:40
JDK7 build28
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
687:デフォルトの名無しさん
08/06/07 07:16:41
教えて君ですまない。
build28というのはどのくらいの進捗なの？
クロージャやプロパティは使えるようになってますか？
688:デフォルトの名無しさん
08/06/07 08:00:59
> build28というのはどのくらいの進捗なの？
まだまだ。
> クロージャやプロパティは使えるようになってますか？
なってない。
689:デフォルトの名無しさん
08/06/07 08:02:52
>>687
クロージャ使いたかったら URLﾘﾝｸ(www.javac.info) のプロトタイプ使うのが手っ取り早い。
690:デフォルトの名無しさん
08/06/07 12:06:41
>>688-689
ありがとう。それは残念、待ち遠しいですね。
691:デフォルトの名無しさん
08/06/07 14:56:19
別にイラネ
692:デフォルトの名無しさん
08/06/12 16:02:03
多値関数がホスィ
693:デフォルトの名無しさん
08/06/12 17:43:41
俺も思う
配列で実現する
シンタックスシュガーでいいんだけどな・・・
( String a, String b ) = hoge( c);
が書きたいだけなんだ・・・
Object[] hoge(String c){
}
で定義する、でもいいから・・・
694:デフォルトの名無しさん
08/06/12 18:45:55
バグの温床なので諦めて下さい
695:デフォルトの名無しさん
08/06/12 18:59:38
>>694
どの辺がバグの温床？
696:デフォルトの名無しさん
08/06/12 21:14:57
javascriptでもできるようになったんだよな。
var [a, b] = (function (a, b){returen [a, a + b]})(10, 20);
って・・・。
697:デフォルトの名無しさん
08/06/12 22:44:05
多値とオプション値型は、
ヒープを消費しない形で多用したいので、
組み込みで入れて欲しい。
698:デフォルトの名無しさん
08/06/12 23:54:09
>>697
スタック使うのは、何年か前にBugDatabaseでVMの大幅な変更が必要だから却下って言われてたような。
699:デフォルトの名無しさん
08/06/13 00:54:28
VMって、戻り値に複数スタック渡せないんだっけ？
700:デフォルトの名無しさん
08/06/13 07:13:10
無理
701:デフォルトの名無しさん
08/06/13 10:27:13
多値だけは止めてくれ吐き気がする
あれは本当にたちが悪い
702:デフォルトの名無しさん
08/06/13 10:27:38
VMは戻り値指定にひとつの型しか指定できないし、戻り値を返す命令もireturn lreturn freturnみたいな単一の型指定しかできないので、最低限、戻り値指定と複合return命令を追加する必要がある。
703:デフォルトの名無しさん
08/06/13 10:36:46
invokedynamicでも入るんだから何でも入りそう。
704:デフォルトの名無しさん
08/06/13 11:37:27
invokedynamicと戻り値指定変更の影響範囲の違いもわからないのか。
705:デフォルトの名無しさん
08/06/13 11:51:59
実行時にはa,i,l,f,d,voidしか区別する必要ないんだから、
結構簡単なんじゃないの?
706:デフォルトの名無しさん
08/06/13 12:30:28
じゃあおまえがプロトタイプを作って見せてくれ
707:デフォルトの名無しさん
08/06/13 12:45:29
コンパイラの方も多値は基本的に代入だけだしね。
708:デフォルトの名無しさん
08/06/13 13:06:16
いや、だから、コンパイラが返値をObject[] に変えてくれればいいんですお。
配列の返値はOKですよね？
709:デフォルトの名無しさん
08/06/13 13:12:01
オプション型は、論理型への暗黙の変換か、
match case文がないとダサダサだね。
Javaには入りづらいだろうね。
710:デフォルトの名無しさん
08/06/13 13:30:19
>>705
戻り値の数と組み合わせの管理が必要になるだろ。
711:デフォルトの名無しさん
08/06/13 13:35:23
引数の参照渡しと多値関数どちらかとれといわれたらどっちがいい？
712:デフォルトの名無しさん
08/06/13 13:38:09
どっちもイラネ。
case節で指定できる型を増やしてくれ
713:デフォルトの名無しさん
08/06/13 13:38:22
>>710
それはコンパイル時に終わらないかな?
*loadのスロット参照すればいいから。
714:デフォルトの名無しさん
08/06/13 13:58:13
> *loadのスロット参照すればいいから。
バイトコードベリファイア書き換えないと無理ね。
変更後のバイトコードベリファイアに脆弱性ないかを調べるの面倒だし。
あと、スタックフレームが連続してる保障ないはずだから、
*loadでやるのが可能なのかも疑問だったりする。
715:デフォルトの名無しさん
08/06/13 14:53:31
>>714
連続してなくても＊loadで参照できればいいんじゃないのかな。
コンパイル時にフレームサイズもindexも決まるわけだし。
ベリファイア書き換えはちょっと面倒だね。
invokedynamicみたいな基本ポリシーy面での変更はないけれど。
716:デフォルトの名無しさん
08/06/13 15:08:26
> 連続してなくても＊loadで参照でき
るようにするためには、VMの書き換えが必要になるわけで。
717:デフォルトの名無しさん
08/06/13 15:41:36
というか基本的にフレーム内は連続してる前提でしょ。
もちろん実装に任されているけれど。
多値だって個数はスタティックに決まるんだからフレーム内におさめられるし。
>>714は何が疑問なんだろ。
718:デフォルトの名無しさん
08/06/13 15:44:58
>>717
VM仕様で、異なるメソッドでフレームが連続していなければならないって記述してある箇所あんの？
719:デフォルトの名無しさん
08/06/13 16:01:11
>>718
*returnしたものが、*storeなどで参照できるってことだけだね。
多値が追加されたとしても、その辺の抽象的なVMの定義は変らないのでは。
720:デフォルトの名無しさん
08/06/13 16:02:24
> 3.6 Frames
> A frame ceases to be current if its method invokes another method or if its method completes.
> When a method is invoked, a new frame is created and becomes current when control transfers to the new method.
> On method return, the current frame passes back the result of its method invocation, if any, to the previous frame.
> The current frame is then discarded as the previous frame becomes the current one.
あたりを読むと、モデルとしては完全に分離してるように見えるが。
721:デフォルトの名無しさん
08/06/13 16:03:36
>>708
Arrayだとdoubleとか入れるの困るじゃん
722:デフォルトの名無しさん
08/06/13 16:09:55
>>719
*return した値ってオペランドスタックに置かれるんじゃなかったっけ？
ローカル変数領域だったっけか？
723:デフォルトの名無しさん
08/06/13 16:23:43
>>721
java.lang.Doubleにboxingすりゃいいのでは？
>>693みたいな構文糖でいいって場合は配列生成するんだろうし
コストはあんまし重要視してないんじゃないかと。
724:デフォルトの名無しさん
08/06/13 16:31:45
>>693
> Object[] hoge(String c){
> }
> で定義する、でもいいから・・・
これはありえんだろ。型弱すぎw
725:デフォルトの名無しさん
08/06/13 16:35:48
型の話でいうなら変換前の言語の時点での問題だろ。問題にならんと思うが。
726:デフォルトの名無しさん
08/06/13 17:07:14
Object[]よりも無名クラスのオブジェクトの方が向いてるんじゃないの。
ボクシングの問題とか。
727:デフォルトの名無しさん
08/06/13 17:18:16
裏側でクラス作るくらいなら、Object[]でいいと思う
そんな謎のpublicなクラス作られると気持ち悪い。
728:デフォルトの名無しさん
08/06/13 19:54:19
本当に構文糖にできるなら、Object[]の部分は何かで書き換えられると思う。
で、Genericsのようにチェックはコンパイル時ってことでいいんじゃないかな？
729:デフォルトの名無しさん
08/06/13 20:45:07
>>701
そこにタッチ
730:デフォルトの名無しさん
08/06/13 21:07:15
>>712
それは思うなぁー
確か7でStringのswitchができるようになるとかいう噂もあったよな
あれは是非お願いしたい。
731:デフォルトの名無しさん
08/06/13 22:21:24
最近Scala触ってるんだけど、正直Javaの拡張はもういらない気がしてきた。
欲しいなと思ってたものが殆ど揃ってる。
732:デフォルトの名無しさん
08/06/13 22:38:47
JavaよりJVMの方だな、もっとよくなってほしいのは。
733:デフォルトの名無しさん
08/06/14 04:51:09
Java仮想マシンの仮想化機能: Multi-Tasking
URLﾘﾝｸ(www.shudo.net)
Javaのメモリ消費問題の解決を目指すSunのプロジェクト「MVM」
URLﾘﾝｸ(www.itmedia.co.jp)
ついにベールを脱いだ米SunのリアルタイムJava
URLﾘﾝｸ(journal.mycom.co.jp)
NASDAQも採用進めるリアルタイムJava
URLﾘﾝｸ(japan.zdnet.com)
Java SEのJVMにマルチタスキング機能とリアルタイム機能が盛り込まれたら
用途がもっと広がると思います。
SUNは自分の商売に使いたいから提供しないのでしょうけど、
コミュニティが独自に開発しないのは何か事情があるのでしょうか？
734:デフォルトの名無しさん
08/06/14 09:46:14
どの会社も独自に頑張ってるよ。特にJ2ME。
735:デフォルトの名無しさん
08/06/17 01:25:43
MVMはJNIがある限り厳しいという話をこのスレで読んだような・・・
736:デフォルトの名無しさん
08/06/17 03:53:10
>>735
JNI必要な応用ばかりじゃないし、
MVMの基準に合致するJNIの制約を作ることも可能。
737:デフォルトの名無しさん
08/06/17 10:42:44
MVMのJVMとノーマルのJVMを別物と思えばいいような気がするなぁ。
MVMに乗せるアプリは一定基準を守る事って。
Appletだってそうなんだから。
738:デフォルトの名無しさん
08/06/18 10:54:58
タプルは使ったことないからいまいち、どのあたりが有用なのか分からない。
Object[]で簡易的にやりたくないなら、
class タプル内部クラス
String a,b;
でいいんじゃないの？これや[]を超える有用なのところがなにかあるのかな。
739:デフォルトの名無しさん
08/06/18 16:02:15
何で突然タプルの話なの?
740:デフォルトの名無しさん
08/06/18 17:45:39
>>738
端的に2つ言うと、
・別にタプルとしてまとめて扱いたい訳じゃない
・見やすいから使いたい
です。
741:デフォルトの名無しさん
08/06/24 18:54:00
invokedynamicは命令ひとつ追加するだけっていう単純なものじゃないんだな。
742:デフォルトの名無しさん
08/06/26 01:14:36
publicなfieldにするのにObject[]なんかできんし、
ただ組を表現するのにclass定義とか面倒すぎる
743:デフォルトの名無しさん
08/06/26 04:34:06
Map.Entryでえぇやん
744:デフォルトの名無しさん
08/06/27 12:20:21
JDK7 build29
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
745:デフォルトの名無しさん
08/07/04 08:59:42
JDK7 build30
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
746:デフォルトの名無しさん
08/07/09 00:37:03
＝ ＝ ＝ 寄生虫一家のだんらん ＝ ＝ ＝
パパ「どうだ〜 大画面のプラズマテレビはスゴいだろ〜〜」
ガキ「スゴいね〜 パパ！ これもパパがいつも言ってる愚民からのお金で
買ったの？」
ママ「パパはね、世間がどうなってもたぁ〜くさんお金が貰えるし
ボーナスで毎年プラズマテレビと車も買えるんだからぁ〜〜」
パパ「しかし最近はさぁ〜 マイッタよ、職場が禁煙になっちゃってさぁ〜
なにしろ30分おきに入り口の外までタバコ吸いにいかなきゃならない
んだからなぁ〜、ヘタにそのまま遊びに行くとどこでオンブズマンとか
いう輩が見てるか解らんからなぁ」
ママ「ほんとにあの連中はウジ虫よね！ 自分がなれなかったからって
人の幸せをねたんで」
パパ「まぁ、うちはおじいちゃんの代から公務員だからな、チョロい1次試験
さえクリアすれば2次の面接なんて特攻服で行ったって満点合格なんだ
よ、ハ〜ッハッハッ！」
ママ「ボクもね、大きくなったら公務員になるのよ、一生遊んで暮らせるん
だから〜〜」
ガキ「ウン、ママ！ ボクも公務員になるよ。 ところでさぁ、今年もまた
あのタダの保養所に遊びに行くんでしょ？」
ママ「ママねぇ〜 あそこ飽きちゃったのよ、休みはいくらでもあるんだから
今年はパリにでも行ってお買い物したいわぁ〜〜」
パパ「そうだな〜〜ぁ カラ出勤と合わせれば1ヶ月は軽いしな
よ〜〜し、今年の夏はいっちょう行くかぁ〜〜 ハァ〜、ハッハッハ」
ガキ「ワ〜イ ワ〜イ」
747:デフォルトの名無しさん
08/07/10 03:18:08
>>693
そこでなぜObject[]をGenericsで表現しないのか
748:デフォルトの名無しさん
08/07/10 03:18:51
>>730
C#と同じノリでいくか。
enumで出来れば十分だろ
749:デフォルトの名無しさん
08/07/10 22:55:31
>>747
複数の返値が型が違う場合を考えて。
750:デフォルトの名無しさん
08/07/10 23:12:29
>>749
それはT=objectで対処可能。
751:デフォルトの名無しさん
08/07/10 23:34:21
>>750
いや、・・・何かGenericsを勘違いしていないか・・・？
752:デフォルトの名無しさん
08/07/11 05:27:30
>>749
戻り値が違う場合？
俺の場合はその戻り値の型を同行する前に
自分で型を作って、二つの型に共通するスーパークラスを
作るにふさわしいかどうかを考えるがな。
そうはいかないときもあるが、そういうときは
根本的に設計上の問題があると考えられる。
デザインパターンを考慮するときはとくに。
753:デフォルトの名無しさん
08/07/20 00:18:11
JDK7 build31
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
754:デフォルトの名無しさん
08/07/21 16:51:54
>>752
(String , Map)
こんな二つの結果が帰ってくるときなら、Superclassも何も無いと思うが・・・
755:デフォルトの名無しさん
08/07/22 21:55:05
TextSS
756:デフォルトの名無しさん
08/07/23 07:28:02
URLﾘﾝｸ(mail.openjdk.java.net)
> Closures and XML support in Java 7 are unlikely.
だってよ、どーするよ。
757:デフォルトの名無しさん
08/07/23 08:28:01
んん？
unlikelyって・・・見込みがないってこと？
758:デフォルトの名無しさん
08/07/23 09:03:58
実装するのは思いのほか大変だってこと。
759:デフォルトの名無しさん
08/07/23 09:17:18
>>758
実装は URLﾘﾝｸ(www.javac.info) から取ってこれるが。
どっちかっつーと技術的な問題じゃなくて政治的な問題でしょ。
google も URLﾘﾝｸ(www.javac.info) みたいに及び腰だし。
760:デフォルトの名無しさん
08/07/23 09:48:43
実装という書き方が悪かったね。
今までのJava(Cの延長）からすればたいぶ異質なパラダイムを入れるのに抵抗があるので、思いのほか大変って意味。
761:デフォルトの名無しさん
08/07/23 09:57:18
そういうことかー
英語弱いんで助かりました。
762:デフォルトの名無しさん
08/07/23 09:58:55
>>760
パラダイムとか関係ないでしょ。
Javaにclosure入れるっていう根本方針に反対な人が多数派ってんならともかく。
763:デフォルトの名無しさん
08/07/23 10:00:18
> Java 7 itself is starting to seem unlikely ;-)
orz
764:デフォルトの名無しさん
08/07/23 10:05:11
genericsの時もやたらと遅れたし大規模に言語変更するときはJSRみたいな委員会型の組織だと動き鈍くて大変だよね
765:デフォルトの名無しさん
08/07/23 10:07:56
ぽんぽん尻軽に大規模な言語変更されても困るからしかたない
766:デフォルトの名無しさん
08/07/23 10:14:55
小規模な言語変更だとぽんぽん尻軽にやっちゃうんだけどね。
assert とか勝手に予約語に追加しやがるし。
767:デフォルトの名無しさん
08/07/23 12:43:43
assertが予約語で何か不満でもあるのか？
768:デフォルトの名無しさん
08/07/23 12:55:23
>>767
JUnitで使われてた assert って名前のメソッドが改名させられたのは有名な話。
enum って変数名使ってて泣いた奴も案外多かったりして。
769:デフォルトの名無しさん
08/07/23 13:33:48
それならC#の方が凄いんじゃないの？
770:デフォルトの名無しさん
08/07/23 13:38:08
enumは多かったな
771:デフォルトの名無しさん
08/07/23 13:40:21
>>768
ﾉｼ
772:デフォルトの名無しさん
08/07/23 15:00:16
>>755
URLﾘﾝｸ(www.vector.co.jp)
773:デフォルトの名無しさん
08/07/23 15:36:24
>>759
googleは時期尚早としか書いてないけど、
> To arrive at the best solution, Google is open to multiple parallel investigations
> but is not currently prepared to commit to any particular proposal.
というのは、もしかしたら、data parallelがやりやすいかどうか、
良く確認してから決めたいと考えているのかな。
774:デフォルトの名無しさん
08/07/23 19:41:05
>>773
BGGA の初版から 2年、BGGA のver 5出てからもう 1年近くたってるし
未だに時期尚早ってのはなぁ……
Java7 から漏れるそうなのも、jsr166 に closure っつーか
function type 入れたくないよって事なんじゃねーかと邪推したくなる。
doug lea は function type 入れない CICE の提案者の一人だしなぁ。
775:デフォルトの名無しさん
08/07/24 00:08:41
さっさとScalaに移行しようぜ。Javaなんて、使ってられなくなるよ。
776:デフォルトの名無しさん
08/07/24 00:26:39
グルービーはもう廃れちゃったの？
777:デフォルトの名無しさん
08/07/24 00:27:15
あらま。delegate感覚で使えると期待してたのに。
まぁListenerの代替として使いたいって程度だから、
Swing Application Frameworkがあれば十分だけど。
代わりといっちゃなんだがOGNL式の静的チェック機能とか欲しい。
778:デフォルトの名無しさん
08/07/24 05:41:11
なんだこいつ？
779:デフォルトの名無しさん
08/07/24 08:01:33
>>777
その辺は JSR-305 さえ入ってくれれば
@Language("OGNL") とかできるようになるんじゃねーかと思うけど……
780:デフォルトの名無しさん
08/07/27 02:53:17
781:デフォルトの名無しさん
08/07/28 00:10:23
jakartaのなかから標準APIに取り込んで欲しいのは？
782:デフォルトの名無しさん
08/07/28 00:22:28
ない
783:デフォルトの名無しさん
08/07/28 00:28:42
俺もないなあ
標準APIは太りすぎだろ
784:デフォルトの名無しさん
08/07/29 16:07:43
EEやSEに突っ込んだら勝ちって競争になりつつあるからね。
土方プログラマ方面では標準化して統一してほしいだろうし。
785:デフォルトの名無しさん
08/07/29 16:24:35
いくら標準化しても、おまえじゃ使えないだろうな。おまえが使えるようになった頃には既に誰も使ってないだろうしw
786:デフォルトの名無しさん
08/07/29 17:15:22
jakarta、generics対応してないの多いからな
JDK1.3くらいのときはありがたかったものも今では必要ないとかかなりあるからね
787:デフォルトの名無しさん
08/07/29 17:35:02
正直、言語面の変化しか注目してない。
後は自分の使いたいクラスライブラリ使う。
788:デフォルトの名無しさん
08/07/29 17:44:27
JSR-203 の試験版。
URLﾘﾝｸ(download.java.net)
しっかし、これ
pfav.setOwner(fs.getUserPrincipalLookupService().lookupPrincipalByName("hoge"));
とか横に長すぎなんですが……
commons-nio が必要になる予感
789:デフォルトの名無しさん
08/07/29 17:49:12
メソッド名長くしすぎると、
Jakarta Commons VFSに負けちゃうかも…
>>774
CICEはクラス中心的でJavaっぽくていいんだけど、
これだけじゃ物足りないね。
790:デフォルトの名無しさん
08/07/29 17:52:12
それからDoug Lea先生は、JSR-166との絡みで、
control abstractionにまいっちゃってる可能性が…
そうするとBGGA, FCMに吸い寄せられるような
791:デフォルトの名無しさん
08/07/29 19:23:49
>>788
生APIってのはそんなもん
だからみんなファサード大量に容易するわけだ
生APIの場合は出来ないことが存在することがまずいわけで
多少のインターフェースの悪さは無視するのが普通かと
792:デフォルトの名無しさん
08/07/29 19:50:04
>>791
>>788 の例は、出来る出来ないの話じゃなくて、どっちかっつーとクラス構造(?)の話かな。
UserPrincipal extends java.security.Principal 使う必要があるんか？って話。
setOwner(String) でいいじゃんって思うんだけど。String じゃダメな理由あるんかな？
793:デフォルトの名無しさん
08/07/29 22:05:32
極端に言えば、BGGA以外は匿名クラスとあまり差はないし、ならクロージャいらないとの議論になりかねない。
BGGA自体も、関数言語指向の方向性は自然な姿だけど、controlのあれはビックリしたけどね。
なんだかんだ言ってサポートされるからブログとか追いかけて気にし過ぎだなｗ
794:デフォルトの名無しさん
08/07/30 00:15:33
>>793
ネストしたときのわけわからなさは異常
1つのメソッドのみのインターフェースを書くのがだるい人向けかな
業務系だと型そのものが大事ではなくてインターフェース名そのものが大事だから
あんまり使われないと思う
795:デフォルトの名無しさん
08/07/30 00:37:34
総称型はコンパイラ時の型安全のつもりだろうけど、インターフェイスの引数で使うとまったく違った使い方ができるし、
クロージャも同じように使ってるうちに全く想定外の使い方がでてくるんじゃないの。
interface Inte <T extends java.lang.Number>
{
int compareTo(T obj);
}
Inte<BigDecimal>だとobj.subtract(this)とかできる。
796:デフォルトの名無しさん
08/07/30 01:22:10
>>795
日本語でもうちょっとわかりやすく
797:デフォルトの名無しさん
08/07/30 01:33:57
言ってることはわかる気がするが
それなんか意味あるの？
798:デフォルトの名無しさん
08/07/30 02:18:49
>>784
> 土方プログラマ
が エア プログラマ にみえたので眼鏡を新調してくる。
799:デフォルトの名無しさん
08/07/30 05:00:44
>>798
おまえのそのメガネは高く売れる。
800:デフォルトの名無しさん
08/07/30 05:12:58
>エア プログラマ にみえた
正解です
801:デフォルトの名無しさん
08/07/30 09:18:27
>>788
これ java.nio.file.Path がディレクトリか調べるのに旧I/O使わないと
path.getFileAttributeView(BasicFileAttributeView.class, true).readAttributes().isDirectory()
とかする必要あるんですが……
旧I/O使うと new File(path.toUri()).isDirectory() で済むけど
旧I/Oだと java.io.File#getPath() で帰ってくるのが java.nio.file.Path っぽいけど、
実は String だとか名前の統一性なくなるからあんまし混ぜたくないんだよなぁ
802:デフォルトの名無しさん
08/07/30 12:00:59
こんなん見つけた。
URLﾘﾝｸ(blogs.sun.com)
module を言語全体のキーワードでなく文脈依存のローカルキーワードにしたいんだけど、例えば
class classname { module classname(){ throw new Error(); } }
って宣言があった場合、module型を返すメソッドなのか
module privateなコンストラクタなのか判別付かなくて悩ましいというお話。
互換性だけを考えると module型を返すメソッドにするべきなんだろうけど……
803:デフォルトの名無しさん
08/07/30 14:08:05
>>796
おまえの知能を疑うが、どこを日本語にして分かりやすくして欲しいんだ？
804:デフォルトの名無しさん
08/07/30 15:34:07
>>803
>>795のどこが不思議な使い方なんだ?
805:デフォルトの名無しさん
08/07/30 15:52:28
つ >>795にとって不思議
806:デフォルトの名無しさん
08/07/30 18:02:10
>>804-805
お前らの頭の中は不思議でいっぱい
807:デフォルトの名無しさん
08/07/30 18:42:40
>>768
あれは面倒くさかった。
ぜんぶassert()メソッドをassertEquals()やassertNotTrue
とかに変更する羽目になった
808:デフォルトの名無しさん
08/07/30 18:44:49
>>781
Log4jかな。あれを標準化したロギングAPIと統合して欲しい。
ライブラリ依存関係で混乱するから。
Commons Math、Commons Collections、Commons Configurations
も標準APIにいれて欲しい
809:デフォルトの名無しさん
08/07/30 18:48:12
>>786
CollectionsのGenerics対応はまだまだ遅いよな。
別ライブラリとしてGenerics対応されたやつがあるだけで
まだまだ時間かかりすぎる。
810:デフォルトの名無しさん
08/07/30 18:53:19
マ版でやってくれないか？
811:デフォルトの名無しさん
08/07/30 19:03:07
この話題はマ板じゃねぇだろ
812:デフォルトの名無しさん
08/07/30 19:44:09
>>802
単純型名で module型が使える場合は module型を返すメソッド、
そうでなければ module privateなコンストラクタってのはダメなんかね？
module型使ってる場合は module privateなコンストラクタを一切使えなくなるけど、
それはmodule privateな静的ファクトリメソッド使うなりして我慢してもらう方向で。
813:デフォルトの名無しさん
08/07/30 20:52:30
>>811
いや。十分にマ版ネタだと思うが。
814:デフォルトの名無しさん
08/07/30 21:04:53
moduleか
package名前空間使って
public package FacadePackage {
public class FacadeClass {
}
private class SomeClass {
}
private package SomePackage {
private class SomeClassB {
}
}
}
んなFacadeなパッケージを作れないだろうか。
UMLで登場したことがある「Facadeに相当するパッケージ」を
作れないかと期待。
今まではクラスレベルでしかできなかったことがパッケージレベルでも
出来ればと期待。
815:デフォルトの名無しさん
08/07/30 21:05:42
>>813
キーワードが増えてこまったこととか、CollectionsのGenerics対応とか、技術ネタだろ。マ板にもっていく必要性がわかんない。
816:デフォルトの名無しさん
08/07/30 21:51:13
技術ネタなんじゃなくて、おまえの愚痴でしかないようだが？
817:デフォルトの名無しさん
08/07/30 21:59:29
ネタとして次世代Javaではなさそうだが。
818:デフォルトの名無しさん
08/07/30 22:02:04
>>816
まぁ、落ち着けよ。
宿題やったか？早いうちに終わらせとけよ。
819:デフォルトの名無しさん
08/07/30 22:15:07
>>814
module で export package 指定できりゃそれで良いんじゃ？
820:デフォルトの名無しさん
08/07/31 00:52:21
>>818
早く死ねよ
821:デフォルトの名無しさん
08/07/31 01:48:01
>>819
それはC/C++のヘッダファイルと同じ運命を辿らないか？
できればimport宣言はそのクラス内ですませたい
822:デフォルトの名無しさん
08/07/31 03:08:13
>>818
ITドカタは来えろ
823:デフォルトの名無しさん
08/07/31 08:22:28
>>821
> それはC/C++のヘッダファイルと同じ運命を辿らないか？
ってどーゆー事？
「export うんたら」 はモジュール外から使えるクラス「うんたら」だけに制限する。
>>814 みたいな事は OSGi の Export-Package 使えばできるんじゃね？って思うんだが。
JSR-277 はそこんとこはクラス単位みたいだけど
それを パッケージ単位でもできるようにすれば良いだけのよーな。
824:デフォルトの名無しさん
08/07/31 10:03:56
>>801
Attributes.getBasicFileAttributes(path, true).isDirectory() までは短くなるな。
十分長いよーな気もするけど。
new File(path.toUri()).isDirectory() に比べても、まだ長いし。
825:デフォルトの名無しさん
08/07/31 10:12:33
>>812
そんな事するぐらいなら module を言語全体に影響するキーワードにした方がすっきりせんか？
変数名とかフィールド名にmoduleって名前使ってる人には泣いてもらう事になるけど。
826:デフォルトの名無しさん
08/07/31 11:51:29
SunにはJavaのコードからexeバイナリを生成するコンパイラの開発をしようという計画は無いんですかね
VM作ってるぐらいだからやる気になればそう難しくなさそうですが
本末転倒かな便利だと思うけど
827:デフォルトの名無しさん
08/07/31 11:59:58
>>826
スレ違いのレベルも下がったな。夏休みか。gcjでも食ってろ蛸。
828:デフォルトの名無しさん
08/07/31 12:13:47
>>826
スレ違いのレベルも下がったな。夏休みか。Visual J#でも食ってろ蛸。
829:デフォルトの名無しさん
08/07/31 12:47:13
粘着はそろそろ消えてくれないか
830:デフォルトの名無しさん
08/07/31 12:49:15
>>825
影響範囲がでかすぎる。
assertのときほどJavaはマイナーではないし、enumほどみんなに使われるわけでもない。
ほとんどの人が直接使わないのにキーワードにされたら、そりゃ怒るだろね。
831:デフォルトの名無しさん
08/07/31 13:05:12
>>830
moduleって名前使ってない人は怒らないから大丈夫。
それに列挙型よりはモジュール機能の方が使用頻度高いと思うが。
言語仕様汚れる方が将来の言語拡張の妨げになるから嫌って人も多いし。
832:デフォルトの名無しさん
08/07/31 13:09:29
>>802
そこに 2つ目の案として
class classname { module classname(){ throw new Error(); } }
はmodule privateなコンストラクタで、package privateなmodule型を返すメソッドは
class classname { package module classname(){ throw new Error(); } }
にしろって案が出てるけど、これも結構汚いよなぁ。
現実的ともいえるけど。
833:デフォルトの名無しさん
08/07/31 13:26:23
>>827
使いものになんねーだろあれ
834:デフォルトの名無しさん
08/07/31 14:11:32
gcjはclasspath使って書き換えるからそれが完了すれば5.0までいけるんだけどな。
835:デフォルトの名無しさん
08/07/31 14:52:33
もうウザイし、誰か相手してやれよ。
836:デフォルトの名無しさん
08/07/31 15:58:31
>>831
言ってることが良く分からないんだけど、どの言語仕様が汚くなるの？
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5384日前に更新/204 KB
担当:undef