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

1 ：デフォルトの名無しさん：2007/05/12(土) 08:25:15

前スレ

[mustang/Java SE 6] 次世代Javaの動向 4 [dolphin]
http://pc11.2ch.net/test/read.cgi/tech/1163986696/

[mustang] 次世代Javaの動向 3 [dolphin]
http://pc8.2ch.net/test/read.cgi/tech/1157227790/

次世代Javaの動向　２
http://pc8.2ch.net/test/read.cgi/tech/1147881822/

【Java】次世代Java・J2SE1.6の動向【Mustang】
http://pc8.2ch.net/test/read.cgi/tech/1081698555/

2 ：デフォルトの名無しさん：2007/05/12(土) 08:33:09

まだ5も消化しきれてないのに7なんて・・・・

3 ：デフォルトの名無しさん：2007/05/12(土) 10:29:46

Java FXはFlashみたいな、
瞬間起動→アプリごとの独自スプラッシュだしてnow loading→実行
ができないときついと思う。実際に動くまでが同じぐらいでも、
スプラッシュなしだと体感が長い。

4 ：デフォルトの名無しさん：2007/05/12(土) 11:46:22

乙

5 ：デフォルトの名無しさん：2007/05/12(土) 15:26:03

アプレットって何でいつまで経ってもブラウザ止めちゃうんだろう。
Flashみたいに瞬間起動できるようにならんもんかね。

6 ：デフォルトの名無しさん：2007/05/12(土) 16:29:11

>>5
> アプレットって何でいつまで経ってもブラウザ止めちゃうんだろう。
> Flashみたいに瞬間起動できるようにならんもんかね。

企業サイトでFlash使ったページがあると、必ずskipを押す。
どうせろくな情報がないんだし。

勝手に起動するまえに、起動させるかどうかを必ず聞いて欲しい。
そういう構造だったら、多少遅くても許せる。

7 ：デフォルトの名無しさん：2007/05/12(土) 17:08:43

>>6
そんな個人の好みの話じゃなくてさ。
> 多少遅くても許せる。
↑こう思ってない人の方が圧倒的に多いんだから。

8 ：デフォルトの名無しさん：2007/05/12(土) 17:12:23

ふーん
どんな割合なの？

9 ：デフォルトの名無しさん：2007/05/12(土) 17:13:11

>>7
だからこそFlashにもJavaアプレットも、

　瞬間起動できて
　　　(かつ|または)
　起動前に起動させるかどうか聞く

というようになってほしい気もする。

>>5 >>6 >>7のいずれとも別人の横レスすまそ。

10 ：デフォルトの名無しさん：2007/05/12(土) 17:14:20

>>8
蕎麦粉八割、つなぎが二割。ジャマイカ？

11 ：デフォルトの名無しさん：2007/05/12(土) 17:14:28

>>8
FlashとAppletの普及率通りなんじゃね？

12 ：デフォルトの名無しさん：2007/05/12(土) 17:16:14

>>8
ググレ！

13 ：デフォルトの名無しさん：2007/05/12(土) 17:16:17

具体的には？

14 ：デフォルトの名無しさん：2007/05/12(土) 17:18:43

>>8
daemon だよもん
stdio.h スタジオエッチ

15 ：デフォルトの名無しさん：2007/05/12(土) 17:21:16

>>8
一割より低いみたい

男性が多くて耐えられない…
http://pc11.2ch.net/test/read.cgi/prog/1159690092/

16 ：デフォルトの名無しさん：2007/05/12(土) 17:43:27

>>8
何の割合？

17 ：デフォルトの名無しさん：2007/05/12(土) 17:46:01

>>1
スレタイの右側、Dolphinは止めて、JavaFXにすればよかったのに・・・

18 ：デフォルトの名無しさん：2007/05/12(土) 17:49:06

>>16
Java SE と Java PG の割合。

19 ：デフォルトの名無しさん：2007/05/12(土) 17:50:48

>>17
JavaFXはコケる可能性高いと思ったんじゃね？
とりあえず、dolphinで良いと思うけど。

20 ：デフォルトの名無しさん：2007/05/12(土) 17:53:03

>>19
いやいずれにせよdolphinは止めた方がいいだろ？dev.javaのプロジェクト名もjdk7に変えられて
sunがdolphinというコードネームを捨てようとしているのに
書いてたら混乱するだけでしょ

21 ：デフォルトの名無しさん：2007/05/12(土) 17:57:16

>>20
誰も混乱しないと思うけど。

仮にJavaFX のコードネームが dolphin になってて紛らわしいとか、
仮にMicrosoft が dolphin ってコードネームの製品作り始めてて混乱するとか、
そーゆーのがあれば変えた方が良いかも知れんけど。

22 ：デフォルトの名無しさん：2007/05/12(土) 18:00:48

次世代Javaの動向の前に今発生してるバグを解決しろ

23 ：デフォルトの名無しさん：2007/05/12(土) 18:02:45

>>22
再現条件を詳しく。

24 ：デフォルトの名無しさん：2007/05/12(土) 18:03:34

コード名dolphinが使われなくなっていっても
そのへんは旧称dolphinで通じるだろうし、
とりたてて混乱はないんじゃないの。

関係ないがTEIKADEを思いだした。

25 ：デフォルトの名無しさん：2007/05/12(土) 18:06:19

>>23
うむ
言葉が足りんかった
正しくは↓

おまいら次世代Javaの動向の前に今発生してるバグを解決しろ

26 ：デフォルトの名無しさん：2007/05/12(土) 18:08:42

>>25
もうちょいkwsk!!

27 ：デフォルトの名無しさん：2007/05/12(土) 18:19:31

>>26
だ～か～ら～。「事件は現場で起こってるんじゃない！会議室でアッーー

28 ：デフォルトの名無しさん：2007/05/12(土) 18:23:28

会議室でのグダグダがデスマを招いている事実

29 ：デフォルトの名無しさん：2007/05/13(日) 07:55:24

FX Scriptの　format as 文はほしいと思ったJavaPG特有だろうなｗ

現状、インタプリタのコンパイルがとてつもなく遅いから早く、javaバイトコード吐いて欲しいけど

30 ：デフォルトの名無しさん：2007/05/13(日) 14:41:32

>>25
具体的にどれが問題か挙げないと話にならないだろ。
バグ報告見てこいって言うのかい？

31 ：デフォルトの名無しさん：2007/05/13(日) 15:17:02

>>30
「おまいら次世代Javaの動向の前におまいらが書いた糞プログラムにあるバグを解決しろ」
だろ？

32 ：デフォルトの名無しさん：2007/05/13(日) 15:22:26

Silverlightより先に発表したかった

33 ：デフォルトの名無しさん：2007/05/14(月) 23:04:31

お願いですから、Windows LaFをまじめに作って下さい。＞SUN
WindowsだけでClassic、XP、Vistaと3つもあって、面倒なのはわかるけど。

いくらサードパーティのLaFがあるとかいっても、ファーストパーティ標準添付のLaFが
ショボかったら初見でアウトなのよ。

34 ：デフォルトの名無しさん：2007/05/14(月) 23:28:29

>>33
どこが違うってのをスクリーンショット取って送ってあげるとか、
どこを直せば良いってのをパッチ書いて送ってあげるとかした方が建設的じゃね？

ってか、ここで愚痴っても改善されないと思うよ。

35 ：デフォルトの名無しさん：2007/05/14(月) 23:32:27

それいったら２ｃｈなりたたんがま

36 ：デフォルトの名無しさん：2007/05/14(月) 23:37:38

>>35
ヲチだけでも十分成り立ちますがな。

37 ：デフォルトの名無しさん：2007/05/15(火) 08:32:32

>>35
>>33は最初からSun宛てに話してるからなｗ

38 ：デフォルトの名無しさん：2007/05/15(火) 09:15:19

>>37
ここSunの窓口じゃねーし。

39 ：デフォルトの名無しさん：2007/05/15(火) 10:16:28

直接相手に苦情を言えないヘタレの巣窟＝2ch

40 ：デフォルトの名無しさん：2007/05/15(火) 10:29:52

>>39
愚痴ならマ板行ってやれ。あっちはそーゆー板だし。

41 ：デフォルトの名無しさん：2007/05/15(火) 13:50:07

>>38
37だが何故それを俺に言う？

42 ：デフォルトの名無しさん：2007/05/15(火) 18:36:52

>>41
そいつは前にもいた嫌われ者だからほっとけ。

43 ：デフォルトの名無しさん：2007/05/15(火) 21:55:26

Javaも終わりだな
次は何だ？

44 ：デフォルトの名無しさん：2007/05/15(火) 22:13:46

マシン丸ごとJava仮想化ブームでむしろ鉄板化してるんだが・・・

45 ：デフォルトの名無しさん：2007/05/15(火) 22:16:20

次はRuby
RubyやるとJavaが古臭く感じる

46 ：デフォルトの名無しさん：2007/05/15(火) 22:17:40

まぁそりゃ
今まで使ってたJavaとは違うからなぁ

47 ：デフォルトの名無しさん：2007/05/15(火) 22:38:15

クロージャー登場で少しは変わるんじゃない？

48 ：デフォルトの名無しさん：2007/05/15(火) 23:08:45

クロージャーでどんな風に変わるの？

49 ：デフォルトの名無しさん：2007/05/16(水) 01:12:27

クロージャーって何？

50 ：デフォルトの名無しさん：2007/05/16(水) 01:42:49

>>49
源頼朝の弟。

　　　　　　　　　　　　　　　　　　　　　　それは九郎じゃー。

51 ：デフォルトの名無しさん：2007/05/16(水) 02:07:35

>>49
スレストのことだよ

52 ：デフォルトの名無しさん：2007/05/16(水) 02:26:54

>>45
そこでJRubyですよ

53 ：デフォルトの名無しさん：2007/05/16(水) 03:42:35

>>44
OS抜きで直接JavaVMを動かす方が速くて当たり前なんだけど、JRockitって流行？
まぁ、携帯＆固い系のサーバーサイド＆Blu-rayと既に確固たる地位を築いたのでどうでも良いけど。

54 ：デフォルトの名無しさん：2007/05/16(水) 07:14:27

携帯もBlu-rayもMEだろ。鯖側ってEEの事か？

そういや前にプロパティで騒いだがアノテーションじゃだめ？

int prop;

@set(prop) public void setProp(int x){
prop=x;
}

@get(prop) public int getProp(){
return prop;
}

これで問題無くない？

55 ：デフォルトの名無しさん：2007/05/16(水) 10:07:06

Java SE 7の「プロパティ」が見えてきた - setter/getterのないJavaへ
http://journal.mycom.co.jp/articles/2007/05/16/java7/index.html

boundキーワードが良くわからん。さらなる解説へのポインタきぼんぬ

56 ：デフォルトの名無しさん：2007/05/16(水) 11:09:56

>>55
なにがよくわからんのかがよくわからん。

get、setの書き方、ローカルキーワードとか、C#のプロパティと同じですね。
それに、boundと#演算子でのリフレクション情報取得か。

57 ：デフォルトの名無しさん：2007/05/16(水) 14:00:16

>>55
boundプロパティなら setter が呼ばれた時に、
プロパティ変更される前に java.beans.PropertyChangeListener にイベントを送る。

bean には対になる vetoableプロパティってのがあって、
こっちはプロパティが変更された後に
java.beans.VetoableChangeListener にイベントを送る。

58 ：デフォルトの名無しさん：2007/05/16(水) 14:05:43

>>57
おいおい、逆だよ。逆。
vetoable はプロパティが変更される前に
登録された java.beans.VetoableChangeListener を呼ぶ。
VetoableChangeListener がプロパティの変更を
拒否したい場合は PropertyVetoException を投げる。

boundプロパティはプロパティを変更した後に
java.beans.PropertyChangeListener を呼ぶ。

で、>>55 のプロパティ案には、前者に対応する機能はない。

59 ：デフォルトの名無しさん：2007/05/16(水) 14:20:35

>>56
# つかって Property<B,T> 取れるってのは
もう一つの closure の草案である FCM の影響なんだろね。
http://docs.google.com/View?docid=ddhp95vd_0f7mcns

60 ：デフォルトの名無しさん：2007/05/16(水) 14:23:47

>>55
http://www.y-adagio.com/public/standards/tr_javabeans/jb10_7.htm

61 ：デフォルトの名無しさん：2007/05/16(水) 19:31:45

何々？
やっとゲッターセッターから解放されるって
まだ開放されてなかったんかYO────！！！

62 ：デフォルトの名無しさん：2007/05/16(水) 20:44:26

# 演算子か・・・・

↑って、書いたらなんかコメントアウトされてる気分ヽ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)メ(ﾟ∀ﾟ)ノ

63 ：デフォルトの名無しさん：2007/05/16(水) 21:02:01

>>59
で、Property<B,T> 自体は https://bean-properties.dev.java.net/ の影響っぽい。
これ、プリミティブ型のプロパティと相性悪そうだけど……

64 ：デフォルトの名無しさん：2007/05/16(水) 22:53:50

オートボクシングがあるじゃん

65 ：デフォルトの名無しさん：2007/05/17(木) 00:35:53

例えば java.beans.XMLEncoderで既存(int&gettrer)のbeanを出力した
java.beans.XMLDecoderで新しい(Integer＆Property)beanに復元するときとか
型変わっちゃうしさ。

66 ：デフォルトの名無しさん：2007/05/17(木) 17:38:15

ttp://journal.mycom.co.jp/articles/2007/05/10/javaone3/003.html
この新型JREに少しだけ期待してみる。

67 ：デフォルトの名無しさん：2007/05/18(金) 21:55:15

setXxxやらgetXxxを自動で作るわけじゃないみたいだね。
とすると、property対応フレームワーク以外で使うときには依然としてsetXxx/getXxx作る必要がありそう。

68 ：デフォルトの名無しさん：2007/05/18(金) 22:20:23

自動で作られるメソッドの名前は "プロパティ名$set" "プロパティ名$get" らしいね。.

69 ：デフォルトの名無しさん：2007/05/19(土) 10:03:31

なんて中途半端なんだ・・・

70 ：デフォルトの名無しさん：2007/05/20(日) 16:11:06

synth lafって全然流行んないね。JDKにsunのデモすら無い。
1.4時代のwinXP/GTK+ system lafがsynthなんだからあれ公開すれば良いのに・・・。

71 ：デフォルトの名無しさん：2007/05/20(日) 16:35:22

>>70
Nimbusじゃダメなん？

72 ：デフォルトの名無しさん：2007/05/20(日) 21:13:27

MOPが仕様に入らないかなwkwk

73 ：デフォルトの名無しさん：2007/05/22(火) 00:01:12

>>70
synth以外のLaFが流行ってるかのような書き方だな。
勉強のために作ってみました、程度の物を除外すると、まともなLaFなんて、
10程度だと思うけど。とても流行ってるとはいえない。
deviantartとかにカテゴリができるぐらいになればいいんだけど。無理か。

74 ：デフォルトの名無しさん：2007/05/22(火) 13:10:11

synthのxml吐くGUIツールはdev.java.netに３つくらいホストされてるけど、
やっぱカスタムlafはsynth以外が多い。てかXULフレームワークがあったよ。
海外製のSwingアプリケーションはlaf自前ってのが多い。（javaとシステムと独自の選択式だが）

75 ：デフォルトの名無しさん：2007/05/27(日) 12:51:27

MVMってどうなってんだ？
研究中？

76 ：デフォルトの名無しさん：2007/05/28(月) 20:56:05

hore

http://www.jp.arm.com/document/whitepater/pdf/pdf04.pdf#search='%E3%83%9E%E3%83%AB%E3%83%81%E3%82%BF%E3%82%B9%E3%82%AF%20java'

77 ：デフォルトの名無しさん：2007/05/31(木) 20:56:32

また１．４かよ・・・・・orz

78 ：デフォルトの名無しさん：2007/06/01(金) 11:10:03

JDK7 build13
http://download.java.net/jdk7/changes/jdk7-b13.html
http://download.java.net/jdk7/binaries/

79 ：デフォルトの名無しさん：2007/06/14(木) 21:56:00

>>3
Java6でできるよスプラッシュ
http://www.javainthebox.net/laboratory/JavaSE6/splash/splash.html

もういないだろうけど

80 ：デフォルトの名無しさん：2007/06/22(金) 14:18:44

JDK7 build14
http://download.java.net/jdk7/changes/jdk7-b14.html
http://download.java.net/jdk7/binaries/

81 ：デフォルトの名無しさん：2007/06/25(月) 21:00:29

>>80
Want to open a Frame without activating it
ttp://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6187066
フォーカスを取らずにフレームをオープンできるようになったのか・・・
何か使い道あるかな？

82 ：デフォルトの名無しさん：2007/06/26(火) 02:18:28

http://bugs.sun.com/bugdatabase
↑のバグ修正情報などを RSS かなんかで取得できませんか？

join SDN すれば、たぶんどうにかして特定のバグを追っかけたり
できるんでしょうけど、できれば join しないで見たいなぁと。

83 ：デフォルトの名無しさん：2007/06/29(金) 01:54:26

>>82
RSSで何をみる？新しく登録されたもの？
joinしたらvoteもできるぞ。

84 ：82：2007/06/29(金) 02:47:38

>>83
RSS で、新しく登録されたバグ、登録されたバグについての変更
が見れたらいいなぁと思います。

85 ：デフォルトの名無しさん：2007/07/07(土) 00:40:40

JDK7 build15
ttp://download.java.net/jdk7/changes/jdk7-b15.html
ttp://download.java.net/jdk7/binaries/

ビルドペースあがってきた？

86 ：デフォルトの名無しさん：2007/07/12(木) 01:38:18

最近ネタないね

87 ：デフォルトの名無しさん：2007/07/12(木) 01:53:12

そーいや、invokedynamic ってもう実装されたの？

88 ：デフォルトの名無しさん：2007/07/12(木) 15:43:33

マルチタスク対応って7で実装されるのか？

89 ：デフォルトの名無しさん：2007/07/12(木) 16:30:29

たしか使用策定は済んでるんじゃなかったけ？
Java Cardならすでに実装されててMIDP3.0が対応中（MIDP3.0自体策定中）。

jdk7はJAMに期待。Libletみたいな使い方をするんだろうね。

90 ：デフォルトの名無しさん：2007/07/13(金) 23:46:55

ODFとか対応しないのかな？

91 ：デフォルトの名無しさん：2007/07/21(土) 13:38:09

JDK7 build15
JDK7 build16
http://download.java.net/jdk7/changes/jdk7-b16.html
http://download.java.net/jdk7/binaries/

92 ：デフォルトの名無しさん：2007/07/24(火) 10:34:30

7っていつ頃リリースを予定しているの？

93 ：デフォルトの名無しさん：2007/07/24(火) 14:36:08

>>92
JDKのメジャーバージョンのリリースが 18～24ヶ月毎って話からすれば
JDK6のリリースが2006年 12月第一週だから、
JDK7のリリースは2008年 6月～12月ぐらいになる。

個人的には、JDK7は機能てんこもりだから遅れ気味になるんじゃないかと予想。

94 ：デフォルトの名無しさん：2007/07/24(火) 15:06:50

確かに。
JAMだってまだ乗ってないし。

95 ：デフォルトの名無しさん：2007/07/24(火) 15:38:04

>>91
何かさ・・・・コンパネが・・・・びろーんって・・・縦に・・・伸びてない・・・(；・∀・)？

96 ：デフォルトの名無しさん：2007/07/24(火) 21:40:33

来年秋って話だったから、再来年の春くらいになるんじゃね～の？

97 ：デフォルトの名無しさん：2007/07/25(水) 00:56:49

>>95
普段は JRE7入れてないから気付かなかった。
入れてみたら、なった。
うちだと、コンパネの天辺もタブも画面外にあって操作できない。

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6581482
これと同じかな？ Image file attached って書いてあるけど見られないんだよね。

98 ：デフォルトの名無しさん：2007/07/25(水) 04:07:24

来年以降か。機能がたくさん追加されるから楽しみだな。

99 ：デフォルトの名無しさん：2007/07/26(木) 01:49:13

俺はどれだけ構文が汚されるのか気になって仕方が無い。

これだけ、getter,setterの糞規約が定着したところでpropertyが普及するのかどうか…。

100 ：デフォルトの名無しさん：2007/07/26(木) 12:25:00

Javaのクロージャは期待できるけどなぁ…
delegateを無理に拡張している冗長構文のクロージャより大分改善されている。

101 ：デフォルトの名無しさん：2007/07/26(木) 23:59:44

>>100
Collectionライブラリもクロージャ対応されてくるかなぁ？
Streamとか、JDBCもクロージャ対応になったら、今のソースとガラッと変りそう。

102 ：デフォルトの名無しさん：2007/07/27(金) 00:24:21

java.util.Collections にクロージャ対応な staticメソッドが追加される予感……

103 ：デフォルトの名無しさん：2007/07/27(金) 00:43:27

これから6勉強しようかって思ってるのに・・・

104 ：デフォルトの名無しさん：2007/07/27(金) 01:44:31

別に覚えた内容が損になるわけじゃないぜ

105 ：デフォルトの名無しさん：2007/07/27(金) 01:48:37

>>103
勉強しとけ。

106 ：デフォルトの名無しさん：2007/07/27(金) 02:35:04

>>101
with(InputStream s: new FileInputStream("c:/test.txt")){
　System.out.println(s.read());
}
みたいなことが書けたり
List<Integer> list = Arrays.asList(1, 2, 3, 4);
int sum = Collections.reduce(
　list, {Integer x, Integer y => x + y});
とすると10が得られたり
Lock lock = ....;
withLock(lock){
　//いろいろロックされる処理
}
と書けたりする予定らしい。

107 ：デフォルトの名無しさん：2007/07/27(金) 07:50:44

こういうのって結局Cのプリプロセス処理と同じなんだよね。

108 ：デフォルトの名無しさん：2007/07/27(金) 09:43:44

>>107
Cのプリプロセッサみたいにコンテキスト考えずに
ただ置換するだけのものとは全然違うよ

109 ：デフォルトの名無しさん：2007/07/27(金) 14:52:46

違いを見せたいのは分かるが、たいした差はない。

110 ：デフォルトの名無しさん：2007/07/27(金) 14:55:54

ようするにシンタックスシュガーっていいたいんだろ。
それをCのプリプロセス処理と同じというのは問題あるがな。

111 ：デフォルトの名無しさん：2007/07/27(金) 22:54:16

単なる置き換え。マクロと同じってことがいいたいんだろう。
そういわれると辛いところだが…

112 ：デフォルトの名無しさん：2007/07/27(金) 23:03:57

プリプロセッサは別の言語仕様として存在してるのが問題なんだろ。
D言語とかはC++のカオスさをうまく言語仕様に馴染ませてて感心した。

113 ：デフォルトの名無しさん：2007/07/28(土) 08:27:49

まあ、でもそれはCore2Duoって8086と同じだよね、っていう感じで、だから何？ってなるんだよね。
仕組み的に同じ系統だからって、便利さは全く違ったりするわけだ。

114 ：デフォルトの名無しさん：2007/07/28(土) 11:10:24

自分で実装するわけにもいかないからね。
便利なのは使わせてもらおっと

115 ：デフォルトの名無しさん：2007/07/28(土) 11:58:04

>>107 >>110
アホですね。

116 ：デフォルトの名無しさん：2007/07/28(土) 12:03:17

Ｇｅｎｅｒｉｃｓの話？

117 ：デフォルトの名無しさん：2007/07/28(土) 14:00:46

どこからその話が・・・

118 ：デフォルトの名無しさん：2007/07/28(土) 15:07:58

>>106
またC#のパクリか

119 ：デフォルトの名無しさん：2007/07/28(土) 15:18:52

クロージャーがC#にしかないと思ってんのか。

120 ：デフォルトの名無しさん：2007/07/30(月) 12:02:37

scriptは何が追加されるんだろう。

121 ：デフォルトの名無しさん：2007/07/30(月) 13:43:25

script乱立しすぎでわけわかんね

122 ：デフォルトの名無しさん：2007/08/01(水) 07:29:47

jdk6ではjavascriptが使えるけど、javaファイルも同じようにスクリプトとして使えるのかな。

123 ：デフォルトの名無しさん：2007/08/01(水) 10:38:25

標準添付はされていない

124 ：デフォルトの名無しさん：2007/08/01(水) 11:36:20

標準ではないのか。次バージョンに期待するよ。

125 ：デフォルトの名無しさん：2007/08/01(水) 12:09:03

>>124
いまのところ、標準添付される雰囲気はないね。
標準添付できるような質のJavaスクリプトエンジンってあるのかな？

126 ：デフォルトの名無しさん：2007/08/01(水) 14:14:13

標準添付のスクリプトエンジンの方が
野良スクリプトエンジンより品質悪かったりするけど……

127 ：デフォルトの名無しさん：2007/08/01(水) 15:02:46

>>125
つ　Pnuts・・・

128 ：デフォルトの名無しさん：2007/08/01(水) 17:08:04

スクリプトだし、質とか速さとかどうでもいいよ。
とりあえず、Javaが動くスクリプトエンジンを実装してくれ。

129 ：デフォルトの名無しさん：2007/08/01(水) 17:13:49

言語としてのJavaならスクリプトエンジン作るよりも
コンパイラAPIの拡充の方が良い。

メソッド宣言時のシグネチャだけみたいな細かい単位で
構文解析＆名前解決してくれればそれで良い。
ツール作る時とか、そっちの方が都合良いし。

130 ：デフォルトの名無しさん：2007/08/01(水) 18:31:03

そんなこといってちゃ、いつまでたってもjavax.scriptでJavaはサポートされないよ。
自分の都合だけで考えるのもいいけどね。

131 ：デフォルトの名無しさん：2007/08/01(水) 20:05:04

俺は両方欲しいぜ、ベイベ
わがままな、俺の願いを聴いてくれよ
イエー

132 ：デフォルトの名無しさん：2007/08/01(水) 20:15:11

>>126
具体的には？

133 ：デフォルトの名無しさん：2007/08/01(水) 21:04:43

何につかうんだよそんなもの

134 ：デフォルトの名無しさん：2007/08/01(水) 21:36:56

>>130
標準添付されないというだけで、javax.scriptでJavaはサポートされてるわけだが。

135 ：デフォルトの名無しさん：2007/08/01(水) 22:35:59

>>132
具体的にはって標準添付されてんのRhinoしかないじゃないか。

136 ：デフォルトの名無しさん：2007/08/01(水) 22:37:07

標準で入ってないと意味ないし、無駄な努力なのだが。

137 ：デフォルトの名無しさん：2007/08/01(水) 22:40:17

SPI使えるんだから、クラスパスに含めるだけで新しいスクリプト言語使えるようにできるんだが……

138 ：デフォルトの名無しさん：2007/08/01(水) 22:42:38

おれは、C言語をスクリプトで実装して欲しいぜ！
それもC99を！

139 ：デフォルトの名無しさん：2007/08/01(水) 22:45:08

>>137
ん？俺が無知なだけなのか・・

140 ：デフォルトの名無しさん：2007/08/01(水) 23:13:33

まあ実際無知なんだろうな。

141 ：デフォルトの名無しさん：2007/08/02(木) 05:09:30

>>135
いや、オレもRhinoしか添付されてないと思ってたのだが、それだと野良スクリプトエンジンの方が品質がいいってのがひっかかる。
Rhinoよりいいスクリプトエンジンって何だ？

142 ：デフォルトの名無しさん：2007/08/02(木) 05:10:04

>>136
いらん。

143 ：デフォルトの名無しさん：2007/08/02(木) 12:28:23

>>141
普通にビルドしたRhino。

144 ：デフォルトの名無しさん：2007/08/02(木) 14:28:20

>>141
つ　Pnuts

145 ：デフォルトの名無しさん：2007/08/03(金) 00:08:05

>>138
個人的にはFORTRANが良い

146 ：デフォルトの名無しさん：2007/08/03(金) 00:12:18

たしかSunがFortressっての開発中だったと思う。
並列計算に特化したJavaとFortranを参考にしたスクリプトっての。

147 ：デフォルトの名無しさん：2007/08/03(金) 00:12:52

>>144
pnutsそんなにいい？
まだこなれてない感じバリバリなんだけど。
yieldの挙動とか。

148 ：デフォルトの名無しさん：2007/08/03(金) 04:44:27

あんま関係ない話で恐縮なんだけど、javax.script バブルの火付け役が php だって噂は本当なん？

