[Java SE 7] 次世代Javaの動向 6 [dolphin]

[Java SE 7] 次世代Ja ..

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
なら仕様を読みまくってる君が簡潔に説明してみたらいいのではないだろうか
なんでここ見てるわけ？

次ページ