[Java SE 7] 次世代Ja ..
511:デフォルトの名無しさん
08/03/07 01:37:44
>>508-510
はよオナニーして寝ろYO
512:デフォルトの名無しさん
08/03/07 01:44:17
ID無くてもBooでがいしゅつになるかで同一チェックできるんじゃないかと思えてきた。
513:デフォルトの名無しさん
08/03/07 01:57:05
>>512
誰だおまえ？
514:デフォルトの名無しさん
08/03/07 02:01:03
>>513
これが噂の負け組みの人だから、かまっちゃダメ！！
515:デフォルトの名無しさん
08/03/07 02:03:03
516:デフォルトの名無しさん
08/03/07 02:30:30
こんなところにも負け組みの人が漂流してるんですね（笑い）
517:デフォルトの名無しさん
08/03/07 02:31:37
ID、IDってうるさい人、あなたも負けたんですか（笑い）
518:デフォルトの名無しさん
08/03/07 02:37:45
ちょっとわからないことがあるのですが、
ゴズリンさんいますか？
519:デフォルトの名無しさん
08/03/07 03:27:18
今日の夜は長いですねｗ
冶金お疲れ様っす！！
520:デフォルトの名無しさん
08/03/07 08:09:52
>>495
Scalaは中の人の議論でもよく出てくる言語だよ。
やっぱりよく出来てる。使ってねーけどw
521:デフォルトの名無しさん
08/03/07 08:16:56
Control invocation syntaxで算術ifも書けるね。うれしい。
522:デフォルトの名無しさん
08/03/07 15:55:38
>>520
使えば分かるよ。Javaから見れば何でもありだからｗ
523:デフォルトの名無しさん
08/03/07 19:51:10
ニート達はもうどっか行っちまったか？
524:デフォルトの名無しさん
08/03/07 22:44:28
ニート、ニートってうるさいんだよ！Java使ったってC＃使ったっていいだろ！！！
525:デフォルトの名無しさん
08/03/07 22:52:21
何この自演ｸｾｰの
526:デフォルトの名無しさん
08/03/08 00:19:40
派遣はいていいですか（・＿・）
527:デフォルトの名無しさん
08/03/08 01:09:17
>>525
ニート乙
528:デフォルトの名無しさん
08/03/08 01:10:46
図星だったか…
529:デフォルトの名無しさん
08/03/08 11:59:23
派遣はいていいですか（・＿・）
530:デフォルトの名無しさん
08/03/08 12:51:33
しつけーよｗいいよ！いていいよｗ、むしろお願いするｗ
531:デフォルトの名無しさん
08/03/08 13:15:38
派遣はいてないですか！？
532:デフォルトの名無しさん
08/03/08 17:01:22
>>530
ニートなんですが…ボクちんもいいですか（・＝・）
533:デフォルトの名無しさん
08/03/08 22:44:17
>>530
誰だってJava使っていいですよね？
534:デフォルトの名無しさん
08/03/09 11:44:37
>>522
何でもできるとかそんなことじゃなくて、すごく良く設計されている。
535:デフォルトの名無しさん
08/03/09 15:38:37
>>534
ボクちんニートなんですが…
536:デフォルトの名無しさん
08/03/09 22:07:15
rubyとscalaの大きな違いは、JavaVM上で動かすことを前提にしているかどうかだな。
537:デフォルトの名無しさん
08/03/09 22:25:37
馬鹿そう…
538:デフォルトの名無しさん
08/03/10 01:34:42
>>478
> 激突スルー
539:デフォルトの名無しさん
08/03/11 11:37:58
どう使うかに絞った簡単な解説
Closures for Java
URLﾘﾝｸ(jazoon.com)
540:デフォルトの名無しさん
08/03/11 19:49:32
ふと思った。例に出てくる for each とかで
for each (String name, Thing thing : myMap) {
if (thing.isCocksucker()) {
return; // ← ｺｲｼはどこに return するのかね？
}
doSomething(name, thing);
}
541:デフォルトの名無しさん
08/03/11 19:57:15
for eachの置かれているメソッドから抜ける。
542:デフォルトの名無しさん
08/03/11 20:24:55
>>540
>>540
>>540
>>540
543:デフォルトの名無しさん
08/03/11 20:45:25
そーいや、BGGA だと Listener系どーすんだろ？
java.awt.event.ActionListener とかみたいに、メソッド一個の場合は良いけど
java.awt.event.MouseListener とかみたいに幾つもメソッドある場合とか。
MouseAdapter 使っても名前指定できないとアレだし。CICE も同じ問題かかえてる。
FCM だと Named inner method が作れるから、この点は問題にならんのだけど。
やっぱ BGGA だと
public void onMouseClicked({MouseEvent e => void} block) {
addMouseListener(new MouseAdaptor(){
public void mouseClicked(MouseEvent e){ block.invoke(e); }
});
}
みたいな感じにすんのかなぁ？ メソッド数が大変な事になるような気もするけど。
544:デフォルトの名無しさん
08/03/11 20:57:59
クロージャより関数オブジェクトとか関数リテラルみたいなラムダの方が欲しいんだけどなぁ。
545:デフォルトの名無しさん
08/03/11 21:32:42
>>544
クロージャと、関数オブジェクトとか関数リテラルみたいなラムダとの違いって？
546:デフォルトの名無しさん
08/03/11 22:20:39
>>543
void addMouseActions(java.awt.Component foo,
{MouseEvent e => void} clicked,
{MouseEvent e => void} released,
{MouseEvent e => void} entered) {
foo.addMouseListener(new MouseListenerBuilder()
.setMouseClicked(clicked) // null check wished?
.setMouseReleased(released)
.setMouseEntered(entered);
}
547:デフォルトの名無しさん
08/03/11 23:16:07
>>546
それだと順番間違えやすいし、順番間違えてもコンパイル時にチェックできないから
実行時に変な動作してから初めて気付く事になるような……
548:デフォルトの名無しさん
08/03/12 01:37:02
じゃあブロック引数は一つの関数にすればいいんじゃないの？
変な人。
549:デフォルトの名無しさん
08/03/12 08:09:04
それじゃ>>543と変わらん
550:デフォルトの名無しさん
08/03/12 09:22:49
builderパターンを使うってアイデアもあるけど、
実際比べてみると匿名クラス使う場合とタイプ数もあんまり変わらんのよね。
builderパターン + クロージャ：
addMouseListener(new MouseListenerBuilder().setMouseClicked({MouseEvent e => System.out.println("clicked"); }));
adapter + 匿名クラス：
addMouseListener(new MouseAdapter(){ public void mouseClicked(MouseEvent e){ System.out.println("clicked"); } });
551:デフォルトの名無しさん
08/03/12 12:03:38
クロージャってこういう呼び出し方出来ないんだろうか・・・。
({arg => hogehoge})(arg);
552:デフォルトの名無しさん
08/03/12 12:06:59
クロージャーよりもやっつけで盛り込んだ既存のライブラリ仕様を洗練させて欲しいんだが。
553:デフォルトの名無しさん
08/03/12 12:34:23
>>551
BGGA v0.5にはない。
554:デフォルトの名無しさん
08/03/12 12:34:44
洗練って・・・
下位互換考えるともう変更できんだろ・・
555:デフォルトの名無しさん
08/03/12 12:37:22
>>551
それだと単なるキャストだね。
argがクラス名と変数名/フィールド名で重複してるけど。
556:デフォルトの名無しさん
08/03/12 12:39:02
>>552
openjdkあたりにパッチ送れば？ acceptされるとは限らんけど。
557:デフォルトの名無しさん
08/03/12 12:43:30
というか勝手にクラスライブラリ作ればいい。
将来採用されることもありうる。
558:デフォルトの名無しさん
08/03/12 13:50:47
必要になれば、Cのtypedefみたいなのでもっとパワーアップしてるのがサポートされるんじゃないか。
タイプ量が多いとかはエイリアスで解決できるわけで、クロージャの言語仕様とは全く関係ない。
といいつつもJavaではtypedefみたいのは永遠とサポートされないと思うけど。
559:デフォルトの名無しさん
08/03/12 14:21:24
typedefとマクロはないだろうな
560:デフォルトの名無しさん
08/03/12 15:14:22
JavaFX はどうなったのさ。
561:デフォルトの名無しさん
08/03/12 16:00:16
>>558
ヘッダファイルを使うC言語と違って、
Javaのコンパイル単位はtypedefと相性悪いでしょ。
publicクラス毎に、何回も同じtypedefを書く必要出てくるし。
あと、typedef入れるより型推論が入った方が嬉しいぞ。
562:デフォルトの名無しさん
08/03/12 17:09:38
Cのtypedefのパワーアップとして考えられるのは、文字通りtype definedのこと。
型推論と似てるけど、型推論は動的にやるでしょｗ
もしあるなら、typedefは静的におこなわれる、型(class)別名で、
変数のようにスコープを持つとかなら、
CやC++ templeteのようにバグとか追跡不可能で
エラーメッセージも意味不明にまでなったりしないと思う。
だから、やっぱり長いしタイプ量が変わんないじゃんというのは分かるけど、
タイプ量が多いのとクロージャとは関係ない。
563:デフォルトの名無しさん
08/03/12 17:13:03
今やるならアノテーションになるけど、
結局はtypedefやりたいならアノテーションつかってツール作って自分でやってくれよってなるんじゃないか。
564:デフォルトの名無しさん
08/03/12 17:16:42
Adaのtypedefならいいわけか
565:デフォルトの名無しさん
08/03/12 17:56:30
typedefというよりも、別名（エイリアス）ってのがあればいいってわけだ
566:デフォルトの名無しさん
08/03/12 18:25:48
>>562
タイプ量が多いのとクロージャは関係ないよ。
タイプ量が多いと builderパターン+クロージャで
リスナを生成するのが面倒くさいってだけで。
それに別名定義できても、C言語のヘッダファイルみたいなものがないと
それほど便利にはならないっしょ。それよりは型推論の方がいいって事。
型推論も別名定義も両方あってもいいけどさ。
567:デフォルトの名無しさん
08/03/12 18:35:57
そーいや、>>45には type aliasingあるけど、これも続報ないからどーなってんのかわからんね。
もっとも、これは generics でバカみたいに長くなった型名を短くてわかりやすいものにするのが
主な目的っぽいから、>>550 みたいに generics使ってない上に、
MouseListenerBuilder やら setMouseClickled やら MouseEvent やらの
個々の識別子は長すぎて読み易さを低下させてる、ってわけでもないのに
使うようなモンでもねーと思うが。
568:デフォルトの名無しさん
08/03/12 18:47:24
もういっそプリプロセッサがあれば良いんじゃね？
569:デフォルトの名無しさん
08/03/12 19:22:09
>>567
>>550ならtype aliasingいらんだろ。
元から MouseListenerBuilder やら setMouseClicked みたいな名前使わなけりゃいいんだし。
っても、別名使うにしろ、元のから短い名前で定義するにしろ
可読性とのトレードがあるから短い名前考えるのも面倒だわな。
どっちかっつーと、>>116みたいな引数の型推論入れたほうが楽だしタイプ量減る。
builderパターン + クロージャ + 短い名前：
addMouseListener(new MLB().sMC({MouseEvent e => System.out.println("clicked"); }));
builderパターン + クロージャ + >>116みたいな引数の型推論：
addMouseListener(new MouseListenerBuilder().setMouseClicked({ e => System.out.println("clicked"); }));
570:デフォルトの名無しさん
08/03/12 19:24:45
> addMouseListener(new MLB().sMC({MouseEvent e => System.out.println("clicked"); }));
なにこれ
571:デフォルトの名無しさん
08/03/12 19:30:27
>>570
よーするに、可読性落とさないような名前が思いつかないなら
>>550のタイプ量は妥当だって事。
572:デフォルトの名無しさん
08/03/12 21:31:24
そもそも、タイプ量だけなら >>543 使って
onMouseClicked({MouseEvent e => System.out.println("clicked"); });
で良いんだし。もしくは >>543 と control invocation syntax 使って
onMouseClicked(MouseEvent e){ System.out.println("clicked"); }
573:デフォルトの名無しさん
08/03/12 21:42:20
別にクロージャーが入っても何か新しいことが出来るようになったり
下らないミスが減ったりするわけじゃないんでしょ。拡張 for 並みに
どうでもいいんだけど。
574:デフォルトの名無しさん
08/03/12 21:43:13
>>572
エイリアスやらマクロやらプリプロセッサやら出してくるぐらいなら、そっちのがいいね
575:デフォルトの名無しさん
08/03/12 22:01:29
拡張forは便利だろ。
いちいちインデクサなんて書いてられるか可読性も落ちる。
576:デフォルトの名無しさん
08/03/12 22:04:29
インデクサ？ Iterator の間違いじゃね？
577:デフォルトの名無しさん
08/03/12 22:10:25
javax書き換えられないようなsuperpackageはいらない、Sunの失態が無いなら良いけど
578:デフォルトの名無しさん
08/03/12 23:00:42
↑ん？どういうこと？
579:デフォルトの名無しさん
08/03/12 23:01:12
>>575
C#に洗脳されすぎｗ
580:デフォルトの名無しさん
08/03/12 23:03:18
クラスとかメソッド名が長いってだけなら、ビルダークラスとかを継承してオーバーライドして自分で短い名前にしてくれよ。
それぐらい頭使え。
581:デフォルトの名無しさん
08/03/12 23:12:34
void hoge(a){actionPerformed(a);]
で、短いメソッド名で実装して、それを呼び出すことね。
582:デフォルトの名無しさん
08/03/12 23:26:28
indexerって普通の英語なんだが。
583:デフォルトの名無しさん
08/03/12 23:30:00
Javaじゃそんな言葉使わんしここ日本。
584:デフォルトの名無しさん
08/03/12 23:31:02
普通の英語って事は「索引を作る人」って意味で使ってるとか？
585:デフォルトの名無しさん
08/03/13 00:02:39
>>583
お前は日本語でプログラム書くのか？
586:デフォルトの名無しさん
08/03/13 00:16:46
演算子オーバーロードが言語仕様にあれば
Javaでもインデクサって普通に呼ぶだろうね。
Javaもinterface経由で演算子オーバーロードに対応したらいいのに。
AppendableとかCalculateableみたく、目的を明示すれば設計者も馬鹿しないでしょ。
587:デフォルトの名無しさん
08/03/13 00:21:01
演算子オーバーロードは絶対にサポートしないといってたけど。
588:デフォルトの名無しさん
08/03/13 00:28:40
>>585
いやいや、言いたいのは話をわざわざ分かりにくくするために英語にする必要はないだろうということ。
589:デフォルトの名無しさん
08/03/13 00:33:24
C#ちゃんはいいかげんに巣に帰れよ
590:デフォルトの名無しさん
08/03/13 02:05:45
インデクサくらい理解してやってくれ。
ループ抽象(拡張for)
コントロール・インヴォケイション・シンタックス
は過激に便利ですよ。>>539のp4-6見てください。
プログラム構造がかなりすっきりまとまります。
プログラム内でのコードの共通化も進みますし。
591:デフォルトの名無しさん
08/03/13 03:43:59
↑もうこなくていいから。死んでくれ
592:デフォルトの名無しさん
08/03/13 06:40:12
病的な過剰反応だな。明らかにネットに向いてない。
593:デフォルトの名無しさん
08/03/13 14:00:38
>>592
おまえも
594:デフォルトの名無しさん
08/03/13 21:56:17
>>561
別に相性は悪く無いと思う
以下のような感じでstatic importでtypedefを取り込めるような仕様にしておけば
問題無し
-- A.java --
package a;
public class Alias {
type FileName = String
}
-- B.java --
import a.Alias._;
public class B {
public static java.io.RandomAccessFile open(FileName name) {
....
}
}
595:デフォルトの名無しさん
08/03/13 22:49:58
>>594
それをやるには static import とは別の仕組みが必要になるし、
どうせやるなら class Alias みたいなものをヘッダファイルモドキとして使うのは間抜けすぎる。
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) みたいに及び腰だし。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5387日前に更新/204 KB
担当:undef