149 ：デフォルトの名無しさん：2007/08/03(金) 06:10:32

msのcliに対抗するため

150 ：デフォルトの名無しさん：2007/08/03(金) 06:16:58

C言語やC#にある値型の struct はいつサポートされるの？

151 ：デフォルトの名無しさん：2007/08/03(金) 08:37:18

>>148
script言語の共通基盤になるチャンスを見逃すわけがない。
javascript, php, python, ruby実装環境をごっそり頂きかも知れない。
コンパイラ基盤もちらほら出てきているし。

152 ：デフォルトの名無しさん：2007/08/03(金) 12:00:15

>>150
なぜそんなものが必要なのか？理由を明確に

153 ：デフォルトの名無しさん：2007/08/03(金) 12:54:23

リンゲージがその関数内であるオブジェクトに対して、イチイチnewしないで済むことが言語として保障されることになる。

154 ：デフォルトの名無しさん：2007/08/03(金) 13:02:33

>>153
コンパイル時に最適化情報がバイトコードに埋め込めればいいんだよね～
そしたら、ガンガンエスケープ解析できる

155 ：デフォルトの名無しさん：2007/08/03(金) 13:28:43

>>151
いや、知り合いから
「php を java vm 上で動かそうって話が最初で、そのあと他の軽量言語が追従した」
って話を聞いたんだけど、本当なのかなって。

156 ：デフォルトの名無しさん：2007/08/03(金) 13:54:15

>>154
そういう小手先解析よりも、普通に言語としてサポートしろってこと。
struct Point {
double a,b
};
どう考えても需要あるだろ。

157 ：デフォルトの名無しさん：2007/08/03(金) 13:56:16

>>155
それだけ需要があるなら、PHPがまずサポートされるはずじゃないか？
VMで他の言語が動けばいいのであって、どうでもいいけど。

158 ：デフォルトの名無しさん：2007/08/03(金) 14:24:28

>>156
その程度なら不要。

値型の利点は、newが必要とかより、
代入が必ずコピーになることによって、
同一オブジェクトに対応する変数が一つであることを保障できることだと思うんだが。

159 ：デフォルトの名無しさん：2007/08/03(金) 16:26:23

>>158
需要の論点ではPointで示したが、利点としては例えが悪かった。
では必ずコピーになる利点のために導入するのではどうだ？ほしいだろ？

160 ：デフォルトの名無しさん：2007/08/03(金) 16:41:03

いや別に

161 ：デフォルトの名無しさん：2007/08/03(金) 17:45:57

値型が導入されたら、今度はポインタ演算を欲しがるに違いない

162 ：デフォルトの名無しさん：2007/08/03(金) 19:10:24

C#はstructの導入に失敗したからNullableが出来たんでしょ
恥ずかしい実装まで追従する必要ないから、別に要らないなぁ
どうしてもってのならByteBufferをラップすりゃいいし

163 ：デフォルトの名無しさん：2007/08/03(金) 19:34:17

値型ってメモリ効率に関する利点のために導入するもんだろ。

164 ：デフォルトの名無しさん：2007/08/03(金) 19:36:02

それが理由ならエスケープ解析が導入されたから今後は不要でしょ

165 ：デフォルトの名無しさん：2007/08/03(金) 21:11:05

>>161 それはない。

166 ：デフォルトの名無しさん：2007/08/03(金) 21:17:46

>>164
複雑じゃなくていいから、普通にCと同じのでいいよ。
メソッドもCの関数ポインタみたいに、staticのみでいい。
エスケーポ解析よりも言語に導入のほうが楽だと思うけど、そうでもないのか
まあ、そのうちちゃっかり導入されるんだろうけど。

167 ：デフォルトの名無しさん：2007/08/03(金) 22:14:07

JDK7 build17
ttp://download.java.net/jdk7/changes/jdk7-b17.html
ttp://download.java.net/jdk7/binaries/

168 ：デフォルトの名無しさん：2007/08/04(土) 00:41:24

いまさら導入されても、C の register 変数と同じ運命をたどる予感。

169 ：デフォルトの名無しさん：2007/08/04(土) 02:00:02

170 ：デフォルトの名無しさん：2007/08/04(土) 07:19:54

>>157
PHPみたいなどうでもいい言語をまずサポートする必要性がみあたらない。

171 ：デフォルトの名無しさん：2007/08/04(土) 08:47:45

structのメモリー効率のよさってのは、オブジェクト廃棄時のコスト云々じゃなくて、
newに頼ってオブジェクト生成するときのコストがまったくないってことだろ。
関数呼び出しでスタックに自動生成されるのであって、newによるオーバーヘッドは
かからないいってこと。

172 ：デフォルトの名無しさん：2007/08/04(土) 08:51:14

オブジェクトがほかのメソッドに伝播される可能性を考えると、エスケープ解析で自動的にやってくれるのが一番効率がよさそうだな。

173 ：デフォルトの名無しさん：2007/08/04(土) 08:52:09

structは、コピーによって、ここのオブジェクトの同一性の確保も
そのとおり利点ではあるが、エスケープ解析の小手先技なんぞに頼らないで
優先的に言語でサポートするのが妥当だろ。
assert, enumとかよりも先にさ。

Javaの文法は、結局Cの文法を真似てるだけってことを忘れて、
「エスケープ解析もできる俺ってすごいだろ」っていい気になってるだろ？

174 ：デフォルトの名無しさん：2007/08/04(土) 08:52:42

エスケープ解析ってのはそれをやるんだよ。
C#のstructと同じような最適化がされることになり、
逆にC#2.0で対応するはめになったNullableのようなstructの欠点も無い

175 ：デフォルトの名無しさん：2007/08/04(土) 08:54:47

>>171
まあ、メリットはあっても、それが"大きく"効いてくるのはかなり特殊なケースで、
そういうのが大量にある応用の時は、ハイバネでいい、ってのが今の流れなんじゃないの?

176 ：デフォルトの名無しさん：2007/08/04(土) 08:55:56

JavaのenumはCのenumとは違うぞ。
定数そのものに振る舞いを持たせることが出来るし、
なおかつタイプセーフだ。

177 ：デフォルトの名無しさん：2007/08/04(土) 08:57:25

メモリーの効率とかじゃなくて、
structを使いたいプログラマーの切実な要望には答えられないのかね？
そういうエスケーポ解析の新技術はどうでもいいからさ。

178 ：デフォルトの名無しさん：2007/08/04(土) 08:58:34

>>173
で、エスケープ解析に比べたstructの利点ってなんなの？

179 ：デフォルトの名無しさん：2007/08/04(土) 08:58:58

structの欠点の無いむしろメリットとなるようなカラクリがあれば導入されるかもな。

180 ：デフォルトの名無しさん：2007/08/04(土) 09:02:12

ちなみに、structなど値型を使いたい場面は、
forや関数呼び出しで100万回以上まわす。
そういう小型オブジェクトの短期生成は、newでは向いてないし、役不足だろ。
またエプケール解析とかいうのか？

GCの新技術はJava以外のVM使うスクリプトにもメリットあるだろうが、
そういうのは使うほうからみてどうでもいいから、まずはJava言語で導入しろ。

181 ：デフォルトの名無しさん：2007/08/04(土) 09:02:38

>>177
メモリーの効率とかじゃないなら、structを使いたいっていう切実な要望っていうのは、新技術以上にどうでもいいんじゃないかと思う。

182 ：デフォルトの名無しさん：2007/08/04(土) 09:03:54

>>180
使う方から見てどうでもいいのがstructだと結論づいてるのに何を・・・

183 ：デフォルトの名無しさん：2007/08/04(土) 09:04:17

>>176
使うほうからすれば、C,Javaどちらのenumも同じ。
いつ使えるようになったかといえば、Javaはサポート遅すぎ。

184 ：デフォルトの名無しさん：2007/08/04(土) 09:04:37

>>180
エスケープ解析で十分です。どうもありがとうございました。

185 ：デフォルトの名無しさん：2007/08/04(土) 09:05:49

>>183
全然違うっての。お前のいう「使う人」って誰だよ。お前限定じゃねーか。
お前はCだけ使ってろ。

186 ：デフォルトの名無しさん：2007/08/04(土) 09:06:52

>>181
きみ、structとclassは実質同じってことを知ってるのか？

187 ：デフォルトの名無しさん：2007/08/04(土) 09:08:35

>>186
C++のデフォルトアクセスレベルの話で言ってる？
同じものなら要らないだろ

188 ：デフォルトの名無しさん：2007/08/04(土) 09:09:11

structを否定するってことは、classつまり、構造体型（集合型）を否定しているようなものだけど・・
君の理解じゃ、ポインタがどうとかってあたりで止まってるんだろうな。

189 ：デフォルトの名無しさん：2007/08/04(土) 09:09:20

>>186
だから、なに？メモリ効率以外に、structの利点ってあるの？

190 ：デフォルトの名無しさん：2007/08/04(土) 09:10:21

>>188
なんで？
きみ、エスケープ解析の意味ちゃんとぐぐってる？

191 ：デフォルトの名無しさん：2007/08/04(土) 09:15:05

なんか、エスケープ解析をわかってないやつがいるみたいなんで書いておくけど
for(int i = 0; i < 10; i++){
　Point p = new Point();
　p.x = i * 2:
　p.y = i * 4;
　System.out.println(p.x + ":" + p.y);
}
が
for(int i = 0; i < 10; i++){
　int px = i * 2:
　int py = i * 4;
　System.out.println(px + ":" + py);
}
に最適化される技術な。

192 ：デフォルトの名無しさん：2007/08/04(土) 09:34:02

まとめると、「エスケープ解析の意味がわかんないやつが暴れてましたとさ」でいいの？

193 ：デフォルトの名無しさん：2007/08/04(土) 10:12:30

>>180
エプケール解析て…これは釣りだろ。
それから値型もnewされることに変りはないぞ。

194 ：デフォルトの名無しさん：2007/08/04(土) 10:20:21

Java版のaptみたいなのがそろそろ出てきてもいい頃合だね。
各種IDEやmavenの資産、そしてJAMの登場によって下地は十分のはず。
JDKに同梱されれば、環境構築のコストが激減しそう。

195 ：デフォルトの名無しさん：2007/08/04(土) 11:09:02

SunがOpenSolaris用のパッケージ配布機構を発表したぞ。
ZFSに基づくサービス、実装らしい。

Sun、『OpenSolaris』でバイナリパッケージ配布モデル採用へ
http://japan.internet.com/busnews/20070713/11.html

196 ：デフォルトの名無しさん：2007/08/04(土) 11:55:05

またエスケープ解析が得意の彼か
彼の言い分も一理あるが、単純に彼は自分の技術を自慢したいだけだから、ほっとけ

197 ：デフォルトの名無しさん：2007/08/04(土) 11:55:58

>>193
そもそも struct とか言う奴は大抵釣り。

198 ：デフォルトの名無しさん：2007/08/04(土) 12:01:23

JOGLやjinputとかをJDKから簡単に取り寄せられたら便利だね

199 ：デフォルトの名無しさん：2007/08/04(土) 12:18:37

下手にやると複数バージョンのjarが入り混じってカオスになるけどね

200 ：デフォルトの名無しさん：2007/08/04(土) 12:25:12

>>196
そういう話は、的確な議論してから言ったほうがいいと思う。

201 ：デフォルトの名無しさん：2007/08/04(土) 13:47:09

struct ：スタックに値を割り付ける
エスケープ解析：スタックにオブジェクトを割り付ける最適化手法

オブジェクトが対象のエスケープ解析の勝ちでおｋ
structは時代遅れの産物

202 ：デフォルトの名無しさん：2007/08/04(土) 14:13:45

>>196
自分の視点でしか判断できないのが彼のような技術者ってもんだし、
他人の要望とかまったく無視で自分の技術一点張りだな、こいつは。
つまりは、一人でコソコソとエスケーポ解析してろってこったな。

あー、ねくら、ねくら

203 ：デフォルトの名無しさん：2007/08/04(土) 14:17:20

>>201
おまえはばかか？勝手にしこってろ。嫌ならCをべんこうしなおせな。

204 ：デフォルトの名無しさん：2007/08/04(土) 14:22:58

>>202
C C++ アセンブラのときでも、小手先技使って最適化大好きって輩がいるけど、こういう根っからの技術者って人の話聞かないしね。こういうねくらは、あんまり表にしゃしゃり出てこないで中にこもって解析していて欲しいよ。

205 ：デフォルトの名無しさん：2007/08/04(土) 14:31:59

有能な学生をいじめたらだめれす！

206 ：デフォルトの名無しさん：2007/08/04(土) 14:36:57

>>201
おまえのその論理だと、Java標準のlong doubleなどプリミティブ型は時代遅れなのか？
そして解析手法を駆使する方が今風なのか？
おまえ、そんなことしてるよりコンパイラ作ってみろ。そうすれば分かる。

207 ：デフォルトの名無しさん：2007/08/04(土) 14:39:43

>>206
暇ならコンパイラとVMに struct実装して OpenJDKあたりにパッチ送ってみれば？
どれぐらいメモリ効率が良くなるかみたいなデータも示せば採用されるかもよ？

208 ：デフォルトの名無しさん：2007/08/04(土) 14:46:21

>>206にコンパイラやVMを書き換えるだけのスキルがあるとは思えないが

209 ：デフォルトの名無しさん：2007/08/04(土) 17:08:16

ひさびさに高品質の夏厨があらわれたな。

210 ：デフォルトの名無しさん：2007/08/04(土) 21:46:11

>>173
＞「エスケープ解析もできる俺ってすごいだろ」
惚れました

211 ：デフォルトの名無しさん：2007/08/05(日) 00:44:29

>>191みたいな馬鹿に突っ込める奴は、
ここにはいないのかｗｗｗ

エスケープ解析とは、ソースコードを解析してバイトコードの最適化を行う話じゃない。
Javaのコンパイラはソースコードとバイトコードの対応付けが規定されているので、
そもそもバイトコードの最適化はありえない。

メソッド内で生成されたインスタンスが、
メソッドの外へ「逃げるか逃げないか」を判断する技術だ。

returnや引数やフィールドに参照が渡されるコードがあれば、
「メソッドの外に逃げる」と判断されて、
インスタンスはヒープに確保される。

逆に「メソッドの外に逃げない」と判断されたら
インスタンスはスタックに確保される。

わかったかいｗｗｗ？>>191

212 ：デフォルトの名無しさん：2007/08/05(日) 00:44:39

くそ天皇　くそ天皇　くそ天皇　くそ天皇

いい加減死ねっつってんだろ屑ニートくそ天皇が

相変わらず病的な粘着っぷりだな屑ニートくそ天皇が

毎日毎日毎日粘着出来て良いでちゅねくそ天皇

くそ天皇さっさと死にやがれゴミが

東京に在住している精神病珍米糞ニートくそ天皇君の末路

さっさと精神病院逝くか首吊って逝くか選べや糞天皇が

早く死ねよ糞ニート天皇が

粘着精神病屑ニート天皇君は自らニートくそ天皇であると公言しました
さっさと死ねやくそ天皇が

早く死ねっつってんだろ屑ニートくそ天皇が

お前みたいなゴミクズ天皇は息してるだけで空気が汚れるからさっさと死ねや

とっと死に晒せや糞ニート天皇が

213 ：デフォルトの名無しさん：2007/08/05(日) 01:22:48

>>211
引数に渡すだけでもエスケープと判断されるのか。
オブジェクトの生存期間がスタックのそれに制限されているだけじゃだめなのね。

214 ：デフォルトの名無しさん：2007/08/05(日) 01:30:19

渡したメソッドがインライン展開されてれば大丈夫

渡した先でそのオブジェクトがどこに保持されて生き延びるかわからんからね

215 ：デフォルトの名無しさん：2007/08/05(日) 01:32:40

>>213
引数がListで、そのListに生成したインスタンスを追加したりとか。

216 ：デフォルトの名無しさん：2007/08/05(日) 01:33:12

>>214
それってつまり実行して見るまで分からんってこと？

217 ：デフォルトの名無しさん：2007/08/05(日) 01:35:41

エスケープ解析の間違ったネタが書き込まれているし・・・
それに誰も突っ込まないし・・・
そもそもエスケープ解析は次世代ネタじゃないし・・・

終わってね？

218 ：デフォルトの名無しさん：2007/08/05(日) 01:38:48

当時の流れて下手に突っこんだら粘着に餌与えるだけだけどな

219 ：デフォルトの名無しさん：2007/08/05(日) 01:40:32

>>216
HotspotVMは実行時にコンパイルするんだから大丈夫

220 ：デフォルトの名無しさん：2007/08/05(日) 09:39:23

>>211はここを見るべき
http://www-06.ibm.com/jp/developerworks/java/051104/j_j-jtp09275.shtml

221 ：デフォルトの名無しさん：2007/08/05(日) 10:18:29

>>220
おまえ191だろｗｗｗ

そんな記事は知ってるわ。
そもそもインライン化とエスケープ解析は違う。

222 ：デフォルトの名無しさん：2007/08/05(日) 13:22:13

>>211
> Javaのコンパイラはソースコードとバイトコードの対応付けが規定されているので、
> そもそもバイトコードの最適化はありえない。

（　ﾟдﾟ）ﾎﾟｶｰﾝ

223 ：デフォルトの名無しさん：2007/08/05(日) 14:45:58

>>221
そうだね、エスケープ解析した結果として、スタックアロケーションしたりインライン化したりするんだね。
違う階層の言葉だったね。

224 ：デフォルトの名無しさん：2007/08/05(日) 14:47:26

if(true)が無視されてバイトコードに埋め込まれないのは、バイトコードの最適化といわないのかな。

225 ：デフォルトの名無しさん：2007/08/05(日) 14:54:08

メソッドに仮実装がある場合で、その処理を通さずメソッドの先頭で値だけ返したい場合とか
if (true) を未到達エラー回避にたまに使うな。C#はboolを変数化しなきゃいけなくて面倒だ。
ああ、まるで脱線した話題だけどね。

226 ：デフォルトの名無しさん：2007/08/05(日) 14:59:07

インライン化はエスケープ解析の結果じゃないけど、まぁいいや。
もうちょっとスレタイトルにふさわしい話題ないの

227 ：デフォルトの名無しさん：2007/08/05(日) 15:02:44

ならクロージャとJAM以外で見所のある機能があれば紹介して。

228 ：デフォルトの名無しさん：2007/08/05(日) 15:03:08

template萌えな私を叱ってください。

229 ：デフォルトの名無しさん：2007/08/05(日) 16:24:56

JITは標準のコンパイル結果に対して最適化するように動くので、
バイトコードへコンパイルするときは、
明らかな最適化が可能なもの意外は何もしないよ。

バイトコードへコンパイルする時に、
Javacが生成しない最適化されたバイトコードを生成すると、
JITは最適化の対象外になるからかえって遅くなる。
Javacを無視してバイトコード生成するのはJikesぐらい

230 ：デフォルトの名無しさん：2007/08/05(日) 16:29:39

ん？javacって最適化方針まで規格化されてるの？

231 ：デフォルトの名無しさん：2007/08/05(日) 16:31:19

規格化なんかされてないでしょ。
特定の実装の話じゃないの？

232 ：デフォルトの名無しさん：2007/08/05(日) 16:33:24

javacが生成しない最適化されたバイトコードって話がどこからでてきたのかがわからん

233 ：デフォルトの名無しさん：2007/08/05(日) 17:44:13

そもそも今のjavaの動的コンパイル技術はJITじゃなくてHotSpotだろ。

>>141
jdkのRhinoはMozillaのRhinoコードが実行できないほどの超絶劣化品。
あれらのエンジン間に互換性はないよ？
Rhinoの実装ライブラリがsun.*パッケージに移動されてるから
Rhinoに含まれるセキュリティーライブラリがどの常に利用できるとも限らんし、
バイトコード吐かないから常にインタプリタモードで動いて遅いし。
E4Xないし。上げ出したら切りがない。

234 ：デフォルトの名無しさん：2007/08/05(日) 21:45:36

>>233
HotSpotは、実行時間食ってる箇所を見つけてJITコンパイルする。
もしくは、あんまし実行されない箇所のJITコンパイルを抑制する。

大雑把な議論をする場合はJITでもHotSpotでもどっちでも良い。
変な拘り持ってる奴を相手にするんでなければ。

235 ：デフォルトの名無しさん：2007/08/05(日) 22:06:34

3回動くとコンパイルが走ると感覚的に判断してるから、
ベンチマーク前は、10回は回してからやってる。

server vmってのは何時間も動かすと更に最適化されたりするんだろうか

236 ：デフォルトの名無しさん：2007/08/06(月) 03:18:49

>>234
でもそれって最適化方法が同じ実装の場合に限られない？
サーバー向けVM製品とかの中にはHotSpotと同じ適応型最適化コンパイルするけどVM実装の都合で
あえて変わったタイミングでコンパイルしたりする奴居るよ。

>変な拘り持ってる奴を相手にするんでなければ。
てのはこいつらのこと？

237 ：デフォルトの名無しさん：2007/08/06(月) 08:15:35

>>235
感覚に頼んじゃなくて -XX:+PrintCompilation とか -Xbatch とか使ったほうがいいと思うけど

238 ：デフォルトの名無しさん：2007/08/06(月) 09:30:04

>>236
一切JITコンパイルしない最適化方法の事をJITって言ってたら
話が通じなくなるから問題だけど、タイミングが変わるぐらいなら問題ないでしょ。

239 ：デフォルトの名無しさん：2007/08/06(月) 11:41:02

>>236
> あえて変わったタイミング

kwsk

240 ：デフォルトの名無しさん：2007/08/06(月) 16:57:02

>>239
たまたま見つけたんで製品名は知らんが
アプリケーションが１度走り出したら負荷のかかるGC/動的コンパイルを
徹底的に発生させないために実行初期にとっとと見切りプロファイルしてマシン語吐いちゃってシステムの稼働を優先させるタイプのVMをどっかで見た。

でも、実行初期段階からボトルネック見つけたりパフォーマンスを平均化する技術を使ってるらしくAOTじゃないみたい。

民生用じゃないVMなんかはそういう変わった実装見るよ。

>JITコンパイルしない最適化方法の事をJITって言ってたら
MEベンダの中にはただのインタプリタ最適化を"独自の"JIT技術と呼んでるところもあるんだなｗ

漁ると結構変なVMっていっぱい。
あと、JITをただの動的コンパイル（OR最適化）のことだと思ってる奴とか。

241 ：デフォルトの名無しさん：2007/08/06(月) 17:00:03

語義的には Just In Timeで何かしてたら、なんでもJITになるわな。

242 ：デフォルトの名無しさん：2007/08/06(月) 17:23:51

JITコンパイラと名乗ってなければ、

> ただのインタプリタ最適化を"独自の"JIT技術と呼んでる

なんの問題もないだろ。

243 ：デフォルトの名無しさん：2007/08/07(火) 15:30:39

JSR-308に関してこんなん見つけた。

http://pag.csail.mit.edu/jsr308/

正式リリースからは削除予定だけど、JDK7の開発期間中は暫定的に、
/*@Readonly*/ Object x;
みたいのがあると、アノテーションとして認められるらしいんだけど、
これJDK6以前とJDK7以降で共用のライブラリ書くとき便利だから
言語仕様として残して欲しかったり……

JMLみたいな既存のツールが既に/*@...... */ ってタイプのコメント使ってるので
言語仕様に組み込むのはダメって話らしいんだけど。

244 ：デフォルトの名無しさん：2007/08/08(水) 03:26:00

コメントに書くのは邪道。

245 ：デフォルトの名無しさん：2007/08/08(水) 19:26:13

>>243
そーゆー事やりたいんだったら、JDK7以降用にソースを書いておいて、
Tree API とか使ってアノテーション落とした方が良いかもね。

246 ：デフォルトの名無しさん：2007/08/09(木) 11:58:02

エスケープ解析って、*.javaを解析するのか、*.classを解析するのかどっちなの？

247 ：デフォルトの名無しさん：2007/08/09(木) 12:35:59

>>246
.javaはまず無い。バイトコードにスタックにオブジェクトアロケーション
する命令なんか無いんだから。おそらくバイトコードをJITコンパイルする
段階でエスケープ解析していると思われる。

248 ：デフォルトの名無しさん：2007/08/09(木) 13:00:12

>>243

> @Readonly Object x;
> if (x instanceof Date) { ... } // error: incompatible annotations
> if (x instanceof @Readonly Date) { ... } // OK
> Object y;
> if (y instanceof Date) { ... } // OK
> if (y instanceof @NonNull Date) { ... } // error: incompatible annotations

これ必要なんだろか？型アノテーションってインスタンス毎に
ついてるわけじゃなくてerasureなgenericsと同じような扱いでしょ。
こんなん付けても無駄に長くなるだけなんじゃ……

249 ：デフォルトの名無しさん：2007/08/09(木) 13:10:08

エスケープ解析って、
＞バイトコードをJITコンパイルする段階
の技術だったのか。よくわかった。
ただ、「思われるとか」憶測で語っているのはどうかと。

250 ：デフォルトの名無しさん：2007/08/09(木) 13:32:15

思われなくても、JITコンパイル時の処理です。

251 ：デフォルトの名無しさん：2007/08/09(木) 13:47:33

>>248
if (list instanceof ArrayList<String>) { ... }
とかはコンパイルエラーになるのにな。

一貫性がないっつーか……

252 ：デフォルトの名無しさん：2007/08/09(木) 13:49:34

>>250 よくよくわかった。

253 ：デフォルトの名無しさん：2007/08/09(木) 14:00:37

>>243
なんつーか互換性重視だった 1.5 までと、
どっちかっつーと互換性軽視機能追加重視の最近の風潮で
ねじれが出てるような気もする。

こんぐらい無節操に機能追加される（予定だ）とプリプロセッサ使いたくなるよな。
>>245 のも発想的にはプリプロセッサだし……

254 ：デフォルトの名無しさん：2007/08/09(木) 14:30:29

アノテーション使わなければ、互換性あるんだからいいんじゃね？

255 ：デフォルトの名無しさん：2007/08/09(木) 14:36:28

どの互換性を軽視だって？

256 ：デフォルトの名無しさん：2007/08/09(木) 14:45:12

>>255
write once compile any version が出来ない、
もしくは無理にやろうとすると、新機能使えなくて不便になるって話。

257 ：デフォルトの名無しさん：2007/08/09(木) 15:03:26

内部でクロージャが使えない、とかは我慢すれば良いとしても
古いバージョンもサポート対象に入ってて JSR-308みたいのが使えないと
新バージョンで使う時に型情報が減るからな。

258 ：デフォルトの名無しさん：2007/08/09(木) 15:22:20

>>256
（　ﾟдﾟ）ﾎﾟｶｰﾝ

259 ：デフォルトの名無しさん：2007/08/09(木) 15:38:30

>>256
まぁ、言語として複数バージョンに対応するための配慮なんかは一切無いな。

#ifdef 使えばソース汚くても複数バージョンに対応できるみたいな救済策もないし。

260 ：デフォルトの名無しさん：2007/08/09(木) 15:39:23

相手に合わせようとするのは、JAVAらしくないな。
逆に、相手がJAVA（JVM）に合わせろってところにJAVAの互換性がある。

261 ：デフォルトの名無しさん：2007/08/09(木) 15:40:54

>>256
クラスワーキング・ツールキット: 古いJVMでJ2SE 5.0の機能を使う
http://www-06.ibm.com/jp/developerworks/java/050819/j_j-cwt07065.shtml

JavaのGenericsに関しては、上位互換性(下位互換性ではなく！)を満たすために
Erasure方式で実現したから、コンパイルオプション指定でJDK1.4でも動くはずだが。

262 ：デフォルトの名無しさん：2007/08/09(木) 15:40:54

>>257
まず型ありきの言語で型情報減るのは痛いよな。

263 ：261：2007/08/09(木) 16:02:17

javac -source 1.5 -target 1.4 Test.java
javac: リリース 1.5 のソースにはリリース 1.5 のターゲットが必要です。

と言われてしまった。偽情報スマソ。

一応、Retroweaverを使えば可能なようだが．．．
Retroweaver supports most 1.5 features while running on 1.4.
* generics
* extended for loops
* static imports
* autoboxing/unboxing
* varargs
* enumerations
* annotations

JDK1.4でコンパイルされたライブラリを、
JDK1.5 以降でGenericsなライブラリとして利用するのは可能だよな．．．
というかこれが無理なら何のためのerasure方式採用なんだよって感じだが。

