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
言ってることが良く分からないんだけど、どの言語仕様が汚くなるの？
837:デフォルトの名無しさん
08/07/31 16:56:07
>>836
全体にキーワード適用した方が言語仕様が単純に保てて汚れずに済むって話。
>>812みたいな小細工が汚れそのもの。
838:デフォルトの名無しさん
08/07/31 16:57:51
>>831
今後の言語拡張だけじゃなくてコンパイラの単純さ健全さバグの少なさにも影響してくるし。
839:デフォルトの名無しさん
08/07/31 19:27:08
はあ？
840:デフォルトの名無しさん
08/07/31 19:48:45
>>837-838
抽象的で分からないんだけど、もうちょっと具体的に技術的な話は出来ないの？
841:デフォルトの名無しさん
08/07/31 22:33:06
>>840
お前、このスレ来るのまだ早いよ。
842:デフォルトの名無しさん
08/07/31 22:40:07
↑頭おかしいだろ？早く病院行ったほうがいいぞ
843:デフォルトの名無しさん
08/07/31 23:34:18
>>840
言語仕様に追加する場合考えてみ？
全体キーワードなら 3.9 Keywords に module 加えればいいだけ。
>>812 をやろうとすると、大量に書き換えが必要になる。
844:デフォルトの名無しさん
08/08/02 17:57:54
>>843
もう全体キーワードの追加は認められないだろね。
moduleなんてパッケージ名はどこにでもありそうだし。
言語処理側ががんばればいいのなら、それでやるべきだと思う。
845:デフォルトの名無しさん
08/08/02 19:36:50
いっそのことmojuleとかにしちゃえばいいのに
846:デフォルトの名無しさん
08/08/02 19:53:09
ところで、module って本当に jdk7に間に合うのか？
OSGi との互換性とか整合性とかどーすんだろね？
なんつーか >>763 の予感が……
847:デフォルトの名無しさん
08/08/02 22:25:45
>>845
それなんてCloneable？
848:デフォルトの名無しさん
08/08/02 23:17:36
そろそろC＃が巻き返してくるんじゃないのか？
849:デフォルトの名無しさん
08/08/03 01:27:02
意味がわからん
850:デフォルトの名無しさん
08/08/03 01:35:26
確かにC#の方が儲かる罠
851:デフォルトの名無しさん
08/08/03 02:35:05
Scalaでえぇよ
852:デフォルトの名無しさん
08/08/03 03:07:57
>>850-851
スレ違い
853:デフォルトの名無しさん
08/08/03 03:25:49
>>848-849
スレ違い
854:デフォルトの名無しさん
08/08/03 04:14:44
>852-853
スレ違い
855:デフォルトの名無しさん
08/08/03 05:46:06
せっかく期待したのにお流れになった機能とかは、MSのやつなら使えるからジャヴァには期待してない。けっきょくジャヴァ使っててもWindowｓしか使わないしｗ
856:デフォルトの名無しさん
08/08/03 07:20:31
ジャヴァとか馬鹿じゃね？
857:デフォルトの名無しさん
08/08/03 07:28:50
確かに今はバカかも試練が、7が出ればそうも言ってられなくなる。
そう思いたい。
858:デフォルトの名無しさん
08/08/03 08:08:30
age厨は意味取り違えるのが好きらしい
859:デフォルトの名無しさん
08/08/03 11:18:41
そのようだ
夏だからしょうがないか
860:デフォルトの名無しさん
08/08/03 14:00:57
どこも夏だな
861:デフォルトの名無しさん
08/08/03 14:23:47
ジャヴァ ジャヴァ
862:デフォルトの名無しさん
08/08/03 16:32:20
kusosure
863:デフォルトの名無しさん
08/08/03 17:20:09
moduleは導入されるけど、closureは無理だろうな。
英語のページだと悲観的見解が多い。
やっぱりいつまでも指をくわえて待ってないで、C#とか既にあるのを使えばいいんじゃないか。C#は使ったことないけど・・
864:デフォルトの名無しさん
08/08/03 17:30:44
> 英語のページだと悲観的見解が多い。
どこ？
865:デフォルトの名無しさん
08/08/03 17:33:42
そーいや closureのプロトタイプが nonlocal return サポートしたってさ。
break と continue は、また今度らしい。
URLﾘﾝｸ(mail.openjdk.java.net)
866:デフォルトの名無しさん
08/08/03 17:47:20
>>865
nonlocal return すると例外吐いてコンパイラ落ちるんだが。
>>788 の NIO2のEA版じゃなくて、正規のjdk1.7使わんと駄目なんだろうか？
867:デフォルトの名無しさん
08/08/05 10:14:55
break と continue も来たってさ。
これで今のところ予定してる機能はコンプリートしたらしい。
URLﾘﾝｸ(mail.openjdk.java.net)
>>866
今回のは >>788 の NIO2のEA版でも大丈夫だったぞ。
868:デフォルトの名無しさん
08/08/05 12:39:28
XMLリテラルって何でなくなっちゃったの？
869:デフォルトの名無しさん
08/08/05 16:05:52
>>867
www.javac.info つながらなくね？
870:デフォルトの名無しさん
08/08/05 19:52:57
7というのが、Windows7 か Java7かは謎だな。
871:デフォルトの名無しさん
08/08/08 03:53:55
>>868
おまえが馬鹿だからじゃね？
872:デフォルトの名無しさん
08/08/09 05:22:27
ゴチャゴチャしているようだけど、使ってみるとC#結構いいよ。癖になりそう
873:デフォルトの名無しさん
08/08/09 10:02:24
夏だなぁ。
874:デフォルトの名無しさん
08/08/09 10:29:07
>>872
スレ違いなんだよアホ
875:デフォルトの名無しさん
08/08/09 12:33:00
やっぱりscalarじゃね？
876:デフォルトの名無しさん
08/08/09 13:04:31
package単位でFacadeパターンを実現する手法ができるとは限らないのか
877:デフォルトの名無しさん
08/08/10 00:24:57
>>874
C++すらも使いこなせないんですか？
878:デフォルトの名無しさん
08/08/10 02:00:13
>>877
またお前か・・・
879:デフォルトの名無しさん
08/08/10 02:15:14
>>878
だれのことだよｗ
880:デフォルトの名無しさん
08/08/10 02:16:53
お前だよw
881:デフォルトの名無しさん
08/08/10 02:45:48
C++ぐらいは使えこなせるけど何か？
882:デフォルトの名無しさん
08/08/10 03:28:36
>>878-880
こういう奴はよく沸いてくるんだけど、どこかの糞溜めに消えてくれないか？
883:デフォルトの名無しさん
08/08/10 09:17:41
夏だな・・・
884:デフォルトの名無しさん
08/08/10 09:20:26
もとから糞の奴はどこに行けばいいんだよ！
885:デフォルトの名無しさん
08/08/10 13:03:51
Java Module SystemはRPMと同等だとみなしてもいいよね？
886:デフォルトの名無しさん
08/08/10 14:06:44
かってにみなせば？
887:デフォルトの名無しさん
08/08/10 16:34:31
>>885
レイヤーからして違う。
888:デフォルトの名無しさん
08/08/10 17:17:13
JavaでもC++でも、どうせ俺たちはIT土方じゃね？
889:デフォルトの名無しさん
08/08/10 21:55:32
もういいよ。土方がそんなに嫌なのか？
経営者以外は土方みたいなもんだ。
自分のやることにちったー誇りもてよ？
890:デフォルトの名無しさん
08/08/10 23:47:00
マ板で話題にすることだね。
そっちでならスレを指定すれば
話に加わってもいいよ。
ここではマ板な話はスルー。
>>865
RPMよりyumのように扱えれば便利だよね。
それもMavenですでに実現しているかな？
891:デフォルトの名無しさん
08/08/11 01:18:14
ちぇ、ツマンネー奴らだな。
経営者なんて、外じゃペコペコ頭下げて、無理な要求持ってきて迷惑なだけじゃん。
人として感情をもってないペコちゃん人形と同じだな。
892:デフォルトの名無しさん
08/08/11 02:37:05
>>891
これは・・・
893:デフォルトの名無しさん
08/08/11 04:01:45
マ版の奴らと同じように本当のところは経営者もしんどいんですよ・・・
894:デフォルトの名無しさん
08/08/11 04:24:58
夏真っ盛りだな・・・眠すぎる
895:デフォルトの名無しさん
08/08/11 07:49:00
どっちにせよマ板の話題
丁度いいスレがあったから紹介しておくよ
ITﾍﾞﾝﾁｬｰ経営者だがそろそろ畳もうと思う
ｽﾚﾘﾝｸ(prog板)
896:デフォルトの名無しさん
08/08/11 09:33:15
経営者は常に最新のものに敏感でいなければならないため、次世代スレに興味あるんですが何か問題でも？
897:デフォルトの名無しさん
08/08/11 10:40:01
そのスレ違いの発言が問題。
898:デフォルトの名無しさん
08/08/11 12:04:24
くそすれ
899:デフォルトの名無しさん
08/08/11 12:43:35
またお前なのかよ
900:デフォルトの名無しさん
08/08/12 00:53:15
それで、クロージャ実装の使い心地はどうよ？
901:デフォルトの名無しさん
08/08/15 02:59:03
クロージャさえあればcatch節でclose()忘れを防ぐことができる
ギャグが現実化すればのう
902:デフォルトの名無しさん
08/08/17 11:48:43
JDK7 build33
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)
903:デフォルトの名無しさん
08/08/28 22:27:20
クロージャどう見ても糞だろ？
なんだよあの関数型w
宣言とか仮引数にいちいちあんなの書いてられるか
インタフェースへのキャストも糞仕様としか思えない
メソッド定義が一つの時だけできるとかまともな設計センスじゃないだろ
904:デフォルトの名無しさん
08/08/28 22:32:38
メソッド定義が一つの時だけできるとか、嘘つくなよ
まずは仕様をちゃんと読め。それから。
905:デフォルトの名無しさん
08/08/28 22:50:09
>>904
ちょっと誤解してたわ
引数が同じものがあったらダメってことか
どっちにしても分かりにくい上にわざわざこんなことしてまで使いたくないな
906:デフォルトの名無しさん
08/08/28 22:55:18
Javaはもうこのままでいいよ。
他の言語のプラットフォームとしてがんばってくれれば。
俺はScalaに逝く。
907:デフォルトの名無しさん
08/08/28 22:59:08
Javaはまだカオスを十分に溜め込んだとはいえないからなぁ
言語仕様そのものはシンプルだし、GenericsやAnnotationの類が
もう２，３種増えないとリファクタリングの効果が薄い気がする。
908:デフォルトの名無しさん
08/08/28 23:01:20
なんでこんな仕様にしちまったもんやら
素直にfunction予約語かなんか導入して
function F(int i, int s);
F f = { int x, int y => x +y };
f(10, 20);
とか
function F(int i, int s) { x +y }
F f = new F();
f(10, 20);
にできなかったのか？
909:デフォルトの名無しさん
08/08/28 23:04:55
それありだわー
単純でいいなぁ
910:デフォルトの名無しさん
08/08/28 23:13:59
それ、typedefした関数ポインタと同じじゃないの？
とっくに議論尽くされて今の仕様まで来たんだけ、全然知らないくせに横から口出すなよ。
おまえはscla使ってれ。たいした差はないと思うけどなｗ
911:デフォルトの名無しさん
08/08/28 23:16:57
function F(int i, int s) { x +y }
F f = new F();
f(10, 20);
これなんか、クラス宣言をちょっとだけ省略した普通の関数（クラス）の宣言じゃんｗ
アノニクラスと一緒にしてるみたいだし、おまえアホだろ？
912:デフォルトの名無しさん
08/08/28 23:24:53
いまのインタフェース下のキャストより10倍はましだが？
interface F {
int f1(int x, int y);
String f2(int x, int y);
}
F f = { int x, int y => x + y };
f(.invoke(10, 100);
とか
{ int, int => int } f = { int x, int y => x + y };
f(.invoke(10, 100);
書いててばかばかしいと思わん？
913:デフォルトの名無しさん
08/08/28 23:37:23
どこが馬鹿馬鹿しいのか分かるようにちゃんと指摘できないのは、バカｗ
914:デフォルトの名無しさん
08/08/28 23:38:33
>>912
関数が多言語使ってるくせに、数学のことまるっきり分かってないようだなｗ
おまえばかだろ？
915:デフォルトの名無しさん
08/08/28 23:49:47
interface F {
int f1(int x, int y);
String f2(int x, int y);
}
F f = { int x, int y => x + y }; //あれぇ、ブロック要素なのにオブジェクト扱い？
f(.invoke(10, 100); //わざわざinvoke()を特別扱い。インタフェースには定義ないし、きもいね
とか
{ int, int => int } f = { int x, int y => x + y }; //{ int, int => int }って、こんなの持ち回るんかい！
f(.invoke(10, 100);
もうねinvokeの特別扱いとかいろいろ導入してんだよ
こんなことやるくらいならもっといろいろできただろ
>>914
数学（笑）
頭いいならさ説明してみろよ
916:デフォルトの名無しさん
08/08/29 00:44:01
久しぶりに誤変換で笑った。
関数型言語を使ってれば数学チックな思考を出来るようになっていてもいいんじゃないの？
917:デフォルトの名無しさん
08/08/29 00:45:29
>>915
君が糞だって事はよーく分かったからｗｗ
918:デフォルトの名無しさん
08/08/29 00:47:16
また糞だめから出てきたのか。
919:デフォルトの名無しさん
08/08/29 01:00:25
糞は糞らしくVBでもやってろｗ
920:デフォルトの名無しさん
08/08/29 01:09:46
VBは早くからUnicodeに対応したユーザフレンドリな言語だと思うが。
ある意味Javaの先輩といってもいいくらいの。
921:デフォルトの名無しさん
08/08/29 01:27:20
javaはこのまま暗黒面に落ちていくと思う。（言語仕様が）
922:デフォルトの名無しさん
08/08/29 01:28:10
もうJAVAはだめぽ（。。
923:デフォルトの名無しさん
08/08/29 02:27:58
ライブラリの仕様はJCPのようなプロセスを経るのもいいのだろうけど、
言語仕様はSUNがびしっと決めてしまったほうがましな気がするな。
船頭多くしてなんとやらだよ、まったく。
924:デフォルトの名無しさん
08/08/29 02:30:48
>>908
Javaはtypedefはやらない流儀。別名を導入しない。
function F(int i, int s);は別名導入しているに等しい。
925:デフォルトの名無しさん
08/08/29 02:39:15
いっそ、functionよりdelegate void F(int i, int s)がよくないかな
926:デフォルトの名無しさん
08/08/29 02:47:55
いや => が混乱の元。
{int o => o<=1 && o>=-1} なんか笑われてるようにしか見えないじゃんか。
もうJAVA終わったorz
927:デフォルトの名無しさん
08/08/29 03:04:36
closureってまだ入らなそうな感じなんじゃないの?
個人的にはfunction typeの構文がかなり可読性を下げる気がするのでやめて欲しい。
型名書いているのかブロック書いているのか分からなくなる。
928:デフォルトの名無しさん
08/08/29 03:08:36
=> は伝統だろ
929:デフォルトの名無しさん
08/08/29 03:22:29
>>927
糞だからな
930:デフォルトの名無しさん
08/08/29 03:54:34
>>927
お前の可読性の好みなど聞いてない
931:デフォルトの名無しさん
08/08/29 06:23:44
ジャバのスレじゃないのか！ジャバが終わったとかC#にしろとか何を愚かなこといってるんだぁ
932:デフォルトの名無しさん
08/08/29 10:29:24
カタカナで書かれると、風呂釜洗い出しそう
933:デフォルトの名無しさん
08/08/29 16:01:03
ジャバはジャバだろ！コーヒーじゃないんだぞ！
934:デフォルトの名無しさん
08/08/29 17:19:05
カバオくんお風呂に入ってハァビバノノ
s/JAVA/KABA/ だめだこりゃ
935:デフォルトの名無しさん
08/08/29 17:19:22
もうVBとVBAだけあれば、俺は幸せ！
936:デフォルトの名無しさん
08/08/29 19:42:34
>>924
おまえはクロージャのインタフェースへのキャスト仕様理解してから話せ
937:デフォルトの名無しさん
08/08/29 20:07:04
>>934
KABAはPrologだけど、知らないんだろうな・・・
938:デフォルトの名無しさん
08/08/29 20:43:30
じゃあ
未だにIISオンリーで糞重C#とか、化石のVBとか、MatzクンのオナニーRubyとか？
ねーよｗｗありえねーわｗｗｗｗｗｗ
939:デフォルトの名無しさん
08/08/29 22:12:36
お前アホだなぁｗｗ
CやVBは化石なんじゃなくて歴史があるってもんよ。
C#なんか常々進化してんじゃん。
それを言うならjavaの方がもう化石なんじゃねーの？
940:デフォルトの名無しさん
08/08/29 23:10:22
まるでJavaが進化してないみたいな言い方だな
2年に一度は大きいアップデートがある（EEも含めると毎年ある）環境だというのに
昔の言語と違って今の言語はどれも大幅な更新が入るのは当たり前だぞ
941:デフォルトの名無しさん
08/08/29 23:15:42
低レベルな言語比較なら他スレでどうぞ
942:デフォルトの名無しさん
08/08/29 23:19:28
and, because of you, you should accept the closure proposal for next generation.
943:デフォルトの名無しさん
08/08/30 06:01:48
何この糞スレ？
944:デフォルトの名無しさん
08/08/30 06:40:38
もうJavaなんてやめちまえ！
945:デフォルトの名無しさん
08/08/30 11:32:40
他の言語のスレで叩かれた厨が流入してるんだろう
しばらくの辛抱だw
946:デフォルトの名無しさん
08/08/30 23:25:58
でもrubyは宗教だろ
947:デフォルトの名無しさん
08/08/31 02:10:45
perlは宗教じゃなきゃ何よ？
948:デフォルトの名無しさん
08/08/31 02:39:31
プログラミング言語
949:デフォルトの名無しさん
08/08/31 08:45:43
驚くほど糞スレ
こんなスレに興味を抱いた俺が馬鹿だったわ
950:デフォルトの名無しさん
08/08/31 09:00:31
続きはマ板でね
951:デフォルトの名無しさん
08/08/31 10:30:15
>>949
おまえのような糞に言われたくない罠
952:デフォルトの名無しさん
08/09/01 12:25:27
>>951
その辺の返し方がクソスレｗｗ
953:デフォルトの名無しさん
08/09/01 17:29:50
typedefもどきはやめてくれ
ソースコードが読みにくくなるんだよ
954:デフォルトの名無しさん
08/09/01 20:08:09
>>952
糞は無理して発言しなくていいよ。それよか、海外でもいいから、ねたブログとかないの？
955:デフォルトの名無しさん
08/09/01 21:09:19
今のクロージャの仕様はtypedefよりひどいじゃねーかww
interface F {
int f1(int x, int y);
String f2(int x, int y);
}
F f = { int x, int y => x + y };
f.invoke(10, 100);
なんだよこれ
956:デフォルトの名無しさん
08/09/01 21:40:54
どこかどう酷いのか書いてない用だけど…
おまえ、あたま大丈夫？
957:デフォルトの名無しさん
08/09/01 23:14:13
>>955
これってメソッドが2つあるからコンパイルエラーでは?
なんか問題あるの?
958:デフォルトの名無しさん
08/09/01 23:37:41
>>957
ところが仕様ではこれがOKなのさ
驚きだろ？
959:デフォルトの名無しさん
08/09/02 03:31:21
これ自体は、イヤな動きだけども、これはどのくらいの頻度でありうるものなのかな
そして、どのくらいの頻度で、問題のある動きになるのかな？
メリットはかなり大きいと思うが、割りにあうのかないのか
960:デフォルトの名無しさん
08/09/02 03:33:35
>>955
それならもうC#しかないな。C#でもDでもいいから、一緒にやらないか？
961:デフォルトの名無しさん
08/09/02 03:42:20
Scalaでいいよ！
962:デフォルトの名無しさん
08/09/02 03:52:42
scalaだけど少し調べてみたけど数年後には来そうだね。
でもグルービーと比べるとイマイチ違いがないんだよね（言語機能じゃなくて）。
グルービーはJSRで仕様堅めに入ってるから先が見込めるけど、scalaは（言語機能じゃなくて）普及の兆しを感じないな。
個人的にはjdk1.6で既にサポートされてるrhinoでいいんじゃないかと思う。
963:デフォルトの名無しさん
08/09/02 04:00:21
静的型でクラスファイルができるのと、スクリプトと、違いがないってのか。
しかもrhinoでいいんじゃないかとかいう。
その言語で作ったクラスをJavaで自由に扱えるかどうかも、でかいとおもうよ。
964:デフォルトの名無しさん
08/09/02 04:04:13
↑全く意味不明なので、書き直してもらえませんか？
965:デフォルトの名無しさん
08/09/02 04:05:43
rhinoやgroovyじゃ、Java言語の代わりにはなれません。
966:デフォルトの名無しさん
08/09/02 06:29:38
スクリプトサポートの目的はJavaの代わりになるかでなくて、Javaでは難しいところやかゆいところに手が届くって意味じゃないの？
967:デフォルトの名無しさん
08/09/02 06:34:55
個人レベルで使うなら何だっていいが、企業向け開発だとなぁ
言語仕様も大事だが、大手のサポートやツールの有無
つまり周辺環境がないとどうしようもない
今んところ実質的な代替はC#にしかできないでしょ
あとはRubyがちょっと流行ったくらい
JavaがgdgdになるならScalaもありかもしんないけど
企業向けに立ち上がるにはよほど運がないと無理でしょ
968:デフォルトの名無しさん
08/09/02 06:39:28
java langやjvmがサポートするのはフレームワークだと思うんだが、なんか外してないか？
まあ、このスレはこの程度かｗ
969:デフォルトの名無しさん
08/09/02 06:42:36
>>966
Scalaはスクリプトサポートではなく、Java言語の代替として使うことを考えられてる。
だから静的コンパイルされてクラスファイルを生成して動かす。
そうすると、Javaと同等かそれ以上の速さで動く。
クラスファイルだから、Javaからも比較的自由に使える。つまり特別な仕組みを使わなくてもServletやJPAのクラスが作れるということ。
部分的な適用がやりやすくなる。
で、今は、Javaの言語仕様拡張よりScalaじゃねぇの？って文脈。Javaの代わりになるかという話。
>>967
企業向けのエンドプログラマはJava1.4で充分でしょ。
970:デフォルトの名無しさん
08/09/02 06:43:38
言語オタクのおもちゃならScalaで十分
Javaになんでもかんでも詰め込んで欲しいとは思わん
971:デフォルトの名無しさん
08/09/02 07:14:40
>>969みたいな
こういう俺様俺様ってのはどこにでもいるよなｗｗC++なんかこんな奴らの固まりだしｗｗ
972:デフォルトの名無しさん
08/09/02 07:17:44
スカラもグルービも、ジャヴァも、クラスファイルを作ってJVMプラットフォームで動くんじゃなかったの？（.Netみたいに）
973:デフォルトの名無しさん
08/09/02 08:04:16
企業向けだって1.4じゃつらすぎる。5つかっててｵﾓﾀ。
974:デフォルトの名無しさん
08/09/02 08:19:55
rhinoもバイトコードコンパイラあるんだが
975:デフォルトの名無しさん
08/09/02 10:45:01
ジャヴァジャヴァ
976:デフォルトの名無しさん
08/09/02 17:12:24
>>958
v0.5って仕様にはclosure conversionはsingle methodを持つもの、
って書いてあるのでそのケースはエラーになると思ったんだけど、どっか他に仕様がある?
呼ばれるメソッドが不定に見えるのでエラーにするのが普通だと思うんだが。
あと最後のinvokeはFがinvoke持ってないからエラーになるような。invokeに関しては、function typeがinvokeを持つinterfaceとして扱われるのでは。
977:デフォルトの名無しさん
08/09/02 20:35:43
Tグループの会社を何件か見たが、どこもJava1.3が入ってたりして焦った。
定期的にアップグレードする計画を立てるのもシステム課の重要な仕事だな。
978:デフォルトの名無しさん
08/09/02 20:51:02
いろいろ動かなくなるからアップグレードしちゃだめだよ
979:デフォルトの名無しさん
08/09/02 21:15:02
>>976
それが普通だよなw
インタフェースのメソッドは一つらしい
でも例外的に他のメソッドの引数がObjectのときはOK
つまり正しくは以下のコードだったよ
interface F {
int f1(int x, int y);
String f2(Object x, Object y);
}
F f = { int x, int y => x + y };
f.invoke(10, 100);
invokeはクロージャを実行する特別メソッド
インタフェースとは全然関係ない
だから以下のように書けるようだ
{ int x, int y => x + y }.invoke(10,20);
これもなんだかどうしようもないよな
最初の例見ると可読性ないよw
980:デフォルトの名無しさん
08/09/02 21:18:48
>>978
部署に一台、事務処理専用マシンを作っていくのは基本だろ？
981:
08/09/02 21:27:40
>>979 それが通るなら、逆にこれも通るのかな？
interface F {
int f1(int x, int y);
String f2(Object x, Object y);
}
class MyClass implements F{
int f1(int x, int y){
return x + y;
}
String f2(Object x, Object y){
return x.toString() + y.toString();
}
}
F f = new MyClass();
f.invoke(2,3);
982:デフォルトの名無しさん
08/09/02 21:50:23
>>981
それは無理だよ
どこにもクロージャ使ってないでそ
983:デフォルトの名無しさん
08/09/02 22:31:58
こいつは、メソッドレファレンスMyClass#meth()のこといってんじゃないの？
984:デフォルトの名無しさん
08/09/02 22:56:47
なんだそりゃw
985:デフォルトの名無しさん
08/09/02 23:09:29
Java 7の目玉機能は、クロージャだけなんですか？
986:デフォルトの名無しさん
08/09/02 23:18:10
モジュール？
987:デフォルトの名無しさん
08/09/02 23:24:08
>>979
その仕様はどこに書いてあるん?
なんでその例外的ルールがあるのかわらない。
それから、
F f = { int x, int y => x + y };
f.invoke(10, 100);
これはFがinvokeを持ってないので無理でしょ?
invokeはclosure literalが持つってだけで、特別なメソッドではないでしょ?
(だから>>981は無理なはず)
{int x, int y => x+y }.invoke(10,100)ができるのは分かる。
これはclosure literalがinvoke(int,int)を持つ型なので。
function typeがinvokeを持ってて、他のinterfaceの型に変換するときにそのinterfaceの持つ1つのメソッドに割り当てられるってことでは。
あと、literalに直接invoke呼ぶのはそんなに無いんじゃないだろうか。
988:デフォルトの名無しさん
08/09/02 23:32:57
>>985
プロパティ構文が一番じゃね?
989:デフォルトの名無しさん
08/09/02 23:36:31
こいつの主義からすれば、func.invoke(aho) じゃなくて、func(aho) とやりたいってのじゃないの？
どうせスカラー云々スクリプト云々って奴だろｗ
こいつの頭の中ではごっちゃになってて、サル脳だから理解できないんだろうｗｗ
990:デフォルトの名無しさん
08/09/02 23:58:48
>>987
たいして仕様を読んでないようなサルの相手をすることもないんじゃないの？
君も同じく相当ヒマだろうけどｗ
991:デフォルトの名無しさん
08/09/03 01:37:33
このスレって偉そうに言ってる奴はどこが悪いのか指摘すらできないんだよなwwww
992:デフォルトの名無しさん
08/09/03 01:39:55
>>990
なら仕様を読みまくってる君が簡潔に説明してみたらいいのではないだろうか
なんでここ見てるわけ？
993:デフォルトの名無しさん
08/09/03 01:45:49
>>991,992
くやしいのｗｗｗくやしいのｗｗｗｗｗｗ
994:デフォルトの名無しさん
08/09/03 02:12:41
> くやしいのｗｗｗ
知らねぇのに無理して使うなよ。ほしのあきじゃねぇんだから。
くやしいのうｗｗｗ
995:デフォルトの名無しさん
08/09/03 02:37:51
>>994
ゴミはまだ常任してんのか。
おまえのうんちくはイランから、はよ死ね。
996:デフォルトの名無しさん
08/09/03 02:42:12
くやしいのうｗｗｗ くやしいのうｗｗｗ (ｹﾞﾗ
997:デフォルトの名無しさん
08/09/03 03:00:33
何この糞ｗｗｗ
次スレもいらんわｗ
998:デフォルトの名無しさん
08/09/03 03:01:51
>>996
そんな雑学よりも、英語をみっちり勉強した方が自分スキル向上になるんじゃないでしょうか？
999:デフォルトの名無しさん
08/09/03 03:02:38
逝 っ て よ し ｗ
1000:デフォルトの名無しさん
08/09/03 03:20:24
age 全開で自己援護に必死
1001:１００１
Over 1000 Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。