264 ：デフォルトの名無しさん：2007/08/09(木) 16:02:53

>>261
-target jsr14 だっけ？文書化されてないんだよね、これ。

265 ：デフォルトの名無しさん：2007/08/09(木) 16:05:35

>>263
> JDK1.4でコンパイルされたライブラリを、
> JDK1.5 以降でGenericsなライブラリとして利用するのは可能だよな．．．
可能っちゃ可能だけど、パラメタ型の情報無いよ

266 ：デフォルトの名無しさん：2007/08/09(木) 16:14:57

>>264
-target jsr14を使うと可能でした。ｔｈｘ。

Java の理論と実践: Java 5 の言語機能を以前の JDK で使う
http://www-06.ibm.com/jp/developerworks/java/library/j-jtp02277.shtml

列挙型以外はほぼ問題ないようだ。

267 ：デフォルトの名無しさん：2007/08/09(木) 17:24:49

>>266
JDK5以降のライブラリや、メソッドを使うときに注意。
Autoboxingなどはちゃんと処理される。

268 ：デフォルトの名無しさん：2007/08/10(金) 01:25:21

win32 apiとか触るの面倒だし、だれかjvm上で.netが動くの作ってくれないかな
C＃をインタプリタ実行するのでもいいからさ

269 ：デフォルトの名無しさん：2007/08/10(金) 01:26:53

>>268
それはそれで凄まじいな

……考えてみるか。

270 ：デフォルトの名無しさん：2007/08/10(金) 01:51:45

C# を Java バイトコードにコンパイルする方が楽じゃない？

271 ：デフォルトの名無しさん：2007/08/10(金) 02:08:05

エスケープ解析は、*.javaに対して行っておくほうが実行効率がいいけど、その情報を*.classに残す手段がないので、実行時の最適化でしか使われていない

272 ：デフォルトの名無しさん：2007/08/10(金) 02:12:52

>>249
>>247だが、実際にソースまで追って確認したわけじゃないので
そういう表現になっただけで、JITコンパイル段階でやってるのは
ほぼ間違いないよ。まあ、厳密に言えばインタープリタモードでも
やってる可能性もあるけど、メリットが考えられない。

273 ：デフォルトの名無しさん：2007/08/10(金) 03:03:50

手段がないわけじゃないと思うけど。
stackmapっぽい新しい属性をクラスファイルに追加すればいいんだし。

ただ、静的に解析しても効果が弱いと思う。
メソッドの非仮想化やインライン展開を終えた後にやる方がいい。

274 ：デフォルトの名無しさん：2007/08/10(金) 03:17:31

>>273
それは、メソッドの非仮想化とインライン展開がエスケープ解析に与える影響がすごく大きいってこと？
そうは思えないんだけど。

275 ：デフォルトの名無しさん：2007/08/10(金) 03:46:33

>stackmapっぽい新しい属性をクラスファイルに追加すればいいんだし。

これは上で出てきたstructをJava言語でサポートするんじゃなくて、
JVMでサポートするってのに実質的に近いんじゃないか？

276 ：デフォルトの名無しさん：2007/08/10(金) 03:55:03

>>274
例えばさ、

public Object[] foo()
{
Vector v = makeVector();
v.add("bar");
v.add("hoge");
return v.toArray();
}
public Vector makeVector()
{
return new Vector();
}

みたいなコードがあったとするじゃない。 (例がやや作為的だけど、そこは目を瞑っていただきたい。)

いっけん v は foo の外にエスケープしてないように見えるけど、add とか toArray とかの中で this をどこかの static 変数に保存しているかもしれない。
誰も Vector クラスのソースを見たことあるわけじゃないし (あるかもしれないが)、 Vector がそういう変な実装になってないとは断言できまい？
そういうわけで、この時点では v をスタック上にアロケートしてしまうわけにはいかない。
(this をどこかの static 変数に保存したりできなくなってしまう。スタックは foo を抜けたら消滅するんだし。)

でも add とか toArray とか makeVector とか Vector コンストラクタを全部インライン展開できれば、v が foo の外にエスケープしてないかどうかがはっきりする。
エスケープしてないと判れば、もう別に Vector を new する必要なんかなくなって、 Vector の全フィールドをみんなスタック上に展開してしまえる。

makeVector は final じゃないから実はオーバーライドされてて他のクラスを返してるかもしれないが、これも非仮想化されてればインライン展開できる。

・・・って思ってるんだけど、現実のJVMがどこまでやってるかは知らない (´･ω･`)

277 ：デフォルトの名無しさん：2007/08/10(金) 04:44:16

>win32 apiとか触るの面倒だし
ここらへんあるから実質C#はマルチプラットフォームじゃないよね。

278 ：デフォルトの名無しさん：2007/08/10(金) 09:53:41

>win32 apiとか触るの面倒だし
それだけだったら、win32 api を触らなくて済むようなGUIフレームワークとかを使えばいいだけと違うん？

279 ：デフォルトの名無しさん：2007/08/10(金) 09:56:34

>>273
> ただ、静的に解析しても効果が弱いと思う。
> メソッドの非仮想化やインライン展開を終えた後にやる方がいい。

二行目は静的/動的と関係ないじゃん。

280 ：278：2007/08/10(金) 09:57:41

って、.C# か・・・じゃあ GTK# とか・・・びみょかな・・・

281 ：デフォルトの名無しさん：2007/08/10(金) 11:35:35

>>279
静的に＝.javaのコンパイル時にって意味で書きました
.javaコンパイル時に非仮想化・インライン展開とかできないでしょ
わかりにくくてごめんなさいね
この暑さでちょっと疲れてるんだ

282 ：デフォルトの名無しさん：2007/08/10(金) 11:49:09

出来ないことないじゃん。もうInner classあるんだから。

283 ：デフォルトの名無しさん：2007/08/10(金) 11:54:25

Inner class って、なんか関係が？

284 ：デフォルトの名無しさん：2007/08/10(金) 11:59:12

インナー・クラスの非仮想化・インライン展開はソース・コンパイル時に出来る。

285 ：デフォルトの名無しさん：2007/08/10(金) 12:21:17

--- Outer.java ---
public class Outer {
class Inner {
int foo( ) { return 1; }
}
void bar( Inner inner ) {
System.out.println( inner.foo( ) );
}
}

インナークラスってこういうのでしょ。
inner.foo( ) をインライン展開するつもり？

--- Main.java ---
public class Main {
public static void main( String[] args ) {
Outer outer = new Outer( );
Outer.Inner inner = outer.new Inner( ) {
int foo( ) { return 2; }
};
outer.bar( inner ); // → 2 を出力する
}
}

286 ：デフォルトの名無しさん：2007/08/10(金) 12:42:11

そもそもprivate:ならインライン展開し放題じゃない。

287 ：デフォルトの名無しさん：2007/08/10(金) 12:45:06

それはまぁね。

288 ：デフォルトの名無しさん：2007/08/10(金) 17:18:14

で、実際デフォルトで（知らないところで）インライン展開はされているのか？
それも、メモリ上に展開なのか、ソースコード（.class）のバイト数が増加しているのか。

289 ：デフォルトの名無しさん：2007/08/10(金) 17:20:42

> で、実際デフォルトで

（　ﾟдﾟ）ﾎﾟｶｰﾝ

290 ：デフォルトの名無しさん：2007/08/10(金) 17:45:00

はいはい、あげあし君はさようならで

291 ：デフォルトの名無しさん：2007/08/10(金) 17:58:23

似たようなことを議論してるよ。
stack allocateについては、
アノテーションで指示するか、
ByteBufferでアドレッシングしてくれってことのようだ。
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4820062

292 ：デフォルトの名無しさん：2007/08/10(金) 18:31:07

>>291
そこの議論の対象はC/C++の struct で作られたような
データ構造にアクセスする事であって、
言語仕様的に stack allocated object が欲しい場合は
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4213096
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4809540
どっちかにvoteしろって書いてあるよ

293 ：デフォルトの名無しさん：2007/08/10(金) 18:35:28

C# だと各メンバに FieldOffset が指定できるよね
>>291 はそういう話じゃないの？

294 ：デフォルトの名無しさん：2007/08/10(金) 18:54:29

>>292
で、君はそっちのREFをチェックしてからものを言ってるわけなのかな？
>>293
C#がどうしたって？
ざっとみてスタックがどうとか言う議論になってたから似たようなの出してみたのだけど。

295 ：デフォルトの名無しさん：2007/08/10(金) 19:02:35

いや、データをバイト列にパックする話とスタックアロケーションは別の問題だから。

296 ：デフォルトの名無しさん：2007/08/11(土) 03:07:02

君の都合にあわないからといって、いちいち相手にｹﾁをつけるところは君の悪い癖だな

297 ：デフォルトの名無しさん：2007/08/11(土) 16:11:19

なあ、全員「デフォルトの名無しさん」じゃねえか
同一人物間でケンカ自演してるのってどうよ

って突っ込んでるオレも同一人物な訳だが

298 ：デフォルトの名無しさん：2007/08/11(土) 16:22:00

夏休み的なツッコミだな

299 ：デフォルトの名無しさん：2007/08/11(土) 19:00:47

ボケだろ、ボケ

300 ：デフォルトの名無しさん：2007/08/13(月) 15:24:33

ノリツッコミか

301 ：デフォルトの名無しさん：2007/08/18(土) 04:47:25

JDK7 build18
http://download.java.net/jdk7/changes/jdk7-b18.html
http://download.java.net/jdk7/binaries/

細かいバグ修正とか。

302 ：デフォルトの名無しさん：2007/08/19(日) 07:15:13

java LnFっていずれocanからSwing new LnFと謳ってるNimbusになるのかね？

303 ：デフォルトの名無しさん：2007/08/19(日) 08:19:46

Nimbusはスクロールバーがヤだ

304 ：デフォルトの名無しさん：2007/08/19(日) 15:38:42

確かにへぼいな

305 ：デフォルトの名無しさん：2007/08/19(日) 16:52:27

javaのスレでC#の話をするなボケども

306 ：デフォルトの名無しさん：2007/08/19(日) 17:31:28

JSR 310ってどうよ

307 ：デフォルトの名無しさん：2007/08/19(日) 19:22:01

>>302
Nimbusはごっつい雰囲気が強すぎて微妙ー
Aquaとかみたいな甘いデザインにしてくれと思う。

>>306
各所のブログでJSR 310は入れてほしくないと言われているな。
どうなんだろう・・・

308 ：デフォルトの名無しさん：2007/08/19(日) 19:34:49

使うことはあまりないだろうな。

309 ：デフォルトの名無しさん：2007/08/19(日) 20:46:56

>>306
オレは JSR-310 スライドに入ってる

> What's wrong with Date?
> ・Uses two digit years from 1900
> ・January is 0, December is 11

のセンスを見て、なんだかなーと思った。
この辺って、たぶん Cの標準ライブラリの
struct tm と同じ方式になってるだけでしょ。
きちんと文書化してあれば大して問題になるとも思えんし……

310 ：デフォルトの名無しさん：2007/08/19(日) 21:28:31

>>306
https://jsr-310.dev.java.net/nonav/javadoc/index.html

311 ：デフォルトの名無しさん：2007/08/20(月) 17:49:33

>>309
いや、正直、1月が0とかは文章にしていてもあり得ない。
使うたびにAPIをその仕様で設計したヤツに殺意を覚える。
ライブラリの使い方からCと違うんだから中途半端にわかりにくくしてるだけ。

312 ：デフォルトの名無しさん：2007/08/20(月) 18:02:22

文章化してあるから問題なしって・・・

313 ：デフォルトの名無しさん：2007/08/20(月) 18:56:22

>>311
分かりにくいっても、C言語使った事あれば1月が0になる事もあるってのは予測可能だし。
不勉強な上に不注意な連中が躓く原因であるのは確かだろうけど、
たぶん、そういう連中は月フィールドが 1オリジンになったら Calendar と互換性なくなって躓くだろう。
ゼロから新しいAPIを作るならともかく、既存の Calendar と共存するつもりなら、
新しいクラスを作って、そのクラスの月フィールドを 1オリジンにしたぐらいじゃ幸せにはなれない。

314 ：デフォルトの名無しさん：2007/08/20(月) 19:37:12

>>311
まぁ有り得ないとか殺意を覚えるってのは程度の差だからなんとも言えんけど。

オレとしては 1月を 1 にしたければ、とりあえずユーティリティメソッド1つ作れば良いと思うんだわ。
で、オレの感覚からすれば、ユーティリティメソッド1つで解決するような問題を掲げて
わざわざ新API作ろうって感覚の方が有り得ないんだわ。
スライド見て感じた事ってのはそーゆー事。

315 ：デフォルトの名無しさん：2007/08/20(月) 19:43:10

今から新しく作るんなら、enumにすればいいんじゃまいか。
public enum Month { JANUARY, FEBRUARY, ... }

316 ：デフォルトの名無しさん：2007/08/20(月) 21:05:04

そして旧暦閏月で困ると。

317 ：デフォルトの名無しさん：2007/08/20(月) 21:21:43

閏月対応してるクラスってあったっけか？

318 ：デフォルトの名無しさん：2007/08/20(月) 23:19:30

Timeの方は刹那とかに対応しないかなと思ってみたりｗ
10^-18なんて精度表せないだろうが。単位として扱えたら面白そう。

319 ：デフォルトの名無しさん：2007/08/20(月) 23:25:25

誰が使うんだ、そんなもん……

320 ：デフォルトの名無しさん：2007/08/20(月) 23:41:02

ナノ時間取得はコストが高すぎるんだよな・・・

321 ：デフォルトの名無しさん：2007/08/21(火) 01:23:50

>>319
坊さん用ソフト開発なプログラマｗ

24時間=30牟呼栗多=900臘縛=54,000怛刹那=6,480,000刹那という変換するとか。

スウォッチインターネットタイムも欲しいな。

322 ：デフォルトの名無しさん：2007/08/21(火) 01:33:32

坊さん用なら卒塔婆プリンタの方が喜ばれそうだが。

っつか、Wikipedia漁って適当な事言ってるだけじゃね？

323 ：デフォルトの名無しさん：2007/08/21(火) 08:50:41

http://www.atmarkit.co.jp/news/200708/20/httpcomp02.png
　同じくフォーチュン1000企業のWebサイトを対象とした調査で、
アプリケーションサーバのシェアはASP/ASP.NETがトップで51.5％のシェアと2年前から7.9ポイントの上昇。
J2EE、JSP、WebLogic、WebSphere、TomCatなどのJavaプラットフォームが2位で12.7％。
そのほか、PHP（6％）、ColdFusion（3.2％）、Perl（1.9％）、Python（0.2％）などとなっている。

とりあえず、ASP.NETの普及が断トツに進んでいる。
Javaは新規プロジェクトで採用される可能性はほとんどなくなってきてるしな。

324 ：デフォルトの名無しさん：2007/08/21(火) 09:53:51

そろそろJava終了のアナウンスがSunからあるのかな
まぁいい思い出になったよ

325 ：デフォルトの名無しさん：2007/08/21(火) 10:20:43

>>323
ASPとASP.NET合計で51.5％か。意外に低シェアだな。

>>324
Sunあぼーんして、IBM & Google が実権を握ってくれる方が嬉しいなぁ。

326 ：デフォルトの名無しさん：2007/08/21(火) 10:23:58

>>315
一応、Calendar.JANUARYとか定数ならあるよ。
そっち使うでしょ普通。

327 ：デフォルトの名無しさん：2007/08/21(火) 10:24:54

あ、そっち使うでしょ、ってのは0とか1とかじゃなくて、って意味。
enumならなおよろしいけど、互換の問題がねぇ・・・。

328 ：デフォルトの名無しさん：2007/08/21(火) 13:37:56

>>327
日付扱うときは、だいたいユーザー入力だから無意味。
プログラム中でJANUARYとか指定することなんてあまりないんじゃね？

329 ：デフォルトの名無しさん：2007/08/21(火) 16:31:57

ユーザー入力を文字列として持ち回すと難儀だよね。

でも、WEBアプリにしろSwingにしろ、フレームワークとか
日付入力コンポーネントとかでDate型で最初から
扱える奴あるし、今時大概そうじゃないのかな。

プログラムの中で月決め打ちってのは確かにあまりないですね。
テストコードくらいか。

330 ：デフォルトの名無しさん：2007/08/21(火) 17:51:54

>>314
いや、ラッパークラスを用意すればいいってのはユーザ側の対応になる。
それはつまり、現状のDate型の変更に依存する訳だし
自分が書いたコードはラッパークラスを必ず含まなくてはならなくなる。
それならコアAPIに入っててくれよ、と思わないか？

今のDate型の実装だと、実装者自身が作り直したいと考えても
仕方がないような作りが多々ある。Calendarを追加して手当したけど
時間、日時を扱う場面は多くある。
これだけJavaが使われてその問題点が明らかになったんだから
新しくより合理的なAPIができてもいいと思う。
言うなればJava3とでもいうものへのへの緩やかな変化。

基本的なモノだからこそ改良が重要になってくるとは思うんだ。
アトは失敗しないようにしっかりと作ろうってところだろうか。

331 ：デフォルトの名無しさん：2007/08/21(火) 18:15:12

Calendarいらないってがんばっている人もいる。
tp://d.hatena.ne.jp/nowokay/20070628
tp://d.hatena.ne.jp/nowokay/20070630

これが本当に通ってくれれば
憂いなしで嬉しいな。

332 ：デフォルトの名無しさん：2007/08/21(火) 18:29:39

つか、きしださんまで月間違ってるし！

333 ：デフォルトの名無しさん：2007/08/21(火) 19:05:53

>>330
ラッパークラスで解決しようというのはダメだろ。
Calendar の set やら get をラップして 1月が1になるようにしても、
自分の目の届く範囲だけなら構わないけど、
第三者が作ったクラスに渡す場合には、そのまま渡したら 1ヶ月ずれる。
そんなゴミをコアAPIに入れられたら、 Calendar をやり取りする
メソッド作る場合に、必ず instanceof とかでチェックしなきゃいけなくなる。

334 ：デフォルトの名無しさん：2007/08/21(火) 19:08:21

>>331
無理じゃね？

java.util.Date は Serializeable だし、
Date の TimeZone対応とかやったら、
シリアライズされたデータの互換性なくなるんじゃないか？

335 ：デフォルトの名無しさん：2007/08/21(火) 19:10:30

W3C-DateTimeからRFC2822-DateTimeに用意に変換できるようなものが欲しい。
RFCのほうはCWFSのおかげでやたらパースがしにくい。

336 ：デフォルトの名無しさん：2007/08/21(火) 19:23:34

>>330
> これだけJavaが使われてその問題点が明らかになったんだから
> 新しくより合理的なAPIができてもいいと思う。
あっても良いけど、closure とかに比べると優先度は低いよね。

それに「問題点」ってのも個人個人で違うわけで、1月が 0 なのがダメなのか、
setter の戻り値の型が void だから、1行に詰め込んで書けないのが問題なのか
それ以外なのか。

現状では愚痴とか不満は出てるけど、
それらを一つに纏めて、多くの人が納得でき、多くの人が幸せになれるような
解決策が提示されているかっていうと、少なくとも JSR-310 は違うと思う。

337 ：デフォルトの名無しさん：2007/08/21(火) 20:22:16

>>335
まえにjavascriptの実装がどっかのブログで公開されてたぞｗ

338 ：デフォルトの名無しさん：2007/08/21(火) 22:16:24

>>336
いや、JSR-310はまだ固まってないし。
そういう動きがある、ということしか言えないと思う。
なんで、これからの頑張り次第でしょ、という話。

それとも、「日付関係の新しいAPIは要らないぜ」という話？

339 ：デフォルトの名無しさん：2007/08/21(火) 23:24:14

>>338
1月が 1 と書けるようになっただけ、の Calendar みたいなクラス作られても
あっちのフレームワークでは互換性のために旧Calendar要求され、
こっちのフレームワークでは機能性のために新API要求され、
みたいに手間が増えるだけになる可能性が高い。

かと言って、Calendar が解決しなかったニッチな要求のためだけのAPI作ったら
わざわざ標準APIに突っ込む必要ないって話にもなるし。

既存のDate＆Calendarがある状況で
日付関係の新しいAPIを作るのは凄く難しいと思ってるんだけど、
1月が 0 なのがキモイみたいな事かかれると、
マトモなものが出来るのか心配になるって話。

340 ：デフォルトの名無しさん：2007/08/21(火) 23:27:03

動画再生用のSwingコンポーネントが標準化されたりしたら嬉しいのだけど、
JavaFX Scriptに合わせて対応してくれたりせんのかねぇ。
Flashは次のバージョンでH.264にも対応するとか発表してるし、
本気でRIA市場に乗り込むならここらへんを抑えてくれないと支持しにくい。

341 ：デフォルトの名無しさん：2007/08/21(火) 23:36:53

つ JMF

342 ：デフォルトの名無しさん：2007/08/21(火) 23:38:58

JRE以外にインスコしてもらえるわけないじゃんｗ

343 ：デフォルトの名無しさん：2007/08/21(火) 23:51:58

jarに全部突っ込んでマニフェストでパス指定するか。JWSでいいだろ。

けどJMFのH.264コーデックがまだIBMのプロプラライセンスものしかなかった気がする。

344 ：デフォルトの名無しさん：2007/08/22(水) 09:04:57

>>339
相互変換はコンストラクタ一発なんだから問題ないんじゃね？

345 ：デフォルトの名無しさん：2007/08/22(水) 09:09:49

SilverlightやFlashに比べて、JREはインストール面で不利すぎる気がするのですが
軽量プラグインとか出す予定はないのでしょうか？

346 ：デフォルトの名無しさん：2007/08/22(水) 09:24:14

何を削るかで揉める事必至だろうなぁ・・・
いっそのことJ2MEのランタイムを作ってそれを軽量プラグインにするとか

347 ：デフォルトの名無しさん：2007/08/22(水) 11:31:10

分割ロードの方が良さそうだなあ。
Javascriptは何でも一つのファイルにぶち込むのが流行ってきているけれども。

348 ：デフォルトの名無しさん：2007/08/22(水) 14:09:41

>>345
Java Kernel と呼ばれているものを jdk6 update 4 で出す予定

http://weblogs.java.net/blog/enicholas/
http://weblogs.java.net/blog/forax/archive/2007/08/java_kernel_in.html

349 ：デフォルトの名無しさん：2007/08/22(水) 14:24:44

>>344
Date と Calendar はコンストラクタ一発で変換できてないじゃん。

それと同じ事が起こる事は十分予測可能。

350 ：デフォルトの名無しさん：2007/08/22(水) 14:30:23

>>349
っつーか、コンストラクタ一発で変換できても煩雑なのは変わらんのだがな。

351 ：デフォルトの名無しさん：2007/08/22(水) 20:01:17

”よく知られた日付型”がこれ以上混在されてもうざいだけだよ。
DateにCalendarにsql.Dateと、”よく知られた日付型”は、もう既に食傷気味です。
所詮は64bit unix epocと割り切ったユーティリティメソッドが拡充される方がよほど嬉しい。

352 ：デフォルトの名無しさん：2007/08/22(水) 21:21:02

なるほど。
良くあるパターンに特化したユーティリティメソッドを用意してくれる方が
ありがたい気がする。

353 ：デフォルトの名無しさん：2007/08/22(水) 21:49:03

JREのインスコなんてウィザードに従えば良いだけだろ。
それより、システム管理全体がside by sideへ以降してきてメンテにエンドユーザーの負担が掛かってると思う。

354 ：デフォルトの名無しさん：2007/08/23(木) 01:19:58

JSR 310はいいと思う。
ユーティリティ・クラスとしても上出来。

355 ：デフォルトの名無しさん：2007/08/23(木) 03:08:43

>>354
そうなん？

>>310 に JSR-310 のAPIリファ来てるけど、
これどんな時に便利なのかサンプルコードとか書いてくれん？

っつか、オレには Moment や Period のサブクラスが
年、月、日、時、分、秒と分かれてる必要性がイマイチわからん。

356 ：デフォルトの名無しさん：2007/08/23(木) 04:03:13

タイムベースの処理が必要でそのフレームワークを自前で作らなきゃいけないときに下のライブラリとして使えそうだな。

357 ：デフォルトの名無しさん：2007/08/23(木) 04:06:51

>>310がJSR-310のリンクになっていることに
今になってようやく気が付いた。

なんか黄色ナンバーの車を1日10台見たとか
ワーゲン見たとかその程度にちょっと幸せ。

358 ：デフォルトの名無しさん：2007/08/23(木) 08:11:21

>>355
ぶっちゃけ、>>310より>>331の方が良いと思う……

359 ：デフォルトの名無しさん：2007/08/23(木) 08:43:24

>>356
逆に言うと、それ以外の目的に使えなさそうじゃね？

360 ：デフォルトの名無しさん：2007/08/23(木) 08:46:22

どっちがいいとかそういうもんじゃないだろ。
310はベースとなる時刻クラスを提供するんだから。

361 ：デフォルトの名無しさん：2007/08/23(木) 08:49:25

今のままだったら Date ＆ Calendar の方が下位層で
JSR-310 はそれに乗っかるだけの上位層になりそうだが

362 ：デフォルトの名無しさん：2007/08/23(木) 08:50:20

（　ﾟдﾟ）ﾎﾟｶｰﾝ

363 ：デフォルトの名無しさん：2007/08/23(木) 08:52:26

おまけに使用用途が酷く限定されている、と。

364 ：デフォルトの名無しさん：2007/08/23(木) 09:01:34

>>360
んじゃ言い直そう。

JSR-310 のスライドにあがってる、
What is wrong with Date and Calendar?
の解決策としては、今のところ>>331の方が良さそうに見える。Date の
Could not be successfully localized とか Most methods deprecated、
SimpleDateFormat の Calendar cannot be directly formatted
は解決できそうだ。

365 ：デフォルトの名無しさん：2007/08/23(木) 09:25:39

>>360
310が提供するベースとなる時刻クラスってどれよ？

366 ：デフォルトの名無しさん：2007/08/23(木) 11:36:39

文字列からのファクトリメソッドは、
別クラスにした方がいいんじゃないの？
L10N考えると劇重プロジェクトだし。

GNU dateコマンドみたいな時間指示を考えると、やること一杯ある。

367 ：デフォルトの名無しさん：2007/08/23(木) 11:46:17

これはひどい

ベースとなる時刻クラス・・・ Instant かねぇ
でも CalendarDay や TimeOfDay との相互変換はできそうになく
既存の Date や Calendar との繋がりもない
どうやって使うんだこれ

368 ：デフォルトの名無しさん：2007/08/24(金) 00:25:02

310はまだ、かなりドラフトな感じだが、
PeriodとMomentとその実装クラスを細かく分けるのは、
安全でかつ読みやすくなるのでよいと思う

例えばMomentにMomentは追加できないがPeriodは追加できるとか

369 ：デフォルトの名無しさん：2007/08/24(金) 01:23:17

Instant と fully defined な SingleMoment を区別する理由と、
Period と Interval を区別する必要とか、
Duration とか良く分からん。
Duration と Inteval はまだ出来てないみたいだけど。

>>368 も同意っちゃ同意なんだけど、
それって Moment と Period が別になってる理由にはなっても、
Moment や Period のサブクラスが年、月、日、時、分、秒と
細かく分かれてる理由にはならんよね。

370 ：デフォルトの名無しさん：2007/08/24(金) 01:58:25

>> 369
>Moment や Period のサブクラスが年、月、日、時、分、秒と
>細かく分かれてる理由にはならんよね。
なんで?
Days days = ...;
days = days.plus(Days.days(3));
とか具体的な型が決まっていたら安全かつ読みやすいじゃん。

しかしメーリングリストだとなんかいろいろ提案とか出されたり、まだまだな感じがしてきた。
sunの中の人が書いてるが、
http://blogs.sun.com/yk/date/20070705
既存のAPIとの互換性とか国際化も考えると大変そうだね。

371 ：デフォルトの名無しさん：2007/08/24(金) 02:02:32

>>369
後者については type safe のためとか？

もしくは、
Moment moment = build(dayOfMonth(1), hourOfDay(3));
とかやると、毎月 1日午前 3時をあらわすようになるとか……

372 ：デフォルトの名無しさん：2007/08/24(金) 02:05:26

>>370
おいおい……

一見型安全かもしれないけど、
それだけだと、逆に Period で 1カ月と3日とか複合的な指定できなくなるんですけど……

373 ：デフォルトの名無しさん：2007/08/24(金) 02:10:03

>>371
あぁなるほど。可変長引数のビルダーメソッドで纏めるとか
そーゆー場合には別々のクラスになってないとダメだな。

>>370
これはひどい

374 ：デフォルトの名無しさん：2007/08/24(金) 02:34:16

>>372
Periodとしての一ヶ月というのは日数として組み合わせて扱えない気がするが。

375 ：デフォルトの名無しさん：2007/08/24(金) 02:37:46

（　ﾟдﾟ）ﾎﾟｶｰﾝ

376 ：374：2007/08/24(金) 02:48:29

今のAPIを見る限り、複数のPeriodを組み合わせたPeriodというのはない気がする。
Monthsに関しては月によって日数は変わるので、months.plus(Days.days(3))みたいな計算は書けないと思うが。

しかしCalendarDayはplus(Period...)というのを持ってるので、一ヶ月と3日後とかを計算できると思う。ただMinutesとSecondsとの変換とかできそうな気がするのにできないように見えるのはよくわからない。

377 ：デフォルトの名無しさん：2007/08/24(金) 02:51:08

>>372
そーゆーのは、まだない Interval でやるって話なんじゃね？

しっかし、凄く分かりにくい API だな、これ。
そこそこ経験がある奴でもサンプルコードが無いと一行も書けないぞ。

378 ：デフォルトの名無しさん：2007/08/24(金) 02:55:09

>>373
instanceof で比較するところを enum と switch で置き換えれば
良いだけだから、別々のクラスになってる必要は全くなかったりする。

379 ：374：2007/08/24(金) 03:03:40

やっぱりわかりにくいのだろうか?

変換とかファクトリとかのメソッドがどこにあるかわからず、分かりにくい、というのはあるかもしれないが、
そもそも日付と時間の長さなどを区別して扱うこと自体が複雑で、結局intとかで扱っても値の種類を把握していないといけないのでは。

ある程度、単位を型でエンコードして分かりやすくすることで安全で読みやすいコードになる方がよいと思うのだが...

380 ：デフォルトの名無しさん：2007/08/24(金) 05:59:11

Sun が NASDAQ での銘柄記号を SUNW から JAVA にかえるんだそうな。
http://blogs.sun.com/jag/date/20070823
http://blogs.sun.com/jonathan/entry/java_is_everywhere

いや、次世代Javaと関係ないけど。
っつーか、これジョークじゃないの？ 4月1日じゃないけどさ。

381 ：デフォルトの名無しさん：2007/08/24(金) 07:09:27

Dateみたいな基本的なところに今から手を入れるのがアリなら、
Numberもどうにかしてくれんかな。
やっぱり Integer inherits Double であってほしいし、BigDecimalで
持っている四則演算メソッドはNumberすべてで使いたいが。

382 ：デフォルトの名無しさん：2007/08/24(金) 07:17:34

>>380
JAVAの株があがったとか下がったとかが問題になってくるわけか。
そしたら、JAVAと大文字で書くやつはJavaのことを知らないという伝説が強くなるわけだ。

383 ：デフォルトの名無しさん：2007/08/24(金) 07:43:01

>>381
Numerics関係は難しいんだよな、後からいじるの。
非互換の影響が大きすぎて。

仕様お目付け役だった、Guy Steeleさん、この辺が弱い。

384 ：デフォルトの名無しさん：2007/08/24(金) 16:04:46

元がSUNWならJAVAWにすればいいのにコンソール出ないし・・・。

385 ：デフォルトの名無しさん：2007/08/24(金) 16:57:17

>>381
メソッド追加はありでも継承関係は変えられないだろうな

386 ：デフォルトの名無しさん：2007/08/29(水) 21:26:22

そろそろ deprecated のクラスやメソッドを一掃してほしい

387 ：デフォルトの名無しさん：2007/08/29(水) 22:30:24

Cloneable を Clonable に直してほしい

388 ：デフォルトの名無しさん：2007/08/30(木) 02:13:33

creat....

389 ：デフォルトの名無しさん：2007/08/30(木) 23:47:25

catch必須例外を堂々と無視できるプラグマを追加してほしい。

390 ：デフォルトの名無しさん：2007/08/31(金) 03:25:48

アホか例外処理の意味ないだろ。
握り潰すことすら面倒くさいか？ｗ

391 ：デフォルトの名無しさん：2007/08/31(金) 12:32:21

JDK7 build19
ttp://www.java.net/download/jdk7/changes/jdk7-b19.html
ttp://download.java.net/jdk7/binaries/

forumで話題になっていた
4811096 Allow mixing of heavy and lightweight components
が入った様子。
SwingとAWT混ぜるなっていうのが古い話になるわけだ。
あと、レポジトリ管理、Teamwareを完全撤廃？SCCSキーワードの削除ってのが結構あった。
公開してるのも、Subversionでだしね。OpenSolarisで採用してる、Mercurialはないんだろうか？

392 ：デフォルトの名無しさん：2007/08/31(金) 21:15:56

>>390
めんどくさい。
どうでもいいコンソールプログラム書くときは
全部例外がトップレベルに流れて死んでくれていい。

あと、どうせならインタフェースの実装も堂々と無視できるプラグマも欲しい。
適当にnullとか0とかfalseとか、あるいはNotImplementedException投げるとか。

IDEにやらせればいいんだけどさ。

393 ：デフォルトの名無しさん：2007/08/31(金) 21:52:53

>>392
お前はCの方が合ってるんじゃないか？
つーかその程度の捨てアプリならスクリプトで実装すれば良いだけじゃん。

394 ：デフォルトの名無しさん：2007/08/31(金) 22:32:46

mainメソッドにthrows ExceptionってすればOK

395 ：デフォルトの名無しさん：2007/09/01(土) 02:07:00

Javaの例外処理の面倒くささはMatzがどっかで言及してたね

396 ：デフォルトの名無しさん：2007/09/01(土) 02:21:10

silentClose(Closeable) みたいなメソッド作るとか
使い捨てアプリ作る時は throws Exception つけるとかすれば
そこそこ改善すると思うんだけどね

397 ：デフォルトの名無しさん：2007/09/01(土) 02:29:38

>>395
むしろその例外処理の面倒さがないからこそ
他の言語があぶなっかしくて使えない。
コード品質重視だと特に。

398 ：デフォルトの名無しさん：2007/09/01(土) 06:37:06

むしろ投げる例外をdoc,code上で明文化されてないと何拾って良いか分からないだろ。拾えないと例外に対処できない。

throw,throwsでthrowable以外が飛んでくるのもおかしいし。

399 ：デフォルトの名無しさん：2007/09/01(土) 16:45:03

ExceptionはThrowableである。以上。

400 ：デフォルトの名無しさん：2007/09/02(日) 09:52:45

例外処理の仕組みが問題というよりも
IOExceptionとかSQLExceptionのようなレベルの例外を
チェック例外にしてるのが問題だと思う
SpringやS2やHibernateなら、これらの例外をランタイム例外にラップしてくれるし
JavaEE5ではランタイム例外を多用してるけど
肝心の、JavaSEのコアなAPIがチェック例外だらけだからな

>>397
現実には、Javaのチェック例外記述のめんどくささに嫌気がさした開発者が
catch (Exception e) {
e.printStackTrace();
}
とか書いて、返って品質悪化するパターンの方が高い気がするorz

401 ：デフォルトの名無しさん：2007/09/02(日) 11:41:41

あと InterruptedException も握りつぶされて困りやすいチェック例外だ

あー
InterruptedIOException とか、きっと知らんうちに IOException もろとも握りつぶしてる気がしてきた

try {
......
} catch (InterruptedIOException e) {
Thread.currentThread.interrupt();
} catch (IOException e) {
......
}

なんて、書いた覚えがないよ

402 ：デフォルトの名無しさん：2007/09/02(日) 11:50:49

例外のためのEffective Javaみたいなのがあれば読んでみたい。
こういうのはお習字の世界だから仕様としてどうこう変えるもんでもないし。

403 ：デフォルトの名無しさん：2007/09/02(日) 13:29:09

>>400
IOExcepotionとかは>>396みたいなメソッドがあれば解決する問題

後半に関して言えば
そーゆー奴は面倒くさいので例外処理しないし
他人のために必要な例外関連のドキュメントも書かない
ので検査例外をあってもなくてもそれほど品質は変化しないと思うが

404 ：デフォルトの名無しさん：2007/09/02(日) 13:39:45

何が言いたいのやら・・・必死なことだけは解るが

405 ：デフォルトの名無しさん：2007/09/02(日) 13:48:59

IOExceptionやSQLExceptionがチェック例外なのは当然だろ？
外部リソースに依存してんだから、チェックし無い方がどうかしてる。
DAOならそれらをcauseにして、DAOExceptionみたいに新たなチェック例外にくるむがよろし。

406 ：デフォルトの名無しさん：2007/09/02(日) 13:55:57

closeが例外なげるバカなAPI

407 ：デフォルトの名無しさん：2007/09/02(日) 14:04:03

close は flush を伴うからエラーが発生する可能性はある

408 ：デフォルトの名無しさん：2007/09/02(日) 14:07:19

closeが例外なげるのがバカってどんだけゆとり脳なんだ

409 ：デフォルトの名無しさん：2007/09/02(日) 14:14:18

思うに、チェック例外をキャッチしないと
警告出すだけの仕様だったらどうなっていただろうか？

410 ：デフォルトの名無しさん：2007/09/02(日) 14:26:33

throws SQLException って書いてないのに throw new SQLException() するような
混ぜるな危険メソッドが書き放題で検査例外の意味がなくなる。
それでいてソースに SuppressWarnings("ignorecheckedexception") とか
コンパイル時に -ignorecheckedexception とか必須だと手間がかかるだけ。

中途半端で役に立たないソリューションの見本だな。

411 ：デフォルトの名無しさん：2007/09/02(日) 14:30:17

んなもんソースレビューで片付けろよ

412 ：デフォルトの名無しさん：2007/09/02(日) 14:44:28

closeが検査例外を投げるバカなAPI

413 ：デフォルトの名無しさん：2007/09/02(日) 14:49:51

>>411
第三者の作ったライブラリやフレームワーク使う時は
それらも全部ソースレビューすんの？

414 ：デフォルトの名無しさん：2007/09/02(日) 14:51:10

必ずソースが見れるとは限らんし

415 ：デフォルトの名無しさん：2007/09/02(日) 15:05:42

>>405
IOExceptionとかって多くの場合リカバリできるの?
リソースの解放はfinallyでやるからチェック付き例外とは関係ないと思うし

なるべく例外がチェックできるべきだという意見は多い様に見えるが、一般的にそれらの例外がほとんどリカバリできる処理を書けないならば >>400の言うようにAPIの設計の問題では?

416 ：デフォルトの名無しさん：2007/09/02(日) 15:10:27

ソケット使って読み書きしてる時にIOExceptionが発生したらリトライするとかあるよね

417 ：デフォルトの名無しさん：2007/09/02(日) 15:53:29

>>416
そういう特定の事情のために、すべてのIO処理で面倒なコードを書かないといけないのはアホ

418 ：デフォルトの名無しさん：2007/09/02(日) 15:56:09

というか、例外が出ないコードで例外の補足が必要になるのが、設計ミス
System.in.read()
とか

419 ：デフォルトの名無しさん：2007/09/02(日) 15:57:17

面倒っても、throws IOException を宣言するくらいのもの。
その場で対処しない例外は上へ送る。

420 ：デフォルトの名無しさん：2007/09/02(日) 16:02:53

System.in.read() ってプラットフォーム側の標準入出力の実装方法によっては
例外が出る可能性があるんだが

421 ：デフォルトの名無しさん：2007/09/02(日) 16:10:33

俺としてはNumberFormatExceptionが実行時例外なのが許せないくらいなんだが。
外側のことは一切信用しないという性悪説プログラミングが心情だとね。

422 ：デフォルトの名無しさん：2007/09/02(日) 16:18:48

俺はUserTransactionのメソッドを使ってみたとき、
Javaのチェック例外は、API側が使い方を根本的に間違ってると痛感したよｗ

423 ：デフォルトの名無しさん：2007/09/02(日) 16:24:01

>>412みたいな事を言う奴から間違ってると言われても

424 ：デフォルトの名無しさん：2007/09/02(日) 16:31:07

>>419
それで上へ送った例外は結局どうなるわけ?
throws IOExceptionをまき散らして、
RuntimeExceptionになるか握りつぶされるぐらいじゃないの?

>>421
一切信用しないというのはいいが、それはどうやって処理される?
他の値で代用するのは多くの場合問題がある気がするし、
再度入力を促すことになると思うが、
可能な場合と不可能な場合(処理を中断するしかない場合)があると思う

...NumberFormatExceptionに関しては微妙な気がしてきた
RuntimeExceptionでよい場合も多いと思うが...

425 ：デフォルトの名無しさん：2007/09/02(日) 16:54:22

最近じゃ例外もAOPで処理するし、リソースはfinallyで閉じるからあまり関係ないしな
matz氏がブログで、例外をぎりぎりまで捕捉しないのがRuby流って書いてたけど
結局はそれがいちばん効率的で、開発者に都度catch処理を強制するよりも品質が上がるんだよね。
例外処理がなくても、異常終了で落ちるからテスト時にすぐわかるが、
catchで不用意に握りつぶされた例外はやっかいだし

426 ：デフォルトの名無しさん：2007/09/02(日) 17:06:07

何層か下のフレームワーク/ライブラリが投げてくる実装依存の例外もやっかいだけどな。

面倒くさいから検査例外は無い方が良いとか考えてる奴は、
例外関連のドキュメントなんて書かないから品質ズタボロのコードを量産する。

427 ：424：2007/09/02(日) 17:27:46

>>425
アプリケーション(基本的なライブラリでない)でのチェック付き例外は有用と見られているはずだ
アプリケーションレベルではリカバするべき例外を決めることができて、チェック付き例外で強制できる

アスペクトを使うことでIO例外をアプリの例外へ変換とかはうまく書けるが、
各メソッドごとの例外処理を常にうまく分離して書けるわけではない

テスト時にすぐわかるというのは理由にならないはずだ
再現が難しい例外だってあるから
それよりも発生したときなにもできないことが多いというのが理由だと思う

428 ：デフォルトの名無しさん：2007/09/02(日) 17:28:11

なんか次世代関係なくなってね？
JAVAの例外について勉強するスレとかたててそっちでやれ

429 ：デフォルトの名無しさん：2007/09/02(日) 18:30:35

例外処理が煩わしいのであれば、
例外処理を包含したテンプレートパターンを適用して処理すればいい。
APIは面倒か面倒じゃないかではなく、安全か安全ではないかが重要。

APIは極力安全に使えるように「馬鹿向け」に作られているが、
本当の馬鹿にはその意味すらわからないらしいｗ

430 ：デフォルトの名無しさん：2007/09/02(日) 18:57:24

わずらわしいどうの以前にその例外をどう扱うべきかというパターン自体が俺みたいな初心者にはわからない
使われる側でチェック例外を投げてから使う側で遺言を言ったあとRuntimeExceptionでラップするとか、
キャンセルなどの特殊な状況を処理するために使うとか、なんだろうか

431 ：デフォルトの名無しさん：2007/09/02(日) 21:40:59

捕捉する場所によって扱い方も異なるとしか言い様がないな。
ライブラリ書いてるなら、抽象的な例外でラップして投げなおすだろうし。
フレームワークならコントローラで一括処理で、それ以外では全部投げっぱなし。

432 ：デフォルトの名無しさん：2007/09/02(日) 21:49:00

個人的にはチェック例外＝病気の診断、ランタイム例外＝安楽死とか思ってる
で、今直せる見込みのない病人がいるとして、いろんな病院をたらいまわしたり（チェック例外のままthrowsしまくる）、
病気ではないとして放置したり（例外を握りつぶす）、
秘密裏に抹殺したり（System.exit(0)）、
するよりはランタイム例外にして安楽死させたほうがいいような気はするんだけどな。

でもそのあたりの常識やパターンやガイドラインみたいなものがないと実際何をやっていいのか分からないし、
ttp://www-06.ibm.com/jp/developerworks/java/040618/j_j-jtp05254.htmlとか見る限り、
今のAPI仕様でそれが完璧に行われているかというとそうでもない気がする。
どう診断すればいい医者であるか、と言う問題についてはもっと語られてもいい気がする。

433 ：デフォルトの名無しさん：2007/09/03(月) 00:54:17

病気になったら即安楽死＝良い医者だと？

434 ：デフォルトの名無しさん：2007/09/03(月) 00:56:05

スレ誘導しようとしたらいつのまにか例外処理スレが落ちてた。

435 ：デフォルトの名無しさん：2007/09/03(月) 04:46:11

>>420
その程度ならRuntimeExceptionで十分

436 ：デフォルトの名無しさん：2007/09/03(月) 07:58:03

>>435
その程度なら throws IOException 書いておけば十分。の間違いじゃね？

437 ：デフォルトの名無しさん：2007/09/03(月) 08:17:25

>>435
もっかい ttp://www-06.ibm.com/jp/developerworks/java/040618/j_j-jtp05254.html 読んでくれば？

438 ：デフォルトの名無しさん：2007/09/03(月) 08:53:56

>>432
ロッド＝ジョンソンの本の説明が出てるな
自分も彼のJ2EE本読んで、チェック例外に対する見方を改めた口だ

439 ：デフォルトの名無しさん：2007/09/04(火) 11:17:45

例外処理がもれなくSystem.exit(0)オンリーなソースを
押し付けられた俺涙目

440 ：デフォルトの名無しさん：2007/09/04(火) 11:21:35

例外処理が全部 System#exit(int) ってのもアレだが、
異常終了してんのに 0戻すってのも相当アレだよな。

441 ：デフォルトの名無しさん：2007/09/04(火) 11:36:48

終了するというコードが正しく実行できたので正常！
と。
曲がった先の信号が青だから曲がれる、という理屈に似てます。
>>439
まあ握りつぶされるよりはいいんじゃないか？

例外処理に関しては、パッケージ単位とか、今度出来るはずのモジュール単位で
包括して処理できる仕組みがあったら便利じゃないかなぁと思う。

442 ：デフォルトの名無しさん：2007/09/04(火) 14:31:16

>曲がった先の信号が青だから曲がれる、という理屈
これめちゃくちゃ危ないんだが・・・特に内輪差考えないで突っ込んで来る馬鹿な大型車とか。

443 ：デフォルトの名無しさん：2007/09/04(火) 22:43:55

>>439
脈絡ないけど、exit()の前にfree()は要らないってのを思い出してしまった。

444 ：デフォルトの名無しさん：2007/09/04(火) 23:43:03

>>432
一理あると思うが、マルチスレッドの場合はランタイム例外もきちんと
捕捉しとかないと握りつぶしたのとたいして変わらないことになるんだよな。
そのへん整合性あるガイドラインならいいんだが。

あと、安楽死というからには本当はやっぱり後始末もちゃんとしておきたいところ。

445 ：デフォルトの名無しさん：2007/09/05(水) 14:32:56

あのfree論争ってさ、
「とりあえずfreeはしておくべき」的な教条的理想論
「どうせ終了と同時にメモリ開放するんだからいいじゃん、っていうかfreeしたって実際何もしてないのとほぼ同じだし」っていう感じの現実論
って理解でいいんだよな？そりゃ永遠に話は平行線だ罠

446 ：デフォルトの名無しさん：2007/09/05(水) 14:37:30

例外ってさ、単純な入力ミスで出るようなはっきりいって例外処理までしてやりたくないようなどうでもいい例外か
出てる時点でもうもうどうしようもない例外が多いような気がする

447 ：デフォルトの名無しさん：2007/09/05(水) 15:06:10

外部からの入力ミスなら対処しないとダメだろ。

使い捨てアプリ作ってんなら、throws Exception 付けといて良いだろうし。

448 ：デフォルトの名無しさん：2007/09/05(水) 15:16:29

>>445
マトモな奴は、free論争なんかする暇があったら他の事をやる。

449 ：デフォルトの名無しさん：2007/09/05(水) 15:25:06

>>445
>>448 の2つに直交する「どっちでもええがな」論があって、これが現実解。

450 ：デフォルトの名無しさん：2007/09/05(水) 15:46:51

parseIntで数字じゃなかったときの処理を例外でやんないといけないとか、ひどすぐる。

451 ：デフォルトの名無しさん：2007/09/05(水) 16:05:21

>>450
なら、どうしたら良いと思う？

parseInt の戻り型を long にして数字以外なら int の範囲外が返ってくるとか、
parseInt の戻り型を Integer にして数字以外なら null 返すとかしても、
例外よりマシになるとは思えないけど。

452 ：デフォルトの名無しさん：2007/09/05(水) 16:11:43

＞parseInt の戻り型を Integer にして数字以外なら null 返す
それやるとオートボクシングしたつもりがヌルポになったりすっからなあ

isValidInteger()みたいなチェックメソッドを作ってやるとかどうよ。二度手間だが

453 ：デフォルトの名無しさん：2007/09/05(水) 16:15:34

>>452
安全なコードを書くためにそのメソッド使った
if文を書くことを強制しないといけない。

ならコンパイラでチェックしてやろうというのが
検査例外な訳で。

どこまで人間を信じるかだな。

454 ：デフォルトの名無しさん：2007/09/05(水) 16:15:42

> isValidInteger()みたいなチェックメソッド
なんという銀の弾丸

455 ：デフォルトの名無しさん：2007/09/05(水) 16:18:36

int[] parseInt(String)
返値は
　{ パースした数字, エラーコード }

俺もparseIntについては何とかならないかと思ってた。
parseできないってのは、想定内の状況だからExceptionにするのはどうかな、と感じてて
例外と言うより１状況として扱いたいと思ってる。
ただ、上のようにしても何かしっくり来ない。

Exception以外に、例外状況をメソッドの返りで扱えるようになればいいな、と思う。
Exception処理が重すぎるというのが元凶なんだが、
RuntimeExceptionでないものに関しては
parseIntのように、stackTraceなんて重いものは要らなくて、
その場で処理してしまう例外状況って多いじゃないですか。

何とかならないのかなぁ。
言語構造的に、Throwable一本ってのが簡単なのは分かるんだが・・・

456 ：デフォルトの名無しさん：2007/09/05(水) 16:25:02

>>453
＞if文を書くことを強制しないといけない。
ここに関しては
Nullチェックに対するNullPointerException
Iterator#hasNext()に対するNoSuchElementException みたいなRuntimeException派生を投げれば済むと思うんだけど
二度手間なんだよね。このチェック。

457 ：デフォルトの名無しさん：2007/09/05(水) 16:29:35

>>456
hasNextはそのチェック自体が軽いからいいけど
parseIntは、parseしちゃってるからねぇ・・・二度手間ですよねぇ・・・・

458 ：デフォルトの名無しさん：2007/09/05(水) 16:29:50

>>455
> parseIntのように、stackTraceなんて重いものは要らなくて、
> その場で処理してしまう例外状況って多いじゃないですか。

parseInt の場合だと、
・ユーザー入力を parseIntした場合はユーザー入力が遅いのでExceptionが重くても問題ない。
・ファイル読み込んでparseIntした場合、パースできないケースは例外を使うべき状況なので問題ない。
だと思うが。

459 ：デフォルトの名無しさん：2007/09/05(水) 16:33:25

自己レス>>457
あ。parse結果をキャッシュできればいいのか。内部で。
って、コトは、staticメソッドじゃ駄目だな。
Stringのインスタンスメソッドになれば何とかなる、という所か・・・・

460 ：デフォルトの名無しさん：2007/09/05(水) 16:35:35

>>456
要するに、検査例外だと
コードがごちゃーとするのがやだから
実行時例外にして欲しいって事でしょ？

どっちにしろ、人間をどこまで信じるかだな。

461 ：デフォルトの名無しさん：2007/09/05(水) 16:37:04

>>460
paeseInt の話なら、NumberFormatException は実行時例外だが。

462 ：デフォルトの名無しさん：2007/09/05(水) 16:44:43

>>455
最近の言語であるみたいにJavaが多値を返せる言語だったら良かった
んだけどなあと思う。

(int, StatusCode) parseInt(String input)

とか。

ちょっとキモイが

interface ParseResult { }
class ParseSucceed implements ParseResult { }
class ParseFailure implements ParseResult {}

というクラスを用意して、ParseResult型の値を返すとかどうだろう。

463 ：デフォルトの名無しさん：2007/09/05(水) 16:48:13

>>462
後半、ただのEnumでよくね？

464 ：デフォルトの名無しさん：2007/09/05(水) 16:48:49

そんなややこしいことやるくらいなら Integer を返して null かどうかで判定できればそれでいいよ

465 ：デフォルトの名無しさん：2007/09/05(水) 16:52:55

>>464
だからそういうのやるとコードの変なところでヌルポが出そうで怖いんだって
オートボクシングするだけで出るし正体不明のバグ増やすだけ

466 ：デフォルトの名無しさん：2007/09/05(水) 16:56:38

じゃあ @CheckForNull 付加で

467 ：デフォルトの名無しさん：2007/09/05(水) 16:57:55

>>462
StatusCodeチェックしない場合はパースに失敗してても intの値が得られちゃうし、
その上現状よりキモくなってるしで、あんま良い事ないんじゃね？

468 ：デフォルトの名無しさん：2007/09/05(水) 17:02:33

>>462
多値を返すという話はだーいぶ昔からBugParadeでやられてて
話に参加してみたものの結局、やらないよーという結論。

まあ、どうしてもやりたきゃ、今は配列をつかえってところ。
それなら俺は、配列に違う型を含められるようにしてくれ、と思い・・・
でも、その場合型チェックはコンパイル時には難しいわけで
Objectの配列使うのと変わらないわけで・・・・
じゃあ、じゃあstructがあったらいいんじゃ・・・・っていうと、
アレ？それってクラスじゃね？と・・・・

型チェックが緩くてもともと実行時にしか型がきまらない
スクリプト型言語なら、複数返値も考えることあんまり無くていいんだろうけどねぇ

469 ：デフォルトの名無しさん：2007/09/05(水) 17:24:54

>>468
いやいや。型に厳しい関数型言語(MLやHaskell)などでは、
昔からタプルという形で多値が扱えたから、それと同等の
仕様にすればいいだけだと思うんだがな。

470 ：デフォルトの名無しさん：2007/09/05(水) 17:28:34

>>463
実装は省いたけど、ParseSucceed型からはパーズ結果の値を、
ParseFailure型からは失敗の原因を取得できるようにする意図が
あったので、ただのEnumだとよくない

471 ：デフォルトの名無しさん：2007/09/05(水) 17:47:44

>>469
>>455 だと Exception重いからException使わないようにしようって話でしょ。
タプルとか使って正常系の処理も重くしたら意味無いんじゃね？

472 ：デフォルトの名無しさん：2007/09/05(水) 17:55:24

>>470
パフォーマンス上の理由なら、そんなもんいちいちnewして返すぐらいなら、例外投げればいいと思う。
単にコードを簡潔にしたいだけなら、
static boolean parseInteger(String text, AtomicInteger out);
みたいなのをどっかに用意してやればいい。
AtomicIntegerは、他に標準でintを参照渡しできるインターフェイスが無いからなんで、
適当なintをsetできるインターフェイスならなんでもいいと思う。

コードを簡潔にするっていっても、結局正しくパースできたかのチェックは必要なんだから、
例外で十分でしょ。

473 ：デフォルトの名無しさん：2007/09/05(水) 18:06:05

しかし事前チェックが出来ないにもかかわらず実行時例外を投げてよろしいものだろうか
同じく文字列を解析して取得するタイプのClass#forNameが発行するClassNotFoundExceptionはキャッチ例外だよね？

474 ：デフォルトの名無しさん：2007/09/05(水) 20:31:41

>>472
パーズ失敗というのは、自分にとっては正常系の処理なんで
例外使うのは違和感があるんだ。感覚的な問題なんだけど、
Map<K, V>#get(K key)がkeyがエントリに存在しない場合に
例外を投げられると嫌なのと似た理由で。

475 ：デフォルトの名無しさん：2007/09/05(水) 20:35:55

>>474の補足だけど、Mapから値を取得しようとしたときにキーが存在しない場合
というのは、正常系の処理であることが多いから、もしもJavaのAPIの設計が、
例外投げるようになってたとしたらうっとおしいだろうなあということ

476 ：デフォルトの名無しさん：2007/09/05(水) 20:44:31

parseIntの場合も、本音で言うと多値よりnull返す方が良いと思ってる。ただ、
現状のJavaでは、nullを許容する/しないを型で表現できないという欠点が
あるので、微妙なところではあるけど。

477 ：デフォルトの名無しさん：2007/09/05(水) 20:46:57

はぁ？

478 ：デフォルトの名無しさん：2007/09/05(水) 20:55:41

C#のNullableは安易にstructをサポートしたがために招いた失敗仕様の名残じゃないか
オートボクシングでラッパーオブジェクトと用意に相互変換可能な現状で、んなもん無用の長物

479 ：デフォルトの名無しさん：2007/09/05(水) 21:53:06

使用できる範囲は限定されるが
int parseInt( String numberInString, int defaultValue )があればよかった。
パーズこけたらデフォルト値を返す。

480 ：デフォルトの名無しさん：2007/09/05(水) 21:55:44

そんなに1行で書きたいんですか

481 ：デフォルトの名無しさん：2007/09/05(水) 21:58:55

ラッパークラスに例えばisConvertable(String)みたいなメソッドがないのがねぇ。
2回パースするくらいなら例外でいいっしょｗｗｗｗｗｗって設計思想はちょっと。。。。

482 ：デフォルトの名無しさん：2007/09/05(水) 21:59:23

>>479
ドトネトのTryParseだな。
ttp://www.atmarkit.co.jp/fdotnet/dotnettips/408tryparse/tryparse.html

483 ：デフォルトの名無しさん：2007/09/05(水) 22:06:09

>>482
Javaだと参照渡しがないし、標準でmutableなintのラッパークラスも無いから作りにくい。

484 ：デフォルトの名無しさん：2007/09/05(水) 22:08:38

俺はjava.util.prefs.Preferencesのget()を思い出した

485 ：デフォルトの名無しさん：2007/09/05(水) 22:13:18

>>483
プリミティブを参照渡しさせない仕様なんだから
可変にしちゃったらラッパークラスにならないぞ

486 ：デフォルトの名無しさん：2007/09/05(水) 22:18:43

>>483
つ java.util.concurrent.atomic.AtomicInteger

っても、atomicな更新のためのクラスだから
mutableなintのラッパークラスとして使うのはアレな感じもするけど

487 ：デフォルトの名無しさん：2007/09/05(水) 23:17:23

org.omg.CORBA.IntHolder

CORBAのクラスなのがあれだが

488 ：デフォルトの名無しさん：2007/09/05(水) 23:25:19

>>478
C#のNullableは単に値型でnull許容可能にするための代物。
俺が言ってるのは、値型/参照型区別無くある型の変数に
nullを許容する/しないを指定できる代物。しかも、nullableな型は
non-nullableの型にそのまま代入しようとしたらエラーになって
コンパイラによるチェックを強制されるようなの。具体的な言語で言うと、Nice
http://nice.sourceforge.net/
がそれをサポートしてる。使ってみればわかるけど、この機能はかなり便利。

489 ：デフォルトの名無しさん：2007/09/05(水) 23:36:14

ウザいと思われるかもしれんけど、続けて書く。Niceで書くと定義はこんな感じで
書ける。

int? parseInt(String input) {//nullを含む可能性があるint型
　try {
　　return Integer.parseInt(input);
}catch(NumberFormatException e) {
　　return null;
　}
}

使用する方はこんな感じ。if(parsedValue != null)によるガードが無いと
コンパイルエラーになるのでNullPointerExceptionの心配は無い。

int? parsedValue = parseInt(inputValue);
if(parsedValue != null) {
　//parsedValueを使った処理
}

490 ：デフォルトの名無しさん：2007/09/05(水) 23:39:25

この機能が無いからNullObjectが出来たんだな

491 ：デフォルトの名無しさん：2007/09/05(水) 23:45:26

>>489
それ、何が嬉しいのか分からん。

parseInt だと実行時例外で例外処理を強制できないから、
nullチェック強制できる >>489 の方が良いって話？

492 ：デフォルトの名無しさん：2007/09/05(水) 23:47:05

よく考えてみたらオートボクシングめんどくせえなｗ
これ

493 ：デフォルトの名無しさん：2007/09/05(水) 23:54:52

>>491
パーズ失敗を例外で扱うのに反対で、返り値でパーズ失敗を扱いたいんだけど、
nullでパーズ失敗を表すとしたらNullPointerExceptionの危険性があるし、意図が
あいまいになる危険性もある。で、この機能があればnullを許容するという事を
明示できるし、NullPointerExceptionの危険性も無いから欲しいなあということ。

494 ：デフォルトの名無しさん：2007/09/06(木) 00:01:56

コンパイルエラーを期待してって考えなら分からんでもない。
javaならメソッド側にアノテーションで実現することになりそうだ。

@NilExclude int parsedValue = parseInt(inputValue);
if (parsedValue != null) {
// このブロック以下でのみparsedValueへはアクセス可能
}
// このスコープでparsedValueへはアクセスできない

をコンパイルすると拡張構文よろしく等価コードに展開されるみたいな感じか。

int parsedValue = 0;
Integer parsedValue$ = parseInt(inputValue);
if (parsedValue$ != null) {
parsedValue = parsedValue$.intValue();
// ...
}

495 ：デフォルトの名無しさん：2007/09/06(木) 00:03:19

結論はおまえにはjavaは合ってないって事だな。
話聞いてると考え方が短いコードで実現させるタイプの動的言語の発想だ。

496 ：デフォルトの名無しさん：2007/09/06(木) 00:04:38

で、何故parseInt()のパーズ失敗を例外で扱うのに反対かというと、parseInt()は
引数から返り値が一意に定まるので、たとえパーズ失敗でも例外的な状態と
言えないと考えるから。

497 ：デフォルトの名無しさん：2007/09/06(木) 00:06:27

>>495
なんで動的言語が関係してくるの？むしろ静的にチェックできる機能が
欲しいって話をしてるわけで、動的言語とは対極の発想だよ。というか、
短いコードが好ましいってのは動的言語特有の発想でもないでしょ。

498 ：デフォルトの名無しさん：2007/09/06(木) 00:07:59

> メソッド側にアノテーションで実現することになりそうだ。
メソッド側にってのは余計。構成してて放置したままだった。

499 ：デフォルトの名無しさん：2007/09/06(木) 00:15:42

契約的言語。

500 ：デフォルトの名無しさん：2007/09/06(木) 00:21:29

アノテーションひとつで
if (n != null) { /* n アクセス */ } と
if (n == null) { return; } /* n アクセス */
のどちらかを選択（および強制）できるのなら歓迎かな。
@Overrideの親戚みたいなもんだ。

501 ：デフォルトの名無しさん：2007/09/06(木) 00:43:04

例外を「例外的な状態でのみ使うべき」というのは言葉が同じだからもっともらしく
聞こえてしまうだけで、何の助けにもならない方針。

http://www.boost.org/more/error_handling.html
http://boost.cppll.jp/HEAD/more/error_handling.html

502 ：デフォルトの名無しさん：2007/09/06(木) 00:48:46

>>500
FindBugsをどうぞ
http://findbugs.sourceforge.net/manual/annotations.html

503 ：デフォルトの名無しさん：2007/09/06(木) 01:03:12

>>493,496
単に自分の考えと合わないってだけ？
それって自前のクラスメソッド書いて、そっち使うんじゃダメなんか？

なんつーか、>>448-449 あたりが結論になりそうな話じゃねーかと。

504 ：デフォルトの名無しさん：2007/09/06(木) 01:14:56

>>503
もちろん自前のクラスメソッド書いて使うことになると思うよ。
実際にJavaプログラム書くときの解決策としては。単に言語の
拡張まで含めて許されるならどういう設計にするのが良いかという思考実験。

あと、free論争とは文脈が違うので一緒にされるのはちと心外だな。
どういう方針でライブラリ設計をするかという話は使い勝手に関わって
くる。もちろん、ここで議論しても実際のJava APIの設計が改善されない
という意味では無益なのはそうだけど。

505 ：デフォルトの名無しさん：2007/09/06(木) 01:26:05

>>496
理解できない
すべての失敗する引数はnullが返ることで一意に定まるということ?

例外的な状態かどうかはparseInt単体でなく、呼出し側がどうしたいかでも異なるはずだ
デフォルト値が定まる場合と定まらない場合、とか
んで、とりあえず保守的にパーズ失敗を例外として扱うと言う設計でよいと思う
checkedかどうかは微妙なとこだが

506 ：デフォルトの名無しさん：2007/09/06(木) 01:26:52

単に好き嫌いの問題で、パフォーマンスとか関係ないんでしょ？
free論争と大して変わらんと思うが。

507 ：デフォルトの名無しさん：2007/09/06(木) 01:30:33

>>504
parseInt の使い勝手を改善する事により、Java での開発効率が 10％向上するんだ！
とか考えてるなら一生懸命考えるのも頷けるんだけど……

ぶっちゃけ瑣末な問題じゃね？

508 ：デフォルトの名無しさん：2007/09/06(木) 01:40:40

例外を握りつぶすユーティリティメソッド作ればOK。

509 ：デフォルトの名無しさん：2007/09/06(木) 02:03:58

>>505
> すべての失敗する引数はnullが返ることで一意に定まるということ?
そういう意図で書いた。正確に言うと、外部の状態に依存せずに
入力*のみ*から返り値が決定される、ということ。その逆の
典型的な例としてはIOExceptionを発生させるような関数や
コンストラクタがある。これらの関数は入力だけでなく外部の
状態によって成功したり失敗したりする。

>>507
parseIntだけの問題として考えればぶっちゃけどうでもいいけど、
一般的な問題としてある関数が失敗を返り値で通知するか
例外で通知するか、というのは瑣末な問題じゃないと思う。

510 ：デフォルトの名無しさん：2007/09/06(木) 09:42:29

ユーティリティメソッド作ればOKってのは、思考停止以外のなにものでもない。

511 ：デフォルトの名無しさん：2007/09/06(木) 09:46:39

parseInt を改変しようとか考えるのは暇人以外のなにものでもない。

512 ：デフォルトの名無しさん：2007/09/06(木) 09:53:09

>>511
そうか？

513 ：デフォルトの名無しさん：2007/09/06(木) 10:14:54

>>511
つきあってた連中も暇人以外のなにものでもない。

514 ：デフォルトの名無しさん：2007/09/06(木) 11:20:14

改変は、ちゃんと考えてbugparadeにあげるなどすれば、なにがしかの影響は与えられる。
ここで改変について語るのも、そういったヤツのインスピレーションになることもあるだろうし、本人が書き込むこともあるだろう。
無駄ではないよ。

515 ：デフォルトの名無しさん：2007/09/06(木) 11:39:06

なにがしかの影響って……
>>509 も parseInt に関してはどうでもいいって言ってるんだが。
そんな瑣末な問題に関わらせる事で
JDK開発者のモチベーションを下げたいって事か？

free論争ってさ、やってる当事者は引っ込みがつかなくなってるだけかと思ってたけど
案外、>>514みたいに「この議論は無駄ではない」とか思ってる人も居るのかも知れないね。

516 ：デフォルトの名無しさん：2007/09/06(木) 11:41:41

parseIntの例外が例に挙がって
- コードを短く書きたい
- 例外で扱う状況とは思えない
という2点の争点があると思う。

さらに後者の視点は、
- 例外を扱うべき状況を設計の美しさから考える
- 例外を扱うべき状況をException処理の重さから考える
という2つの立場がある

俺は、parseIntに例外の記述が出てきてもいいが、重いException処理が
いやだなぁ、という点から、こういうのがあればいいんじゃないかと思う。

定義済Exception/ StaticException / 短距離Exception /LightWeightException ?

今、Exception処理が重いのは、Exceptionオブジェクトの生成にある（スタックトレース生成など）
つまり、生成処理をなくしてやれば大幅にパフォーマンスは改善するはず。
なので思い切って、stackTraceとかが空っぽのExceptionで
すぐ直上のcatch節で捉える決まりで、
さらにThrowの必要があるときは別のExceptionにしなくてはいけないようなもの。
気軽に例外が投げられるようになって、正常系の処理が例外でトリッキーに実装されるように
なっちゃうかもしれないけど、こういうのってどうですかね。

517 ：デフォルトの名無しさん：2007/09/06(木) 11:47:27

>>515
相手にするから調子に乗るんだろ。ほっとけ。

518 ：デフォルトの名無しさん：2007/09/06(木) 12:05:24

>>516
> 重いException処理がいやだなぁ、という点
いやなだけなのか。

これこれこういう使い方をすると、
（パーズ失敗する）parseInt の呼び出しがボトルネックになって困る、
そして、このような使われ方をする事が多いので標準APIを改善して欲しい、
ってんなら議論の余地もあるけど、それって単なる好き嫌いの問題じゃね？

519 ：デフォルトの名無しさん：2007/09/06(木) 12:39:29

>>518
包丁一本で、何でも作るのって大変じゃないかな、って話です。

http://sourcepost.sytes.net/sourcepost/sourceview.aspx?source_id=29658
のコード書いて、Exception生成のコストを見てみました。
ウチのマシンでの結果です（かかった時間）
Try[1]:422
Try[2]:10469
Try[3]:78
Try[4]:10875
１つめが、Throwableを継承して、Overrideで色々ぶった切ったクラス。
２つめが、単なるException。
３つめが、単なるObject。
４つめが、NumberFormatException。
Objectのnewに比べて、Exceptionのが大幅に重い処理となっています。
NumberFormatExceptionもそうです。
もし、ファイルを読む処理をするときに、数字でないものも大量に含むフィールドがあれば
Exception処理が時間を食うことが予想されます。
Exceptionの機能を大幅にカットすれば、２桁のオーダーで処理を軽くすることができるわけです。
現在の仕組みを使って、実装するならこうなりますがシステムとしてサポートしてくれても
いいかなぁ、と思ったわけで。

520 ：デフォルトの名無しさん：2007/09/06(木) 12:53:24

>>519
> 数字でないものも大量に含むフィールドがあれば
普通はフォーマットエラー吐いて終わりでしょ。

521 ：デフォルトの名無しさん：2007/09/06(木) 13:10:14

　　　　〃〃∩ 　_, ,_
　　　　　⊂⌒（　`Д´）　＜　ヤダヤダ！ parseInt が例外使っちゃヤダ！
　　　　　　｀ヽ_つ ⊂ノ
　　　　　　　　　　　　　　ジタバタ

　　　　　　〃∩
　　　　　⊂⌒(　　_, ,_）　＜　ぶっちゃけどうでもいいけど、やっぱりヤダヤダ……
　　　　　　｀ヽ_つ ⊂ノ
　　　　　　　　　　　　　　ﾋｯｸ...ﾋｯｸ...

　　　　　⊂⌒(　　_, ,_）
　　　　　　｀ヽ_つ ⊂ノ　　zzz…

522 ：デフォルトの名無しさん：2007/09/06(木) 13:56:24

delphiのStrToIntDefみたいに、数値にできないときのデフォルト値が指定できればかなりいい

523 ：デフォルトの名無しさん：2007/09/06(木) 14:17:51

>>520
何で？全部読んで例外をチェックしないと駄目かもしれないですよ。

いや、というか例外を使うなとかいう話ではなく、
パフォーマンスを気にして例外を使うべき場面を回避しようとするのは
本末転倒だから、例外を使わなきゃ駄目なときパフォーマンスが
落ちなければそういう誤解、というか誤用がなくなるんじゃないかと。

524 ：デフォルトの名無しさん：2007/09/06(木) 14:45:35

>>523
「かもしれない」って……
要するに、今現在（パーズ失敗する）parseInt の呼び出しが
ボトルネックになって困ってるわけじゃないんでしょ。
単なる好き嫌いの問題にしか見えないが。

それに、誤用とか誤解とか言われても……
>>509の理論がいつでもどこでも通用する例外のガイドラインとはとても思えないし、
使い勝手、堅牢性、パフォーマンス、好き嫌いとか色々な要素が絡んでくるから
いつでもどこでも誰にでも通用する例外のガイドラインを作るのは難しいだろうし。

525 ：デフォルトの名無しさん：2007/09/06(木) 14:47:32

ということは例外はこれまでどおりフィーリングとわずかなドキュメントで判断していくしかないのかね

526 ：デフォルトの名無しさん：2007/09/06(木) 15:21:46

>>524
>>523 ≠>>509です。
parseIntはあくまで例です。
確かにちょっと誤解されそうなレスでした・・・

誤用というのは、Exceptionを使うまいとして
ごちゃごちゃとしたコードになってしまうような状況を指してます。
具体的にカチッとした基準に基づいた「ごちゃごちゃ」ではありませんが。

私は、parseIntに関わらず、Exception処理が軽くなればいいな、という話をしているつもりでした。

527 ：デフォルトの名無しさん：2007/09/06(木) 15:36:41

>>526
parseInt で例外生成コストが下がると嬉しいか？

それに、parseInt で Exceptionを使うまいとして
ごちゃごちゃとしたコードになるって、どんな状況？

あと、俺は Exception処理が軽くなれば良いって要望に対する返答が
「例外的な状況以外で例外使うな」って話なんだと理解してるんだが。
例外って濫用すれば goto より悲惨なスパゲッティコード書けるしね。

528 ：デフォルトの名無しさん：2007/09/06(木) 17:31:04

パースの失敗は十分、例外的状況に値すると思うが・・・。
例外処理の乱用がスパゲッティーコード招いてるんじゃなくてそういうコード書いてる自分がスパゲッティー作ってるんだと思う。

アプリケーションかミドルウェア側の設計でどうにかなると思うんだが？

529 ：デフォルトの名無しさん：2007/09/06(木) 17:37:48

>>527
InterruptExceptionって例外的だと思う？
スレッドのキャンセルを実装しようと思ったら普通に出るけど

530 ：デフォルトの名無しさん：2007/09/06(木) 18:49:35

>>528
設計っつーか、実装で吸収できるでしょ。

531 ：デフォルトの名無しさん：2007/09/06(木) 20:19:45

便利なら便利なほうがいい。

532 ：デフォルトの名無しさん：2007/09/06(木) 20:24:49

何を便利と感じるかは人によって違う、と。

かと言ってなんでも標準APIに入れたら標準APIメンテする人間の負担が増えて
バグが増えたり放置されたりといった悪影響も考えられる、と。

533 ：デフォルトの名無しさん：2007/09/06(木) 20:47:42

NICEのnullableってのは興味深いネタだったけど、
それと一緒に語られたparseIntの仕様には何の興味も湧かなかった。
つーことで、イディオム補完型（保証型）のアノテーションの充実を期待したい。

534 ：デフォルトの名無しさん：2007/09/07(金) 07:32:33

>>445
終了前のfreeは害っていうのがいるだろ。

535 ：デフォルトの名無しさん：2007/09/07(金) 07:55:31

そんなものは無い

536 ：デフォルトの名無しさん：2007/09/07(金) 22:37:51

http://blogs.wankuma.com/kacchan6/archive/2007/09/07/94499.aspx

537 ：デフォルトの名無しさん：2007/09/07(金) 22:39:06

http://blogs.wankuma.com/kacchan6/archive/2007/09/07/94499.aspx

538 ：デフォルトの名無しさん：2007/09/08(土) 00:14:55

parseIntで100近くもダベれるお前らに脱帽

539 ：デフォルトの名無しさん：2007/09/08(土) 00:53:35

>>536
低脳な質問で悪いんだけど
「クリティカルで速度が要求される場面での数値チェックは、例外を使わないのが無難っぽいです。」

って言ってるけど、じゃぁどういう処理が望ましいんだろうな。
俺も、試しに同じ用なプログラムを10000000回処理をぶん回してみたが、
正直それほど有意差は認められなかった。

----以下結果----
StringUtils.isNumeric() : boolean で不正な文字かどうかを検知
1回目 451 ms
2回目 401 ms

Integer.parseInt() : 例外で不正な文字かどうかを検知
1回目 42822 ms
2回目 42771 ms

540 ：デフォルトの名無しさん：2007/09/08(土) 01:03:04

>>539
例外を使ってるバージョンが100倍近く遅いんだが、それは
有意な差じゃないの？

541 ：デフォルトの名無しさん：2007/09/08(土) 01:05:19

あ、もちろん実際にparseIntが使われる局面で1000000万回も
呼ばれることは無いだろうから、そういう意味では例外を使っても
いいんだろうけど、有意な差が無いってのは変でないの？ってこと

542 ：デフォルトの名無しさん：2007/09/08(土) 01:05:27

>>539
ネタにマジレス。

まず数値チェックに parseInt 使って
> クリティカルで速度が要求される場面
が具体的にどういう場面なのかってのを特定するのが先決。

それをしないで「どういう処理が望ましいか」を考えても時間の無駄。

543 ：デフォルトの名無しさん：2007/09/08(土) 01:07:45

間違った。1000000万回 -> 1000万回

544 ：デフォルトの名無しさん：2007/09/08(土) 01:12:44

>>538
まだまだ続くよ

545 ：デフォルトの名無しさん：2007/09/08(土) 01:59:22

巫女巫女ナース巫女巫女ナース♪

546 ：デフォルトの名無しさん：2007/09/08(土) 02:32:19

｢まだまだ　いくよぉ～｣だな

547 ：デフォルトの名無しさん：2007/09/08(土) 03:09:27

もうちょっとだけ続くのじゃ

548 ：デフォルトの名無しさん：2007/09/08(土) 07:03:01

つうか、例外は制御構造の要だろ
ttp://d.hatena.ne.jp/smeghead/20070309/baka

549 ：デフォルトの名無しさん：2007/09/08(土) 08:05:55

多値にしてもnullableにしても、
失敗をnullで表すのはちょっと古いんじゃないかな。

多値なら失敗(false)したら(undef, false)とundefみたいな値を返す方がいいと思う。

550 ：デフォルトの名無しさん：2007/09/08(土) 10:19:24

>>544,547
続けるなよ……

551 ：519：2007/09/08(土) 14:09:14

>>536
ちょっと待て、ほとんど俺が書いたコードじゃねえかそれ。
ちなみに、おれじゃねえぞ。そのblog

552 ：デフォルトの名無しさん：2007/09/08(土) 14:18:22

>>549
undefがnullとどう違うのかわからん

553 ：デフォルトの名無しさん：2007/09/08(土) 15:06:37

>>552
お前はそもそもnullは何をモデル化したと考えてるんだ？

554 ：かつのり：2007/09/08(土) 16:03:23

本人降臨っす。

>>519
実験用にパクらせていただきましたｗ

ちなみにStringUtils.isNumeric()は微妙ですね。
Integer.parseIntの高速版とするなら、
Integerとしての要件を満たさなければいけません。

正規表現のパターンを予めキャッシュしておいて、
そのパターンでマッチングするのが一番早いのかな。

555 ：デフォルトの名無しさん：2007/09/08(土) 16:29:24

NumberUtils#isNumberもあるけどlong型とかでも判定しちゃうな

556 ：519：2007/09/08(土) 17:34:45

>>554
ああ、バッチでファイル読む時は俺もそうしてるなぁ
どうせ桁数制限とか入る事が多いし

557 ：デフォルトの名無しさん：2007/09/08(土) 17:52:06

Patternのcompileってホントにコンパイルしてるの？

558 ：デフォルトの名無しさん：2007/09/08(土) 18:01:25

>>557
コンパイルの意味を、パースして実行用データ作っとくって意味なら、コンパイルしてるんじゃねぇの？

559 ：デフォルトの名無しさん：2007/09/08(土) 18:21:18

たしかに最適化オプション付きであるとはいってないからね。
Strategyパターンとか駆使してガチガチに最適化されたPatternを返して欲しいとこだ。

560 ：デフォルトの名無しさん：2007/09/08(土) 19:03:46

Javaの正規表現はDFAでしょ？確か。
DFAはバックトラックしなくていいから、
最適化は高速化ではなく使用メモリのレベル。
遷移テーブルとかその辺。

下手な自前のマッチングコードを書くより早いよ。正規表現は。

561 ：デフォルトの名無しさん：2007/09/08(土) 19:55:04

>>560
Javaの正規表現はNFA。実装読んでみるべし。
最近の言語に組み込みの正規表現ライブラリの多くはNFA(または
その変種)を採用してる。理由はNFAじゃないと扱いづらい機能
(後方参照など)があるため。

562 ：デフォルトの名無しさん：2007/09/08(土) 19:56:36

ちなみに各言語における正規表現ライブラリの実装がどのように
なっているかの概要を知りたい場合は、詳説正規表現がオススメ

563 ：デフォルトの名無しさん：2007/09/08(土) 22:35:20

>561
そか。情報サンクスコ

564 ：デフォルトの名無しさん：2007/09/09(日) 19:28:16

DFAじゃあ不便すぎる。

565 ：デフォルトの名無しさん：2007/09/09(日) 21:49:32

DFAはNFAから変換できるけど、NFAにしておく意義としては、
NFAのまま何かの機能を追加するってこと？
バックトラックする際に後方参照も同時にサポートするためなのか。

566 ：デフォルトの名無しさん：2007/09/09(日) 22:28:17

>>560
> 下手な自前のマッチングコードを書くより早いよ。正規表現は。

んなわけねーだろ。正規表現遅すぎだ。計測してねーだろ。
ただ、Web アプリとかでせいぜい項目が数百程度の
入力チェックや変換程度なら速度差は計測不能。

567 ：デフォルトの名無しさん：2007/09/09(日) 22:41:57

>>566
単純な文字パターンの検証なら正規表現の方が遅いだろうけど、
ごく一般的な業務システムプログラマが、
自前で複雑な検証コードを書くよりは速い。
きちんとロジックを書ける人なら速いんだけど。

568 ：デフォルトの名無しさん：2007/09/09(日) 23:18:56

文脈的に parseInt でパーズ成功/失敗を予め判定するためのコードでしょ。

>>554が言うように Intergerとしての要件を満たす、
文字列が数字で構成されてるかだけじゃなくて最大値や最小値チェックもするなら
正規表現つかうより自前でやった方が早く書けるんじゃねーの？

569 ：デフォルトの名無しさん：2007/09/09(日) 23:23:20

最大値や最小値をチェックする時点で、成功/失敗を予め判定するどころか、すでに値が求まってる気がする

570 ：デフォルトの名無しさん：2007/09/09(日) 23:56:08

>>566 >>567 >>568

>>560は正規表現エンジンがDFAで実装されてる場合の
話をしてると思うよ。その場合なら、下手に自前の
コード書くより早いというのは間違いでもなんでもないよ

571 ：デフォルトの名無しさん：2007/09/10(月) 00:01:33

> ちなみにStringUtils.isNumeric()は微妙ですね。
> Integer.parseIntの高速版とするなら、
> Integerとしての要件を満たさなければいけません。

だからなぁ…… 最大値/最小値チェックしないなら
ほとんどStringUtils.isNumeric()で用足りるんじゃね？

572 ：デフォルトの名無しさん：2007/09/10(月) 00:01:37

>>565
そういうこと。NFAのままにしておけば、「非正規な」機能である後方参照
やその他もろもろ、比較的容易に追加できる

573 ：デフォルトの名無しさん：2007/09/10(月) 00:13:43

>>569
例外使わないだけで 100倍程速くなるそうだから、
変換処理が 2回やる事によって 2倍の時間かかっても大した問題じゃないんじゃね？

まぁ、場合によっては大した問題になるかもしれんが。
そんなん問題になってから考えりゃいいっしょ。

574 ：デフォルトの名無しさん：2007/09/10(月) 01:42:54

正規表現使うほうが１００倍速いよ。実装が。

575 ：デフォルトの名無しさん：2007/09/10(月) 20:17:24

C#の正規表現はグループに名前を付けられるみたいだね

576 ：デフォルトの名無しさん：2007/09/10(月) 21:14:45

>>574
StringUtils.isNumeric()では足りない部分までIntegerの要件を満たすかチェックするんだったら
正規表現でやるのは面倒くさそうだが。

577 ：デフォルトの名無しさん：2007/09/10(月) 22:50:21

正規表現のスレでやれよ。ここには関係ないから。

578 ：デフォルトの名無しさん：2007/09/10(月) 23:04:10

>>576
桁数制限してIntegerの半分以上の範囲捨てるなら簡単だけどな

579 ：デフォルトの名無しさん：2007/09/12(水) 00:32:10

>>575
正規表現のマッチング処理高速化のためにコンパイルすると、
メモリリークするとかＭＳＤＮのドキュメントに書いてあるけどな。

580 ：デフォルトの名無しさん：2007/09/12(水) 00:53:38

>>579
それドトネト1.1のころの制限じゃない？

581 ：デフォルトの名無しさん：2007/09/15(土) 10:08:16

なんと言う次世代

582 ：デフォルトの名無しさん：2007/09/15(土) 10:59:42

次世代試作機・・・。

583 ：デフォルトの名無しさん：2007/09/15(土) 13:48:51

Javaを拡張するのではなく、OSを拡張するというのはJSRにならんのかね？
例えばjinputをJava標準にするための下地にするためにとか。

584 ：デフォルトの名無しさん：2007/09/15(土) 14:16:31

JDK7 build20
http://download.java.net/jdk7/binaries/
http://download.java.net/jdk7/changes/jdk7-b20.html

585 ：デフォルトの名無しさん：2007/09/15(土) 19:49:01

そういやjdk7が出来たらOpenJDK6をOpenJDK7ベースで再構築してOpenJDK6をGPL2で配布するらしいな。
将来的には公式バイナリも完全にOpenJDKからビルドするらしい。

586 ：デフォルトの名無しさん：2007/09/16(日) 12:58:01

７は変な機能増えすぎ
もっとシンプルに保てよ

587 ：デフォルトの名無しさん：2007/09/16(日) 13:16:10

クロージャというか関数導入するならperl見たいな複数戻り値の関数もできるようにしてくれ

588 ：デフォルトの名無しさん：2007/09/16(日) 14:09:47

多値返せたらいいのにと思うことはよくある

589 ：デフォルトの名無しさん：2007/09/16(日) 15:38:35

時々、妙に多値希望の人っているよね
そういう人はロートルだと思っておｋ？

590 ：デフォルトの名無しさん：2007/09/16(日) 15:39:53

多値が返せる言語ってあるの？

591 ：デフォルトの名無しさん：2007/09/16(日) 15:44:03

Perlしかしらない。
ただstateとvalueみたいな多値が欲しいがために
ReultFooみたいなクラスを書くのはなんだかなぁと思うときは多い。

592 ：デフォルトの名無しさん：2007/09/16(日) 16:23:13

lispまでいくと多値というよりリストか
Object[]のシンタックスシュガーで十分なんだけどな
C#のstructなんかよりずっと有用

593 ：デフォルトの名無しさん：2007/09/16(日) 17:16:56

pythonのtupleみたいなの。
まあ、Object[]でもいいけど。

>>591みたいな
型に名前つけるのが面倒なんだよ。

594 ：デフォルトの名無しさん：2007/09/16(日) 19:17:12

Pair<A, B> みたいなクラスを作って使いまわすとか

595 ：デフォルトの名無しさん：2007/09/16(日) 19:48:49

最近は多値返せる言語増えたよ。
javaだとどうせバイトコードレベルでは配列になるんだろうね。

596 ：デフォルトの名無しさん：2007/09/16(日) 20:16:58

public const<String, Boolean> getResult() {
return const { "おｋｗｗｗｗ", true };
}

こんな感じで死にキーワードを流用できないものか

597 ：デフォルトの名無しさん：2007/09/16(日) 20:20:27

>>596
それだったら Pair<A, B> で良いじゃん。

598 ：デフォルトの名無しさん：2007/09/16(日) 20:26:16

普通のGenericsは可変長じゃねー

599 ：デフォルトの名無しさん：2007/09/16(日) 20:36:13

じゃ、

static <A, B> Pair<A, B> tuple(A a, B b)
static <A, B, C> Triple<A, B, C> tuple(A a, B b, C c)
static <A, B, C, D> Quadruple<A, B, C, D> tuple(A a, B b, C c, D d)

みたいにすれば？

600 ：デフォルトの名無しさん：2007/09/16(日) 20:49:41

こらこら。Javaにrefやoutはないでしょ。
尤もCommonsLangあたりにはあっていいクラスだとは思うけど

601 ：デフォルトの名無しさん：2007/09/16(日) 20:52:29

ref や out って、どこの話だ？

602 ：デフォルトの名無しさん：2007/09/16(日) 20:52:37

多値よりも Ref<T> のほうがまだ使い勝手が良さそうな気がする。

603 ：デフォルトの名無しさん：2007/09/16(日) 20:53:37

ああ、ファクトリメソッドか、俺の勘違い。
>>601 C#

604 ：デフォルトの名無しさん：2007/09/16(日) 20:55:55

>>603
いや、レス番の話。
このスレのどこで ref や out の話が出てんのか、と。

605 ：デフォルトの名無しさん：2007/09/16(日) 20:57:38

俺が>>601をクラス定義と勘違いしただけだって。

606 ：デフォルトの名無しさん：2007/09/16(日) 20:59:21

あ、>>599ね。あかん、おねむの時間っぽい。

607 ：デフォルトの名無しさん：2007/09/16(日) 21:03:13

>>599 にも ref や out があるようには見えんが……

608 ：デフォルトの名無しさん：2007/09/16(日) 21:04:09

どう勘違いしたのかくらい考えろ馬鹿ちん

609 ：デフォルトの名無しさん：2007/09/16(日) 21:07:16

なんだ、勘違いか。なら考えても無駄だな。

610 ：デフォルトの名無しさん：2007/09/16(日) 21:09:24

遅かれ速かれ多値はサポートしてくれるものと思いたい。

611 ：デフォルトの名無しさん：2007/09/16(日) 21:10:54

JVM系LLで多値サポートしてたら、そっち使えって話になるんじゃね？

612 ：デフォルトの名無しさん：2007/09/16(日) 21:15:23

var rand = new Random();
int n = rand.nextInt();
みたいな書き方も需要あるから、多値もJSRには上がるとは思う。

613 ：デフォルトの名無しさん：2007/09/16(日) 21:17:32

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4222792
will not be fixed になってる。

614 ：デフォルトの名無しさん：2007/09/16(日) 21:23:36

>>612
どうだろね？

型推論ですら、変数宣言時の型指定を省くのは Java 的じゃないってんで
G<T> g = new G();
みたいに、初期化子の方のパラメタ型指定を省けるようにしようって
論調の方が強いみたいだけど。今までの
G<T> g = factoryOfG();
みたいな型推論とも一貫性あるってのが良いらしい

615 ：デフォルトの名無しさん：2007/09/16(日) 21:28:40

G<T> g = new(); みたいなのもどっかで見たな。

616 ：デフォルトの名無しさん：2007/09/16(日) 21:31:31

極力interfaceで受け取れいうてる今までとの親和性の問題もあるし、
今後の拡張はローカルキーワードで行きたいって思惑もあるから
早い段階でサポートするならそっちかもな

>>615
みたけど流石にそれはないｗ

617 ：デフォルトの名無しさん：2007/09/16(日) 21:42:13

varの方はGraphicsEnvironment.getLocalGraphicsEnvironment()とか長すぎるから何とか汁って考えもあったはず

618 ：デフォルトの名無しさん：2007/09/16(日) 21:47:32

>>617
つ static import

619 ：デフォルトの名無しさん：2007/09/16(日) 21:49:48

staticじゃなきゃ役にたたねーけどね

620 ：デフォルトの名無しさん：2007/09/16(日) 21:52:21

メソッド名が長いのはメソッド名のalias導入とかせんと解決せんのでは？

621 ：デフォルトの名無しさん：2007/09/16(日) 21:54:22

関係ないけど、メソッド名ってたしか長さ制限あったよね

622 ：デフォルトの名無しさん：2007/09/16(日) 22:00:53

static importはユーティリティメソッドに
沢山依存してる状態じゃないと返って面倒なだけ

623 ：デフォルトの名無しさん：2007/09/16(日) 22:05:31

名前空間が汚れる。

624 ：デフォルトの名無しさん：2007/09/16(日) 22:06:13

まあ、結局のところD言語はvarで解決としたみたいだからJavaもそうなるよ。
プロパティ問題も馬鹿なことやらないで、素直にC#風にしたしね。

625 ：デフォルトの名無しさん：2007/09/16(日) 22:26:52

> プロパティ問題も馬鹿なことやらないで、素直にC#風にした
ソースは？

626 ：デフォルトの名無しさん：2007/09/16(日) 23:43:33

>>590
Common Lisp, Scheme(R5RSから)

(define (foo) (values 1 2))
(set!-values x y (foo))

(set!-values q r (quotient&remainder 10 3))

スタックフレームの返値を格納するスロットが一つ増えるだけだから、
tupleやlistやarrayを箱にする方法より性能がいい。

627 ：デフォルトの名無しさん：2007/09/17(月) 00:01:39

>スタックフレームの返値を格納するスロットが一つ増えるだけだから、
それやると VM の変更が必要にならんか？

> tupleやlistやarrayを箱にする方法より性能がいい。
その辺の性能あげるためにエスケープ解析とか頑張ってるんじゃね？

628 ：デフォルトの名無しさん：2007/09/17(月) 00:02:35

>>627
VMの変更っつーか、VM仕様の変更じゃね？

629 ：デフォルトの名無しさん：2007/09/17(月) 00:07:16

>>625
http://docs.google.com/View?docid=dfhbvdfw_1f7mzf2
これの事じゃね？

でも、これbeansのプロパティと互換性ないし、
フィールドとプロパティの名前がかぶった場合どうなるかって部分も甘いような。

630 ：デフォルトの名無しさん：2007/09/17(月) 12:14:51

多値はいつか実現して欲しいね。
引数は0個以上なのに、結果は0か1に制限されているのは不便。

>>589
他の言語で使うと癖になるから、粘着的なw要望が続くんだと思う。

631 ：デフォルトの名無しさん：2007/09/17(月) 12:20:52

>>630
なんつーか、Perlとかで初めてsplitの結果を複数の変数に
まとめて入れる表現見たとき便利だと思ったわけで、
こういうのって、返値は配列として扱ってるじゃない。

配列の返値を、各変数に代入するシンタックス糖分があればいいんじゃないかな？

632 ：デフォルトの名無しさん：2007/09/17(月) 13:34:05

> スタックフレームの返値を格納するスロットが一つ増えるだけ

> 配列の返値を、各変数に代入するシンタックス糖分があればいい

この二つって全然別の要求なわけで……

633 ：デフォルトの名無しさん：2007/09/17(月) 13:35:18

>>630
粘着的な要望する奴は口だけ動かして手を動かさんからなぁ……

634 ：デフォルトの名無しさん：2007/09/17(月) 14:09:07

>>632
多値って一口に言っても、考えてる事が微妙に違うからなぁ……

635 ：デフォルトの名無しさん：2007/09/17(月) 14:49:27

とりあえず配列でやっておけばいいんじゃないの？

636 ：デフォルトの名無しさん：2007/09/17(月) 14:52:17

>>635
Object[]を使えばいいじゃんって意味？その場合、複数種類の型を内包する配列を扱うことになるから、
言語的なサポートが欲しいって言ってるんじゃない？

637 ：デフォルトの名無しさん：2007/09/17(月) 14:53:20

>>633
このスレに要望出しても意味ねえんだけどな

638 ：デフォルトの名無しさん：2007/09/17(月) 14:54:47

型の問題があるなら、引数のほうに値をうけとる配列として渡すとかね。

639 ：デフォルトの名無しさん：2007/09/17(月) 14:58:05

>>637
要望だした時点で気持ちよくなってんじゃないかと。
要望を実現する事よりも、気持ちいい事の方が重要なんじゃね？

640 ：デフォルトの名無しさん：2007/09/17(月) 15:48:10

ゆとりのやつって、直接的な効果がなければ意味ねぇとかよく言うよね。
間接的な効果を想像できないんだよね。

641 ：デフォルトの名無しさん：2007/09/17(月) 15:53:01

あるあるｗ
ちょっとたとえを出して、それを否定できただけで、全てを否定ｗ

642 ：デフォルトの名無しさん：2007/09/17(月) 15:53:48

間接的な効果に期待（するだけ）しかできないんだったら
> 要望を実現する事よりも、気持ちいい事の方が重要なんじゃね？
って評価は正しいような。

643 ：デフォルトの名無しさん：2007/09/17(月) 17:26:43

はいはい、ここは次世代Javaのスレですよっと

JSR-310 に generics版なるものが出来ていた。
https://jsr-310.dev.java.net/nonav/generics/index.html
https://jsr-310.dev.java.net/servlets/ReadMsg?list=dev&msgNo=726
> The basic theory is to define a class for each of the basic concepts -
> Day, Month, Year, Hour, Second etc, and then utilise those in other
> ways. These are TimePart subclasses.
>
> Instead of having a dedicated Seconds class that holds only seconds,
> there is a single TimeAmount class that is generified:
>
> Standard design:
>　 Seconds s = seconds(3);
> Generics design:
> 　TimeAmount<Second> s = seconds(3);
>
> Similarly, the field classes such as DayOfMonth are removed with a
> single generified TimeField class:
>
> Standard design:
> 　DayOfMonth dom = dayOfMonth(3);
> Generics design:
> 　TimeField<Day, Month> dom = dayOfMonth(3);

個人的に generics版にするなら var dom = dayOfMonth(3); タイプの型推論が欲しいような。

644 ：デフォルトの名無しさん：2007/09/17(月) 20:18:05

http://blogs.wankuma.com/kacchan6/archive/2007/09/17/96592.aspx

645 ：デフォルトの名無しさん：2007/09/18(火) 08:41:40

generics版は、入力めんどすぎだな

646 ：デフォルトの名無しさん：2007/09/18(火) 16:45:33

ドキュメント簡潔で理解しやすいしこっちのほうが好きなのは俺だけか

それはそうと９月の第三月曜日とか毎月第五土曜日（と、第五土曜日が存在するかチェックする方法）とか
どうやって入力するんだろう？この程度のことがいちいち煩雑なのは嫌なんだけど。
曜日指定できそうなCalenderDayのDayOfWeekは引数がなぜかint型だし。
曜日関係はまだまだこれからなのかね？

647 ：デフォルトの名無しさん：2007/09/18(火) 20:37:07

あれだ。
カレンダー用のXPathみたいなの作って
W3C標準にすればいいんじゃね？

648 ：デフォルトの名無しさん：2007/09/18(火) 21:04:02

CQL

CalendarQueryLanguage

ばばーん >>647 がただ今鋭意作成中です

649 ：デフォルトの名無しさん：2007/09/18(火) 23:12:45

>>647
Structured Calendar And Time Markup Language
略してSCATML。それのAPIがSCATMLAPI。

650 ：デフォルトの名無しさん：2007/09/18(火) 23:19:52

31日や2月29日みたいなTimeFieldやTimeViewって
カレンダーが背後にあるクラスに受け入れられるまで、意味のあるカレンダーデータかどうかわかんないわけだよな。
ついでにPeriodを加算するみたいな日付計算もできない。
それなら『カレンダーが背後にあるクラス』をインターフェース化しておいたほうがいいんじゃないかと思ったり。
最初はCalendricalがそうかと思ったんだけどなんか違うっぽいな。

651 ：デフォルトの名無しさん：2007/09/18(火) 23:54:39

やっぱCalendricalか。何故かTimeViewやTimeFieldに継承されているけどこれは何かの間違いだな。

weekOfMonthが作れるようになったりTimeField同士を結合してTimeViewを作ったりできねえかな。
そしたら今年の９月の第３月曜日とかでも楽に指定できるのに。難しいのかこれは。

652 ：デフォルトの名無しさん：2007/09/19(水) 00:00:02

TimeAmountで期間データの変換が相互に可能になってるっぽいが
Second～DayはともかくDay～Foreverのデータはカレンダーないと変換できないような。
いちいちUnsupportedOperationException投げるつもりかいな

653 ：デフォルトの名無しさん：2007/09/19(水) 02:32:47

こんな感じで書けないかな
static import javax.time.Moments.*

...

TimeView<Day,Year> leapyearday = build(MonthOfYear(2), dayOfMonth(29));
CarenderYear year = now().currentYear();

List<CalenderDay> lyds = new ArrayList<CalenderDay>();
for(int i = 0; i < 10; i++){
　　CarenderDay tmp = CalenderDay(year.plus(i), leapyearday);
　　if(!tmp.wasRolledGenerate())
　　　　lyds.add(tmp);
}

654 ：デフォルトの名無しさん：2007/09/19(水) 02:54:46

>javax.time.Moments.*
パッケージ名だけ見たらとてつもなく抽象的すぎて何に使って良いかわかりづらいな。

655 ：デフォルトの名無しさん：2007/09/19(水) 03:17:56

TimeUtilsとかの方がいいよな。常識的に考えて。
そのうち変わると思うが

656 ：デフォルトの名無しさん：2007/09/19(水) 11:16:37

>>654
time.Momentsってそんなにわかりにくいかな？

657 ：デフォルトの名無しさん：2007/09/19(水) 13:15:14

個人的にクラス名変えるならこんな感じ
時刻系
TimeView＞TimeExpression：時刻表現
Calendrical＞ScaledTime：カレンダー評価済み時刻表現
TimeField＞TimeField：即値時刻表現

期間系
Period＞Period：期間
TimeAmount＞PeriodField：即値期間

単位系
TimePart＞Unit：単位

その他
Moments＞TimeUtils：ユーティリティクラス

うーん、イマイチ。

658 ：デフォルトの名無しさん：2007/09/19(水) 16:48:46

クラス名・変数名に迷ったら書き込むスレ。Part10
ttp://pc11.2ch.net/test/read.cgi/tech/1180146315/

ここにお願いしてみては

659 ：デフォルトの名無しさん：2007/09/19(水) 18:46:41

>>656
今のクラス名だと高精度の時間取得APIとも取れるし、時系列系APIのフレームワークとも取れる。

名前から想像できる用途が曖昧で冗長といった印象。
名前からすると一見汎用性がありそうだけど、
けど中身はカレンダーAPIの上位API程度の印象も受ける。

そのため、今のカレンダーAPIとの関係も分かりづらい。
そうなると移行や使い分けが難しいかと。

要するに何のために作ったのか分からん、と・・・。

660 ：デフォルトの名無しさん：2007/09/19(水) 19:01:06

どう見ても完全に置き換えるものとして使うようにできてるだろ。
互換性を意識しないといけない場合以外は全部移行していいようにするんじゃないのか？
まだOverViewには入ってないがフォーマッティングやパーシング用のクラスも作るらしいし。

661 ：デフォルトの名無しさん：2007/09/19(水) 19:22:46

java.util.concurrent.TimeUnit も忘れないであげて

662 ：デフォルトの名無しさん：2007/09/21(金) 13:05:43

JSR 277とJSR 291は議論が熱いね。
http://www.infoq.com/jp/osgi

663 ：デフォルトの名無しさん：2007/09/22(土) 10:54:13

OSGi関係は熱そうだね。
関わってるところ多いし、影響が大きそう

664 ：デフォルトの名無しさん：2007/09/24(月) 18:48:55

JDK7、機能はすごい魅力的なんだが、リリースが一年以上先か・・・。
堅実なのはいいことだけど、もうちょっと早くならんかなあ。

665 ：デフォルトの名無しさん：2007/09/25(火) 01:28:48

目玉機能とされてるJSR-277もまだだし
Closureに至ってはJSRすらないしなぁ。

これでリリースまでに全部つっこんできたら十分早いと思うが。

666 ：デフォルトの名無しさん：2007/09/27(木) 22:46:13

業界的にはまだバージョン4が多数だから早い感じもする。

667 ：デフォルトの名無しさん：2007/09/28(金) 00:51:19

テンプレート(1.5)、クロージャ(1.7)とくれば、最後に来るのは…マクロ！(1.9予定)

すべての言語は最後はlispの一部を再実装する事になるのかと思うと、複雑な気分だな。

668 ：デフォルトの名無しさん：2007/09/28(金) 01:00:50

バージョン4なんかない。

669 ：デフォルトの名無しさん：2007/09/28(金) 02:22:08

>>668
R4のことだろ？

670 ：デフォルトの名無しさん：2007/09/28(金) 04:08:52

RhinoR4？ライセンスが・・・ｗ

671 ：デフォルトの名無しさん：2007/09/28(金) 10:11:40

最後はevalだな。

672 ：デフォルトの名無しさん：2007/09/28(金) 11:10:22

OSGiじゃないのか？

673 ：デフォルトの名無しさん：2007/09/28(金) 14:32:28

JDK7 build21
http://download.java.net/jdk7/binaries/
http://download.java.net/jdk7/changes/jdk7-b21.html
だって。
ようやくコンパネの縦長が直った。

674 ：デフォルトの名無しさん：2007/10/09(火) 15:06:09

OSGiかなにかのプラグイン機構がJava SEに入るまでまだ一年位あるので、
Javaのスクリプトで代わりをできないかと思ったんですが、
次を読むと普通にできそうですね。
（つまりJavaプログラム実行中に動的に実行コードを入れ替えたい。）

JavaからRubyスクリプトを実行する
http://codezine.jp/a/article/aid/1647.aspx?p=3

個人的にプラグイン機構の重要度がかなり下がりました。

675 ：デフォルトの名無しさん：2007/10/09(火) 15:14:59

普通にクラスローダを使えばいいだけじゃないの？

676 ：デフォルトの名無しさん：2007/10/09(火) 15:26:11

クラスローダは難しい・・・
昔OSGiを使ってたときですらクラスローダで苦労した。
確か、setContextClassLoader辺りとか頻発した。
（OSSのライブラリでこれが設定できないので、プラグインから使うために
　ソースを書き換える必要が発生したこともあった。）
記憶が薄れてるけどOSGiが無いとさらに倍以上苦労する感じだったと思う。

677 ：デフォルトの名無しさん：2007/10/10(水) 02:31:03

URLClassLoaderで簡単にJARファイルからクラスを読み込めるから、
プログラム実行中に動的に実行コードを入れ替えるのは簡単だと思うけどな。

678 ：デフォルトの名無しさん：2007/10/10(水) 08:53:59

>>674
Rubyてw
Javascript使えよ。最初からSEに入ってんだから。

679 ：674：2007/10/10(水) 13:46:54

助言？ありがとうございます。

>>677
setContextClassLoaderは、Jar内のファイルを読むために
基盤とプラグインのJarのClassLoaderを切り替える
のに使ってたんだったと思いますが、
URLClassLoaderを使うと簡単にできそうな気がします。

>>678
JRubyは速いと言う記事が目に入ったので
条件反射で調べてみたのですが、
JavaScriptでいいですね。Rubyは殆ど知らないし。

680 ：674：2007/10/10(水) 13:49:23

ちなみにやりたい事は、
UMLのステートチャート図で状態遷移を定義しXMLを生成する
（このエディタは自作する）
実行時はXMLに従って、各状態と遷移時の処理を行う。
基本的に、ステートパターンで実現する。
こんな感じの多目的に使えるフレームワーク作り。

と言う感じで、DIコンテナで普通にできそうですね…。
それが一番早いなｗ

681 ：デフォルトの名無しさん：2007/10/10(水) 16:20:30

>>677
具体的にどういうコードになるの？
クラスローダーは複雑で言ってる事が見えてこない…

682 ：デフォルトの名無しさん：2007/10/10(水) 16:44:08

>> 681
丁度いいページがあったので勝手にリンクさせてもらいます。
ttp://homepage3.nifty.com/satoshis/java/memo.html#extension

683 ：デフォルトの名無しさん：2007/10/11(木) 03:45:19

JRubyは本家と比べて早いって意味だ。
まあ、宗教は自由だぜ！

684 ：デフォルトの名無しさん：2007/10/11(木) 09:54:50

>>682おお、そういうことか！

685 ：デフォルトの名無しさん：2007/10/13(土) 23:07:55

そろそろクロージャの仕様決まった？情報まだぁ

686 ：デフォルトの名無しさん：2007/10/13(土) 23:23:22

http://www.javac.info/
http://www.javac.info/closures-v05.html
http://www.javac.info/consensus-closures-jsr.html

あたりは動いてないね。JCPのJSRのリストにも登録されてないみたいだし。
他の場所では動いてるのかも知らんけど

687 ：デフォルトの名無しさん：2007/10/13(土) 23:49:45

ああ、いろいろプロポーズはあるみたいだけどそれが採用されそう。

688 ：デフォルトの名無しさん：2007/10/14(日) 01:16:57

簡単に読み書きできることが重視されるJavaでは導入が難しいのかも。

クロージャに結びつけた変数に対して破壊的操作を行うプログラムを書いちゃうと、
非常に理解が難しいプログラムになる。と某所で言われていた。

689 ：デフォルトの名無しさん：2007/10/14(日) 01:28:27

staticメソッドとクロージャを組み合わせて制御文みたいなのを作れるのは面白いと思ったけど
フォールスルーしないswitch文みたいなのは無理かね

690 ：デフォルトの名無しさん：2007/10/14(日) 02:13:48

クロージャ、クロージャ言うけどクロージャ導入しても元々クロージャに書き換えるようなメソッドなら
コンパイル時にインライン化されてるだろうから人がクロージャ書く意味ってあるか？

JavaScriptも使うからクロージャは大好きだが・・・。

691 ：デフォルトの名無しさん：2007/10/14(日) 02:20:41

うん、無理っぽいな。できたとしてもがcaseに指定された値が定数かどうかを判別するすべがないから意味ないし

String line;
while ((line = br.readLine()) != null)
みたいなループをfor eachLine(String line : br)みたいには直せそうだ。あんまりいい例じゃないが

>>690
コストが低いからクロージャを使うわけじゃないだろ

692 ：デフォルトの名無しさん：2007/10/14(日) 03:35:29

いいかげんプリプロセッサとはいわんからせめて#ifdefを導入しろよ

693 ：デフォルトの名無しさん：2007/10/14(日) 03:46:15

＞＞６９０
わかりやすいから使うんじゃないのか？
いい加減いちいち無名クラスを宣言するのめんどうになってきたよ。

694 ：デフォルトの名無しさん：2007/10/14(日) 04:47:24

もう関数型のパラダイム全部入れちゃえばいいじゃんｗ

695 ：デフォルトの名無しさん：2007/10/14(日) 05:53:53

どうせこうなるんなら最初からいれちゃえばよかったのに

696 ：デフォルトの名無しさん：2007/10/14(日) 13:56:40

クロージャが、多重継承のようにうまく使えば有用だが弊害もある機能だったらどうするんだ？
Javaはハッカー向け言語ではなく一般向け言語なんだし、彼らが誤用しにくい機能であるか検証しなければならない。

697 ：デフォルトの名無しさん：2007/10/14(日) 14:24:52

どのように有用？
別に一般向けでないが？
自分で使いこなせればよいだけだし？
おまえ、キモイ顔しているんだろうな。

698 ：デフォルトの名無しさん：2007/10/14(日) 14:27:52

>>692
既にあるにはあるだろう。

699 ：デフォルトの名無しさん：2007/10/14(日) 14:50:31

根本的には関数型言語のパラダイムを中途半端に取り入れるのが不味いんだろうな。
だれか、両方を統合するようなアイデアを発明してくれればいいんだが。

700 ：デフォルトの名無しさん：2007/10/14(日) 15:46:57

ところで、>>696は一体全体何を主張したかったのだろうか…謎は深まるばかりだ…

701 ：デフォルトの名無しさん：2007/10/14(日) 16:55:18

>>699
命令型と関数型で、破壊的代入の在る/無しという根本的な前提が異なっているからなぁ。
この大きく異なる前提を乗り越えて上手く使える機構が欲しいね。

702 ：デフォルトの名無しさん：2007/10/14(日) 17:07:59

不変なオブジェクトを渡すか防衛的コピーして渡すか変更不可能なビューを渡すかすればいい話なんじゃないのか
Immutableオブジェクトを作るときと同じじゃん

703 ：デフォルトの名無しさん：2007/10/14(日) 17:09:24

その違いがなくなると、命令型と関数型の垣根がなくなってしまうし、いくら欲しくても乗り越える事はできなだろう。

704 ：デフォルトの名無しさん：2007/10/14(日) 18:53:24

>>688
int な変数を final int[] みたいに似非参照化して
内部クラスや匿名クラスで使えば結局同じ事になるけど、
記述が容易になると初心者が躓く可能性が高いとかそーゆー話？

http://docs.google.com/View?docid=k73_1ggr36h
CICE とかの public int みたいな構文糖の方が良いって話か？

705 ：デフォルトの名無しさん：2007/10/14(日) 18:54:47

こんなん考えてみた。
public static <R, T, throws E>
R log(T t, Class<T> clazz, { T => R throws E } block) throws E {
　　T proxy = Proxy.newProxyInstance(t.getClass().getClassLoader(),
　　　　　　　　　　　　　　　　new Class[]{ clazz },
　　　　　　　　　　　　　　　　new InvocationHandler(Object obj, Method method, Object args)){
　　　　　　　　　　　　　　　　　　StringBuilder sb = new StringBuilder(obj + " : " +method + " : ");
　　　　　　　　　　　　　　　　　　for(Object o : args){ sb.append(o).append(" , "); }
　　　　　　　　　　　　　　　　　　System.out.println(sb);
　　　　　　　　　　　　　　　　　　return method.invoke( obj, args );
　　　　　　　　　　　　　　　　}
　　System.out.println("Logging Start : " + t );
　　R r = block.invoke(proxy);
　　System.out.println("Logging End : " + t );
　　return r;
}

で、使い方
log(List logList : list, List.class){
　　//処理
}

これでこのブロックの中でだけ特定の変数のメソッド呼び出しのログが取れるはず
ちょっといじれば特定のアノテーションのついているメソッドの呼び出しだけに反応するようにもできると思う

706 ：デフォルトの名無しさん：2007/10/14(日) 19:27:18

そんなに難しく考えなくともecma-262とかScalaがあるじゃないか。
両立は可能だ。

707 ：デフォルトの名無しさん：2007/10/14(日) 19:48:05

>>705
return method.invoke( obj, args );じゃなくて
return method.invoke( t, args );だわ
そういやobjはプロキシインスタンスだった

708 ：デフォルトの名無しさん：2007/10/14(日) 19:49:58

>>704
void hoge(){
　public int total;
　array.each{int item => total += item;}
　System.out.println("合計は" + total);
}
とすると
void hoge(){
　final int total[] = new int[1];
　array.each(new EachRunner(){
　　public void run(int item){
　　　total[0] += item;
　　}
　}
　System.out.println(合計は" + total[0]);
}
と変換されるという案が出てたはず。

709 ：デフォルトの名無しさん：2007/10/14(日) 19:53:00

>>708
CICEとBGGAごっちゃになってねーか？

710 ：デフォルトの名無しさん：2007/10/14(日) 20:54:04

>array.each{int item => total += item;}
こういう文は見慣れない奴はインデントに困るだろうな。

array.each{ int item =>
total += item;
}

711 ：デフォルトの名無しさん：2007/10/14(日) 21:15:14

array.each(
　　{int item => total += item;}
);

こういうインデントは？

712 ：デフォルトの名無しさん：2007/10/14(日) 21:35:40

>>711みたいに>>710のインデントを知らん奴がいるから混乱するんだ。

713 ：デフォルトの名無しさん：2007/10/14(日) 21:50:42

>>712
インデントにうるさいおまえと一緒だと疲れる

714 ：デフォルトの名無しさん：2007/10/14(日) 22:33:45

インデントにうるさい言語があったよな。おまえはそれを使ってればいい

715 ：デフォルトの名無しさん：2007/10/14(日) 22:53:03

ぱいそん

716 ：デフォルトの名無しさん：2007/10/15(月) 01:28:48

複人数開発でインデントにうるさいのは当たり前だろ。
コーディング規約なんだから。

717 ：デフォルトの名無しさん：2007/10/15(月) 01:54:18

インデントなんか IDE が勝手にするだろ。
保存時に規約に沿うように自動フォーマット。
気にすんのはエディタ使ってるおっさんだけだ。

718 ：デフォルトの名無しさん：2007/10/15(月) 11:38:51

改行位置は勝手にやってくれなくないか？

719 ：デフォルトの名無しさん：2007/10/15(月) 11:50:20

今時のIDEならやってくれなくなくない？

720 ：デフォルトの名無しさん：2007/10/15(月) 12:53:26

Eclipse使えば自動フォーマットもすごいカスタマイズできるよ。
改行の位置も、(俺はコードの単位を明示的に分けたいから有効にはしないけど）
設定すればできる、と思う。

721 ：デフォルトの名無しさん：2007/10/15(月) 16:43:38

既にインデントは「する」ものじゃなくて「される」ものだろ。
人間がやるのは、内容の記述だけで、その整形は完全にIDEまかせ。
でも、eclipseできれいにインデントできないって理由で、仮引数へのアノテーションをためらう本末転倒な俺ガイル

722 ：デフォルトの名無しさん：2007/10/15(月) 17:03:49

細かい事気にしすぎ。

723 ：デフォルトの名無しさん：2007/10/15(月) 17:35:52

>>721
見やすさのためのインデントはそれでいいんだけど、
Pythonのようなインデント自体が括弧の役割をする言語ではまた別の話だよね。

724 ：デフォルトの名無しさん：2007/10/15(月) 17:38:12

人の書いたプログラムなど見ないで済むように偉くなれ。

725 ：デフォルトの名無しさん：2007/10/15(月) 17:39:06

>>723
とは言っても、Pythonでも見やすいインデント、というのはあるわけで。

726 ：デフォルトの名無しさん：2007/10/15(月) 18:05:18

ト・コ・ロ・デ

JDK7 build22
ttp://download.java.net/jdk7/changes/jdk7-b22.html
ttp://download.java.net/jdk7/binaries/

SwingWorkerのスレッドプールを使う処理が書き直されたらしい。
シャットダウンフックを使うようになったとかなんとか。

727 ：デフォルトの名無しさん：2007/10/15(月) 18:40:16

Javaは原則フリースタイル系統の言語だし、インデントはどうでもいいと思うが？
コーディング規約が別にあるとかいうならそれに従うまでだし。

728 ：デフォルトの名無しさん：2007/10/15(月) 20:45:32

Cとかに比べれば相当コーディング規約はしっかりしてると思うが

729 ：デフォルトの名無しさん：2007/10/15(月) 21:48:21

しっかりしているのは認めるが、しかしそれは言語仕様ではない。
インデントも含めて、コーディング規約も次世代に入れて欲しいと願っているのだろうか。

730 ：デフォルトの名無しさん：2007/10/16(火) 01:17:12

>シャットダウンフックを使うようになったとかなんとか。
使い方によってはwinでコケまくりだな。

昔よくフォーラムで流れたjavawからシャットダウンフックが起動しないってのが復活するんじゃない？

731 ：デフォルトの名無しさん：2007/10/16(火) 03:00:16

>>729
そこまですると、やり過ぎではなかろうかと思う。
俺はとりあえず括弧とif, for, whileの書式さえ統一されてればいいと考えてる。

732 ：デフォルトの名無しさん：2007/10/16(火) 03:16:45

まあもういいんじゃないか。そのコーディングとらやの話は。

733 ：デフォルトの名無しさん：2007/10/16(火) 10:56:12

20年以上前、ACM SIGPLAN Noticeでも、
インデントの話は禁止になったことがある。

734 ：デフォルトの名無しさん：2007/10/16(火) 14:07:05

↓↓↓次世代Javaの動向↓↓↓

735 ：デフォルトの名無しさん：2007/10/16(火) 14:11:07

命名規則とインデントはどうやっても宗教戦争になっちゃうからね。

736 ：デフォルトの名無しさん：2007/10/16(火) 17:12:35

まあもういいんじゃないか。そのコーディング虎屋の話は。

737 ：デフォルトの名無しさん：2007/10/16(火) 21:26:53

コーディングとらやの羊羹

738 ：デフォルトの名無しさん：2007/10/16(火) 21:53:01

とらやの話か。

739 ：デフォルトの名無しさん：2007/10/17(水) 01:35:40

虎屋の話と聞いて飛んできますた。

740 ：デフォルトの名無しさん：2007/10/17(水) 01:51:43

どうしてこうも人は争いの種を作ってしまうんだろうか

741 ：デフォルトの名無しさん：2007/10/17(水) 01:56:03

Javaの世界なのにJava以外の前提（CやC＋＋）を持ち出したのが原因。

742 ：デフォルトの名無しさん：2007/10/17(水) 01:58:35

人は人、自分は自分。偉い人には分からないのです。

743 ：デフォルトの名無しさん：2007/10/17(水) 02:23:48

誰もC/C++の話はしてないが

744 ：デフォルトの名無しさん：2007/10/17(水) 02:37:55

で、次世代はどーくるわけよ？

745 ：デフォルトの名無しさん：2007/10/17(水) 05:04:25

>>742 偉い人には分かるんじゃないか？ん？

746 ：デフォルトの名無しさん：2007/10/17(水) 07:58:18

俺はJavaの標準コーディング規約には満足してるけどな。
C#の、先頭を大文字にする記法や、プライベートフィールドの先頭にアンダーバーを付ける記法に比べれば、
よっぽどスマートだよ。

747 ：デフォルトの名無しさん：2007/10/17(水) 08:49:20

Rubyを侮辱するのは止めてください。

748 ：デフォルトの名無しさん：2007/10/17(水) 11:36:31

ﾜﾛﾀ、Rubyのコーディング規約はそうなってるのかｗ

749 ：デフォルトの名無しさん：2007/10/17(水) 12:23:57

規約でなく、言語仕様だね。@で始まるとメンバフィールドになる。

750 ：デフォルトの名無しさん：2007/10/17(水) 13:07:54

大文字で始まるとimmutable。> Ruby

751 ：デフォルトの名無しさん：2007/10/17(水) 15:10:32

C#はVCと同じくMSのキモサモサが良く出ている言語だと思う

752 ：デフォルトの名無しさん：2007/10/17(水) 16:05:50

C#で画面を作るとコントロールを描画している過程が見えるからなぁ

753 ：デフォルトの名無しさん：2007/10/17(水) 16:13:23

C#出たころからｺﾞﾃｺﾞﾃとJavaにいろんな機能がつき始めたよな

754 ：デフォルトの名無しさん：2007/10/17(水) 16:16:12

最近のJavaは美しくないというか崩れてきてる感があるな

755 ：デフォルトの名無しさん：2007/10/17(水) 16:21:23

genericsとannotation(とprintf)くらいで十分だったのにな
静的型言語でgenericsなしとかﾊﾞｶじゃないかと思ってたが今はいらんのつけすぎ

756 ：デフォルトの名無しさん：2007/10/17(水) 16:38:36

まぁでも早くC#に追いついて欲しいとは思うし難しいところだ

757 ：デフォルトの名無しさん：2007/10/17(水) 16:38:40

>>754 具体的にどこ？
>>755 といっても数年後にはクロージャとかenumとか使うようになるよ。

758 ：デフォルトの名無しさん：2007/10/17(水) 17:27:17

今だに使われるFORTRAN77は不滅だよ

759 ：デフォルトの名無しさん：2007/10/17(水) 17:32:40

>>754
なんとなくだがいいたいことはわかる。初期の頃の簡潔さは失われつつあるからな。
それでも、頻繁にクロージャ用無名クラスを作ってるようなら、クロージャを導入する意味はあると思う。

760 ：デフォルトの名無しさん：2007/10/17(水) 19:16:44

クロージャは必須だろ。
プロパティは辞めて欲しいが。

761 ：デフォルトの名無しさん：2007/10/17(水) 20:38:25

プロパティを作ってほしいとも思うが、セッターゲッターと互換性のないプロパティ作られるのも困る

762 ：デフォルトの名無しさん：2007/10/17(水) 22:15:11

セッターゲッターと互換性あるプロパティって何？？？

763 ：デフォルトの名無しさん：2007/10/17(水) 22:20:36

obj.property = value; が obj.setProperty(value); に、
value = obj.property; が value = obj.getProperty(); に、
展開されるような構文糖プロパティの事じゃね？

764 ：デフォルトの名無しさん：2007/10/17(水) 22:31:18

バージョンアップする限りJavaは肥大し続ける。

Java自体が陳腐化するか、
言語として互換性を捨て新たな言語に生まれかわらないとな。

765 ：デフォルトの名無しさん：2007/10/17(水) 22:39:36

どれだけ互換性捨てるかにもよるけど、新たな言語に生まれ変わらせるぐらいなら
Javaを捨てて、JVM用の新言語を立ち上げた方が既存のプログラムに影響少ないし
過去のしがらみ捨ててドラスティックに変えられるしで、良いと思うがね。

766 ：デフォルトの名無しさん：2007/10/17(水) 22:47:09

それはまだとっておこう。

767 ：デフォルトの名無しさん：2007/10/17(水) 22:49:25

新たな言語になったって、
バージョンアップのたびに肥大化し続けるのは変わらんだろうし、
時間が経つにつれ陳腐化するのは止められないだろうし。

768 ：デフォルトの名無しさん：2007/10/17(水) 23:10:19

Javaのクロージャで拘束変数の扱いはどうするつもりだろ？
楽なのは匿名クラスと同じでstatic finalな定数だけにするか、
拘束変数は必ずコピーにする方法なのだけど。

769 ：デフォルトの名無しさん：2007/10/17(水) 23:37:14

草案によって違う。

本命っぽい BGGA だと、
http://www.javac.info/closures-v05.html の Closure Literals にある
> All free lexical bindings (中略) are bound at the time of evaluation of the closure literal
> to their meaning in the lexical context in which the closure literal appears.

CICEだと、http://docs.google.com/View?docid=k73_1ggr36h
の III. Local Variables From the Enclosing Scope あたり、

FCM だと、http://docs.google.com/View?docid=ddhp95vd_6hg3qhc
B. Common rules and mechanisms にある
> Local variables from the enclosing scope may be accessed, both read and write

770 ：デフォルトの名無しさん：2007/10/17(水) 23:51:32

BGGA だと、受け取り側が java.lang.RestrictedFunction しかうけとらねーよと明示しておけば、
final がついてない局所変数使ってるクロージャリテラルは変換できなくてコンパイルエラーになる
とか、そーゆー制限も考えられてるみたいだけど。

771 ：デフォルトの名無しさん：2007/10/18(木) 02:47:35

レキシカルクロージャがいいな。

javaはVMも言語もクラスファイル仕様も互換性確保は相当なものだが、ライブラリ詰め込みすぎが悪い。

#rubyは言語界のモルモン教

772 ：デフォルトの名無しさん：2007/10/18(木) 03:08:54

どの辺りがモルモンしてる？

773 ：デフォルトの名無しさん：2007/10/18(木) 11:08:02

製作者がモルモン教徒

774 ：デフォルトの名無しさん：2007/10/18(木) 18:24:15

というかruby信者がモルモン信者と同じ臭いがする。

775 ：デフォルトの名無しさん：2007/10/18(木) 20:37:37

Macユーザーで、はてなユーザーで、rubyユーザーでケータイがMEDIA SKINあたりだったら、
もう半径5mには入りたくない感じ。
聞きたくもない長所の押し売りをえんえんと聞かされそう。

776 ：デフォルトの名無しさん：2007/10/18(木) 20:49:07

それ、なんて宗教？

777 ：デフォルトの名無しさん：2007/10/18(木) 21:13:55

>>775
プログラマーはあんましMAC使わないとおもうんだが。

778 ：デフォルトの名無しさん：2007/10/18(木) 21:16:36

MacもWindowsも使う。

どれかしか使わないというのが、言語論争と同じく不毛な流れかな？
javaもrubyもperlもpythonも適材適所に使えばいいじゃない

779 ：デフォルトの名無しさん：2007/10/18(木) 21:45:47

>>778
たしかに其れが一番かっこいい。

780 ：デフォルトの名無しさん：2007/10/18(木) 21:59:27

rubyはperlとpythonのパラダイムに影響受けてるからそっちの分野に食い込んでくるんだよ無理やり。
rubyの影響を受けたGroovyは言語が止まってるから問題ないが。

結局、JRubyとGroovyとJythonはScripting APIに組み込まれるのかね？
要らん気がする・・・。

781 ：デフォルトの名無しさん：2007/10/18(木) 23:46:52

JavaFXは偉大

782 ：デフォルトの名無しさん：2007/10/18(木) 23:47:28

なにが？

783 ：デフォルトの名無しさん：2007/10/19(金) 00:04:32

手元にあればmac使いたけどな。
だけどwinの方が安いからmac使う機会がないだけ。

784 ：デフォルトの名無しさん：2007/10/19(金) 00:13:40

普通にlinux使えよ

785 ：デフォルトの名無しさん：2007/10/19(金) 00:16:36

linuxは普通なのか？

786 ：デフォルトの名無しさん：2007/10/19(金) 00:58:05

MacメインでWindowsも使うJava好きのモルモン信者ですが、何か？

787 ：デフォルトの名無しさん：2007/10/19(金) 01:23:42

>>777
おいおい、Macはちょっとバージョンアップが遅いとは言え、
JREがプレインストールだし、JDKもインストールCDに付いているぞ。

Javaアプリを配布する環境としては優秀なのだ。
まだ、↓だけどな。
$ java -version
java version "1.5.0_07"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-164)
Java HotSpot(TM) Client VM (build 1.5.0_07-87, mixed mode, sharing)

788 ：デフォルトの名無しさん：2007/10/19(金) 01:46:49

アホ。釣られんな。

789 ：デフォルトの名無しさん：2007/10/19(金) 02:05:16

>>777
君、アタマ悪イッショ。
オンモ二デテミ。
君ノ馬鹿サガ…

790 ：デフォルトの名無しさん：2007/10/19(金) 02:54:19

アホ。釣られんな。

791 ：デフォルトの名無しさん：2007/10/19(金) 09:53:36

モルモンっていうと家畜の内臓がどうしても思い浮かぶ

792 ：デフォルトの名無しさん：2007/10/19(金) 23:47:33

未だに1.6が出てなかったのか…＞Mac

793 ：デフォルトの名無しさん：2007/10/20(土) 00:26:03

酷い話でしょ？コミュニティに任せた方がいいような気がするよ。

794 ：デフォルトの名無しさん：2007/10/20(土) 00:34:37

MacでJavaってそんなに使われてる？

795 ：デフォルトの名無しさん：2007/10/20(土) 00:46:49

V2Cを動かすのに必須。
これが無くなるとMacを捨てなくては・・・とまでいう重要ソフト。

796 ：デフォルトの名無しさん：2007/10/20(土) 01:00:03

fx＋bbs2chreaderでいいじゃない

797 ：デフォルトの名無しさん：2007/10/20(土) 01:04:06

icedteaだっけ？フリー版のないのか

798 ：デフォルトの名無しさん：2007/10/20(土) 01:06:55

Java SE 6 Update N
https://jdk6.dev.java.net/6uNea.html

ブラウザプラグインの書き直し
http://ajaxian.com/archives/ken-russell-on-the-new-java-plugin

この辺りの改良でクライアントサイドの勢いがついてほしい所だな。

799 ：デフォルトの名無しさん：2007/10/20(土) 11:18:05

java6のSwingは、結構Windowsのクライアントサイドでも戦える形になってきたかなと思う。
5と6での差異なんて、数ドット単位のデザインの違いが主なんだけど、その数ドットの差が大きい。
あとはスプリットボタン、シェブロンあたりのウィジェットが追加されればなー。

800 ：デフォルトの名無しさん：2007/10/21(日) 00:47:19

>>798
> The JVM also runs in its own OS process,
> so if the JVM crashes it doesn’t affect the browser.

へー、便利じゃんって、オイッ！

801 ：デフォルトの名無しさん：2007/10/21(日) 01:14:37

このJVMは独自のプロセスでも動くので、
JVMがクラッシュしたとしてもブラウザには影響を与えません。

そんなに変か？

802 ：デフォルトの名無しさん：2007/10/21(日) 10:03:06

今まで、さんざんブラウザを巻き沿いにしてきたみたいだよなw

803 ：デフォルトの名無しさん：2007/10/21(日) 10:18:23

巻き添えっていうか、一気に重くなってその負荷で落ちたように見えることは多かったけど。
ブラウザとは別のプロセスで実行できるってセキュリティ的に大丈夫なんだろうか。
ただでさえVistaでUACとかいうややこしいシステムをとってるのに。

804 ：デフォルトの名無しさん：2007/10/21(日) 10:27:36

↑大丈夫だからやったんじゃないかね

805 ：デフォルトの名無しさん：2007/10/21(日) 11:47:14

>>803
まずくなる理由が見つからんが…

806 ：デフォルトの名無しさん：2007/10/21(日) 12:25:31

>>803
Javaアプレットは、なぜネットワークからダウンロードしてきたコードを実行しても
安全なのか知りたければ、「バイトコードベリファイア」「サンドボックスシステム」
について調べてみるといい。
そうすれば、別プロセスで動作させても安全な理由がわかる。

807 ：デフォルトの名無しさん：2007/10/21(日) 12:27:37

>>805
Vistaで導入された鬱陶しい機能の一つに、UACとかいうのがある。
これは、セキュリティ対策のために、ブラウザの権限を制限するもんだ。
だから、ブラウザ上から呼び出されたプロセスには、なにかと制限がかかる可能性がある。
特に、ローカルのリソースにアクセスするようなのは、実行できないかもしれない。

まあ、>>804のいうようにわかってやってるはずだから、対策がないわけがないんだけどね。

808 ：デフォルトの名無しさん：2007/10/21(日) 17:03:53

>>807
>Vistaで導入された鬱陶しい機能の一つに、UACとかいうのがある。
>これは、セキュリティ対策のために、ブラウザの権限を制限するもんだ。

それはIE7の「保護モード」であって、UACではない。

809 ：デフォルトの名無しさん：2007/10/21(日) 18:32:03

>>808
そうだった。
今思い浮かんだんだが、もしかして保護モードを回避するために別プロセスに分けたのか？
だとしたら、俺が言ってたことはまるで逆だったのか。

810 ：デフォルトの名無しさん：2007/10/21(日) 19:18:12

↑だからここは君の浅知恵を披露する場ではないようだが

811 ：デフォルトの名無しさん：2007/10/21(日) 20:14:23

なんで次世代Javaスレに猿が混じっているのか不思議

812 ：デフォルトの名無しさん：2007/10/22(月) 10:35:00

↑猿の脳みそを持つ男

813 ：デフォルトの名無しさん：2007/10/22(月) 11:58:57

↓ご立派な人登場。

814 ：デフォルトの名無しさん：2007/10/22(月) 14:32:22

呼んだ？

815 ：デフォルトの名無しさん：2007/10/22(月) 16:23:51

おいおい、俺を差し置いてか？

ゴスリンが、JDK on Mac OS Xについて少し喋ってる。
http://blogs.sun.com/jag/

816 ：デフォルトの名無しさん：2007/10/22(月) 16:52:06

イヤ待て、もっと大変な事言ってないか？
オレには、MacOSXにZonesが載るって書いてるようにも読めるぞ。
流れ的にそう明言してないが・・・

817 ：デフォルトの名無しさん：2007/10/22(月) 18:52:08

>>816
Zonesってなに？

818 ：デフォルトの名無しさん：2007/10/22(月) 18:59:43

スレ違いだが、
Solaris:BSD:Linux≒Zones:Jail:Vserver

819 ：デフォルトの名無しさん：2007/10/22(月) 22:37:44

ｚ

820 ：デフォルトの名無しさん：2007/10/23(火) 04:27:30

sunはJava SEの後につく数字をマイナーバージョンとリンクさせているように見えるけど、
メジャーバージョンが上がる時にはどうするつもりなんだろう。
Java 2 SEとかにするのかな

821 ：デフォルトの名無しさん：2007/10/23(火) 06:18:24

>>820
予想
java version "1.6.0_0x"
java version "1.7.0_0x"
java version "1.8.0_0x"
java version "1.9.0_0x"
・・・わくわく
java version "1.10.0_0x"
・・・なんじゃそりゃ～

822 ：デフォルトの名無しさん：2007/10/23(火) 08:57:17

>>820
Java 2 Platform, Standar Editionとかぶりすぎ
>>821
そういうマイナーバージョンの桁上がりの問題じゃないからw

823 ：デフォルトの名無しさん：2007/10/23(火) 10:17:44

メジャーバージョンが上がるときの対策
・Javaのあとに新しいバージョンだとわかるようなコード・名前・別名をつける
・Java自体の名前がかわる
・何事もなかったかのようにバージョン表記統一

824 ：デフォルトの名無しさん：2007/10/23(火) 14:30:33

>>821
前にlinuxのソフトウェアでndiswrapperっていうのを使ってたんだが、
使用してるバージョンが1.7で、最新のバージョンが1.21だったのを1.2.1だと勘違いして
なんでバージョンダウンしてるのかすごい悩んだことがある。

825 ：デフォルトの名無しさん：2007/10/23(火) 16:31:30

SunOSとSolarisは、
Solaris 7から、SunOS 5.X=Solaris Xって関係で、
5ってのはkernelのメジャー番号。Xは共通の連番。

だからこれからJava/JDKも7, 8, 9, 10, 11と連番が上がっていって、
JVMの実装が大きく変わった時に、
連番とは関係なくJDKのメジャー番号が1→2と予想。

826 ：デフォルトの名無しさん：2007/10/31(水) 19:07:24

JDK7 build23
ttp://download.java.net/jdk7/changes/jdk7-b23.html
ttp://download.java.net/jdk7/binaries/

なんか今回は実質的な進捗なさげだな。
「ソースのスペースを掃除したよ」って。
なんか行き詰まってるときの作業だろ。

でも2週間に1ビルドのペースが出てきたのは評価したい。

827 ：デフォルトの名無しさん：2007/10/31(水) 21:05:23

クロージャのプロトタイプ発表とかどうとかは、どうだった？

828 ：デフォルトの名無しさん：2007/11/09(金) 23:07:29

クラス注釈に@RAIIとかサポートされたらいいな。
必ずスタックに乗るように解釈させて、スコープ抜けると必ずfinalizeされる。
メンバ内も含めてthisが代入または引数にされた場合は、コンパイルエラーとするとか。

829 ：デフォルトの名無しさん：2007/11/09(金) 23:20:54

７は5よりもいろいろと、てこもりで楽しみだな。

830 ：デフォルトの名無しさん：2007/11/10(土) 01:50:16

>>828
C言語のregisterとかと同じで、最初のうちは最適化義務はなく将来対応するとか言っておいて、
そのうち最適化が進化したので必要ないから無視するよってなるような気もする。

831 ：デフォルトの名無しさん：2007/11/10(土) 05:06:57

なんかもうJavaはIDE前提の言語として突き進んでほしいなあ。
言語仕様もとにかくIDEでサポートしやすい方向で。

832 ：デフォルトの名無しさん：2007/11/10(土) 09:24:07

>>828
finalizeされるタイミングを陽に指定できることは除いて、
今やescape解析の仕事です。
そんな時代遅れなものが入るわけがない。
>>831
馬鹿丸出し。

833 ：デフォルトの名無しさん：2007/11/10(土) 11:27:07

>>832
ゴスリングのこの発言があったタイミングで
バカ丸出しと脊髄反射するほうがバカ丸出し
http://www.atmarkit.co.jp/news/200711/07/techday.html

834 ：デフォルトの名無しさん：2007/11/10(土) 11:50:46

そんなの知ってるw
その解釈こそ馬鹿丸出しじゃん。
IDEで出来ることは、IDEでやればいいんだから。
言語を糞仕様にする必要はない。

835 ：デフォルトの名無しさん：2007/11/10(土) 13:04:43

>>194
Jakarta JJarのことか？
MavenにもJJarは同梱されているんだが

836 ：デフォルトの名無しさん：2007/11/10(土) 13:19:03

SunはSolaris向けのIPSを発表したしなあ。
http://opensolaris.org/os/project/pkg/documents/

最近、言語ごとにパッケージ管理/配布システムがあって困惑気味です。

837 ：デフォルトの名無しさん：2007/11/10(土) 19:31:56

ここにはエスケープ解析を研究してる奴いるから聞きたいことあれば聞いとけ。

838 ：デフォルトの名無しさん：2007/11/10(土) 20:58:50

Googleで検索すればすぐでてくる内容しか書かれてないのに研究だと？

839 ：デフォルトの名無しさん：2007/11/11(日) 06:30:11

クロージャの演算子 => , {int=>int}は他のなかったのかな？もう決定ぽいけど。
{int x=>x+1}とかぱっと見どうかと

840 ：デフォルトの名無しさん：2007/11/12(月) 15:07:20

lambda見なれてしまったから、他はなんでも違和感がある。
だからどうでもいい感じ。lambdaキーワードはあり得ないし。
Haskellみたいに\ってのもどうかと思うしさ。

841 ：デフォルトの名無しさん：2007/11/12(月) 23:40:09

>>839
1.5がでるときにGenerics見て、こんなのJavaじゃねぇって書き込みがいくつかあったよな
今、そんなこと言ってる奴いないだろう。慣れればそれが普通に見えてくるはず

842 ：デフォルトの名無しさん：2007/11/13(火) 00:10:57

プロパティのアクセス演算子は
c->p=x
x=c->p
で決定なのか？

843 ：デフォルトの名無しさん：2007/11/13(火) 00:40:12

>>842
いつの情報だ、それは。

844 ：デフォルトの名無しさん：2007/11/13(火) 01:03:03

結局Javaっていっても現状Web用途がメインなんだから
Servlet&JSPのほうがもっと良くなってほしい。

JSPがダメすぎてどうにもならない。

845 ：デフォルトの名無しさん：2007/11/13(火) 01:08:22

JSP、JSF、VelocityServlet、Wicket・・・好きなもの使え。

846 ：デフォルトの名無しさん：2007/11/13(火) 01:10:41

>>844
ここはSEのスレなんだよ。
そんな呆けだから(ry

847 ：デフォルトの名無しさん：2007/11/13(火) 01:36:26

>>843
え、古かった？
じゃ、今はなんだよ

848 ：デフォルトの名無しさん：2007/11/13(火) 02:20:28

>>846

ていうか標準のView仕様くらいもうSEに含めろっちゅう話やねん。
JSPにしても単なる条件分岐記述するのに別ライブラリダウンロードさせるってどないやねんって話やねん。

スクリプティングサポートする暇あったらテンプレートエンジンサポートしたほうが人気出るねん。

849 ：デフォルトの名無しさん：2007/11/13(火) 02:29:59

スクリプトレットの存在も知らなければ
テンプレートエンジンはスクリプトエンジンのひとつに過ぎないという実態も知らないのか？
テンプレートエンジンなんぞとっくにサポートされてるっての

850 ：デフォルトの名無しさん：2007/11/13(火) 02:39:48

>>849

おい、JSP2.1の時代にスクリプトレット使ってんのかよ・・・

851 ：デフォルトの名無しさん：2007/11/13(火) 02:41:43

お前が使いたいだけだろ、お前って御託だけで使い分けもできないのな

852 ：デフォルトの名無しさん：2007/11/13(火) 02:45:42

Java系の開発者って世の中のニーズが読めないやつばっかだよな・・・

853 ：デフォルトの名無しさん：2007/11/13(火) 02:51:53

典型的なかまってちゃんだな、JCPのこと調べたらJavaは諦めてPHPでもやっとけ

854 ：デフォルトの名無しさん：2007/11/13(火) 02:59:26

どっちにしろDerbyなんかSEに組み込むより、Viewのほうが先だろ・・・常識的に考えて・・・

855 ：デフォルトの名無しさん：2007/11/13(火) 03:01:41

かまってちゃんとわがままちゃんって同じ匂いがするんだよな。２ｃｈの経験上

856 ：デフォルトの名無しさん：2007/11/13(火) 04:23:08

>>848
頭悪～
Web制作板に行きなよ。
このスレはまだ早いよ。

857 ：デフォルトの名無しさん：2007/11/13(火) 15:25:07

>>82
これには何かぐっと来たぞ

858 ：デフォルトの名無しさん：2007/11/15(木) 01:06:38

>>854
ViewならSwingがあるじゃねぇか。

859 ：デフォルトの名無しさん：2007/11/15(木) 01:08:16

お前らこれ以上XSLTさんを泣かすな
名実ともにSEのViewだろ

860 ：デフォルトの名無しさん：2007/11/16(金) 18:41:58

名実が伴っているなら泣くこともないだろうw

861 ：デフォルトの名無しさん：2007/11/23(金) 18:53:57

Extension Methods とか出てる。
http://gafter.blogspot.com/2007/11/closures-prototype-update-and-extension.html

どうなんだろ？嬉しい事は嬉しいけど、これって名前空間汚れるような。
これが許されるなら、クロージャも closure.invoke(argument);
じゃなくて closure(argument); したい。

862 ：デフォルトの名無しさん：2007/11/23(金) 19:04:27

D言語にある機能だってのは知ってるけど、この機能の初出って何だろうね

863 ：デフォルトの名無しさん：2007/11/23(金) 19:14:58

そう書くことで綺麗に気持ちよく書けるものはどれくらいあるのかね

864 ：デフォルトの名無しさん：2007/11/23(金) 19:27:54

>>863
java.util.List みたいな published interface にメソッド追加するのが主な目的ってのはいわずもがなだけど。
他の使い道ってなんかあるかね？

865 ：デフォルトの名無しさん：2007/11/23(金) 19:44:36

例えばこんな感じのがあれば、それなりに便利だと思うよ。
int UnicodeUtils.getCodePointCount(Charsequence src, int off, int len);
int UnicodeUtils.getCodePointCount(char[] src, int off, int len);
int UnicodeUtils.getCodePointAt(Charsequence src, int index);
int UnicodeUtils.getCodePointAt(char[] src, int index);

866 ：デフォルトの名無しさん：2007/11/23(金) 20:02:23

>>865
char[] はともかくとして、String も StringBuilder も StringBuffer も、
codePointCount や codePointAt を持ってるはずだぞ。
CharSequence で持ってないのって java.nio.CharBuffer ぐらいか？

867 ：デフォルトの名無しさん：2007/11/23(金) 20:02:25

こんなダサイの入れるくらいなら、
Haskellのtype classとかC++のconceptみたいな
generic programming支援の機構を入れて欲しいわ。

868 ：デフォルトの名無しさん：2007/11/23(金) 20:24:34

interfaceで扱う事に意味があるんじゃないの。例えばC#だけど
List<E>.ForEach(delegate(E)) みたいなのがあるけど、IList<E>じゃ使えなくて困惑したことがある。

重複したときはエラーかオリジナルのオーバーロードどちらを優先するんだろう。
interfaceのままでもリフレクションで解決とかもいいけど、それは遅くなるか。

869 ：デフォルトの名無しさん：2007/11/23(金) 20:35:45

>>868
それは published interface の話じゃなくて？

そーいや、C# は 3.0 で extension method 入るんじゃなかったか？

870 ：デフォルトの名無しさん：2007/11/23(金) 20:59:46

static importはIDEと相性が悪い印象があってあまり使われてないけど
これが導入されたらIDEに第一引数でサーチいかせる感じで使われ出すんじゃないかな。

871 ：デフォルトの名無しさん：2007/11/23(金) 21:29:37

やっぱpublished interfaceにメソッド追加（したように見せかける）以外に使い道ないんじゃ？

872 ：デフォルトの名無しさん：2007/11/23(金) 21:56:47

内部構造はまったくいじれないしな

873 ：デフォルトの名無しさん：2007/11/25(日) 22:09:42

Javaってプライドとかないの？

874 ：デフォルトの名無しさん：2007/11/25(日) 22:19:37

ttp://java.sun.com/javase/ja/6/docs/ja/api/index-files/index-16.html
無いね。Java7 でもきっと無い。

875 ：デフォルトの名無しさん：2007/11/25(日) 22:19:46

Javaのプライドって何のプライドよ？

876 ：デフォルトの名無しさん：2007/11/25(日) 23:24:42

言語としてのプライド

877 ：デフォルトの名無しさん：2007/11/25(日) 23:27:34

なんかアホの子が出現してるな

878 ：デフォルトの名無しさん：2007/11/26(月) 11:50:05

>>861
> これって名前空間汚れるような。

その点、リンク張られているExpanderの方がまだいいね。

879 ：デフォルトの名無しさん：2007/11/26(月) 13:59:55

>>875
Java使いが集まって、大晦日に闘う。

880 ：デフォルトの名無しさん：2007/11/26(月) 14:17:23

Gosling緊急参戦！

とかなら見に行く。

881 ：デフォルトの名無しさん：2007/11/26(月) 14:50:30

>>879
冗談としては面白くないけど
本当にやったら面白そうだな、それ。

882 ：デフォルトの名無しさん：2007/11/26(月) 17:48:38

>>881
想像したらわろた

883 ：デフォルトの名無しさん：2007/11/26(月) 18:07:02

>>879
何で戦うんだよwwwコーディングかwww

884 ：デフォルトの名無しさん：2007/11/26(月) 19:52:13

JavaOne Tokyoのときみたいに、プロレス

885 ：デフォルトの名無しさん：2007/11/26(月) 22:05:45

そうね、ここはコーディングでといいたいところを
ぐっとこらえて、総合ルールでやってもらった方が
盛り上がるね！

886 ：デフォルトの名無しさん：2007/11/26(月) 23:12:33

じゃあ多重継承もfriendも属性も継続もありでいいんだな。

887 ：デフォルトの名無しさん：2007/11/26(月) 23:14:37

属性って？ annotation じゃダメなん？

888 ：デフォルトの名無しさん：2007/11/27(火) 10:35:10

>>880
Goslingが和太鼓たたきながら、
「本物のプログラマでてこいや！」

889 ：デフォルトの名無しさん：2007/11/27(火) 11:18:22

本物のプログラマはPascalを使わない―――Javaも使わない。きっと。

890 ：デフォルトの名無しさん：2007/11/27(火) 18:39:40

本物のプログラマだなんてガキみたいなこと言ってるうちは、
その本物のプログラマなるものにはなれんだろうな

891 ：デフォルトの名無しさん：2007/11/27(火) 18:57:17

何を使うんだろう。やっぱりLisp？

892 ：デフォルトの名無しさん：2007/11/27(火) 19:37:41

>>890
本物のプログラマネタくらいは知っておこうぜ、本物のプログラマならｗ
ググればすぐに出てくるよ

893 ：デフォルトの名無しさん：2007/11/27(火) 19:37:47

ホンモノのプログラマになる極意は、ホンモノの真似をしないことである

894 ：デフォルトの名無しさん：2007/11/28(水) 17:06:57

ふるいネタだな。キッシュを食わないとかいうヤツだっけ。

895 ：デフォルトの名無しさん：2007/11/28(水) 22:21:39

ホンモノのプログラマはデスマーチで2chに書く暇などありません。

偽者の人生が楽しい

896 ：デフォルトの名無しさん：2007/11/28(水) 23:07:44

業務が設計中心になってからはデスマはないなぁ。
設計工程に現役プログラマが携わらないことの危険性が
頭でもなく心でもなく体で理解したｗ

897 ：デフォルトの名無しさん：2007/11/29(木) 01:38:43

よほどヘボいSEとやってたんだな。

898 ：デフォルトの名無しさん：2007/11/29(木) 13:16:30

プログラマーは設計書が全然上がってこねーぞと文句を言っているはず
デスマの原因作ってるのはお前だｗ

899 ：デフォルトの名無しさん：2007/11/29(木) 21:09:42

↑こいつ文盲？

900 ：デフォルトの名無しさん：2007/11/29(木) 21:13:46

うん

901 ：デフォルトの名無しさん：2007/11/29(木) 22:11:53

宣言側の拡張メソッドだってさ。
http://digital-sushi.org/entry/declaration-site-extension-methods/

ユーザ側で拡張すると、メソッド名の衝突とか面倒くさいって話らしいけど。

902 ：デフォルトの名無しさん：2007/11/29(木) 22:25:27

宣言側でやっても
interface A { void method() import static SomeClass.method; }
interface B { void method() import static AnotherClass.method; }
class C implements A, B { }

があって、

C c = new C();
c.method();

したとき、どっちのメソッド呼ぶかって曖昧さが残るわな。

903 ：デフォルトの名無しさん：2007/11/30(金) 01:37:50

曖昧な場合はコンパイルエラーになるだけ

904 ：デフォルトの名無しさん：2007/11/30(金) 02:11:30

>>901
馬鹿馬鹿しい…

905 ：デフォルトの名無しさん：2007/11/30(金) 02:20:12

>>903
いや、use-site でも declaration-site でも曖昧なケースが出てくるのは同じじゃねーかって話。

906 ：デフォルトの名無しさん：2007/11/30(金) 22:05:42

LINQのような糖構文がほしい・・・

やっぱいらない

907 ：デフォルトの名無しさん：2007/11/30(金) 23:13:41

ハイバーネートだかなんだかのO/R マッピング使ったらええんとちゃう？
俺もLINQはいらんけど、varはほしいな。

908 ：デフォルトの名無しさん：2007/12/07(金) 14:03:49

JDK7 build24
ttp://download.java.net/jdk7/binaries/
ttp://download.java.net/jdk7/changes/jdk7-b24.html

あれ？変更点からっぽ？

909 ：デフォルトの名無しさん：2007/12/07(金) 16:32:16

>>906
今更だが、糖衣構文を糖構文とは略しないでしょ。

910 ：デフォルトの名無しさん：2007/12/07(金) 17:05:48

syntax sugarを糖構文と訳すのはアリだと思うが。

911 ：デフォルトの名無しさん：2007/12/07(金) 17:08:07

>>910
マジすか・・・。略語じゃなくて訳の違いだったわけか。

912 ：デフォルトの名無しさん：2007/12/07(金) 18:35:49

「糖衣構文」と「構文糖」は聞いたことあるけど「糖構文」はあまりないな。

913 ：デフォルトの名無しさん：2007/12/07(金) 18:35:52

>>910
うーん、それはやめた方がいいと思う。
糖衣構文がうざければ、シンタックス・シュガーでいいし。

914 ：デフォルトの名無しさん：2007/12/07(金) 21:23:36

>>908
JDK6u3と比べて、アプリケーションのメモリ消費量が減っているような気がする。

915 ：デフォルトの名無しさん：2007/12/11(火) 01:19:49

Java SE 6 Update N Early Access build 08キタ。新しいJava Plug-Inが入った模様。

JDK 6u10 build b08
https://jdk6.dev.java.net/6uNea.html
http://download.java.net/jdk6/6u10/promoted/b08/changes/jdk6uN-b08.html

916 ：デフォルトの名無しさん：2007/12/11(火) 13:13:20

>>908
b23 と b24 は TeamWare から Mercurial にリポジトリを移動しただけで、全く同じものらしい。
http://weblogs.java.net/blog/kellyohair/archive/2007/12/openjdk_mercuri_7.html

フォーラムで出てた。
http://forums.java.net/jive/thread.jspa?threadID=34125&tstart=0

917 ：デフォルトの名無しさん：2007/12/11(火) 13:17:01

>>905
あれって use-site でというか、static import で use-site extension methods やると
既存の static import 使ってるコードで問題出るかもって話じゃないの？

918 ：デフォルトの名無しさん：2007/12/11(火) 13:56:19

>>916
ナルホド。開発者の使ってる環境が知りたいな。GUI無しかな？
Teamwareとコマンドラインの体系は似てるし、CUIベースでかな？
それとも開発者は、Netbeans使ってるから最近出てきたMercurialのプラグイン使ってる？

919 ：デフォルトの名無しさん：2007/12/21(金) 12:17:34

まだ草案レベルにもなってない例外関連のアイデアらしい
http://www.javac.info/Multicatch.html
http://www.javac.info/Rethrown.html

multicatchは欲しい。
multicatchがあれば、rethrownはいらないような気もする。

920 ：デフォルトの名無しさん：2007/12/21(金) 12:32:25

"Exception1 | Exception2" って型ができるのかとおもうと、おらわくわくして（ｒｙ
型とか安全なのかな。とりあえず実現できなくはないと思うけど。

921 ：デフォルトの名無しさん：2007/12/21(金) 12:47:57

基本的には「複数の catch節をくっつける」ってアイデアで
型安全どーするの？とかの問題は先送りされてるんじゃね？

Exception1 | Exception2 って型も共通の親クラスのメソッドしか
呼べないんじゃないかと思ってる。下手にcatch節以外でも
Exception1 | Exception2って型が使いたいとか騒ぐと、
仕様考える連中が面倒になってポシャるんじゃないかなとか思ったり思わなかったり。

っつーか、Rethrown はその辺が面倒になったから出てきたアイデアなんじゃ？

922 ：デフォルトの名無しさん：2007/12/21(金) 16:49:50

catch(Exception1 | Exception2 ex) { ex.Foo(); }

から

catch(Exception1 ex) { ex.Foo(); }
catch(Exception2 ex) { ex.Foo(); }

は機械的に作れるから、まあ何とかなるんじゃない？

923 ：デフォルトの名無しさん：2007/12/21(金) 17:24:21

複数の例外型について handler_pc の位置を共通にするようにするんかと思ってた。

VM仕様で handler_pc はユニークにしろ、とかって制約ついてたっけ？

924 ：デフォルトの名無しさん：2007/12/23(日) 21:24:10

ConcurrentHashMap<CustomKey<Exception, Handler>, Executor<Runnable>> とかすればいいと思うよ。

925 ：デフォルトの名無しさん：2007/12/29(土) 10:41:26

http://www.infoq.com/jp/news/2007/12/closures-preserving-feel-of-java
クロージャ入れるのも一苦労じゃ

926 ：デフォルトの名無しさん：2007/12/29(土) 11:01:42

おれクロージャいらねぇ派だがどうせ新機能入れるなら個人的には多値返却かAda風の型定義がほしいかな。

927 ：デフォルトの名無しさん：2007/12/29(土) 12:01:37

皆でScalaへGO!

928 ：デフォルトの名無しさん：2007/12/29(土) 12:28:15

そーいや、ム板にscalaスレあったっけ？

929 ：デフォルトの名無しさん：2007/12/30(日) 00:05:55

C#3.0さわってみたが進化してるなあ。
lambda関数が int a => return a + 10 みたいな感じでインラインに書けたりと、
スクリプト言語ラブな人は嬉しい機能がどっさり。
思わず浮気しそうになる・・・。

930 ：デフォルトの名無しさん：2007/12/30(日) 00:22:31

>>929
> lambda関数が int a => return a + 10 みたいな感じでインラインに書けたりと、
これreturn要らないんじゃ？

BGGAのクロージャの構文、セミコロンがついたりつかなかったりで
局所リターン文だったり単なる式文だったりっつーのはバグの原因になりそうな。
ラムダ式っぽく使うならreturn書きたくないってのもわかるんだけど……
その点、C#の構文はよくできてると思う。

931 ：デフォルトの名無しさん：2007/12/30(日) 00:55:17

その程度ならecma262で十分。

932 ：デフォルトの名無しさん：2007/12/30(日) 01:05:59

>>930
それだけじゃなくて、C#3.0のラムダ式で int a みたいにパラメタ型を明示する場合はパラメータリストに括弧が必要なはず。

933 ：デフォルトの名無しさん：2007/12/30(日) 03:15:35

>>926
それだとクラスを返しても全く同じだけど、どう違いをみせたいわけ？

934 ：デフォルトの名無しさん：2007/12/30(日) 10:22:01

>>933
戻り値のためにクラスをわざわざ定義するのがめんどいんじゃね？
シンタックスシュガーとしてやってくれると、ちょっと便利かもね、と。

935 ：デフォルトの名無しさん：2007/12/30(日) 10:52:00

>>928
ちょっと前に探したときは見当たらなかった。

936 ：デフォルトの名無しさん：2007/12/30(日) 11:09:29

JVM系で残っているスレはこれだけだと思う。

Jython、Groovy、JRuby - どれが一番効率的？
http://pc11.2ch.net/test/read.cgi/tech/1100563765/
Java系スクリプト言語Groovy
http://pc11.2ch.net/test/read.cgi/tech/1080052050/

落ちないようにJVM系は統一して欲しいなあ。
Scalaは、Javaとの連携除いても、結構いい型システム持っているけど、
単独ではすぐに落ちちゃうと思う。

937 ：デフォルトの名無しさん：2007/12/31(月) 16:42:52

>>934
同じくタプルとかも賛成なんだけど、どうもそういうのはJavaぽくないみたい。
面倒だしとかじゃ「違う言語で」とかだから、だから「どう違いをみせたいわけ？」って聞いてる。

少なくとも君の要求ていどならわざわざ文法とか複雑にしなくとも、
Object[] func()
でこと足りるしｗ

938 ：デフォルトの名無しさん：2007/12/31(月) 16:58:01

多値用のGenericsを標準で用意してくれると嬉しいんだけどね。
こっちで用意してもいいけど、それ専用のjarってのもちょっとね。

939 ：デフォルトの名無しさん：2007/12/31(月) 18:28:14

前も出たなこの話題w
俺にいわせりゃ多値引数はあるのに多値返却がないのはおかしいんだけどな
クロージャとかの方が違う言語でやってほしいよ。javaがシンプルさとかけ離れていく

940 ：デフォルトの名無しさん：2007/12/31(月) 18:44:28

クロージャって匿名クラスで作るんだろ？
クロージャの生成側のローカル変数は、その時点で固定になるのかな？

941 ：デフォルトの名無しさん：2007/12/31(月) 19:08:51

>>940
そのやりかたが2つくらい出てきてどっちにするかまだ決まってなかったんじゃなかったっけ？

942 ：デフォルトの名無しさん：2007/12/31(月) 19:23:38

>>769 あたりか。

943 ：デフォルトの名無しさん：2007/12/31(月) 19:32:57

あら、割と近めにあったのね。すまんこつ。

944 ：デフォルトの名無しさん：2007/12/31(月) 19:35:51

可変長引数を多値引数って言うのは初めてみたかも。

945 ：デフォルトの名無しさん：2007/12/31(月) 20:18:52

可変長引数のこと言ってたのか。

946 ：デフォルトの名無しさん：2007/12/31(月) 20:21:18

たぶん。

いや、はじめてみた言葉だから間違ってるかも知らんけど。

947 ：デフォルトの名無しさん：2007/12/31(月) 20:32:39

すまん今作った＞多値引数
とっさに出てこなかったんだよ

948 ：デフォルトの名無しさん：2007/12/31(月) 20:39:13

オーバーロードのことじゃなくて？

949 ：デフォルトの名無しさん：2007/12/31(月) 20:44:29

単純に引数を複数渡せるってだけの話だろ

950 ：デフォルトの名無しさん：2008/01/01(火) 03:36:41

>>949が正解だろ。
単純に引数(インプット)には複数の値を渡せるのに、
返値(アウトプット)が一つしか返せないのはおかしい、という話。

そもそも、大元の関数型言語が(厳密には違うが)一入力一出力だったのを、
手続き型言語で使いやすいよう多入力にしたのが原因。
OOPの思想が確立したときに多出力にすればよかったのだが、折しもCベースのC++が主流だったのでそのまま。
またCPUの最適化の関係もあり、ずるずるとJava, C#・・・と今に至る。

もしJavaで多出力をサポートするなら、
rubyやpythonの返値の扱い（タプル関連)で、シンタックスシュガーが複雑になりすぎてる感があるので、(特にruby)
Javaが簡潔かつわかりやすい書式（もしくはタプルに代わる概念)を策定して欲しい、と思う。

951 ：デフォルトの名無しさん：2008/01/01(火) 10:04:29

単純に引数1個に制限すれば、対称になって>>950の気は済むってこと？

952 ：デフォルトの名無しさん：2008/01/01(火) 13:43:46

もはや return は継続の呼び出しで良くね？

953 ：デフォルトの名無しさん：2008/01/02(水) 13:56:26

＞Javaが簡潔かつわかりやすい書式（もしくはタプルに代わる概念)を策定して欲しい、と思う。

結局それかよ。それを策定するのが難しいからないんだろ！
おまえが考えて提案したらどうだ？当然英語はできるよな？
面倒って言うのが理由なら、あまり期待しないほうがいいじゃないか。
それと>>950はツッコミどころが多すぎだけど、
JavaはC++辺りと違って理念が実稼動重視（現実的)だから。

>>951もいいと思うよ。でも

Object[] func(Object[]);

で十分。JDK1.0 OK
有用であるが、使うかどうかは任意。

954 ：デフォルトの名無しさん：2008/01/02(水) 14:05:23

>>953書いて思ったけど、
というか普通にポインタ(C, C++)理解してるかってことに行き着くと思うよ。
本質的には、ポインタとかデータ構造とかそういうところ。

955 ：デフォルトの名無しさん：2008/01/02(水) 16:52:28

ポインタ関係ないな。
参照でいい。

956 ：デフォルトの名無しさん：2008/01/02(水) 17:21:18

It is assumed that many value return was realized by JAVA and on earth wants to do what?

957 ：デフォルトの名無しさん：2008/01/02(水) 19:02:07

新年早々とんだ釣りだw

958 ：デフォルトの名無しさん：2008/01/02(水) 19:15:55

そうするに偉そうなこといってる>>953はようやくポインタを理解したガキだってこと？
Object[]で戻していいが型の安全を言語側で保証できたらいいねって話なんだが

959 ：デフォルトの名無しさん：2008/01/02(水) 19:33:42

>>958
痛いおまえはｗｗ晒しあげｗｗ

960 ：デフォルトの名無しさん：2008/01/02(水) 19:42:24

また宗教ですか？

961 ：デフォルトの名無しさん：2008/01/02(水) 19:49:45

>>958
当然英語はできるよな？

962 ：958：2008/01/02(水) 19:59:22

おいおいなんだこれ('A`)
>JavaはC++辺りと違って理念が実稼動重視（現実的)だから。
>というか普通にポインタ(C, C++)理解してるかってことに行き着くと思うよ。
こういうのはスルーして俺に総ツッコミかよw

963 ：デフォルトの名無しさん：2008/01/02(水) 20:00:23

ストールマンのお友達ですか？

964 ：デフォルトの名無しさん：2008/01/02(水) 20:03:50

>>958
>>962
英語は当然できるんですか？

965 ：デフォルトの名無しさん：2008/01/02(水) 22:57:58

953 名前：デフォルトの名無しさん[sage] 投稿日：2008/01/02(水) 13:56:26
＞Javaが簡潔かつわかりやすい書式（もしくはタプルに代わる概念)を策定して欲しい、と思う。

結局それかよ。それを策定するのが難しいからないんだろ！
おまえが考えて提案したらどうだ？当然英語はできるよな？

961 名前：デフォルトの名無しさん[sage] 投稿日：2008/01/02(水) 19:49:45
>>958
当然英語はできるよな？

964 名前：デフォルトの名無しさん[sage] 投稿日：2008/01/02(水) 20:03:50
>>958
>>962
英語は当然できるんですか？

>>953が何を言ってるのかはさっぱりわからんが、他人の英語の能力に並々ならぬ関心があることだけはわかった。

966 ：デフォルトの名無しさん：2008/01/02(水) 23:04:05

>>953
> それと>>950はツッコミどころが多すぎだけど、
> JavaはC++辺りと違って理念が実稼動重視（現実的)だから。

C言語のソースがそのままコンパイルできるC++を差し置いてJavaのどこが”実稼働重視(現実的)”なんだww
もしかしてC++をまったくさわったことがないんだろうか？

それと>>950のツッコミどころとやらを説明よろしくww

967 ：958：2008/01/02(水) 23:23:15

ああそういう話ね
>>613で出てるけどhttp://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4222792で多値はwill not be fixedになってるのよ
で、その理由がjavaはシンプルであるべきだーと。

当然コメントには
ジェネリクスも加わったし昔のシンプルなjavaじゃないじゃん、とか
配列のシンタクスシュガーならJVMに変更いらないだろ、とか
可変引数があるのに戻り値が複数取れないのはおかしい、とかもうすでに散々出てるわけよ。

でそれを踏まえた上での>>939(俺)の
＞クロージャとかの方が違う言語でやってほしいよ。javaがシンプルさとかけ離れていく
だったわけよ

英語が堪能な>>953はそれを踏まえた上で
>結局それかよ。それを策定するのが難しいからないんだろ！
>おまえが考えて提案したらどうだ？当然英語はできるよな？
と言ってるんだよな？（>>950は俺じゃねーけど）

968 ：デフォルトの名無しさん：2008/01/03(木) 00:35:05

他でやれよもう。

969 ：デフォルトの名無しさん：2008/01/03(木) 01:59:17

苦労じゃのう

970 ：デフォルトの名無しさん：2008/01/03(木) 06:43:34

ストールマンじゃないです。
ゴズリンと友達です。

971 ：デフォルトの名無しさん：2008/01/03(木) 06:48:51

英語で会話できるようになるのは、日本人の夢なのです！
ジーニアス、ジーニアス！

972 ：デフォルトの名無しさん：2008/01/03(木) 06:51:34

>>966を読んでみても、相当痛いやつだなということだけは分かるw
30台は間違えないねｗ

この様子ならすぐ1000行くけど？どうする？やっちゃう？

973 ：デフォルトの名無しさん：2008/01/03(木) 07:30:05

>>962
>>966
おまえに勝ち目はないなｗ
そろそろ目を覚ませよｗ