991コメント291KB

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

レス数が950を超えています。1000を超えると書き込みができなくなります。

0001デフォルトの名無しさん

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/

0002デフォルトの名無しさん

2007/05/12(土) 08:33:09

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

0003デフォルトの名無しさん

2007/05/12(土) 10:29:46

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

0004デフォルトの名無しさん

2007/05/12(土) 11:46:22

乙

0005デフォルトの名無しさん

2007/05/12(土) 15:26:03

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

0006デフォルトの名無しさん

2007/05/12(土) 16:29:11

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

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

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

0007デフォルトの名無しさん

2007/05/12(土) 17:08:43

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

0008デフォルトの名無しさん

2007/05/12(土) 17:12:23

ふーん
どんな割合なの？

0009デフォルトの名無しさん

2007/05/12(土) 17:13:11

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

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

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

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

0010デフォルトの名無しさん

2007/05/12(土) 17:14:20

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

0011デフォルトの名無しさん

2007/05/12(土) 17:14:28

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

0012デフォルトの名無しさん

2007/05/12(土) 17:16:14

>>8
ググレ！

0013デフォルトの名無しさん

2007/05/12(土) 17:16:17

具体的には？

0014デフォルトの名無しさん

2007/05/12(土) 17:18:43

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

0015デフォルトの名無しさん

2007/05/12(土) 17:21:16

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

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

0016デフォルトの名無しさん

2007/05/12(土) 17:43:27

>>8
何の割合？

0017デフォルトの名無しさん

2007/05/12(土) 17:46:01

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

0018デフォルトの名無しさん

2007/05/12(土) 17:49:06

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

0019デフォルトの名無しさん

2007/05/12(土) 17:50:48

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

0020デフォルトの名無しさん

2007/05/12(土) 17:53:03

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

0021デフォルトの名無しさん

2007/05/12(土) 17:57:16

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

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

0022デフォルトの名無しさん

2007/05/12(土) 18:00:48

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

0023デフォルトの名無しさん

2007/05/12(土) 18:02:45

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

0024デフォルトの名無しさん

2007/05/12(土) 18:03:34

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

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

0025デフォルトの名無しさん

2007/05/12(土) 18:06:19

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

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

0026デフォルトの名無しさん

2007/05/12(土) 18:08:42

>>25
もうちょいkwsk!!

0027デフォルトの名無しさん

2007/05/12(土) 18:19:31

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

0028デフォルトの名無しさん

2007/05/12(土) 18:23:28

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

0029デフォルトの名無しさん

2007/05/13(日) 07:55:24

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

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

0030デフォルトの名無しさん

2007/05/13(日) 14:41:32

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

0031デフォルトの名無しさん

2007/05/13(日) 15:17:02

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

0032デフォルトの名無しさん

2007/05/13(日) 15:22:26

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

0033デフォルトの名無しさん

2007/05/14(月) 23:04:31

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

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

0034デフォルトの名無しさん

2007/05/14(月) 23:28:29

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

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

0035デフォルトの名無しさん

2007/05/14(月) 23:32:27

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

0036デフォルトの名無しさん

2007/05/14(月) 23:37:38

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

0037デフォルトの名無しさん

2007/05/15(火) 08:32:32

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

0038デフォルトの名無しさん

2007/05/15(火) 09:15:19

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

0039デフォルトの名無しさん

2007/05/15(火) 10:16:28

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

0040デフォルトの名無しさん

2007/05/15(火) 10:29:52

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

0041デフォルトの名無しさん

2007/05/15(火) 13:50:07

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

0042デフォルトの名無しさん

2007/05/15(火) 18:36:52

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

0043デフォルトの名無しさん

2007/05/15(火) 21:55:26

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

0044デフォルトの名無しさん

2007/05/15(火) 22:13:46

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

0045デフォルトの名無しさん

2007/05/15(火) 22:16:20

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

0046デフォルトの名無しさん

2007/05/15(火) 22:17:40

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

0047デフォルトの名無しさん

2007/05/15(火) 22:38:15

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

0048デフォルトの名無しさん

2007/05/15(火) 23:08:45

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

0049デフォルトの名無しさん

2007/05/16(水) 01:12:27

クロージャーって何？

0050デフォルトの名無しさん

2007/05/16(水) 01:42:49

>>49
源頼朝の弟。

　　　　　　　　　　　　　　　　　　　　　　それは九郎じゃー。

0051デフォルトの名無しさん

2007/05/16(水) 02:07:35

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

0052デフォルトの名無しさん

2007/05/16(水) 02:26:54

>>45
そこでJRubyですよ

0053デフォルトの名無しさん

2007/05/16(水) 03:42:35

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

0054デフォルトの名無しさん

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;
}

これで問題無くない？

0055デフォルトの名無しさん

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キーワードが良くわからん。さらなる解説へのポインタきぼんぬ

0056デフォルトの名無しさん

2007/05/16(水) 11:09:56

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

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

0057デフォルトの名無しさん

2007/05/16(水) 14:00:16

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

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

0058デフォルトの名無しさん

2007/05/16(水) 14:05:43

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

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

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

0059デフォルトの名無しさん

2007/05/16(水) 14:20:35

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

0060デフォルトの名無しさん

2007/05/16(水) 14:23:47

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

0061デフォルトの名無しさん

2007/05/16(水) 19:31:45

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

0062デフォルトの名無しさん

2007/05/16(水) 20:44:26

# 演算子か・・・・

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

0063デフォルトの名無しさん

2007/05/16(水) 21:02:01

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

0064デフォルトの名無しさん

2007/05/16(水) 22:53:50

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

0065デフォルトの名無しさん

2007/05/17(木) 00:35:53

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

0066デフォルトの名無しさん

2007/05/17(木) 17:38:15

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

0067デフォルトの名無しさん

2007/05/18(金) 21:55:15

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

0068デフォルトの名無しさん

2007/05/18(金) 22:20:23

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

0069デフォルトの名無しさん

2007/05/19(土) 10:03:31

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

0070デフォルトの名無しさん

2007/05/20(日) 16:11:06

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

0071デフォルトの名無しさん

2007/05/20(日) 16:35:22

>>70
Nimbusじゃダメなん？

0072デフォルトの名無しさん

2007/05/20(日) 21:13:27

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

0073デフォルトの名無しさん

2007/05/22(火) 00:01:12

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

0074デフォルトの名無しさん

2007/05/22(火) 13:10:11

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

0075デフォルトの名無しさん

2007/05/27(日) 12:51:27

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

0076デフォルトの名無しさん

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'

0077デフォルトの名無しさん

2007/05/31(木) 20:56:32

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

0078デフォルトの名無しさん

2007/06/01(金) 11:10:03

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

0079デフォルトの名無しさん

2007/06/14(木) 21:56:00

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

もういないだろうけど

0080デフォルトの名無しさん

2007/06/22(金) 14:18:44

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

0081デフォルトの名無しさん

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
フォーカスを取らずにフレームをオープンできるようになったのか・・・
何か使い道あるかな？

0082デフォルトの名無しさん

2007/06/26(火) 02:18:28

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

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

0083デフォルトの名無しさん

2007/06/29(金) 01:54:26

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

008482

2007/06/29(金) 02:47:38

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

0085デフォルトの名無しさん

2007/07/07(土) 00:40:40

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

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

0086デフォルトの名無しさん

2007/07/12(木) 01:38:18

最近ネタないね

0087デフォルトの名無しさん

2007/07/12(木) 01:53:12

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

0088デフォルトの名無しさん

2007/07/12(木) 15:43:33

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

0089デフォルトの名無しさん

2007/07/12(木) 16:30:29

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

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

0090デフォルトの名無しさん

2007/07/13(金) 23:46:55

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

0091デフォルトの名無しさん

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/

0092デフォルトの名無しさん

2007/07/24(火) 10:34:30

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

0093デフォルトの名無しさん

2007/07/24(火) 14:36:08

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

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

0094デフォルトの名無しさん

2007/07/24(火) 15:06:50

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

0095デフォルトの名無しさん

2007/07/24(火) 15:38:04

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

0096デフォルトの名無しさん

2007/07/24(火) 21:40:33

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

0097デフォルトの名無しさん

2007/07/25(水) 00:56:49

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

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

0098デフォルトの名無しさん

2007/07/25(水) 04:07:24

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

0099デフォルトの名無しさん

2007/07/26(木) 01:49:13

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

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

0100デフォルトの名無しさん

2007/07/26(木) 12:25:00

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

0101デフォルトの名無しさん

2007/07/26(木) 23:59:44

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

0102デフォルトの名無しさん

2007/07/27(金) 00:24:21

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

0103デフォルトの名無しさん

2007/07/27(金) 00:43:27

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

0104デフォルトの名無しさん

2007/07/27(金) 01:44:31

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

0105デフォルトの名無しさん

2007/07/27(金) 01:48:37

>>103
勉強しとけ。

0106デフォルトの名無しさん

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){
　//いろいろロックされる処理
}
と書けたりする予定らしい。

0107デフォルトの名無しさん

2007/07/27(金) 07:50:44

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

0108デフォルトの名無しさん

2007/07/27(金) 09:43:44

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

0109デフォルトの名無しさん

2007/07/27(金) 14:52:46

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

0110デフォルトの名無しさん

2007/07/27(金) 14:55:54

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

0111デフォルトの名無しさん

2007/07/27(金) 22:54:16

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

0112デフォルトの名無しさん

2007/07/27(金) 23:03:57

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

0113デフォルトの名無しさん

2007/07/28(土) 08:27:49

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

0114デフォルトの名無しさん

2007/07/28(土) 11:10:24

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

0115デフォルトの名無しさん

2007/07/28(土) 11:58:04

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

0116デフォルトの名無しさん

2007/07/28(土) 12:03:17

Ｇｅｎｅｒｉｃｓの話？

0117デフォルトの名無しさん

2007/07/28(土) 14:00:46

どこからその話が・・・

0118デフォルトの名無しさん

2007/07/28(土) 15:07:58

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

0119デフォルトの名無しさん

2007/07/28(土) 15:18:52

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

0120デフォルトの名無しさん

2007/07/30(月) 12:02:37

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

0121デフォルトの名無しさん

2007/07/30(月) 13:43:25

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

0122デフォルトの名無しさん

2007/08/01(水) 07:29:47

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

0123デフォルトの名無しさん

2007/08/01(水) 10:38:25

標準添付はされていない

0124デフォルトの名無しさん

2007/08/01(水) 11:36:20

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

0125デフォルトの名無しさん

2007/08/01(水) 12:09:03

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

0126デフォルトの名無しさん

2007/08/01(水) 14:14:13

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

0127デフォルトの名無しさん

2007/08/01(水) 15:02:46

>>125
つ　Pnuts・・・

0128デフォルトの名無しさん

2007/08/01(水) 17:08:04

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

0129デフォルトの名無しさん

2007/08/01(水) 17:13:49

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

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

0130デフォルトの名無しさん

2007/08/01(水) 18:31:03

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

0131デフォルトの名無しさん

2007/08/01(水) 20:05:04

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

0132デフォルトの名無しさん

2007/08/01(水) 20:15:11

>>126
具体的には？

0133デフォルトの名無しさん

2007/08/01(水) 21:04:43

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

0134デフォルトの名無しさん

2007/08/01(水) 21:36:56

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

0135デフォルトの名無しさん

2007/08/01(水) 22:35:59

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

0136デフォルトの名無しさん

2007/08/01(水) 22:37:07

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

0137デフォルトの名無しさん

2007/08/01(水) 22:40:17

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

0138デフォルトの名無しさん

2007/08/01(水) 22:42:38

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

0139デフォルトの名無しさん

2007/08/01(水) 22:45:08

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

0140デフォルトの名無しさん

2007/08/01(水) 23:13:33

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

0141デフォルトの名無しさん

2007/08/02(木) 05:09:30

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

0142デフォルトの名無しさん

2007/08/02(木) 05:10:04

>>136
いらん。

0143デフォルトの名無しさん

2007/08/02(木) 12:28:23

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

0144デフォルトの名無しさん

2007/08/02(木) 14:28:20

>>141
つ　Pnuts

0145デフォルトの名無しさん

2007/08/03(金) 00:08:05

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

0146デフォルトの名無しさん

2007/08/03(金) 00:12:18

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

0147デフォルトの名無しさん

2007/08/03(金) 00:12:52

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

0148デフォルトの名無しさん

2007/08/03(金) 04:44:27

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

0149デフォルトの名無しさん

2007/08/03(金) 06:10:32

msのcliに対抗するため

0150デフォルトの名無しさん

2007/08/03(金) 06:16:58

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

0151デフォルトの名無しさん

2007/08/03(金) 08:37:18

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

0152デフォルトの名無しさん

2007/08/03(金) 12:00:15

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

0153デフォルトの名無しさん

2007/08/03(金) 12:54:23

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

0154デフォルトの名無しさん

2007/08/03(金) 13:02:33

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

0155デフォルトの名無しさん

2007/08/03(金) 13:28:43

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

0156デフォルトの名無しさん

2007/08/03(金) 13:54:15

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

0157デフォルトの名無しさん

2007/08/03(金) 13:56:16

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

0158デフォルトの名無しさん

2007/08/03(金) 14:24:28

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

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

0159デフォルトの名無しさん

2007/08/03(金) 16:26:23

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

0160デフォルトの名無しさん

2007/08/03(金) 16:41:03

いや別に

0161デフォルトの名無しさん

2007/08/03(金) 17:45:57

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

0162デフォルトの名無しさん

2007/08/03(金) 19:10:24

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

0163デフォルトの名無しさん

2007/08/03(金) 19:34:17

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

0164デフォルトの名無しさん

2007/08/03(金) 19:36:02

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

0165デフォルトの名無しさん

2007/08/03(金) 21:11:05

>>161 それはない。

0166デフォルトの名無しさん

2007/08/03(金) 21:17:46

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

0167デフォルトの名無しさん

2007/08/03(金) 22:14:07

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

0168デフォルトの名無しさん

2007/08/04(土) 00:41:24

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

0169デフォルトの名無しさん

2007/08/04(土) 02:00:02

0170デフォルトの名無しさん

2007/08/04(土) 07:19:54

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

0171デフォルトの名無しさん

2007/08/04(土) 08:47:45

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

0172デフォルトの名無しさん

2007/08/04(土) 08:51:14

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

0173デフォルトの名無しさん

2007/08/04(土) 08:52:09

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

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

0174デフォルトの名無しさん

2007/08/04(土) 08:52:42

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

0175デフォルトの名無しさん

2007/08/04(土) 08:54:47

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

0176デフォルトの名無しさん

2007/08/04(土) 08:55:56

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

0177デフォルトの名無しさん

2007/08/04(土) 08:57:25

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

0178デフォルトの名無しさん

2007/08/04(土) 08:58:34

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

0179デフォルトの名無しさん

2007/08/04(土) 08:58:58

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

0180デフォルトの名無しさん

2007/08/04(土) 09:02:12

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

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

0181デフォルトの名無しさん

2007/08/04(土) 09:02:38

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

0182デフォルトの名無しさん

2007/08/04(土) 09:03:54

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

0183デフォルトの名無しさん

2007/08/04(土) 09:04:17

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

0184デフォルトの名無しさん

2007/08/04(土) 09:04:37

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

0185デフォルトの名無しさん

2007/08/04(土) 09:05:49

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

0186デフォルトの名無しさん

2007/08/04(土) 09:06:52

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

0187デフォルトの名無しさん

2007/08/04(土) 09:08:35

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

0188デフォルトの名無しさん

2007/08/04(土) 09:09:11

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

0189デフォルトの名無しさん

2007/08/04(土) 09:09:20

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

0190デフォルトの名無しさん

2007/08/04(土) 09:10:21

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

0191デフォルトの名無しさん

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);
}
に最適化される技術な。

0192デフォルトの名無しさん

2007/08/04(土) 09:34:02

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

0193デフォルトの名無しさん

2007/08/04(土) 10:12:30

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

0194デフォルトの名無しさん

2007/08/04(土) 10:20:21

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

0195デフォルトの名無しさん

2007/08/04(土) 11:09:02

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

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

0196デフォルトの名無しさん

2007/08/04(土) 11:55:05

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

0197デフォルトの名無しさん

2007/08/04(土) 11:55:58

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

0198デフォルトの名無しさん

2007/08/04(土) 12:01:23

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

0199デフォルトの名無しさん

2007/08/04(土) 12:18:37

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

0200デフォルトの名無しさん

2007/08/04(土) 12:25:12

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

0201デフォルトの名無しさん

2007/08/04(土) 13:47:09

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

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

0202デフォルトの名無しさん

2007/08/04(土) 14:13:45

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

あー、ねくら、ねくら

0203デフォルトの名無しさん

2007/08/04(土) 14:17:20

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

0204デフォルトの名無しさん

2007/08/04(土) 14:22:58

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

0205デフォルトの名無しさん

2007/08/04(土) 14:31:59

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

0206デフォルトの名無しさん

2007/08/04(土) 14:36:57

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

0207デフォルトの名無しさん

2007/08/04(土) 14:39:43

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

0208デフォルトの名無しさん

2007/08/04(土) 14:46:21

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

0209デフォルトの名無しさん

2007/08/04(土) 17:08:16

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

0210デフォルトの名無しさん

2007/08/04(土) 21:46:11

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

0211デフォルトの名無しさん

2007/08/05(日) 00:44:29

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

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

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

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

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

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

0212デフォルトの名無しさん

2007/08/05(日) 00:44:39

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

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

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

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

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

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

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

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

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

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

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

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

0213デフォルトの名無しさん

2007/08/05(日) 01:22:48

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

0214デフォルトの名無しさん

2007/08/05(日) 01:30:19

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

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

0215デフォルトの名無しさん

2007/08/05(日) 01:32:40

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

0216デフォルトの名無しさん

2007/08/05(日) 01:33:12

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

0217デフォルトの名無しさん

2007/08/05(日) 01:35:41

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

終わってね？

0218デフォルトの名無しさん

2007/08/05(日) 01:38:48

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

0219デフォルトの名無しさん

2007/08/05(日) 01:40:32

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

0220デフォルトの名無しさん

2007/08/05(日) 09:39:23

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

0221デフォルトの名無しさん

2007/08/05(日) 10:18:29

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

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

0222デフォルトの名無しさん

2007/08/05(日) 13:22:13

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

（　ﾟдﾟ）ﾎﾟｶｰﾝ

0223デフォルトの名無しさん

2007/08/05(日) 14:45:58

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

0224デフォルトの名無しさん

2007/08/05(日) 14:47:26

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

0225デフォルトの名無しさん

2007/08/05(日) 14:54:08

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

0226デフォルトの名無しさん

2007/08/05(日) 14:59:07

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

0227デフォルトの名無しさん

2007/08/05(日) 15:02:44

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

0228デフォルトの名無しさん

2007/08/05(日) 15:03:08

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

0229デフォルトの名無しさん

2007/08/05(日) 16:24:56

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

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

0230デフォルトの名無しさん

2007/08/05(日) 16:29:39

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

0231デフォルトの名無しさん

2007/08/05(日) 16:31:19

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

0232デフォルトの名無しさん

2007/08/05(日) 16:33:24

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

0233デフォルトの名無しさん

2007/08/05(日) 17:44:13

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

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

0234デフォルトの名無しさん

2007/08/05(日) 21:45:36

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

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

0235デフォルトの名無しさん

2007/08/05(日) 22:06:34

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

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

0236デフォルトの名無しさん

2007/08/06(月) 03:18:49

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

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

0237デフォルトの名無しさん

2007/08/06(月) 08:15:35

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

0238デフォルトの名無しさん

2007/08/06(月) 09:30:04

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

0239デフォルトの名無しさん

2007/08/06(月) 11:41:02

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

kwsk

0240デフォルトの名無しさん

2007/08/06(月) 16:57:02

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

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

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

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

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

0241デフォルトの名無しさん

2007/08/06(月) 17:00:03

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

0242デフォルトの名無しさん

2007/08/06(月) 17:23:51

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

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

なんの問題もないだろ。

0243デフォルトの名無しさん

2007/08/07(火) 15:30:39

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

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

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

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

0244デフォルトの名無しさん

2007/08/08(水) 03:26:00

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

0245デフォルトの名無しさん

2007/08/08(水) 19:26:13

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

0246デフォルトの名無しさん

2007/08/09(木) 11:58:02

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

0247デフォルトの名無しさん

2007/08/09(木) 12:35:59

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

0248デフォルトの名無しさん

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と同じような扱いでしょ。
こんなん付けても無駄に長くなるだけなんじゃ……

0249デフォルトの名無しさん

2007/08/09(木) 13:10:08

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

0250デフォルトの名無しさん

2007/08/09(木) 13:32:15

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

0251デフォルトの名無しさん

2007/08/09(木) 13:47:33

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

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

0252デフォルトの名無しさん

2007/08/09(木) 13:49:34

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

0253デフォルトの名無しさん

2007/08/09(木) 14:00:37

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

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

0254デフォルトの名無しさん

2007/08/09(木) 14:30:29

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

0255デフォルトの名無しさん

2007/08/09(木) 14:36:28

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

0256デフォルトの名無しさん

2007/08/09(木) 14:45:12

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

0257デフォルトの名無しさん

2007/08/09(木) 15:03:26

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

0258デフォルトの名無しさん

2007/08/09(木) 15:22:20

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

0259デフォルトの名無しさん

2007/08/09(木) 15:38:30

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

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

0260デフォルトの名無しさん

2007/08/09(木) 15:39:23

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

0261デフォルトの名無しさん

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でも動くはずだが。

0262デフォルトの名無しさん

2007/08/09(木) 15:40:54

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

0263261

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方式採用なんだよって感じだが。

0264デフォルトの名無しさん

2007/08/09(木) 16:02:53

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

0265デフォルトの名無しさん

2007/08/09(木) 16:05:35

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

0266デフォルトの名無しさん

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

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

0267デフォルトの名無しさん

2007/08/09(木) 17:24:49

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

0268デフォルトの名無しさん

2007/08/10(金) 01:25:21

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

0269デフォルトの名無しさん

2007/08/10(金) 01:26:53

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

……考えてみるか。

0270デフォルトの名無しさん

2007/08/10(金) 01:51:45

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

0271デフォルトの名無しさん

2007/08/10(金) 02:08:05

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

0272デフォルトの名無しさん

2007/08/10(金) 02:12:52

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

0273デフォルトの名無しさん

2007/08/10(金) 03:03:50

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

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

0274デフォルトの名無しさん

2007/08/10(金) 03:17:31

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

0275デフォルトの名無しさん

2007/08/10(金) 03:46:33

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

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

0276デフォルトの名無しさん

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がどこまでやってるかは知らない (´･ω･`)

0277デフォルトの名無しさん

2007/08/10(金) 04:44:16

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

0278デフォルトの名無しさん

2007/08/10(金) 09:53:41

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

0279デフォルトの名無しさん

2007/08/10(金) 09:56:34

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

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

0280278

2007/08/10(金) 09:57:41

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

0281デフォルトの名無しさん

2007/08/10(金) 11:35:35

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

0282デフォルトの名無しさん

2007/08/10(金) 11:49:09

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

0283デフォルトの名無しさん

2007/08/10(金) 11:54:25

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

0284デフォルトの名無しさん

2007/08/10(金) 11:59:12

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

0285デフォルトの名無しさん

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 を出力する
}
}

0286デフォルトの名無しさん

2007/08/10(金) 12:42:11

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

0287デフォルトの名無しさん

2007/08/10(金) 12:45:06

それはまぁね。

0288デフォルトの名無しさん

2007/08/10(金) 17:18:14

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

0289デフォルトの名無しさん

2007/08/10(金) 17:20:42

> で、実際デフォルトで

（　ﾟдﾟ）ﾎﾟｶｰﾝ

0290デフォルトの名無しさん

2007/08/10(金) 17:45:00

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

0291デフォルトの名無しさん

2007/08/10(金) 17:58:23

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

0292デフォルトの名無しさん

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しろって書いてあるよ

0293デフォルトの名無しさん

2007/08/10(金) 18:35:28

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

0294デフォルトの名無しさん

2007/08/10(金) 18:54:29

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

0295デフォルトの名無しさん

2007/08/10(金) 19:02:35

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

0296デフォルトの名無しさん

2007/08/11(土) 03:07:02

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

0297デフォルトの名無しさん

2007/08/11(土) 16:11:19

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

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

0298デフォルトの名無しさん

2007/08/11(土) 16:22:00

夏休み的なツッコミだな

0299デフォルトの名無しさん

2007/08/11(土) 19:00:47

ボケだろ、ボケ

0300デフォルトの名無しさん

2007/08/13(月) 15:24:33

ノリツッコミか

0301デフォルトの名無しさん

2007/08/18(土) 04:47:25

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

細かいバグ修正とか。

0302デフォルトの名無しさん

2007/08/19(日) 07:15:13

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

0303デフォルトの名無しさん

2007/08/19(日) 08:19:46

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

0304デフォルトの名無しさん

2007/08/19(日) 15:38:42

確かにへぼいな

0305デフォルトの名無しさん

2007/08/19(日) 16:52:27

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

0306デフォルトの名無しさん

2007/08/19(日) 17:31:28

JSR 310ってどうよ

0307デフォルトの名無しさん

2007/08/19(日) 19:22:01

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

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

0308デフォルトの名無しさん

2007/08/19(日) 19:34:49

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

0309デフォルトの名無しさん

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 と同じ方式になってるだけでしょ。
きちんと文書化してあれば大して問題になるとも思えんし……

0310デフォルトの名無しさん

2007/08/19(日) 21:28:31

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

0311デフォルトの名無しさん

2007/08/20(月) 17:49:33

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

0312デフォルトの名無しさん

2007/08/20(月) 18:02:22

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

0313デフォルトの名無しさん

2007/08/20(月) 18:56:22

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

0314デフォルトの名無しさん

2007/08/20(月) 19:37:12

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

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

0315デフォルトの名無しさん

2007/08/20(月) 19:43:10

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

0316デフォルトの名無しさん

2007/08/20(月) 21:05:04

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

0317デフォルトの名無しさん

2007/08/20(月) 21:21:43

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

0318デフォルトの名無しさん

2007/08/20(月) 23:19:30

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

0319デフォルトの名無しさん

2007/08/20(月) 23:25:25

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

0320デフォルトの名無しさん

2007/08/20(月) 23:41:02

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

0321デフォルトの名無しさん

2007/08/21(火) 01:23:50

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

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

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

0322デフォルトの名無しさん

2007/08/21(火) 01:33:32

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

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

0323デフォルトの名無しさん

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は新規プロジェクトで採用される可能性はほとんどなくなってきてるしな。

0324デフォルトの名無しさん

2007/08/21(火) 09:53:51

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

0325デフォルトの名無しさん

2007/08/21(火) 10:20:43

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

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

0326デフォルトの名無しさん

2007/08/21(火) 10:23:58

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

0327デフォルトの名無しさん

2007/08/21(火) 10:24:54

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

0328デフォルトの名無しさん

2007/08/21(火) 13:37:56

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

0329デフォルトの名無しさん

2007/08/21(火) 16:31:57

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

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

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

0330デフォルトの名無しさん

2007/08/21(火) 17:51:54

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

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

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

0331デフォルトの名無しさん

2007/08/21(火) 18:15:12

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

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

0332デフォルトの名無しさん

2007/08/21(火) 18:29:39

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

0333デフォルトの名無しさん

2007/08/21(火) 19:05:53

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

0334デフォルトの名無しさん

2007/08/21(火) 19:08:21

>>331
無理じゃね？

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

0335デフォルトの名無しさん

2007/08/21(火) 19:10:30

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

0336デフォルトの名無しさん

2007/08/21(火) 19:23:34

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

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

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

0337デフォルトの名無しさん

2007/08/21(火) 20:22:16

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

0338デフォルトの名無しさん

2007/08/21(火) 22:16:24

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

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

0339デフォルトの名無しさん

2007/08/21(火) 23:24:14

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

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

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

0340デフォルトの名無しさん

2007/08/21(火) 23:27:03

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

0341デフォルトの名無しさん

2007/08/21(火) 23:36:53

つ JMF

0342デフォルトの名無しさん

2007/08/21(火) 23:38:58

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

0343デフォルトの名無しさん

2007/08/21(火) 23:51:58

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

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

0344デフォルトの名無しさん

2007/08/22(水) 09:04:57

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

0345デフォルトの名無しさん

2007/08/22(水) 09:09:49

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

0346デフォルトの名無しさん

2007/08/22(水) 09:24:14

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

0347デフォルトの名無しさん

2007/08/22(水) 11:31:10

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

0348デフォルトの名無しさん

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

0349デフォルトの名無しさん

2007/08/22(水) 14:24:44

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

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

0350デフォルトの名無しさん

2007/08/22(水) 14:30:23

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

0351デフォルトの名無しさん

2007/08/22(水) 20:01:17

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

0352デフォルトの名無しさん

2007/08/22(水) 21:21:02

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

0353デフォルトの名無しさん

2007/08/22(水) 21:49:03

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

0354デフォルトの名無しさん

2007/08/23(木) 01:19:58

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

0355デフォルトの名無しさん

2007/08/23(木) 03:08:43

>>354
そうなん？

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

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

0356デフォルトの名無しさん

2007/08/23(木) 04:03:13

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

0357デフォルトの名無しさん

2007/08/23(木) 04:06:51

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

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

0358デフォルトの名無しさん

2007/08/23(木) 08:11:21

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

0359デフォルトの名無しさん

2007/08/23(木) 08:43:24

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

0360デフォルトの名無しさん

2007/08/23(木) 08:46:22

どっちがいいとかそういうもんじゃないだろ。
310はベースとなる時刻クラスを提供するんだから。

0361デフォルトの名無しさん

2007/08/23(木) 08:49:25

今のままだったら Date ＆ Calendar の方が下位層で
JSR-310 はそれに乗っかるだけの上位層になりそうだが

0362デフォルトの名無しさん

2007/08/23(木) 08:50:20

（　ﾟдﾟ）ﾎﾟｶｰﾝ

0363デフォルトの名無しさん

2007/08/23(木) 08:52:26

おまけに使用用途が酷く限定されている、と。

0364デフォルトの名無しさん

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
は解決できそうだ。

0365デフォルトの名無しさん

2007/08/23(木) 09:25:39

>>360
310が提供するベースとなる時刻クラスってどれよ？

0366デフォルトの名無しさん

2007/08/23(木) 11:36:39

文字列からのファクトリメソッドは、
別クラスにした方がいいんじゃないの？
L10N考えると劇重プロジェクトだし。

GNU dateコマンドみたいな時間指示を考えると、やること一杯ある。

0367デフォルトの名無しさん

2007/08/23(木) 11:46:17

これはひどい

ベースとなる時刻クラス・・・ Instant かねぇ
でも CalendarDay や TimeOfDay との相互変換はできそうになく
既存の Date や Calendar との繋がりもない
どうやって使うんだこれ

0368デフォルトの名無しさん

2007/08/24(金) 00:25:02

310はまだ、かなりドラフトな感じだが、
PeriodとMomentとその実装クラスを細かく分けるのは、
安全でかつ読みやすくなるのでよいと思う

例えばMomentにMomentは追加できないがPeriodは追加できるとか

0369デフォルトの名無しさん

2007/08/24(金) 01:23:17

Instant と fully defined な SingleMoment を区別する理由と、
Period と Interval を区別する必要とか、
Duration とか良く分からん。
Duration と Inteval はまだ出来てないみたいだけど。

>>368 も同意っちゃ同意なんだけど、
それって Moment と Period が別になってる理由にはなっても、
Moment や Period のサブクラスが年、月、日、時、分、秒と
細かく分かれてる理由にはならんよね。

0370デフォルトの名無しさん

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との互換性とか国際化も考えると大変そうだね。

0371デフォルトの名無しさん

2007/08/24(金) 02:02:32

>>369
後者については type safe のためとか？

もしくは、
Moment moment = build(dayOfMonth(1), hourOfDay(3));
とかやると、毎月 1日午前 3時をあらわすようになるとか……

0372デフォルトの名無しさん

2007/08/24(金) 02:05:26

>>370
おいおい……

一見型安全かもしれないけど、
それだけだと、逆に Period で 1カ月と3日とか複合的な指定できなくなるんですけど……

0373デフォルトの名無しさん

2007/08/24(金) 02:10:03

>>371
あぁなるほど。可変長引数のビルダーメソッドで纏めるとか
そーゆー場合には別々のクラスになってないとダメだな。

>>370
これはひどい

0374デフォルトの名無しさん

2007/08/24(金) 02:34:16

>>372
Periodとしての一ヶ月というのは日数として組み合わせて扱えない気がするが。

0375デフォルトの名無しさん

2007/08/24(金) 02:37:46

（　ﾟдﾟ）ﾎﾟｶｰﾝ

0376374

2007/08/24(金) 02:48:29

今のAPIを見る限り、複数のPeriodを組み合わせたPeriodというのはない気がする。
Monthsに関しては月によって日数は変わるので、months.plus(Days.days(3))みたいな計算は書けないと思うが。

しかしCalendarDayはplus(Period...)というのを持ってるので、一ヶ月と3日後とかを計算できると思う。ただMinutesとSecondsとの変換とかできそうな気がするのにできないように見えるのはよくわからない。

0377デフォルトの名無しさん

2007/08/24(金) 02:51:08

>>372
そーゆーのは、まだない Interval でやるって話なんじゃね？

しっかし、凄く分かりにくい API だな、これ。
そこそこ経験がある奴でもサンプルコードが無いと一行も書けないぞ。

0378デフォルトの名無しさん

2007/08/24(金) 02:55:09

>>373
instanceof で比較するところを enum と switch で置き換えれば
良いだけだから、別々のクラスになってる必要は全くなかったりする。

0379374

2007/08/24(金) 03:03:40

やっぱりわかりにくいのだろうか?

変換とかファクトリとかのメソッドがどこにあるかわからず、分かりにくい、というのはあるかもしれないが、
そもそも日付と時間の長さなどを区別して扱うこと自体が複雑で、結局intとかで扱っても値の種類を把握していないといけないのでは。

ある程度、単位を型でエンコードして分かりやすくすることで安全で読みやすいコードになる方がよいと思うのだが...

0380デフォルトの名無しさん

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日じゃないけどさ。

0381デフォルトの名無しさん

2007/08/24(金) 07:09:27

Dateみたいな基本的なところに今から手を入れるのがアリなら、
Numberもどうにかしてくれんかな。
やっぱり Integer inherits Double であってほしいし、BigDecimalで
持っている四則演算メソッドはNumberすべてで使いたいが。

0382デフォルトの名無しさん

2007/08/24(金) 07:17:34

>>380
JAVAの株があがったとか下がったとかが問題になってくるわけか。
そしたら、JAVAと大文字で書くやつはJavaのことを知らないという伝説が強くなるわけだ。

0383デフォルトの名無しさん

2007/08/24(金) 07:43:01

>>381
Numerics関係は難しいんだよな、後からいじるの。
非互換の影響が大きすぎて。

仕様お目付け役だった、Guy Steeleさん、この辺が弱い。

0384デフォルトの名無しさん

2007/08/24(金) 16:04:46

元がSUNWならJAVAWにすればいいのにコンソール出ないし・・・。

0385デフォルトの名無しさん

2007/08/24(金) 16:57:17

>>381
メソッド追加はありでも継承関係は変えられないだろうな

0386デフォルトの名無しさん

2007/08/29(水) 21:26:22

そろそろ deprecated のクラスやメソッドを一掃してほしい

0387デフォルトの名無しさん

2007/08/29(水) 22:30:24

Cloneable を Clonable に直してほしい

0388デフォルトの名無しさん

2007/08/30(木) 02:13:33

creat....

0389デフォルトの名無しさん

2007/08/30(木) 23:47:25

catch必須例外を堂々と無視できるプラグマを追加してほしい。

0390デフォルトの名無しさん

2007/08/31(金) 03:25:48

アホか例外処理の意味ないだろ。
握り潰すことすら面倒くさいか？ｗ

0391デフォルトの名無しさん

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はないんだろうか？

0392デフォルトの名無しさん

2007/08/31(金) 21:15:56

>>390
めんどくさい。
どうでもいいコンソールプログラム書くときは
全部例外がトップレベルに流れて死んでくれていい。

あと、どうせならインタフェースの実装も堂々と無視できるプラグマも欲しい。
適当にnullとか0とかfalseとか、あるいはNotImplementedException投げるとか。

IDEにやらせればいいんだけどさ。

0393デフォルトの名無しさん

2007/08/31(金) 21:52:53

>>392
お前はCの方が合ってるんじゃないか？
つーかその程度の捨てアプリならスクリプトで実装すれば良いだけじゃん。

0394デフォルトの名無しさん

2007/08/31(金) 22:32:46

mainメソッドにthrows ExceptionってすればOK

0395デフォルトの名無しさん

2007/09/01(土) 02:07:00

Javaの例外処理の面倒くささはMatzがどっかで言及してたね

0396デフォルトの名無しさん

2007/09/01(土) 02:21:10

silentClose(Closeable) みたいなメソッド作るとか
使い捨てアプリ作る時は throws Exception つけるとかすれば
そこそこ改善すると思うんだけどね

0397デフォルトの名無しさん

2007/09/01(土) 02:29:38

>>395
むしろその例外処理の面倒さがないからこそ
他の言語があぶなっかしくて使えない。
コード品質重視だと特に。

0398デフォルトの名無しさん

2007/09/01(土) 06:37:06

むしろ投げる例外をdoc,code上で明文化されてないと何拾って良いか分からないだろ。拾えないと例外に対処できない。

throw,throwsでthrowable以外が飛んでくるのもおかしいし。

0399デフォルトの名無しさん

2007/09/01(土) 16:45:03

ExceptionはThrowableである。以上。

0400デフォルトの名無しさん

2007/09/02(日) 09:52:45

例外処理の仕組みが問題というよりも
IOExceptionとかSQLExceptionのようなレベルの例外を
チェック例外にしてるのが問題だと思う
SpringやS2やHibernateなら、これらの例外をランタイム例外にラップしてくれるし
JavaEE5ではランタイム例外を多用してるけど
肝心の、JavaSEのコアなAPIがチェック例外だらけだからな

>>397
現実には、Javaのチェック例外記述のめんどくささに嫌気がさした開発者が
catch (Exception e) {
e.printStackTrace();
}
とか書いて、返って品質悪化するパターンの方が高い気がするorz

0401デフォルトの名無しさん

2007/09/02(日) 11:41:41

あと InterruptedException も握りつぶされて困りやすいチェック例外だ

あー
InterruptedIOException とか、きっと知らんうちに IOException もろとも握りつぶしてる気がしてきた

try {
......
} catch (InterruptedIOException e) {
Thread.currentThread.interrupt();
} catch (IOException e) {
......
}

なんて、書いた覚えがないよ

0402デフォルトの名無しさん

2007/09/02(日) 11:50:49

例外のためのEffective Javaみたいなのがあれば読んでみたい。
こういうのはお習字の世界だから仕様としてどうこう変えるもんでもないし。

0403デフォルトの名無しさん

2007/09/02(日) 13:29:09

>>400
IOExcepotionとかは>>396みたいなメソッドがあれば解決する問題

後半に関して言えば
そーゆー奴は面倒くさいので例外処理しないし
他人のために必要な例外関連のドキュメントも書かない
ので検査例外をあってもなくてもそれほど品質は変化しないと思うが

0404デフォルトの名無しさん

2007/09/02(日) 13:39:45

何が言いたいのやら・・・必死なことだけは解るが

0405デフォルトの名無しさん

2007/09/02(日) 13:48:59

IOExceptionやSQLExceptionがチェック例外なのは当然だろ？
外部リソースに依存してんだから、チェックし無い方がどうかしてる。
DAOならそれらをcauseにして、DAOExceptionみたいに新たなチェック例外にくるむがよろし。

0406デフォルトの名無しさん

2007/09/02(日) 13:55:57

closeが例外なげるバカなAPI

0407デフォルトの名無しさん

2007/09/02(日) 14:04:03

close は flush を伴うからエラーが発生する可能性はある

0408デフォルトの名無しさん

2007/09/02(日) 14:07:19

closeが例外なげるのがバカってどんだけゆとり脳なんだ

0409デフォルトの名無しさん

2007/09/02(日) 14:14:18

思うに、チェック例外をキャッチしないと
警告出すだけの仕様だったらどうなっていただろうか？

0410デフォルトの名無しさん

2007/09/02(日) 14:26:33

throws SQLException って書いてないのに throw new SQLException() するような
混ぜるな危険メソッドが書き放題で検査例外の意味がなくなる。
それでいてソースに SuppressWarnings("ignorecheckedexception") とか
コンパイル時に -ignorecheckedexception とか必須だと手間がかかるだけ。

中途半端で役に立たないソリューションの見本だな。

0411デフォルトの名無しさん

2007/09/02(日) 14:30:17

んなもんソースレビューで片付けろよ

0412デフォルトの名無しさん

2007/09/02(日) 14:44:28

closeが検査例外を投げるバカなAPI

0413デフォルトの名無しさん

2007/09/02(日) 14:49:51

>>411
第三者の作ったライブラリやフレームワーク使う時は
それらも全部ソースレビューすんの？

0414デフォルトの名無しさん

2007/09/02(日) 14:51:10

必ずソースが見れるとは限らんし

0415デフォルトの名無しさん

2007/09/02(日) 15:05:42

>>405
IOExceptionとかって多くの場合リカバリできるの?
リソースの解放はfinallyでやるからチェック付き例外とは関係ないと思うし

なるべく例外がチェックできるべきだという意見は多い様に見えるが、一般的にそれらの例外がほとんどリカバリできる処理を書けないならば >>400の言うようにAPIの設計の問題では?

0416デフォルトの名無しさん

2007/09/02(日) 15:10:27

ソケット使って読み書きしてる時にIOExceptionが発生したらリトライするとかあるよね

0417デフォルトの名無しさん

2007/09/02(日) 15:53:29

>>416
そういう特定の事情のために、すべてのIO処理で面倒なコードを書かないといけないのはアホ

0418デフォルトの名無しさん

2007/09/02(日) 15:56:09

というか、例外が出ないコードで例外の補足が必要になるのが、設計ミス
System.in.read()
とか

0419デフォルトの名無しさん

2007/09/02(日) 15:57:17

面倒っても、throws IOException を宣言するくらいのもの。
その場で対処しない例外は上へ送る。

0420デフォルトの名無しさん

2007/09/02(日) 16:02:53

System.in.read() ってプラットフォーム側の標準入出力の実装方法によっては
例外が出る可能性があるんだが

0421デフォルトの名無しさん

2007/09/02(日) 16:10:33

俺としてはNumberFormatExceptionが実行時例外なのが許せないくらいなんだが。
外側のことは一切信用しないという性悪説プログラミングが心情だとね。

0422デフォルトの名無しさん

2007/09/02(日) 16:18:48

俺はUserTransactionのメソッドを使ってみたとき、
Javaのチェック例外は、API側が使い方を根本的に間違ってると痛感したよｗ

0423デフォルトの名無しさん

2007/09/02(日) 16:24:01

>>412みたいな事を言う奴から間違ってると言われても

0424デフォルトの名無しさん

2007/09/02(日) 16:31:07

>>419
それで上へ送った例外は結局どうなるわけ?
throws IOExceptionをまき散らして、
RuntimeExceptionになるか握りつぶされるぐらいじゃないの?

>>421
一切信用しないというのはいいが、それはどうやって処理される?
他の値で代用するのは多くの場合問題がある気がするし、
再度入力を促すことになると思うが、
可能な場合と不可能な場合(処理を中断するしかない場合)があると思う

...NumberFormatExceptionに関しては微妙な気がしてきた
RuntimeExceptionでよい場合も多いと思うが...

0425デフォルトの名無しさん

2007/09/02(日) 16:54:22

最近じゃ例外もAOPで処理するし、リソースはfinallyで閉じるからあまり関係ないしな
matz氏がブログで、例外をぎりぎりまで捕捉しないのがRuby流って書いてたけど
結局はそれがいちばん効率的で、開発者に都度catch処理を強制するよりも品質が上がるんだよね。
例外処理がなくても、異常終了で落ちるからテスト時にすぐわかるが、
catchで不用意に握りつぶされた例外はやっかいだし

0426デフォルトの名無しさん

2007/09/02(日) 17:06:07

何層か下のフレームワーク/ライブラリが投げてくる実装依存の例外もやっかいだけどな。

面倒くさいから検査例外は無い方が良いとか考えてる奴は、
例外関連のドキュメントなんて書かないから品質ズタボロのコードを量産する。

0427424

2007/09/02(日) 17:27:46

>>425
アプリケーション(基本的なライブラリでない)でのチェック付き例外は有用と見られているはずだ
アプリケーションレベルではリカバするべき例外を決めることができて、チェック付き例外で強制できる

アスペクトを使うことでIO例外をアプリの例外へ変換とかはうまく書けるが、
各メソッドごとの例外処理を常にうまく分離して書けるわけではない

テスト時にすぐわかるというのは理由にならないはずだ
再現が難しい例外だってあるから
それよりも発生したときなにもできないことが多いというのが理由だと思う

0428デフォルトの名無しさん

2007/09/02(日) 17:28:11

なんか次世代関係なくなってね？
JAVAの例外について勉強するスレとかたててそっちでやれ

0429デフォルトの名無しさん

2007/09/02(日) 18:30:35

例外処理が煩わしいのであれば、
例外処理を包含したテンプレートパターンを適用して処理すればいい。
APIは面倒か面倒じゃないかではなく、安全か安全ではないかが重要。

APIは極力安全に使えるように「馬鹿向け」に作られているが、
本当の馬鹿にはその意味すらわからないらしいｗ

0430デフォルトの名無しさん

2007/09/02(日) 18:57:24

わずらわしいどうの以前にその例外をどう扱うべきかというパターン自体が俺みたいな初心者にはわからない
使われる側でチェック例外を投げてから使う側で遺言を言ったあとRuntimeExceptionでラップするとか、
キャンセルなどの特殊な状況を処理するために使うとか、なんだろうか

0431デフォルトの名無しさん

2007/09/02(日) 21:40:59

捕捉する場所によって扱い方も異なるとしか言い様がないな。
ライブラリ書いてるなら、抽象的な例外でラップして投げなおすだろうし。
フレームワークならコントローラで一括処理で、それ以外では全部投げっぱなし。

0432デフォルトの名無しさん

2007/09/02(日) 21:49:00

個人的にはチェック例外＝病気の診断、ランタイム例外＝安楽死とか思ってる
で、今直せる見込みのない病人がいるとして、いろんな病院をたらいまわしたり（チェック例外のままthrowsしまくる）、
病気ではないとして放置したり（例外を握りつぶす）、
秘密裏に抹殺したり（System.exit(0)）、
するよりはランタイム例外にして安楽死させたほうがいいような気はするんだけどな。

でもそのあたりの常識やパターンやガイドラインみたいなものがないと実際何をやっていいのか分からないし、
ttp://www-06.ibm.com/jp/developerworks/java/040618/j_j-jtp05254.htmlとか見る限り、
今のAPI仕様でそれが完璧に行われているかというとそうでもない気がする。
どう診断すればいい医者であるか、と言う問題についてはもっと語られてもいい気がする。

0433デフォルトの名無しさん

2007/09/03(月) 00:54:17

病気になったら即安楽死＝良い医者だと？

0434デフォルトの名無しさん

2007/09/03(月) 00:56:05

スレ誘導しようとしたらいつのまにか例外処理スレが落ちてた。

0435デフォルトの名無しさん

2007/09/03(月) 04:46:11

>>420
その程度ならRuntimeExceptionで十分

0436デフォルトの名無しさん

2007/09/03(月) 07:58:03

>>435
その程度なら throws IOException 書いておけば十分。の間違いじゃね？

0437デフォルトの名無しさん

2007/09/03(月) 08:17:25

>>435
もっかい ttp://www-06.ibm.com/jp/developerworks/java/040618/j_j-jtp05254.html 読んでくれば？

0438デフォルトの名無しさん

2007/09/03(月) 08:53:56

>>432
ロッド＝ジョンソンの本の説明が出てるな
自分も彼のJ2EE本読んで、チェック例外に対する見方を改めた口だ

0439デフォルトの名無しさん

2007/09/04(火) 11:17:45

例外処理がもれなくSystem.exit(0)オンリーなソースを
押し付けられた俺涙目

0440デフォルトの名無しさん

2007/09/04(火) 11:21:35

例外処理が全部 System#exit(int) ってのもアレだが、
異常終了してんのに 0戻すってのも相当アレだよな。

0441デフォルトの名無しさん

2007/09/04(火) 11:36:48

終了するというコードが正しく実行できたので正常！
と。
曲がった先の信号が青だから曲がれる、という理屈に似てます。
>>439
まあ握りつぶされるよりはいいんじゃないか？

例外処理に関しては、パッケージ単位とか、今度出来るはずのモジュール単位で
包括して処理できる仕組みがあったら便利じゃないかなぁと思う。

0442デフォルトの名無しさん

2007/09/04(火) 14:31:16

>曲がった先の信号が青だから曲がれる、という理屈
これめちゃくちゃ危ないんだが・・・特に内輪差考えないで突っ込んで来る馬鹿な大型車とか。

0443デフォルトの名無しさん

2007/09/04(火) 22:43:55

>>439
脈絡ないけど、exit()の前にfree()は要らないってのを思い出してしまった。

0444デフォルトの名無しさん

2007/09/04(火) 23:43:03

>>432
一理あると思うが、マルチスレッドの場合はランタイム例外もきちんと
捕捉しとかないと握りつぶしたのとたいして変わらないことになるんだよな。
そのへん整合性あるガイドラインならいいんだが。

あと、安楽死というからには本当はやっぱり後始末もちゃんとしておきたいところ。

0445デフォルトの名無しさん

2007/09/05(水) 14:32:56

あのfree論争ってさ、
「とりあえずfreeはしておくべき」的な教条的理想論
「どうせ終了と同時にメモリ開放するんだからいいじゃん、っていうかfreeしたって実際何もしてないのとほぼ同じだし」っていう感じの現実論
って理解でいいんだよな？そりゃ永遠に話は平行線だ罠

0446デフォルトの名無しさん

2007/09/05(水) 14:37:30

例外ってさ、単純な入力ミスで出るようなはっきりいって例外処理までしてやりたくないようなどうでもいい例外か
出てる時点でもうもうどうしようもない例外が多いような気がする

0447デフォルトの名無しさん

2007/09/05(水) 15:06:10

外部からの入力ミスなら対処しないとダメだろ。

使い捨てアプリ作ってんなら、throws Exception 付けといて良いだろうし。

0448デフォルトの名無しさん

2007/09/05(水) 15:16:29

>>445
マトモな奴は、free論争なんかする暇があったら他の事をやる。

0449デフォルトの名無しさん

2007/09/05(水) 15:25:06

>>445
>>448 の2つに直交する「どっちでもええがな」論があって、これが現実解。

0450デフォルトの名無しさん

2007/09/05(水) 15:46:51

parseIntで数字じゃなかったときの処理を例外でやんないといけないとか、ひどすぐる。

0451デフォルトの名無しさん

2007/09/05(水) 16:05:21

>>450
なら、どうしたら良いと思う？

parseInt の戻り型を long にして数字以外なら int の範囲外が返ってくるとか、
parseInt の戻り型を Integer にして数字以外なら null 返すとかしても、
例外よりマシになるとは思えないけど。

0452デフォルトの名無しさん

2007/09/05(水) 16:11:43

＞parseInt の戻り型を Integer にして数字以外なら null 返す
それやるとオートボクシングしたつもりがヌルポになったりすっからなあ

isValidInteger()みたいなチェックメソッドを作ってやるとかどうよ。二度手間だが

0453デフォルトの名無しさん

2007/09/05(水) 16:15:34

>>452
安全なコードを書くためにそのメソッド使った
if文を書くことを強制しないといけない。

ならコンパイラでチェックしてやろうというのが
検査例外な訳で。

どこまで人間を信じるかだな。

0454デフォルトの名無しさん

2007/09/05(水) 16:15:42

> isValidInteger()みたいなチェックメソッド
なんという銀の弾丸

0455デフォルトの名無しさん

2007/09/05(水) 16:18:36

int[] parseInt(String)
返値は
　{ パースした数字, エラーコード }

俺もparseIntについては何とかならないかと思ってた。
parseできないってのは、想定内の状況だからExceptionにするのはどうかな、と感じてて
例外と言うより１状況として扱いたいと思ってる。
ただ、上のようにしても何かしっくり来ない。

Exception以外に、例外状況をメソッドの返りで扱えるようになればいいな、と思う。
Exception処理が重すぎるというのが元凶なんだが、
RuntimeExceptionでないものに関しては
parseIntのように、stackTraceなんて重いものは要らなくて、
その場で処理してしまう例外状況って多いじゃないですか。

何とかならないのかなぁ。
言語構造的に、Throwable一本ってのが簡単なのは分かるんだが・・・

0456デフォルトの名無しさん

2007/09/05(水) 16:25:02

>>453
＞if文を書くことを強制しないといけない。
ここに関しては
Nullチェックに対するNullPointerException
Iterator#hasNext()に対するNoSuchElementException みたいなRuntimeException派生を投げれば済むと思うんだけど
二度手間なんだよね。このチェック。

0457デフォルトの名無しさん

2007/09/05(水) 16:29:35

>>456
hasNextはそのチェック自体が軽いからいいけど
parseIntは、parseしちゃってるからねぇ・・・二度手間ですよねぇ・・・・

0458デフォルトの名無しさん

2007/09/05(水) 16:29:50

>>455
> parseIntのように、stackTraceなんて重いものは要らなくて、
> その場で処理してしまう例外状況って多いじゃないですか。

parseInt の場合だと、
・ユーザー入力を parseIntした場合はユーザー入力が遅いのでExceptionが重くても問題ない。
・ファイル読み込んでparseIntした場合、パースできないケースは例外を使うべき状況なので問題ない。
だと思うが。

0459デフォルトの名無しさん

2007/09/05(水) 16:33:25

自己レス>>457
あ。parse結果をキャッシュできればいいのか。内部で。
って、コトは、staticメソッドじゃ駄目だな。
Stringのインスタンスメソッドになれば何とかなる、という所か・・・・

0460デフォルトの名無しさん

2007/09/05(水) 16:35:35

>>456
要するに、検査例外だと
コードがごちゃーとするのがやだから
実行時例外にして欲しいって事でしょ？

どっちにしろ、人間をどこまで信じるかだな。

0461デフォルトの名無しさん

2007/09/05(水) 16:37:04

>>460
paeseInt の話なら、NumberFormatException は実行時例外だが。

0462デフォルトの名無しさん

2007/09/05(水) 16:44:43

>>455
最近の言語であるみたいにJavaが多値を返せる言語だったら良かった
んだけどなあと思う。

(int, StatusCode) parseInt(String input)

とか。

ちょっとキモイが

interface ParseResult { }
class ParseSucceed implements ParseResult { }
class ParseFailure implements ParseResult {}

というクラスを用意して、ParseResult型の値を返すとかどうだろう。

0463デフォルトの名無しさん

2007/09/05(水) 16:48:13

>>462
後半、ただのEnumでよくね？

0464デフォルトの名無しさん

2007/09/05(水) 16:48:49

そんなややこしいことやるくらいなら Integer を返して null かどうかで判定できればそれでいいよ

0465デフォルトの名無しさん

2007/09/05(水) 16:52:55

>>464
だからそういうのやるとコードの変なところでヌルポが出そうで怖いんだって
オートボクシングするだけで出るし正体不明のバグ増やすだけ

0466デフォルトの名無しさん

2007/09/05(水) 16:56:38

じゃあ @CheckForNull 付加で

0467デフォルトの名無しさん

2007/09/05(水) 16:57:55

>>462
StatusCodeチェックしない場合はパースに失敗してても intの値が得られちゃうし、
その上現状よりキモくなってるしで、あんま良い事ないんじゃね？

0468デフォルトの名無しさん

2007/09/05(水) 17:02:33

>>462
多値を返すという話はだーいぶ昔からBugParadeでやられてて
話に参加してみたものの結局、やらないよーという結論。

まあ、どうしてもやりたきゃ、今は配列をつかえってところ。
それなら俺は、配列に違う型を含められるようにしてくれ、と思い・・・
でも、その場合型チェックはコンパイル時には難しいわけで
Objectの配列使うのと変わらないわけで・・・・
じゃあ、じゃあstructがあったらいいんじゃ・・・・っていうと、
アレ？それってクラスじゃね？と・・・・

型チェックが緩くてもともと実行時にしか型がきまらない
スクリプト型言語なら、複数返値も考えることあんまり無くていいんだろうけどねぇ

0469デフォルトの名無しさん

2007/09/05(水) 17:24:54

>>468
いやいや。型に厳しい関数型言語(MLやHaskell)などでは、
昔からタプルという形で多値が扱えたから、それと同等の
仕様にすればいいだけだと思うんだがな。

0470デフォルトの名無しさん

2007/09/05(水) 17:28:34

>>463
実装は省いたけど、ParseSucceed型からはパーズ結果の値を、
ParseFailure型からは失敗の原因を取得できるようにする意図が
あったので、ただのEnumだとよくない

0471デフォルトの名無しさん

2007/09/05(水) 17:47:44

>>469
>>455 だと Exception重いからException使わないようにしようって話でしょ。
タプルとか使って正常系の処理も重くしたら意味無いんじゃね？

0472デフォルトの名無しさん

2007/09/05(水) 17:55:24

>>470
パフォーマンス上の理由なら、そんなもんいちいちnewして返すぐらいなら、例外投げればいいと思う。
単にコードを簡潔にしたいだけなら、
static boolean parseInteger(String text, AtomicInteger out);
みたいなのをどっかに用意してやればいい。
AtomicIntegerは、他に標準でintを参照渡しできるインターフェイスが無いからなんで、
適当なintをsetできるインターフェイスならなんでもいいと思う。

コードを簡潔にするっていっても、結局正しくパースできたかのチェックは必要なんだから、
例外で十分でしょ。

0473デフォルトの名無しさん

2007/09/05(水) 18:06:05

しかし事前チェックが出来ないにもかかわらず実行時例外を投げてよろしいものだろうか
同じく文字列を解析して取得するタイプのClass#forNameが発行するClassNotFoundExceptionはキャッチ例外だよね？

0474デフォルトの名無しさん

2007/09/05(水) 20:31:41

>>472
パーズ失敗というのは、自分にとっては正常系の処理なんで
例外使うのは違和感があるんだ。感覚的な問題なんだけど、
Map<K, V>#get(K key)がkeyがエントリに存在しない場合に
例外を投げられると嫌なのと似た理由で。

0475デフォルトの名無しさん

2007/09/05(水) 20:35:55

>>474の補足だけど、Mapから値を取得しようとしたときにキーが存在しない場合
というのは、正常系の処理であることが多いから、もしもJavaのAPIの設計が、
例外投げるようになってたとしたらうっとおしいだろうなあということ

0476デフォルトの名無しさん

2007/09/05(水) 20:44:31

parseIntの場合も、本音で言うと多値よりnull返す方が良いと思ってる。ただ、
現状のJavaでは、nullを許容する/しないを型で表現できないという欠点が
あるので、微妙なところではあるけど。

0477デフォルトの名無しさん

2007/09/05(水) 20:46:57

はぁ？

0478デフォルトの名無しさん

2007/09/05(水) 20:55:41

C#のNullableは安易にstructをサポートしたがために招いた失敗仕様の名残じゃないか
オートボクシングでラッパーオブジェクトと用意に相互変換可能な現状で、んなもん無用の長物

0479デフォルトの名無しさん

2007/09/05(水) 21:53:06

使用できる範囲は限定されるが
int parseInt( String numberInString, int defaultValue )があればよかった。
パーズこけたらデフォルト値を返す。

0480デフォルトの名無しさん

2007/09/05(水) 21:55:44

そんなに1行で書きたいんですか

0481デフォルトの名無しさん

2007/09/05(水) 21:58:55

ラッパークラスに例えばisConvertable(String)みたいなメソッドがないのがねぇ。
2回パースするくらいなら例外でいいっしょｗｗｗｗｗｗって設計思想はちょっと。。。。

0482デフォルトの名無しさん

2007/09/05(水) 21:59:23

>>479
ドトネトのTryParseだな。
ttp://www.atmarkit.co.jp/fdotnet/dotnettips/408tryparse/tryparse.html

0483デフォルトの名無しさん

2007/09/05(水) 22:06:09

>>482
Javaだと参照渡しがないし、標準でmutableなintのラッパークラスも無いから作りにくい。

0484デフォルトの名無しさん

2007/09/05(水) 22:08:38

俺はjava.util.prefs.Preferencesのget()を思い出した

0485デフォルトの名無しさん

2007/09/05(水) 22:13:18

>>483
プリミティブを参照渡しさせない仕様なんだから
可変にしちゃったらラッパークラスにならないぞ

0486デフォルトの名無しさん

2007/09/05(水) 22:18:43

>>483
つ java.util.concurrent.atomic.AtomicInteger

っても、atomicな更新のためのクラスだから
mutableなintのラッパークラスとして使うのはアレな感じもするけど

0487デフォルトの名無しさん

2007/09/05(水) 23:17:23

org.omg.CORBA.IntHolder

CORBAのクラスなのがあれだが

0488デフォルトの名無しさん

2007/09/05(水) 23:25:19

>>478
C#のNullableは単に値型でnull許容可能にするための代物。
俺が言ってるのは、値型/参照型区別無くある型の変数に
nullを許容する/しないを指定できる代物。しかも、nullableな型は
non-nullableの型にそのまま代入しようとしたらエラーになって
コンパイラによるチェックを強制されるようなの。具体的な言語で言うと、Nice
http://nice.sourceforge.net/
がそれをサポートしてる。使ってみればわかるけど、この機能はかなり便利。

0489デフォルトの名無しさん

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を使った処理
}

0490デフォルトの名無しさん

2007/09/05(水) 23:39:25

この機能が無いからNullObjectが出来たんだな

0491デフォルトの名無しさん

2007/09/05(水) 23:45:26

>>489
それ、何が嬉しいのか分からん。

parseInt だと実行時例外で例外処理を強制できないから、
nullチェック強制できる >>489 の方が良いって話？

0492デフォルトの名無しさん

2007/09/05(水) 23:47:05

よく考えてみたらオートボクシングめんどくせえなｗ
これ

0493デフォルトの名無しさん

2007/09/05(水) 23:54:52

>>491
パーズ失敗を例外で扱うのに反対で、返り値でパーズ失敗を扱いたいんだけど、
nullでパーズ失敗を表すとしたらNullPointerExceptionの危険性があるし、意図が
あいまいになる危険性もある。で、この機能があればnullを許容するという事を
明示できるし、NullPointerExceptionの危険性も無いから欲しいなあということ。

0494デフォルトの名無しさん

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();
// ...
}

0495デフォルトの名無しさん

2007/09/06(木) 00:03:19

結論はおまえにはjavaは合ってないって事だな。
話聞いてると考え方が短いコードで実現させるタイプの動的言語の発想だ。

0496デフォルトの名無しさん

2007/09/06(木) 00:04:38

で、何故parseInt()のパーズ失敗を例外で扱うのに反対かというと、parseInt()は
引数から返り値が一意に定まるので、たとえパーズ失敗でも例外的な状態と
言えないと考えるから。

0497デフォルトの名無しさん

2007/09/06(木) 00:06:27

>>495
なんで動的言語が関係してくるの？むしろ静的にチェックできる機能が
欲しいって話をしてるわけで、動的言語とは対極の発想だよ。というか、
短いコードが好ましいってのは動的言語特有の発想でもないでしょ。

0498デフォルトの名無しさん

2007/09/06(木) 00:07:59

> メソッド側にアノテーションで実現することになりそうだ。
メソッド側にってのは余計。構成してて放置したままだった。

0499デフォルトの名無しさん

2007/09/06(木) 00:15:42

契約的言語。

0500デフォルトの名無しさん

2007/09/06(木) 00:21:29

アノテーションひとつで
if (n != null) { /* n アクセス */ } と
if (n == null) { return; } /* n アクセス */
のどちらかを選択（および強制）できるのなら歓迎かな。
@Overrideの親戚みたいなもんだ。

0501デフォルトの名無しさん

2007/09/06(木) 00:43:04

例外を「例外的な状態でのみ使うべき」というのは言葉が同じだからもっともらしく
聞こえてしまうだけで、何の助けにもならない方針。

http://www.boost.org/more/error_handling.html
http://boost.cppll.jp/HEAD/more/error_handling.html

0502デフォルトの名無しさん

2007/09/06(木) 00:48:46

>>500
FindBugsをどうぞ
http://findbugs.sourceforge.net/manual/annotations.html

0503デフォルトの名無しさん

2007/09/06(木) 01:03:12

>>493,496
単に自分の考えと合わないってだけ？
それって自前のクラスメソッド書いて、そっち使うんじゃダメなんか？

なんつーか、>>448-449 あたりが結論になりそうな話じゃねーかと。

0504デフォルトの名無しさん

2007/09/06(木) 01:14:56

>>503
もちろん自前のクラスメソッド書いて使うことになると思うよ。
実際にJavaプログラム書くときの解決策としては。単に言語の
拡張まで含めて許されるならどういう設計にするのが良いかという思考実験。

あと、free論争とは文脈が違うので一緒にされるのはちと心外だな。
どういう方針でライブラリ設計をするかという話は使い勝手に関わって
くる。もちろん、ここで議論しても実際のJava APIの設計が改善されない
という意味では無益なのはそうだけど。

0505デフォルトの名無しさん

2007/09/06(木) 01:26:05

>>496
理解できない
すべての失敗する引数はnullが返ることで一意に定まるということ?

例外的な状態かどうかはparseInt単体でなく、呼出し側がどうしたいかでも異なるはずだ
デフォルト値が定まる場合と定まらない場合、とか
んで、とりあえず保守的にパーズ失敗を例外として扱うと言う設計でよいと思う
checkedかどうかは微妙なとこだが

0506デフォルトの名無しさん

2007/09/06(木) 01:26:52

単に好き嫌いの問題で、パフォーマンスとか関係ないんでしょ？
free論争と大して変わらんと思うが。

0507デフォルトの名無しさん

2007/09/06(木) 01:30:33

>>504
parseInt の使い勝手を改善する事により、Java での開発効率が 10％向上するんだ！
とか考えてるなら一生懸命考えるのも頷けるんだけど……

ぶっちゃけ瑣末な問題じゃね？

0508デフォルトの名無しさん

2007/09/06(木) 01:40:40

例外を握りつぶすユーティリティメソッド作ればOK。

0509デフォルトの名無しさん

2007/09/06(木) 02:03:58

>>505
> すべての失敗する引数はnullが返ることで一意に定まるということ?
そういう意図で書いた。正確に言うと、外部の状態に依存せずに
入力*のみ*から返り値が決定される、ということ。その逆の
典型的な例としてはIOExceptionを発生させるような関数や
コンストラクタがある。これらの関数は入力だけでなく外部の
状態によって成功したり失敗したりする。

>>507
parseIntだけの問題として考えればぶっちゃけどうでもいいけど、
一般的な問題としてある関数が失敗を返り値で通知するか
例外で通知するか、というのは瑣末な問題じゃないと思う。

0510デフォルトの名無しさん

2007/09/06(木) 09:42:29

ユーティリティメソッド作ればOKってのは、思考停止以外のなにものでもない。

0511デフォルトの名無しさん

2007/09/06(木) 09:46:39

parseInt を改変しようとか考えるのは暇人以外のなにものでもない。

0512デフォルトの名無しさん

2007/09/06(木) 09:53:09

>>511
そうか？

0513デフォルトの名無しさん

2007/09/06(木) 10:14:54

>>511
つきあってた連中も暇人以外のなにものでもない。

0514デフォルトの名無しさん

2007/09/06(木) 11:20:14

改変は、ちゃんと考えてbugparadeにあげるなどすれば、なにがしかの影響は与えられる。
ここで改変について語るのも、そういったヤツのインスピレーションになることもあるだろうし、本人が書き込むこともあるだろう。
無駄ではないよ。

0515デフォルトの名無しさん

2007/09/06(木) 11:39:06

なにがしかの影響って……
>>509 も parseInt に関してはどうでもいいって言ってるんだが。
そんな瑣末な問題に関わらせる事で
JDK開発者のモチベーションを下げたいって事か？

free論争ってさ、やってる当事者は引っ込みがつかなくなってるだけかと思ってたけど
案外、>>514みたいに「この議論は無駄ではない」とか思ってる人も居るのかも知れないね。

0516デフォルトの名無しさん

2007/09/06(木) 11:41:41

parseIntの例外が例に挙がって
- コードを短く書きたい
- 例外で扱う状況とは思えない
という2点の争点があると思う。

さらに後者の視点は、
- 例外を扱うべき状況を設計の美しさから考える
- 例外を扱うべき状況をException処理の重さから考える
という2つの立場がある

俺は、parseIntに例外の記述が出てきてもいいが、重いException処理が
いやだなぁ、という点から、こういうのがあればいいんじゃないかと思う。

定義済Exception/ StaticException / 短距離Exception /LightWeightException ?

今、Exception処理が重いのは、Exceptionオブジェクトの生成にある（スタックトレース生成など）
つまり、生成処理をなくしてやれば大幅にパフォーマンスは改善するはず。
なので思い切って、stackTraceとかが空っぽのExceptionで
すぐ直上のcatch節で捉える決まりで、
さらにThrowの必要があるときは別のExceptionにしなくてはいけないようなもの。
気軽に例外が投げられるようになって、正常系の処理が例外でトリッキーに実装されるように
なっちゃうかもしれないけど、こういうのってどうですかね。

0517デフォルトの名無しさん

2007/09/06(木) 11:47:27

>>515
相手にするから調子に乗るんだろ。ほっとけ。

0518デフォルトの名無しさん

2007/09/06(木) 12:05:24

>>516
> 重いException処理がいやだなぁ、という点
いやなだけなのか。

これこれこういう使い方をすると、
（パーズ失敗する）parseInt の呼び出しがボトルネックになって困る、
そして、このような使われ方をする事が多いので標準APIを改善して欲しい、
ってんなら議論の余地もあるけど、それって単なる好き嫌いの問題じゃね？

0519デフォルトの名無しさん

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の機能を大幅にカットすれば、２桁のオーダーで処理を軽くすることができるわけです。
現在の仕組みを使って、実装するならこうなりますがシステムとしてサポートしてくれても
いいかなぁ、と思ったわけで。

0520デフォルトの名無しさん

2007/09/06(木) 12:53:24

>>519
> 数字でないものも大量に含むフィールドがあれば
普通はフォーマットエラー吐いて終わりでしょ。

0521デフォルトの名無しさん

2007/09/06(木) 13:10:14

　　　　〃〃∩ 　_, ,_
　　　　　⊂⌒（　`Д´）　＜　ヤダヤダ！ parseInt が例外使っちゃヤダ！
　　　　　　｀ヽ_つ ⊂ノ
　　　　　　　　　　　　　　ジタバタ

　　　　　　〃∩
　　　　　⊂⌒(　　_, ,_）　＜　ぶっちゃけどうでもいいけど、やっぱりヤダヤダ……
　　　　　　｀ヽ_つ ⊂ノ
　　　　　　　　　　　　　　ﾋｯｸ...ﾋｯｸ...

　　　　　⊂⌒(　　_, ,_）
　　　　　　｀ヽ_つ ⊂ノ　　zzz…

0522デフォルトの名無しさん

2007/09/06(木) 13:56:24

delphiのStrToIntDefみたいに、数値にできないときのデフォルト値が指定できればかなりいい

0523デフォルトの名無しさん

2007/09/06(木) 14:17:51

>>520
何で？全部読んで例外をチェックしないと駄目かもしれないですよ。

いや、というか例外を使うなとかいう話ではなく、
パフォーマンスを気にして例外を使うべき場面を回避しようとするのは
本末転倒だから、例外を使わなきゃ駄目なときパフォーマンスが
落ちなければそういう誤解、というか誤用がなくなるんじゃないかと。

0524デフォルトの名無しさん

2007/09/06(木) 14:45:35

>>523
「かもしれない」って……
要するに、今現在（パーズ失敗する）parseInt の呼び出しが
ボトルネックになって困ってるわけじゃないんでしょ。
単なる好き嫌いの問題にしか見えないが。

それに、誤用とか誤解とか言われても……
>>509の理論がいつでもどこでも通用する例外のガイドラインとはとても思えないし、
使い勝手、堅牢性、パフォーマンス、好き嫌いとか色々な要素が絡んでくるから
いつでもどこでも誰にでも通用する例外のガイドラインを作るのは難しいだろうし。

0525デフォルトの名無しさん

2007/09/06(木) 14:47:32

ということは例外はこれまでどおりフィーリングとわずかなドキュメントで判断していくしかないのかね

0526デフォルトの名無しさん

2007/09/06(木) 15:21:46

>>524
>>523 ≠>>509です。
parseIntはあくまで例です。
確かにちょっと誤解されそうなレスでした・・・

誤用というのは、Exceptionを使うまいとして
ごちゃごちゃとしたコードになってしまうような状況を指してます。
具体的にカチッとした基準に基づいた「ごちゃごちゃ」ではありませんが。

私は、parseIntに関わらず、Exception処理が軽くなればいいな、という話をしているつもりでした。

0527デフォルトの名無しさん

2007/09/06(木) 15:36:41

>>526
parseInt で例外生成コストが下がると嬉しいか？

それに、parseInt で Exceptionを使うまいとして
ごちゃごちゃとしたコードになるって、どんな状況？

あと、俺は Exception処理が軽くなれば良いって要望に対する返答が
「例外的な状況以外で例外使うな」って話なんだと理解してるんだが。
例外って濫用すれば goto より悲惨なスパゲッティコード書けるしね。

0528デフォルトの名無しさん

2007/09/06(木) 17:31:04

パースの失敗は十分、例外的状況に値すると思うが・・・。
例外処理の乱用がスパゲッティーコード招いてるんじゃなくてそういうコード書いてる自分がスパゲッティー作ってるんだと思う。

アプリケーションかミドルウェア側の設計でどうにかなると思うんだが？

0529デフォルトの名無しさん

2007/09/06(木) 17:37:48

>>527
InterruptExceptionって例外的だと思う？
スレッドのキャンセルを実装しようと思ったら普通に出るけど

0530デフォルトの名無しさん

2007/09/06(木) 18:49:35

>>528
設計っつーか、実装で吸収できるでしょ。

0531デフォルトの名無しさん

2007/09/06(木) 20:19:45

便利なら便利なほうがいい。

0532デフォルトの名無しさん

2007/09/06(木) 20:24:49

何を便利と感じるかは人によって違う、と。

かと言ってなんでも標準APIに入れたら標準APIメンテする人間の負担が増えて
バグが増えたり放置されたりといった悪影響も考えられる、と。

0533デフォルトの名無しさん

2007/09/06(木) 20:47:42

NICEのnullableってのは興味深いネタだったけど、
それと一緒に語られたparseIntの仕様には何の興味も湧かなかった。
つーことで、イディオム補完型（保証型）のアノテーションの充実を期待したい。

0534デフォルトの名無しさん

2007/09/07(金) 07:32:33

>>445
終了前のfreeは害っていうのがいるだろ。

0535デフォルトの名無しさん

2007/09/07(金) 07:55:31

そんなものは無い

0536デフォルトの名無しさん

2007/09/07(金) 22:37:51

http://blogs.wankuma.com/kacchan6/archive/2007/09/07/94499.aspx

0537デフォルトの名無しさん

2007/09/07(金) 22:39:06

http://blogs.wankuma.com/kacchan6/archive/2007/09/07/94499.aspx

0538デフォルトの名無しさん

2007/09/08(土) 00:14:55

parseIntで100近くもダベれるお前らに脱帽

0539デフォルトの名無しさん

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

0540デフォルトの名無しさん

2007/09/08(土) 01:03:04

>>539
例外を使ってるバージョンが100倍近く遅いんだが、それは
有意な差じゃないの？

0541デフォルトの名無しさん

2007/09/08(土) 01:05:19

あ、もちろん実際にparseIntが使われる局面で1000000万回も
呼ばれることは無いだろうから、そういう意味では例外を使っても
いいんだろうけど、有意な差が無いってのは変でないの？ってこと

0542デフォルトの名無しさん

2007/09/08(土) 01:05:27

>>539
ネタにマジレス。

まず数値チェックに parseInt 使って
> クリティカルで速度が要求される場面
が具体的にどういう場面なのかってのを特定するのが先決。

それをしないで「どういう処理が望ましいか」を考えても時間の無駄。

0543デフォルトの名無しさん

2007/09/08(土) 01:07:45

間違った。1000000万回 -> 1000万回

0544デフォルトの名無しさん

2007/09/08(土) 01:12:44

>>538
まだまだ続くよ

0545デフォルトの名無しさん

2007/09/08(土) 01:59:22

巫女巫女ナース巫女巫女ナース♪

0546デフォルトの名無しさん

2007/09/08(土) 02:32:19

｢まだまだ　いくよぉ～｣だな

0547デフォルトの名無しさん

2007/09/08(土) 03:09:27

もうちょっとだけ続くのじゃ

0548デフォルトの名無しさん

2007/09/08(土) 07:03:01

つうか、例外は制御構造の要だろ
ttp://d.hatena.ne.jp/smeghead/20070309/baka

0549デフォルトの名無しさん

2007/09/08(土) 08:05:55

多値にしてもnullableにしても、
失敗をnullで表すのはちょっと古いんじゃないかな。

多値なら失敗(false)したら(undef, false)とundefみたいな値を返す方がいいと思う。

0550デフォルトの名無しさん

2007/09/08(土) 10:19:24

>>544,547
続けるなよ……

0551519

2007/09/08(土) 14:09:14

>>536
ちょっと待て、ほとんど俺が書いたコードじゃねえかそれ。
ちなみに、おれじゃねえぞ。そのblog

0552デフォルトの名無しさん

2007/09/08(土) 14:18:22

>>549
undefがnullとどう違うのかわからん

0553デフォルトの名無しさん

2007/09/08(土) 15:06:37

>>552
お前はそもそもnullは何をモデル化したと考えてるんだ？

0554かつのり

2007/09/08(土) 16:03:23

本人降臨っす。

>>519
実験用にパクらせていただきましたｗ

ちなみにStringUtils.isNumeric()は微妙ですね。
Integer.parseIntの高速版とするなら、
Integerとしての要件を満たさなければいけません。

正規表現のパターンを予めキャッシュしておいて、
そのパターンでマッチングするのが一番早いのかな。

0555デフォルトの名無しさん

2007/09/08(土) 16:29:24

NumberUtils#isNumberもあるけどlong型とかでも判定しちゃうな

0556519

2007/09/08(土) 17:34:45

>>554
ああ、バッチでファイル読む時は俺もそうしてるなぁ
どうせ桁数制限とか入る事が多いし

0557デフォルトの名無しさん

2007/09/08(土) 17:52:06

Patternのcompileってホントにコンパイルしてるの？

0558デフォルトの名無しさん

2007/09/08(土) 18:01:25

>>557
コンパイルの意味を、パースして実行用データ作っとくって意味なら、コンパイルしてるんじゃねぇの？

0559デフォルトの名無しさん

2007/09/08(土) 18:21:18

たしかに最適化オプション付きであるとはいってないからね。
Strategyパターンとか駆使してガチガチに最適化されたPatternを返して欲しいとこだ。

0560デフォルトの名無しさん

2007/09/08(土) 19:03:46

Javaの正規表現はDFAでしょ？確か。
DFAはバックトラックしなくていいから、
最適化は高速化ではなく使用メモリのレベル。
遷移テーブルとかその辺。

下手な自前のマッチングコードを書くより早いよ。正規表現は。

0561デフォルトの名無しさん

2007/09/08(土) 19:55:04

>>560
Javaの正規表現はNFA。実装読んでみるべし。
最近の言語に組み込みの正規表現ライブラリの多くはNFA(または
その変種)を採用してる。理由はNFAじゃないと扱いづらい機能
(後方参照など)があるため。

0562デフォルトの名無しさん

2007/09/08(土) 19:56:36

ちなみに各言語における正規表現ライブラリの実装がどのように
なっているかの概要を知りたい場合は、詳説正規表現がオススメ

0563デフォルトの名無しさん

2007/09/08(土) 22:35:20

>561
そか。情報サンクスコ

0564デフォルトの名無しさん

2007/09/09(日) 19:28:16

DFAじゃあ不便すぎる。

0565デフォルトの名無しさん

2007/09/09(日) 21:49:32

DFAはNFAから変換できるけど、NFAにしておく意義としては、
NFAのまま何かの機能を追加するってこと？
バックトラックする際に後方参照も同時にサポートするためなのか。

0566デフォルトの名無しさん

2007/09/09(日) 22:28:17

>>560
> 下手な自前のマッチングコードを書くより早いよ。正規表現は。

んなわけねーだろ。正規表現遅すぎだ。計測してねーだろ。
ただ、Web アプリとかでせいぜい項目が数百程度の
入力チェックや変換程度なら速度差は計測不能。

0567デフォルトの名無しさん

2007/09/09(日) 22:41:57

>>566
単純な文字パターンの検証なら正規表現の方が遅いだろうけど、
ごく一般的な業務システムプログラマが、
自前で複雑な検証コードを書くよりは速い。
きちんとロジックを書ける人なら速いんだけど。

0568デフォルトの名無しさん

2007/09/09(日) 23:18:56

文脈的に parseInt でパーズ成功/失敗を予め判定するためのコードでしょ。

>>554が言うように Intergerとしての要件を満たす、
文字列が数字で構成されてるかだけじゃなくて最大値や最小値チェックもするなら
正規表現つかうより自前でやった方が早く書けるんじゃねーの？

0569デフォルトの名無しさん

2007/09/09(日) 23:23:20

最大値や最小値をチェックする時点で、成功/失敗を予め判定するどころか、すでに値が求まってる気がする

0570デフォルトの名無しさん

2007/09/09(日) 23:56:08

>>566 >>567 >>568

>>560は正規表現エンジンがDFAで実装されてる場合の
話をしてると思うよ。その場合なら、下手に自前の
コード書くより早いというのは間違いでもなんでもないよ

0571デフォルトの名無しさん

2007/09/10(月) 00:01:33

> ちなみにStringUtils.isNumeric()は微妙ですね。
> Integer.parseIntの高速版とするなら、
> Integerとしての要件を満たさなければいけません。

だからなぁ…… 最大値/最小値チェックしないなら
ほとんどStringUtils.isNumeric()で用足りるんじゃね？

0572デフォルトの名無しさん

2007/09/10(月) 00:01:37

>>565
そういうこと。NFAのままにしておけば、「非正規な」機能である後方参照
やその他もろもろ、比較的容易に追加できる

0573デフォルトの名無しさん

2007/09/10(月) 00:13:43

>>569
例外使わないだけで 100倍程速くなるそうだから、
変換処理が 2回やる事によって 2倍の時間かかっても大した問題じゃないんじゃね？

まぁ、場合によっては大した問題になるかもしれんが。
そんなん問題になってから考えりゃいいっしょ。

0574デフォルトの名無しさん

2007/09/10(月) 01:42:54

正規表現使うほうが１００倍速いよ。実装が。

0575デフォルトの名無しさん

2007/09/10(月) 20:17:24

C#の正規表現はグループに名前を付けられるみたいだね

0576デフォルトの名無しさん

2007/09/10(月) 21:14:45

>>574
StringUtils.isNumeric()では足りない部分までIntegerの要件を満たすかチェックするんだったら
正規表現でやるのは面倒くさそうだが。

0577デフォルトの名無しさん

2007/09/10(月) 22:50:21

正規表現のスレでやれよ。ここには関係ないから。

0578デフォルトの名無しさん

2007/09/10(月) 23:04:10

>>576
桁数制限してIntegerの半分以上の範囲捨てるなら簡単だけどな

0579デフォルトの名無しさん

2007/09/12(水) 00:32:10

>>575
正規表現のマッチング処理高速化のためにコンパイルすると、
メモリリークするとかＭＳＤＮのドキュメントに書いてあるけどな。

0580デフォルトの名無しさん

2007/09/12(水) 00:53:38

>>579
それドトネト1.1のころの制限じゃない？

0581デフォルトの名無しさん

2007/09/15(土) 10:08:16

なんと言う次世代

0582デフォルトの名無しさん

2007/09/15(土) 10:59:42

次世代試作機・・・。

0583デフォルトの名無しさん

2007/09/15(土) 13:48:51

Javaを拡張するのではなく、OSを拡張するというのはJSRにならんのかね？
例えばjinputをJava標準にするための下地にするためにとか。

0584デフォルトの名無しさん

2007/09/15(土) 14:16:31

JDK7 build20
http://download.java.net/jdk7/binaries/
http://download.java.net/jdk7/changes/jdk7-b20.html

0585デフォルトの名無しさん

2007/09/15(土) 19:49:01

そういやjdk7が出来たらOpenJDK6をOpenJDK7ベースで再構築してOpenJDK6をGPL2で配布するらしいな。
将来的には公式バイナリも完全にOpenJDKからビルドするらしい。

0586デフォルトの名無しさん

2007/09/16(日) 12:58:01

７は変な機能増えすぎ
もっとシンプルに保てよ

0587デフォルトの名無しさん

2007/09/16(日) 13:16:10

クロージャというか関数導入するならperl見たいな複数戻り値の関数もできるようにしてくれ

0588デフォルトの名無しさん

2007/09/16(日) 14:09:47

多値返せたらいいのにと思うことはよくある

0589デフォルトの名無しさん

2007/09/16(日) 15:38:35

時々、妙に多値希望の人っているよね
そういう人はロートルだと思っておｋ？

0590デフォルトの名無しさん

2007/09/16(日) 15:39:53

多値が返せる言語ってあるの？

0591デフォルトの名無しさん

2007/09/16(日) 15:44:03

Perlしかしらない。
ただstateとvalueみたいな多値が欲しいがために
ReultFooみたいなクラスを書くのはなんだかなぁと思うときは多い。

0592デフォルトの名無しさん

2007/09/16(日) 16:23:13

lispまでいくと多値というよりリストか
Object[]のシンタックスシュガーで十分なんだけどな
C#のstructなんかよりずっと有用

0593デフォルトの名無しさん

2007/09/16(日) 17:16:56

pythonのtupleみたいなの。
まあ、Object[]でもいいけど。

>>591みたいな
型に名前つけるのが面倒なんだよ。

0594デフォルトの名無しさん

2007/09/16(日) 19:17:12

Pair<A, B> みたいなクラスを作って使いまわすとか

0595デフォルトの名無しさん

2007/09/16(日) 19:48:49

最近は多値返せる言語増えたよ。
javaだとどうせバイトコードレベルでは配列になるんだろうね。

0596デフォルトの名無しさん

2007/09/16(日) 20:16:58

public const<String, Boolean> getResult() {
return const { "おｋｗｗｗｗ", true };
}

こんな感じで死にキーワードを流用できないものか

0597デフォルトの名無しさん

2007/09/16(日) 20:20:27

>>596
それだったら Pair<A, B> で良いじゃん。

0598デフォルトの名無しさん

2007/09/16(日) 20:26:16

普通のGenericsは可変長じゃねー

0599デフォルトの名無しさん

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)

みたいにすれば？

0600デフォルトの名無しさん

2007/09/16(日) 20:49:41

こらこら。Javaにrefやoutはないでしょ。
尤もCommonsLangあたりにはあっていいクラスだとは思うけど

0601デフォルトの名無しさん

2007/09/16(日) 20:52:29

ref や out って、どこの話だ？

0602デフォルトの名無しさん

2007/09/16(日) 20:52:37

多値よりも Ref<T> のほうがまだ使い勝手が良さそうな気がする。

0603デフォルトの名無しさん

2007/09/16(日) 20:53:37

ああ、ファクトリメソッドか、俺の勘違い。
>>601 C#

0604デフォルトの名無しさん

2007/09/16(日) 20:55:55

>>603
いや、レス番の話。
このスレのどこで ref や out の話が出てんのか、と。

0605デフォルトの名無しさん

2007/09/16(日) 20:57:38

俺が>>601をクラス定義と勘違いしただけだって。

0606デフォルトの名無しさん

2007/09/16(日) 20:59:21

あ、>>599ね。あかん、おねむの時間っぽい。

0607デフォルトの名無しさん

2007/09/16(日) 21:03:13

>>599 にも ref や out があるようには見えんが……

0608デフォルトの名無しさん

2007/09/16(日) 21:04:09

どう勘違いしたのかくらい考えろ馬鹿ちん

0609デフォルトの名無しさん

2007/09/16(日) 21:07:16

なんだ、勘違いか。なら考えても無駄だな。

0610デフォルトの名無しさん

2007/09/16(日) 21:09:24

遅かれ速かれ多値はサポートしてくれるものと思いたい。

0611デフォルトの名無しさん

2007/09/16(日) 21:10:54

JVM系LLで多値サポートしてたら、そっち使えって話になるんじゃね？

0612デフォルトの名無しさん

2007/09/16(日) 21:15:23

var rand = new Random();
int n = rand.nextInt();
みたいな書き方も需要あるから、多値もJSRには上がるとは思う。

0613デフォルトの名無しさん

2007/09/16(日) 21:17:32

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4222792
will not be fixed になってる。

0614デフォルトの名無しさん

2007/09/16(日) 21:23:36

>>612
どうだろね？

型推論ですら、変数宣言時の型指定を省くのは Java 的じゃないってんで
G<T> g = new G();
みたいに、初期化子の方のパラメタ型指定を省けるようにしようって
論調の方が強いみたいだけど。今までの
G<T> g = factoryOfG();
みたいな型推論とも一貫性あるってのが良いらしい

0615デフォルトの名無しさん

2007/09/16(日) 21:28:40

G<T> g = new(); みたいなのもどっかで見たな。

0616デフォルトの名無しさん

2007/09/16(日) 21:31:31

極力interfaceで受け取れいうてる今までとの親和性の問題もあるし、
今後の拡張はローカルキーワードで行きたいって思惑もあるから
早い段階でサポートするならそっちかもな

>>615
みたけど流石にそれはないｗ

0617デフォルトの名無しさん

2007/09/16(日) 21:42:13

varの方はGraphicsEnvironment.getLocalGraphicsEnvironment()とか長すぎるから何とか汁って考えもあったはず

0618デフォルトの名無しさん

2007/09/16(日) 21:47:32

>>617
つ static import

0619デフォルトの名無しさん

2007/09/16(日) 21:49:48

staticじゃなきゃ役にたたねーけどね

0620デフォルトの名無しさん

2007/09/16(日) 21:52:21

メソッド名が長いのはメソッド名のalias導入とかせんと解決せんのでは？

0621デフォルトの名無しさん

2007/09/16(日) 21:54:22

関係ないけど、メソッド名ってたしか長さ制限あったよね

0622デフォルトの名無しさん

2007/09/16(日) 22:00:53

static importはユーティリティメソッドに
沢山依存してる状態じゃないと返って面倒なだけ

0623デフォルトの名無しさん

2007/09/16(日) 22:05:31

名前空間が汚れる。

0624デフォルトの名無しさん

2007/09/16(日) 22:06:13

まあ、結局のところD言語はvarで解決としたみたいだからJavaもそうなるよ。
プロパティ問題も馬鹿なことやらないで、素直にC#風にしたしね。

0625デフォルトの名無しさん

2007/09/16(日) 22:26:52

> プロパティ問題も馬鹿なことやらないで、素直にC#風にした
ソースは？

0626デフォルトの名無しさん

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を箱にする方法より性能がいい。

0627デフォルトの名無しさん

2007/09/17(月) 00:01:39

>スタックフレームの返値を格納するスロットが一つ増えるだけだから、
それやると VM の変更が必要にならんか？

> tupleやlistやarrayを箱にする方法より性能がいい。
その辺の性能あげるためにエスケープ解析とか頑張ってるんじゃね？

0628デフォルトの名無しさん

2007/09/17(月) 00:02:35

>>627
VMの変更っつーか、VM仕様の変更じゃね？

0629デフォルトの名無しさん

2007/09/17(月) 00:07:16

>>625
http://docs.google.com/View?docid=dfhbvdfw_1f7mzf2
これの事じゃね？

でも、これbeansのプロパティと互換性ないし、
フィールドとプロパティの名前がかぶった場合どうなるかって部分も甘いような。

0630デフォルトの名無しさん

2007/09/17(月) 12:14:51

多値はいつか実現して欲しいね。
引数は0個以上なのに、結果は0か1に制限されているのは不便。

>>589
他の言語で使うと癖になるから、粘着的なw要望が続くんだと思う。

0631デフォルトの名無しさん

2007/09/17(月) 12:20:52

>>630
なんつーか、Perlとかで初めてsplitの結果を複数の変数に
まとめて入れる表現見たとき便利だと思ったわけで、
こういうのって、返値は配列として扱ってるじゃない。

配列の返値を、各変数に代入するシンタックス糖分があればいいんじゃないかな？

0632デフォルトの名無しさん

2007/09/17(月) 13:34:05

> スタックフレームの返値を格納するスロットが一つ増えるだけ

> 配列の返値を、各変数に代入するシンタックス糖分があればいい

この二つって全然別の要求なわけで……

0633デフォルトの名無しさん

2007/09/17(月) 13:35:18

>>630
粘着的な要望する奴は口だけ動かして手を動かさんからなぁ……

0634デフォルトの名無しさん

2007/09/17(月) 14:09:07

>>632
多値って一口に言っても、考えてる事が微妙に違うからなぁ……

0635デフォルトの名無しさん

2007/09/17(月) 14:49:27

とりあえず配列でやっておけばいいんじゃないの？

0636デフォルトの名無しさん

2007/09/17(月) 14:52:17

>>635
Object[]を使えばいいじゃんって意味？その場合、複数種類の型を内包する配列を扱うことになるから、
言語的なサポートが欲しいって言ってるんじゃない？

0637デフォルトの名無しさん

2007/09/17(月) 14:53:20

>>633
このスレに要望出しても意味ねえんだけどな

0638デフォルトの名無しさん

2007/09/17(月) 14:54:47

型の問題があるなら、引数のほうに値をうけとる配列として渡すとかね。

0639デフォルトの名無しさん

2007/09/17(月) 14:58:05

>>637
要望だした時点で気持ちよくなってんじゃないかと。
要望を実現する事よりも、気持ちいい事の方が重要なんじゃね？

0640デフォルトの名無しさん

2007/09/17(月) 15:48:10

ゆとりのやつって、直接的な効果がなければ意味ねぇとかよく言うよね。
間接的な効果を想像できないんだよね。

0641デフォルトの名無しさん

2007/09/17(月) 15:53:01

あるあるｗ
ちょっとたとえを出して、それを否定できただけで、全てを否定ｗ

0642デフォルトの名無しさん

2007/09/17(月) 15:53:48

間接的な効果に期待（するだけ）しかできないんだったら
> 要望を実現する事よりも、気持ちいい事の方が重要なんじゃね？
って評価は正しいような。

0643デフォルトの名無しさん

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); タイプの型推論が欲しいような。

0644デフォルトの名無しさん

2007/09/17(月) 20:18:05

http://blogs.wankuma.com/kacchan6/archive/2007/09/17/96592.aspx

0645デフォルトの名無しさん

2007/09/18(火) 08:41:40

generics版は、入力めんどすぎだな

0646デフォルトの名無しさん

2007/09/18(火) 16:45:33

ドキュメント簡潔で理解しやすいしこっちのほうが好きなのは俺だけか

それはそうと９月の第三月曜日とか毎月第五土曜日（と、第五土曜日が存在するかチェックする方法）とか
どうやって入力するんだろう？この程度のことがいちいち煩雑なのは嫌なんだけど。
曜日指定できそうなCalenderDayのDayOfWeekは引数がなぜかint型だし。
曜日関係はまだまだこれからなのかね？

0647デフォルトの名無しさん

2007/09/18(火) 20:37:07

あれだ。
カレンダー用のXPathみたいなの作って
W3C標準にすればいいんじゃね？

0648デフォルトの名無しさん

2007/09/18(火) 21:04:02

CQL

CalendarQueryLanguage

ばばーん >>647 がただ今鋭意作成中です

0649デフォルトの名無しさん

2007/09/18(火) 23:12:45

>>647
Structured Calendar And Time Markup Language
略してSCATML。それのAPIがSCATMLAPI。

0650デフォルトの名無しさん

2007/09/18(火) 23:19:52

31日や2月29日みたいなTimeFieldやTimeViewって
カレンダーが背後にあるクラスに受け入れられるまで、意味のあるカレンダーデータかどうかわかんないわけだよな。
ついでにPeriodを加算するみたいな日付計算もできない。
それなら『カレンダーが背後にあるクラス』をインターフェース化しておいたほうがいいんじゃないかと思ったり。
最初はCalendricalがそうかと思ったんだけどなんか違うっぽいな。

0651デフォルトの名無しさん

2007/09/18(火) 23:54:39

やっぱCalendricalか。何故かTimeViewやTimeFieldに継承されているけどこれは何かの間違いだな。

weekOfMonthが作れるようになったりTimeField同士を結合してTimeViewを作ったりできねえかな。
そしたら今年の９月の第３月曜日とかでも楽に指定できるのに。難しいのかこれは。

0652デフォルトの名無しさん

2007/09/19(水) 00:00:02

TimeAmountで期間データの変換が相互に可能になってるっぽいが
Second～DayはともかくDay～Foreverのデータはカレンダーないと変換できないような。
いちいちUnsupportedOperationException投げるつもりかいな

0653デフォルトの名無しさん

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);
}

0654デフォルトの名無しさん

2007/09/19(水) 02:54:46

>javax.time.Moments.*
パッケージ名だけ見たらとてつもなく抽象的すぎて何に使って良いかわかりづらいな。

0655デフォルトの名無しさん

2007/09/19(水) 03:17:56

TimeUtilsとかの方がいいよな。常識的に考えて。
そのうち変わると思うが

0656デフォルトの名無しさん

2007/09/19(水) 11:16:37

>>654
time.Momentsってそんなにわかりにくいかな？

0657デフォルトの名無しさん

2007/09/19(水) 13:15:14

個人的にクラス名変えるならこんな感じ
時刻系
TimeView＞TimeExpression：時刻表現
Calendrical＞ScaledTime：カレンダー評価済み時刻表現
TimeField＞TimeField：即値時刻表現

期間系
Period＞Period：期間
TimeAmount＞PeriodField：即値期間

単位系
TimePart＞Unit：単位

その他
Moments＞TimeUtils：ユーティリティクラス

うーん、イマイチ。

0658デフォルトの名無しさん

2007/09/19(水) 16:48:46

クラス名・変数名に迷ったら書き込むスレ。Part10
ttp://pc11.2ch.net/test/read.cgi/tech/1180146315/

ここにお願いしてみては

0659デフォルトの名無しさん

2007/09/19(水) 18:46:41

>>656
今のクラス名だと高精度の時間取得APIとも取れるし、時系列系APIのフレームワークとも取れる。

名前から想像できる用途が曖昧で冗長といった印象。
名前からすると一見汎用性がありそうだけど、
けど中身はカレンダーAPIの上位API程度の印象も受ける。

そのため、今のカレンダーAPIとの関係も分かりづらい。
そうなると移行や使い分けが難しいかと。

要するに何のために作ったのか分からん、と・・・。

0660デフォルトの名無しさん

2007/09/19(水) 19:01:06

どう見ても完全に置き換えるものとして使うようにできてるだろ。
互換性を意識しないといけない場合以外は全部移行していいようにするんじゃないのか？
まだOverViewには入ってないがフォーマッティングやパーシング用のクラスも作るらしいし。

0661デフォルトの名無しさん

2007/09/19(水) 19:22:46

java.util.concurrent.TimeUnit も忘れないであげて

0662デフォルトの名無しさん

2007/09/21(金) 13:05:43

JSR 277とJSR 291は議論が熱いね。
http://www.infoq.com/jp/osgi

0663デフォルトの名無しさん

2007/09/22(土) 10:54:13

OSGi関係は熱そうだね。
関わってるところ多いし、影響が大きそう

0664デフォルトの名無しさん

2007/09/24(月) 18:48:55

JDK7、機能はすごい魅力的なんだが、リリースが一年以上先か・・・。
堅実なのはいいことだけど、もうちょっと早くならんかなあ。

0665デフォルトの名無しさん

2007/09/25(火) 01:28:48

目玉機能とされてるJSR-277もまだだし
Closureに至ってはJSRすらないしなぁ。

これでリリースまでに全部つっこんできたら十分早いと思うが。

0666デフォルトの名無しさん

2007/09/27(木) 22:46:13

業界的にはまだバージョン4が多数だから早い感じもする。

0667デフォルトの名無しさん

2007/09/28(金) 00:51:19

テンプレート(1.5)、クロージャ(1.7)とくれば、最後に来るのは…マクロ！(1.9予定)

すべての言語は最後はlispの一部を再実装する事になるのかと思うと、複雑な気分だな。

0668デフォルトの名無しさん

2007/09/28(金) 01:00:50

バージョン4なんかない。

0669デフォルトの名無しさん

2007/09/28(金) 02:22:08

>>668
R4のことだろ？

0670デフォルトの名無しさん

2007/09/28(金) 04:08:52

RhinoR4？ライセンスが・・・ｗ

0671デフォルトの名無しさん

2007/09/28(金) 10:11:40

最後はevalだな。

0672デフォルトの名無しさん

2007/09/28(金) 11:10:22

OSGiじゃないのか？

0673デフォルトの名無しさん

2007/09/28(金) 14:32:28

JDK7 build21
http://download.java.net/jdk7/binaries/
http://download.java.net/jdk7/changes/jdk7-b21.html
だって。
ようやくコンパネの縦長が直った。

0674デフォルトの名無しさん

2007/10/09(火) 15:06:09

OSGiかなにかのプラグイン機構がJava SEに入るまでまだ一年位あるので、
Javaのスクリプトで代わりをできないかと思ったんですが、
次を読むと普通にできそうですね。
（つまりJavaプログラム実行中に動的に実行コードを入れ替えたい。）

JavaからRubyスクリプトを実行する
http://codezine.jp/a/article/aid/1647.aspx?p=3

個人的にプラグイン機構の重要度がかなり下がりました。

0675デフォルトの名無しさん

2007/10/09(火) 15:14:59

普通にクラスローダを使えばいいだけじゃないの？

0676デフォルトの名無しさん

2007/10/09(火) 15:26:11

クラスローダは難しい・・・
昔OSGiを使ってたときですらクラスローダで苦労した。
確か、setContextClassLoader辺りとか頻発した。
（OSSのライブラリでこれが設定できないので、プラグインから使うために
　ソースを書き換える必要が発生したこともあった。）
記憶が薄れてるけどOSGiが無いとさらに倍以上苦労する感じだったと思う。

0677デフォルトの名無しさん

2007/10/10(水) 02:31:03

URLClassLoaderで簡単にJARファイルからクラスを読み込めるから、
プログラム実行中に動的に実行コードを入れ替えるのは簡単だと思うけどな。

0678デフォルトの名無しさん

2007/10/10(水) 08:53:59

>>674
Rubyてw
Javascript使えよ。最初からSEに入ってんだから。

0679674

2007/10/10(水) 13:46:54

助言？ありがとうございます。

>>677
setContextClassLoaderは、Jar内のファイルを読むために
基盤とプラグインのJarのClassLoaderを切り替える
のに使ってたんだったと思いますが、
URLClassLoaderを使うと簡単にできそうな気がします。

>>678
JRubyは速いと言う記事が目に入ったので
条件反射で調べてみたのですが、
JavaScriptでいいですね。Rubyは殆ど知らないし。

0680674

2007/10/10(水) 13:49:23

ちなみにやりたい事は、
UMLのステートチャート図で状態遷移を定義しXMLを生成する
（このエディタは自作する）
実行時はXMLに従って、各状態と遷移時の処理を行う。
基本的に、ステートパターンで実現する。
こんな感じの多目的に使えるフレームワーク作り。

と言う感じで、DIコンテナで普通にできそうですね…。
それが一番早いなｗ

0681デフォルトの名無しさん

2007/10/10(水) 16:20:30

>>677
具体的にどういうコードになるの？
クラスローダーは複雑で言ってる事が見えてこない…

0682デフォルトの名無しさん

2007/10/10(水) 16:44:08

>> 681
丁度いいページがあったので勝手にリンクさせてもらいます。
ttp://homepage3.nifty.com/satoshis/java/memo.html#extension

0683デフォルトの名無しさん

2007/10/11(木) 03:45:19

JRubyは本家と比べて早いって意味だ。
まあ、宗教は自由だぜ！

0684デフォルトの名無しさん

2007/10/11(木) 09:54:50

>>682おお、そういうことか！

0685デフォルトの名無しさん

2007/10/13(土) 23:07:55

そろそろクロージャの仕様決まった？情報まだぁ

0686デフォルトの名無しさん

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のリストにも登録されてないみたいだし。
他の場所では動いてるのかも知らんけど

0687デフォルトの名無しさん

2007/10/13(土) 23:49:45

ああ、いろいろプロポーズはあるみたいだけどそれが採用されそう。

0688デフォルトの名無しさん

2007/10/14(日) 01:16:57

簡単に読み書きできることが重視されるJavaでは導入が難しいのかも。

クロージャに結びつけた変数に対して破壊的操作を行うプログラムを書いちゃうと、
非常に理解が難しいプログラムになる。と某所で言われていた。

0689デフォルトの名無しさん

2007/10/14(日) 01:28:27

staticメソッドとクロージャを組み合わせて制御文みたいなのを作れるのは面白いと思ったけど
フォールスルーしないswitch文みたいなのは無理かね

0690デフォルトの名無しさん

2007/10/14(日) 02:13:48

クロージャ、クロージャ言うけどクロージャ導入しても元々クロージャに書き換えるようなメソッドなら
コンパイル時にインライン化されてるだろうから人がクロージャ書く意味ってあるか？

JavaScriptも使うからクロージャは大好きだが・・・。

0691デフォルトの名無しさん

2007/10/14(日) 02:20:41

うん、無理っぽいな。できたとしてもがcaseに指定された値が定数かどうかを判別するすべがないから意味ないし

String line;
while ((line = br.readLine()) != null)
みたいなループをfor eachLine(String line : br)みたいには直せそうだ。あんまりいい例じゃないが

>>690
コストが低いからクロージャを使うわけじゃないだろ

0692デフォルトの名無しさん

2007/10/14(日) 03:35:29

いいかげんプリプロセッサとはいわんからせめて#ifdefを導入しろよ

0693デフォルトの名無しさん

2007/10/14(日) 03:46:15

＞＞６９０
わかりやすいから使うんじゃないのか？
いい加減いちいち無名クラスを宣言するのめんどうになってきたよ。

0694デフォルトの名無しさん

2007/10/14(日) 04:47:24

もう関数型のパラダイム全部入れちゃえばいいじゃんｗ

0695デフォルトの名無しさん

2007/10/14(日) 05:53:53

どうせこうなるんなら最初からいれちゃえばよかったのに

0696デフォルトの名無しさん

2007/10/14(日) 13:56:40

クロージャが、多重継承のようにうまく使えば有用だが弊害もある機能だったらどうするんだ？
Javaはハッカー向け言語ではなく一般向け言語なんだし、彼らが誤用しにくい機能であるか検証しなければならない。

0697デフォルトの名無しさん

2007/10/14(日) 14:24:52

どのように有用？
別に一般向けでないが？
自分で使いこなせればよいだけだし？
おまえ、キモイ顔しているんだろうな。

0698デフォルトの名無しさん

2007/10/14(日) 14:27:52

>>692
既にあるにはあるだろう。

0699デフォルトの名無しさん

2007/10/14(日) 14:50:31

根本的には関数型言語のパラダイムを中途半端に取り入れるのが不味いんだろうな。
だれか、両方を統合するようなアイデアを発明してくれればいいんだが。

0700デフォルトの名無しさん

2007/10/14(日) 15:46:57

ところで、>>696は一体全体何を主張したかったのだろうか…謎は深まるばかりだ…

0701デフォルトの名無しさん

2007/10/14(日) 16:55:18

>>699
命令型と関数型で、破壊的代入の在る/無しという根本的な前提が異なっているからなぁ。
この大きく異なる前提を乗り越えて上手く使える機構が欲しいね。

0702デフォルトの名無しさん

2007/10/14(日) 17:07:59

不変なオブジェクトを渡すか防衛的コピーして渡すか変更不可能なビューを渡すかすればいい話なんじゃないのか
Immutableオブジェクトを作るときと同じじゃん

0703デフォルトの名無しさん

2007/10/14(日) 17:09:24

その違いがなくなると、命令型と関数型の垣根がなくなってしまうし、いくら欲しくても乗り越える事はできなだろう。

0704デフォルトの名無しさん

2007/10/14(日) 18:53:24

>>688
int な変数を final int[] みたいに似非参照化して
内部クラスや匿名クラスで使えば結局同じ事になるけど、
記述が容易になると初心者が躓く可能性が高いとかそーゆー話？

http://docs.google.com/View?docid=k73_1ggr36h
CICE とかの public int みたいな構文糖の方が良いって話か？

0705デフォルトの名無しさん

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){
　　//処理
}

これでこのブロックの中でだけ特定の変数のメソッド呼び出しのログが取れるはず
ちょっといじれば特定のアノテーションのついているメソッドの呼び出しだけに反応するようにもできると思う

0706デフォルトの名無しさん

2007/10/14(日) 19:27:18

そんなに難しく考えなくともecma-262とかScalaがあるじゃないか。
両立は可能だ。

0707デフォルトの名無しさん

2007/10/14(日) 19:48:05

>>705
return method.invoke( obj, args );じゃなくて
return method.invoke( t, args );だわ
そういやobjはプロキシインスタンスだった

0708デフォルトの名無しさん

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]);
}
と変換されるという案が出てたはず。

0709デフォルトの名無しさん

2007/10/14(日) 19:53:00

>>708
CICEとBGGAごっちゃになってねーか？

0710デフォルトの名無しさん

2007/10/14(日) 20:54:04

>array.each{int item => total += item;}
こういう文は見慣れない奴はインデントに困るだろうな。

array.each{ int item =>
total += item;
}

0711デフォルトの名無しさん

2007/10/14(日) 21:15:14

array.each(
　　{int item => total += item;}
);

こういうインデントは？

0712デフォルトの名無しさん

2007/10/14(日) 21:35:40

>>711みたいに>>710のインデントを知らん奴がいるから混乱するんだ。

0713デフォルトの名無しさん

2007/10/14(日) 21:50:42

>>712
インデントにうるさいおまえと一緒だと疲れる

0714デフォルトの名無しさん

2007/10/14(日) 22:33:45

インデントにうるさい言語があったよな。おまえはそれを使ってればいい

0715デフォルトの名無しさん

2007/10/14(日) 22:53:03

ぱいそん

0716デフォルトの名無しさん

2007/10/15(月) 01:28:48

複人数開発でインデントにうるさいのは当たり前だろ。
コーディング規約なんだから。

0717デフォルトの名無しさん

2007/10/15(月) 01:54:18

インデントなんか IDE が勝手にするだろ。
保存時に規約に沿うように自動フォーマット。
気にすんのはエディタ使ってるおっさんだけだ。

0718デフォルトの名無しさん

2007/10/15(月) 11:38:51

改行位置は勝手にやってくれなくないか？

0719デフォルトの名無しさん

2007/10/15(月) 11:50:20

今時のIDEならやってくれなくなくない？

0720デフォルトの名無しさん

2007/10/15(月) 12:53:26

Eclipse使えば自動フォーマットもすごいカスタマイズできるよ。
改行の位置も、(俺はコードの単位を明示的に分けたいから有効にはしないけど）
設定すればできる、と思う。

0721デフォルトの名無しさん

2007/10/15(月) 16:43:38

既にインデントは「する」ものじゃなくて「される」ものだろ。
人間がやるのは、内容の記述だけで、その整形は完全にIDEまかせ。
でも、eclipseできれいにインデントできないって理由で、仮引数へのアノテーションをためらう本末転倒な俺ガイル

0722デフォルトの名無しさん

2007/10/15(月) 17:03:49

細かい事気にしすぎ。

0723デフォルトの名無しさん

2007/10/15(月) 17:35:52

>>721
見やすさのためのインデントはそれでいいんだけど、
Pythonのようなインデント自体が括弧の役割をする言語ではまた別の話だよね。

0724デフォルトの名無しさん

2007/10/15(月) 17:38:12

人の書いたプログラムなど見ないで済むように偉くなれ。

0725デフォルトの名無しさん

2007/10/15(月) 17:39:06

>>723
とは言っても、Pythonでも見やすいインデント、というのはあるわけで。

0726デフォルトの名無しさん

2007/10/15(月) 18:05:18

ト・コ・ロ・デ

JDK7 build22
ttp://download.java.net/jdk7/changes/jdk7-b22.html
ttp://download.java.net/jdk7/binaries/

SwingWorkerのスレッドプールを使う処理が書き直されたらしい。
シャットダウンフックを使うようになったとかなんとか。

0727デフォルトの名無しさん

2007/10/15(月) 18:40:16

Javaは原則フリースタイル系統の言語だし、インデントはどうでもいいと思うが？
コーディング規約が別にあるとかいうならそれに従うまでだし。

0728デフォルトの名無しさん

2007/10/15(月) 20:45:32

Cとかに比べれば相当コーディング規約はしっかりしてると思うが

0729デフォルトの名無しさん

2007/10/15(月) 21:48:21

しっかりしているのは認めるが、しかしそれは言語仕様ではない。
インデントも含めて、コーディング規約も次世代に入れて欲しいと願っているのだろうか。

0730デフォルトの名無しさん

2007/10/16(火) 01:17:12

>シャットダウンフックを使うようになったとかなんとか。
使い方によってはwinでコケまくりだな。

昔よくフォーラムで流れたjavawからシャットダウンフックが起動しないってのが復活するんじゃない？

0731デフォルトの名無しさん

2007/10/16(火) 03:00:16

>>729
そこまですると、やり過ぎではなかろうかと思う。
俺はとりあえず括弧とif, for, whileの書式さえ統一されてればいいと考えてる。

0732デフォルトの名無しさん

2007/10/16(火) 03:16:45

まあもういいんじゃないか。そのコーディングとらやの話は。

0733デフォルトの名無しさん

2007/10/16(火) 10:56:12

20年以上前、ACM SIGPLAN Noticeでも、
インデントの話は禁止になったことがある。

0734デフォルトの名無しさん

2007/10/16(火) 14:07:05

↓↓↓次世代Javaの動向↓↓↓

0735デフォルトの名無しさん

2007/10/16(火) 14:11:07

命名規則とインデントはどうやっても宗教戦争になっちゃうからね。

0736デフォルトの名無しさん

2007/10/16(火) 17:12:35

まあもういいんじゃないか。そのコーディング虎屋の話は。

0737デフォルトの名無しさん

2007/10/16(火) 21:26:53

コーディングとらやの羊羹

0738デフォルトの名無しさん

2007/10/16(火) 21:53:01

とらやの話か。

0739デフォルトの名無しさん

2007/10/17(水) 01:35:40

虎屋の話と聞いて飛んできますた。

0740デフォルトの名無しさん

2007/10/17(水) 01:51:43

どうしてこうも人は争いの種を作ってしまうんだろうか

0741デフォルトの名無しさん

2007/10/17(水) 01:56:03

Javaの世界なのにJava以外の前提（CやC＋＋）を持ち出したのが原因。

0742デフォルトの名無しさん

2007/10/17(水) 01:58:35

人は人、自分は自分。偉い人には分からないのです。

0743デフォルトの名無しさん

2007/10/17(水) 02:23:48

誰もC/C++の話はしてないが

0744デフォルトの名無しさん

2007/10/17(水) 02:37:55

で、次世代はどーくるわけよ？

0745デフォルトの名無しさん

2007/10/17(水) 05:04:25

>>742 偉い人には分かるんじゃないか？ん？

0746デフォルトの名無しさん

2007/10/17(水) 07:58:18

俺はJavaの標準コーディング規約には満足してるけどな。
C#の、先頭を大文字にする記法や、プライベートフィールドの先頭にアンダーバーを付ける記法に比べれば、
よっぽどスマートだよ。

0747デフォルトの名無しさん

2007/10/17(水) 08:49:20

Rubyを侮辱するのは止めてください。

0748デフォルトの名無しさん

2007/10/17(水) 11:36:31

ﾜﾛﾀ、Rubyのコーディング規約はそうなってるのかｗ

0749デフォルトの名無しさん

2007/10/17(水) 12:23:57

規約でなく、言語仕様だね。@で始まるとメンバフィールドになる。

0750デフォルトの名無しさん

2007/10/17(水) 13:07:54

大文字で始まるとimmutable。> Ruby

0751デフォルトの名無しさん

2007/10/17(水) 15:10:32

C#はVCと同じくMSのキモサモサが良く出ている言語だと思う

0752デフォルトの名無しさん

2007/10/17(水) 16:05:50

C#で画面を作るとコントロールを描画している過程が見えるからなぁ

0753デフォルトの名無しさん

2007/10/17(水) 16:13:23

C#出たころからｺﾞﾃｺﾞﾃとJavaにいろんな機能がつき始めたよな

0754デフォルトの名無しさん

2007/10/17(水) 16:16:12

最近のJavaは美しくないというか崩れてきてる感があるな

0755デフォルトの名無しさん

2007/10/17(水) 16:21:23

genericsとannotation(とprintf)くらいで十分だったのにな
静的型言語でgenericsなしとかﾊﾞｶじゃないかと思ってたが今はいらんのつけすぎ

0756デフォルトの名無しさん

2007/10/17(水) 16:38:36

まぁでも早くC#に追いついて欲しいとは思うし難しいところだ

0757デフォルトの名無しさん

2007/10/17(水) 16:38:40

>>754 具体的にどこ？
>>755 といっても数年後にはクロージャとかenumとか使うようになるよ。

0758デフォルトの名無しさん

2007/10/17(水) 17:27:17

今だに使われるFORTRAN77は不滅だよ

0759デフォルトの名無しさん

2007/10/17(水) 17:32:40

>>754
なんとなくだがいいたいことはわかる。初期の頃の簡潔さは失われつつあるからな。
それでも、頻繁にクロージャ用無名クラスを作ってるようなら、クロージャを導入する意味はあると思う。

0760デフォルトの名無しさん

2007/10/17(水) 19:16:44

クロージャは必須だろ。
プロパティは辞めて欲しいが。

0761デフォルトの名無しさん

2007/10/17(水) 20:38:25

プロパティを作ってほしいとも思うが、セッターゲッターと互換性のないプロパティ作られるのも困る

0762デフォルトの名無しさん

2007/10/17(水) 22:15:11

セッターゲッターと互換性あるプロパティって何？？？

0763デフォルトの名無しさん

2007/10/17(水) 22:20:36

obj.property = value; が obj.setProperty(value); に、
value = obj.property; が value = obj.getProperty(); に、
展開されるような構文糖プロパティの事じゃね？

0764デフォルトの名無しさん

2007/10/17(水) 22:31:18

バージョンアップする限りJavaは肥大し続ける。

Java自体が陳腐化するか、
言語として互換性を捨て新たな言語に生まれかわらないとな。

0765デフォルトの名無しさん

2007/10/17(水) 22:39:36

どれだけ互換性捨てるかにもよるけど、新たな言語に生まれ変わらせるぐらいなら
Javaを捨てて、JVM用の新言語を立ち上げた方が既存のプログラムに影響少ないし
過去のしがらみ捨ててドラスティックに変えられるしで、良いと思うがね。

0766デフォルトの名無しさん

2007/10/17(水) 22:47:09

それはまだとっておこう。

0767デフォルトの名無しさん

2007/10/17(水) 22:49:25

新たな言語になったって、
バージョンアップのたびに肥大化し続けるのは変わらんだろうし、
時間が経つにつれ陳腐化するのは止められないだろうし。

0768デフォルトの名無しさん

2007/10/17(水) 23:10:19

Javaのクロージャで拘束変数の扱いはどうするつもりだろ？
楽なのは匿名クラスと同じでstatic finalな定数だけにするか、
拘束変数は必ずコピーにする方法なのだけど。

0769デフォルトの名無しさん

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

0770デフォルトの名無しさん

2007/10/17(水) 23:51:32

BGGA だと、受け取り側が java.lang.RestrictedFunction しかうけとらねーよと明示しておけば、
final がついてない局所変数使ってるクロージャリテラルは変換できなくてコンパイルエラーになる
とか、そーゆー制限も考えられてるみたいだけど。

0771デフォルトの名無しさん

2007/10/18(木) 02:47:35

レキシカルクロージャがいいな。

javaはVMも言語もクラスファイル仕様も互換性確保は相当なものだが、ライブラリ詰め込みすぎが悪い。

#rubyは言語界のモルモン教

0772デフォルトの名無しさん

2007/10/18(木) 03:08:54

どの辺りがモルモンしてる？

0773デフォルトの名無しさん

2007/10/18(木) 11:08:02

製作者がモルモン教徒

0774デフォルトの名無しさん

2007/10/18(木) 18:24:15

というかruby信者がモルモン信者と同じ臭いがする。

0775デフォルトの名無しさん

2007/10/18(木) 20:37:37

Macユーザーで、はてなユーザーで、rubyユーザーでケータイがMEDIA SKINあたりだったら、
もう半径5mには入りたくない感じ。
聞きたくもない長所の押し売りをえんえんと聞かされそう。

0776デフォルトの名無しさん

2007/10/18(木) 20:49:07

それ、なんて宗教？

0777デフォルトの名無しさん

2007/10/18(木) 21:13:55

>>775
プログラマーはあんましMAC使わないとおもうんだが。

0778デフォルトの名無しさん

2007/10/18(木) 21:16:36

MacもWindowsも使う。

どれかしか使わないというのが、言語論争と同じく不毛な流れかな？
javaもrubyもperlもpythonも適材適所に使えばいいじゃない

0779デフォルトの名無しさん

2007/10/18(木) 21:45:47

>>778
たしかに其れが一番かっこいい。

0780デフォルトの名無しさん

2007/10/18(木) 21:59:27

rubyはperlとpythonのパラダイムに影響受けてるからそっちの分野に食い込んでくるんだよ無理やり。
rubyの影響を受けたGroovyは言語が止まってるから問題ないが。

結局、JRubyとGroovyとJythonはScripting APIに組み込まれるのかね？
要らん気がする・・・。

0781デフォルトの名無しさん

2007/10/18(木) 23:46:52

JavaFXは偉大

0782デフォルトの名無しさん

2007/10/18(木) 23:47:28

なにが？

0783デフォルトの名無しさん

2007/10/19(金) 00:04:32

手元にあればmac使いたけどな。
だけどwinの方が安いからmac使う機会がないだけ。

0784デフォルトの名無しさん

2007/10/19(金) 00:13:40

普通にlinux使えよ

0785デフォルトの名無しさん

2007/10/19(金) 00:16:36

linuxは普通なのか？

0786デフォルトの名無しさん

2007/10/19(金) 00:58:05

MacメインでWindowsも使うJava好きのモルモン信者ですが、何か？

0787デフォルトの名無しさん

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)

0788デフォルトの名無しさん

2007/10/19(金) 01:46:49

アホ。釣られんな。

0789デフォルトの名無しさん

2007/10/19(金) 02:05:16

>>777
君、アタマ悪イッショ。
オンモ二デテミ。
君ノ馬鹿サガ…

0790デフォルトの名無しさん

2007/10/19(金) 02:54:19

アホ。釣られんな。

0791デフォルトの名無しさん

2007/10/19(金) 09:53:36

モルモンっていうと家畜の内臓がどうしても思い浮かぶ

0792デフォルトの名無しさん

2007/10/19(金) 23:47:33

未だに1.6が出てなかったのか…＞Mac

0793デフォルトの名無しさん

2007/10/20(土) 00:26:03

酷い話でしょ？コミュニティに任せた方がいいような気がするよ。

0794デフォルトの名無しさん

2007/10/20(土) 00:34:37

MacでJavaってそんなに使われてる？

0795デフォルトの名無しさん

2007/10/20(土) 00:46:49

V2Cを動かすのに必須。
これが無くなるとMacを捨てなくては・・・とまでいう重要ソフト。

0796デフォルトの名無しさん

2007/10/20(土) 01:00:03

fx＋bbs2chreaderでいいじゃない

0797デフォルトの名無しさん

2007/10/20(土) 01:04:06

icedteaだっけ？フリー版のないのか

0798デフォルトの名無しさん

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

この辺りの改良でクライアントサイドの勢いがついてほしい所だな。

0799デフォルトの名無しさん

2007/10/20(土) 11:18:05

java6のSwingは、結構Windowsのクライアントサイドでも戦える形になってきたかなと思う。
5と6での差異なんて、数ドット単位のデザインの違いが主なんだけど、その数ドットの差が大きい。
あとはスプリットボタン、シェブロンあたりのウィジェットが追加されればなー。

0800デフォルトの名無しさん

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.

へー、便利じゃんって、オイッ！

0801デフォルトの名無しさん

2007/10/21(日) 01:14:37

このJVMは独自のプロセスでも動くので、
JVMがクラッシュしたとしてもブラウザには影響を与えません。

そんなに変か？

0802デフォルトの名無しさん

2007/10/21(日) 10:03:06

今まで、さんざんブラウザを巻き沿いにしてきたみたいだよなw

0803デフォルトの名無しさん

2007/10/21(日) 10:18:23

巻き添えっていうか、一気に重くなってその負荷で落ちたように見えることは多かったけど。
ブラウザとは別のプロセスで実行できるってセキュリティ的に大丈夫なんだろうか。
ただでさえVistaでUACとかいうややこしいシステムをとってるのに。

0804デフォルトの名無しさん

2007/10/21(日) 10:27:36

↑大丈夫だからやったんじゃないかね

0805デフォルトの名無しさん

2007/10/21(日) 11:47:14

>>803
まずくなる理由が見つからんが…

0806デフォルトの名無しさん

2007/10/21(日) 12:25:31

>>803
Javaアプレットは、なぜネットワークからダウンロードしてきたコードを実行しても
安全なのか知りたければ、「バイトコードベリファイア」「サンドボックスシステム」
について調べてみるといい。
そうすれば、別プロセスで動作させても安全な理由がわかる。

0807デフォルトの名無しさん

2007/10/21(日) 12:27:37

>>805
Vistaで導入された鬱陶しい機能の一つに、UACとかいうのがある。
これは、セキュリティ対策のために、ブラウザの権限を制限するもんだ。
だから、ブラウザ上から呼び出されたプロセスには、なにかと制限がかかる可能性がある。
特に、ローカルのリソースにアクセスするようなのは、実行できないかもしれない。

まあ、>>804のいうようにわかってやってるはずだから、対策がないわけがないんだけどね。

0808デフォルトの名無しさん

2007/10/21(日) 17:03:53

>>807
>Vistaで導入された鬱陶しい機能の一つに、UACとかいうのがある。
>これは、セキュリティ対策のために、ブラウザの権限を制限するもんだ。

それはIE7の「保護モード」であって、UACではない。

0809デフォルトの名無しさん

2007/10/21(日) 18:32:03

>>808
そうだった。
今思い浮かんだんだが、もしかして保護モードを回避するために別プロセスに分けたのか？
だとしたら、俺が言ってたことはまるで逆だったのか。

0810デフォルトの名無しさん

2007/10/21(日) 19:18:12

↑だからここは君の浅知恵を披露する場ではないようだが

0811デフォルトの名無しさん

2007/10/21(日) 20:14:23

なんで次世代Javaスレに猿が混じっているのか不思議

0812デフォルトの名無しさん

2007/10/22(月) 10:35:00

↑猿の脳みそを持つ男

0813デフォルトの名無しさん

2007/10/22(月) 11:58:57

↓ご立派な人登場。

0814デフォルトの名無しさん

2007/10/22(月) 14:32:22

呼んだ？

0815デフォルトの名無しさん

2007/10/22(月) 16:23:51

おいおい、俺を差し置いてか？

ゴスリンが、JDK on Mac OS Xについて少し喋ってる。
http://blogs.sun.com/jag/

0816デフォルトの名無しさん

2007/10/22(月) 16:52:06

イヤ待て、もっと大変な事言ってないか？
オレには、MacOSXにZonesが載るって書いてるようにも読めるぞ。
流れ的にそう明言してないが・・・

0817デフォルトの名無しさん

2007/10/22(月) 18:52:08

>>816
Zonesってなに？

0818デフォルトの名無しさん

2007/10/22(月) 18:59:43

スレ違いだが、
Solaris:BSD:Linux≒Zones:Jail:Vserver

0819デフォルトの名無しさん

2007/10/22(月) 22:37:44

ｚ

0820デフォルトの名無しさん

2007/10/23(火) 04:27:30

sunはJava SEの後につく数字をマイナーバージョンとリンクさせているように見えるけど、
メジャーバージョンが上がる時にはどうするつもりなんだろう。
Java 2 SEとかにするのかな

0821デフォルトの名無しさん

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"
・・・なんじゃそりゃ～

0822デフォルトの名無しさん

2007/10/23(火) 08:57:17

>>820
Java 2 Platform, Standar Editionとかぶりすぎ
>>821
そういうマイナーバージョンの桁上がりの問題じゃないからw

0823デフォルトの名無しさん

2007/10/23(火) 10:17:44

メジャーバージョンが上がるときの対策
・Javaのあとに新しいバージョンだとわかるようなコード・名前・別名をつける
・Java自体の名前がかわる
・何事もなかったかのようにバージョン表記統一

0824デフォルトの名無しさん

2007/10/23(火) 14:30:33

>>821
前にlinuxのソフトウェアでndiswrapperっていうのを使ってたんだが、
使用してるバージョンが1.7で、最新のバージョンが1.21だったのを1.2.1だと勘違いして
なんでバージョンダウンしてるのかすごい悩んだことがある。

0825デフォルトの名無しさん

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と予想。

0826デフォルトの名無しさん

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ビルドのペースが出てきたのは評価したい。

0827デフォルトの名無しさん

2007/10/31(水) 21:05:23

クロージャのプロトタイプ発表とかどうとかは、どうだった？

0828デフォルトの名無しさん

2007/11/09(金) 23:07:29

クラス注釈に@RAIIとかサポートされたらいいな。
必ずスタックに乗るように解釈させて、スコープ抜けると必ずfinalizeされる。
メンバ内も含めてthisが代入または引数にされた場合は、コンパイルエラーとするとか。

0829デフォルトの名無しさん

2007/11/09(金) 23:20:54

７は5よりもいろいろと、てこもりで楽しみだな。

0830デフォルトの名無しさん

2007/11/10(土) 01:50:16

>>828
C言語のregisterとかと同じで、最初のうちは最適化義務はなく将来対応するとか言っておいて、
そのうち最適化が進化したので必要ないから無視するよってなるような気もする。

0831デフォルトの名無しさん

2007/11/10(土) 05:06:57

なんかもうJavaはIDE前提の言語として突き進んでほしいなあ。
言語仕様もとにかくIDEでサポートしやすい方向で。

0832デフォルトの名無しさん

2007/11/10(土) 09:24:07

>>828
finalizeされるタイミングを陽に指定できることは除いて、
今やescape解析の仕事です。
そんな時代遅れなものが入るわけがない。
>>831
馬鹿丸出し。

0833デフォルトの名無しさん

2007/11/10(土) 11:27:07

>>832
ゴスリングのこの発言があったタイミングで
バカ丸出しと脊髄反射するほうがバカ丸出し
http://www.atmarkit.co.jp/news/200711/07/techday.html

0834デフォルトの名無しさん

2007/11/10(土) 11:50:46

そんなの知ってるw
その解釈こそ馬鹿丸出しじゃん。
IDEで出来ることは、IDEでやればいいんだから。
言語を糞仕様にする必要はない。

0835デフォルトの名無しさん

2007/11/10(土) 13:04:43

>>194
Jakarta JJarのことか？
MavenにもJJarは同梱されているんだが

0836デフォルトの名無しさん

2007/11/10(土) 13:19:03

SunはSolaris向けのIPSを発表したしなあ。
http://opensolaris.org/os/project/pkg/documents/

最近、言語ごとにパッケージ管理/配布システムがあって困惑気味です。

0837デフォルトの名無しさん

2007/11/10(土) 19:31:56

ここにはエスケープ解析を研究してる奴いるから聞きたいことあれば聞いとけ。

0838デフォルトの名無しさん

2007/11/10(土) 20:58:50

Googleで検索すればすぐでてくる内容しか書かれてないのに研究だと？

0839デフォルトの名無しさん

2007/11/11(日) 06:30:11

クロージャの演算子 => , {int=>int}は他のなかったのかな？もう決定ぽいけど。
{int x=>x+1}とかぱっと見どうかと

0840デフォルトの名無しさん

2007/11/12(月) 15:07:20

lambda見なれてしまったから、他はなんでも違和感がある。
だからどうでもいい感じ。lambdaキーワードはあり得ないし。
Haskellみたいに\ってのもどうかと思うしさ。

0841デフォルトの名無しさん

2007/11/12(月) 23:40:09

>>839
1.5がでるときにGenerics見て、こんなのJavaじゃねぇって書き込みがいくつかあったよな
今、そんなこと言ってる奴いないだろう。慣れればそれが普通に見えてくるはず

0842デフォルトの名無しさん

2007/11/13(火) 00:10:57

プロパティのアクセス演算子は
c->p=x
x=c->p
で決定なのか？

0843デフォルトの名無しさん

2007/11/13(火) 00:40:12

>>842
いつの情報だ、それは。

0844デフォルトの名無しさん

2007/11/13(火) 01:03:03

結局Javaっていっても現状Web用途がメインなんだから
Servlet&JSPのほうがもっと良くなってほしい。

JSPがダメすぎてどうにもならない。

0845デフォルトの名無しさん

2007/11/13(火) 01:08:22

JSP、JSF、VelocityServlet、Wicket・・・好きなもの使え。

0846デフォルトの名無しさん

2007/11/13(火) 01:10:41

>>844
ここはSEのスレなんだよ。
そんな呆けだから(ry

0847デフォルトの名無しさん

2007/11/13(火) 01:36:26

>>843
え、古かった？
じゃ、今はなんだよ

0848デフォルトの名無しさん

2007/11/13(火) 02:20:28

>>846

ていうか標準のView仕様くらいもうSEに含めろっちゅう話やねん。
JSPにしても単なる条件分岐記述するのに別ライブラリダウンロードさせるってどないやねんって話やねん。

スクリプティングサポートする暇あったらテンプレートエンジンサポートしたほうが人気出るねん。

0849デフォルトの名無しさん

2007/11/13(火) 02:29:59

スクリプトレットの存在も知らなければ
テンプレートエンジンはスクリプトエンジンのひとつに過ぎないという実態も知らないのか？
テンプレートエンジンなんぞとっくにサポートされてるっての

0850デフォルトの名無しさん

2007/11/13(火) 02:39:48

>>849

おい、JSP2.1の時代にスクリプトレット使ってんのかよ・・・

0851デフォルトの名無しさん

2007/11/13(火) 02:41:43

お前が使いたいだけだろ、お前って御託だけで使い分けもできないのな

0852デフォルトの名無しさん

2007/11/13(火) 02:45:42

Java系の開発者って世の中のニーズが読めないやつばっかだよな・・・

0853デフォルトの名無しさん

2007/11/13(火) 02:51:53

典型的なかまってちゃんだな、JCPのこと調べたらJavaは諦めてPHPでもやっとけ

0854デフォルトの名無しさん

2007/11/13(火) 02:59:26

どっちにしろDerbyなんかSEに組み込むより、Viewのほうが先だろ・・・常識的に考えて・・・

0855デフォルトの名無しさん

2007/11/13(火) 03:01:41

かまってちゃんとわがままちゃんって同じ匂いがするんだよな。２ｃｈの経験上

0856デフォルトの名無しさん

2007/11/13(火) 04:23:08

>>848
頭悪～
Web制作板に行きなよ。
このスレはまだ早いよ。

0857デフォルトの名無しさん

2007/11/13(火) 15:25:07

>>82
これには何かぐっと来たぞ

0858デフォルトの名無しさん

2007/11/15(木) 01:06:38

>>854
ViewならSwingがあるじゃねぇか。

0859デフォルトの名無しさん

2007/11/15(木) 01:08:16

お前らこれ以上XSLTさんを泣かすな
名実ともにSEのViewだろ

0860デフォルトの名無しさん

2007/11/16(金) 18:41:58

名実が伴っているなら泣くこともないだろうw

0861デフォルトの名無しさん

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); したい。

0862デフォルトの名無しさん

2007/11/23(金) 19:04:27

D言語にある機能だってのは知ってるけど、この機能の初出って何だろうね

0863デフォルトの名無しさん

2007/11/23(金) 19:14:58

そう書くことで綺麗に気持ちよく書けるものはどれくらいあるのかね

0864デフォルトの名無しさん

2007/11/23(金) 19:27:54

>>863
java.util.List みたいな published interface にメソッド追加するのが主な目的ってのはいわずもがなだけど。
他の使い道ってなんかあるかね？

0865デフォルトの名無しさん

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);

0866デフォルトの名無しさん

2007/11/23(金) 20:02:23

>>865
char[] はともかくとして、String も StringBuilder も StringBuffer も、
codePointCount や codePointAt を持ってるはずだぞ。
CharSequence で持ってないのって java.nio.CharBuffer ぐらいか？

0867デフォルトの名無しさん

2007/11/23(金) 20:02:25

こんなダサイの入れるくらいなら、
Haskellのtype classとかC++のconceptみたいな
generic programming支援の機構を入れて欲しいわ。

0868デフォルトの名無しさん

2007/11/23(金) 20:24:34

interfaceで扱う事に意味があるんじゃないの。例えばC#だけど
List<E>.ForEach(delegate(E)) みたいなのがあるけど、IList<E>じゃ使えなくて困惑したことがある。

重複したときはエラーかオリジナルのオーバーロードどちらを優先するんだろう。
interfaceのままでもリフレクションで解決とかもいいけど、それは遅くなるか。

0869デフォルトの名無しさん

2007/11/23(金) 20:35:45

>>868
それは published interface の話じゃなくて？

そーいや、C# は 3.0 で extension method 入るんじゃなかったか？

0870デフォルトの名無しさん

2007/11/23(金) 20:59:46

static importはIDEと相性が悪い印象があってあまり使われてないけど
これが導入されたらIDEに第一引数でサーチいかせる感じで使われ出すんじゃないかな。

0871デフォルトの名無しさん

2007/11/23(金) 21:29:37

やっぱpublished interfaceにメソッド追加（したように見せかける）以外に使い道ないんじゃ？

0872デフォルトの名無しさん

2007/11/23(金) 21:56:47

内部構造はまったくいじれないしな

0873デフォルトの名無しさん

2007/11/25(日) 22:09:42

Javaってプライドとかないの？

0874デフォルトの名無しさん

2007/11/25(日) 22:19:37

ttp://java.sun.com/javase/ja/6/docs/ja/api/index-files/index-16.html
無いね。Java7 でもきっと無い。

0875デフォルトの名無しさん

2007/11/25(日) 22:19:46

Javaのプライドって何のプライドよ？

0876デフォルトの名無しさん

2007/11/25(日) 23:24:42

言語としてのプライド

0877デフォルトの名無しさん

2007/11/25(日) 23:27:34

なんかアホの子が出現してるな

0878デフォルトの名無しさん

2007/11/26(月) 11:50:05

>>861
> これって名前空間汚れるような。

その点、リンク張られているExpanderの方がまだいいね。

0879デフォルトの名無しさん

2007/11/26(月) 13:59:55

>>875
Java使いが集まって、大晦日に闘う。

0880デフォルトの名無しさん

2007/11/26(月) 14:17:23

Gosling緊急参戦！

とかなら見に行く。

0881デフォルトの名無しさん

2007/11/26(月) 14:50:30

>>879
冗談としては面白くないけど
本当にやったら面白そうだな、それ。

0882デフォルトの名無しさん

2007/11/26(月) 17:48:38

>>881
想像したらわろた

0883デフォルトの名無しさん

2007/11/26(月) 18:07:02

>>879
何で戦うんだよwwwコーディングかwww

0884デフォルトの名無しさん

2007/11/26(月) 19:52:13

JavaOne Tokyoのときみたいに、プロレス

0885デフォルトの名無しさん

2007/11/26(月) 22:05:45

そうね、ここはコーディングでといいたいところを
ぐっとこらえて、総合ルールでやってもらった方が
盛り上がるね！

0886デフォルトの名無しさん

2007/11/26(月) 23:12:33

じゃあ多重継承もfriendも属性も継続もありでいいんだな。

0887デフォルトの名無しさん

2007/11/26(月) 23:14:37

属性って？ annotation じゃダメなん？

0888デフォルトの名無しさん

2007/11/27(火) 10:35:10

>>880
Goslingが和太鼓たたきながら、
「本物のプログラマでてこいや！」

0889デフォルトの名無しさん

2007/11/27(火) 11:18:22

本物のプログラマはPascalを使わない―――Javaも使わない。きっと。

0890デフォルトの名無しさん

2007/11/27(火) 18:39:40

本物のプログラマだなんてガキみたいなこと言ってるうちは、
その本物のプログラマなるものにはなれんだろうな

0891デフォルトの名無しさん

2007/11/27(火) 18:57:17

何を使うんだろう。やっぱりLisp？

0892デフォルトの名無しさん

2007/11/27(火) 19:37:41

>>890
本物のプログラマネタくらいは知っておこうぜ、本物のプログラマならｗ
ググればすぐに出てくるよ

0893デフォルトの名無しさん

2007/11/27(火) 19:37:47

ホンモノのプログラマになる極意は、ホンモノの真似をしないことである

0894デフォルトの名無しさん

2007/11/28(水) 17:06:57

ふるいネタだな。キッシュを食わないとかいうヤツだっけ。

0895デフォルトの名無しさん

2007/11/28(水) 22:21:39

ホンモノのプログラマはデスマーチで2chに書く暇などありません。

偽者の人生が楽しい

0896デフォルトの名無しさん

2007/11/28(水) 23:07:44

業務が設計中心になってからはデスマはないなぁ。
設計工程に現役プログラマが携わらないことの危険性が
頭でもなく心でもなく体で理解したｗ

0897デフォルトの名無しさん

2007/11/29(木) 01:38:43

よほどヘボいSEとやってたんだな。

0898デフォルトの名無しさん

2007/11/29(木) 13:16:30

プログラマーは設計書が全然上がってこねーぞと文句を言っているはず
デスマの原因作ってるのはお前だｗ

0899デフォルトの名無しさん

2007/11/29(木) 21:09:42

↑こいつ文盲？

0900デフォルトの名無しさん

2007/11/29(木) 21:13:46

うん

0901デフォルトの名無しさん

2007/11/29(木) 22:11:53

宣言側の拡張メソッドだってさ。
http://digital-sushi.org/entry/declaration-site-extension-methods/

ユーザ側で拡張すると、メソッド名の衝突とか面倒くさいって話らしいけど。

0902デフォルトの名無しさん

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();

したとき、どっちのメソッド呼ぶかって曖昧さが残るわな。

0903デフォルトの名無しさん

2007/11/30(金) 01:37:50

曖昧な場合はコンパイルエラーになるだけ

0904デフォルトの名無しさん

2007/11/30(金) 02:11:30

>>901
馬鹿馬鹿しい…

0905デフォルトの名無しさん

2007/11/30(金) 02:20:12

>>903
いや、use-site でも declaration-site でも曖昧なケースが出てくるのは同じじゃねーかって話。

0906デフォルトの名無しさん

2007/11/30(金) 22:05:42

LINQのような糖構文がほしい・・・

やっぱいらない

0907デフォルトの名無しさん

2007/11/30(金) 23:13:41

ハイバーネートだかなんだかのO/R マッピング使ったらええんとちゃう？
俺もLINQはいらんけど、varはほしいな。

0908デフォルトの名無しさん

2007/12/07(金) 14:03:49

JDK7 build24
ttp://download.java.net/jdk7/binaries/
ttp://download.java.net/jdk7/changes/jdk7-b24.html

あれ？変更点からっぽ？

0909デフォルトの名無しさん

2007/12/07(金) 16:32:16

>>906
今更だが、糖衣構文を糖構文とは略しないでしょ。

0910デフォルトの名無しさん

2007/12/07(金) 17:05:48

syntax sugarを糖構文と訳すのはアリだと思うが。

0911デフォルトの名無しさん

2007/12/07(金) 17:08:07

>>910
マジすか・・・。略語じゃなくて訳の違いだったわけか。

0912デフォルトの名無しさん

2007/12/07(金) 18:35:49

「糖衣構文」と「構文糖」は聞いたことあるけど「糖構文」はあまりないな。

0913デフォルトの名無しさん

2007/12/07(金) 18:35:52

>>910
うーん、それはやめた方がいいと思う。
糖衣構文がうざければ、シンタックス・シュガーでいいし。

0914デフォルトの名無しさん

2007/12/07(金) 21:23:36

>>908
JDK6u3と比べて、アプリケーションのメモリ消費量が減っているような気がする。

0915デフォルトの名無しさん

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

0916デフォルトの名無しさん

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

0917デフォルトの名無しさん

2007/12/11(火) 13:17:01

>>905
あれって use-site でというか、static import で use-site extension methods やると
既存の static import 使ってるコードで問題出るかもって話じゃないの？

0918デフォルトの名無しさん

2007/12/11(火) 13:56:19

>>916
ナルホド。開発者の使ってる環境が知りたいな。GUI無しかな？
Teamwareとコマンドラインの体系は似てるし、CUIベースでかな？
それとも開発者は、Netbeans使ってるから最近出てきたMercurialのプラグイン使ってる？

0919デフォルトの名無しさん

2007/12/21(金) 12:17:34

まだ草案レベルにもなってない例外関連のアイデアらしい
http://www.javac.info/Multicatch.html
http://www.javac.info/Rethrown.html

multicatchは欲しい。
multicatchがあれば、rethrownはいらないような気もする。

0920デフォルトの名無しさん

2007/12/21(金) 12:32:25

"Exception1 | Exception2" って型ができるのかとおもうと、おらわくわくして（ｒｙ
型とか安全なのかな。とりあえず実現できなくはないと思うけど。

0921デフォルトの名無しさん

2007/12/21(金) 12:47:57

基本的には「複数の catch節をくっつける」ってアイデアで
型安全どーするの？とかの問題は先送りされてるんじゃね？

Exception1 | Exception2 って型も共通の親クラスのメソッドしか
呼べないんじゃないかと思ってる。下手にcatch節以外でも
Exception1 | Exception2って型が使いたいとか騒ぐと、
仕様考える連中が面倒になってポシャるんじゃないかなとか思ったり思わなかったり。

っつーか、Rethrown はその辺が面倒になったから出てきたアイデアなんじゃ？

0922デフォルトの名無しさん

2007/12/21(金) 16:49:50

catch(Exception1 | Exception2 ex) { ex.Foo(); }

から

catch(Exception1 ex) { ex.Foo(); }
catch(Exception2 ex) { ex.Foo(); }

は機械的に作れるから、まあ何とかなるんじゃない？

0923デフォルトの名無しさん

2007/12/21(金) 17:24:21

複数の例外型について handler_pc の位置を共通にするようにするんかと思ってた。

VM仕様で handler_pc はユニークにしろ、とかって制約ついてたっけ？

0924デフォルトの名無しさん

2007/12/23(日) 21:24:10

ConcurrentHashMap<CustomKey<Exception, Handler>, Executor<Runnable>> とかすればいいと思うよ。

0925デフォルトの名無しさん

2007/12/29(土) 10:41:26

http://www.infoq.com/jp/news/2007/12/closures-preserving-feel-of-java
クロージャ入れるのも一苦労じゃ

0926デフォルトの名無しさん

2007/12/29(土) 11:01:42

おれクロージャいらねぇ派だがどうせ新機能入れるなら個人的には多値返却かAda風の型定義がほしいかな。

0927デフォルトの名無しさん

2007/12/29(土) 12:01:37

皆でScalaへGO!

0928デフォルトの名無しさん

2007/12/29(土) 12:28:15

そーいや、ム板にscalaスレあったっけ？

0929デフォルトの名無しさん

2007/12/30(日) 00:05:55

C#3.0さわってみたが進化してるなあ。
lambda関数が int a => return a + 10 みたいな感じでインラインに書けたりと、
スクリプト言語ラブな人は嬉しい機能がどっさり。
思わず浮気しそうになる・・・。

0930デフォルトの名無しさん

2007/12/30(日) 00:22:31

>>929
> lambda関数が int a => return a + 10 みたいな感じでインラインに書けたりと、
これreturn要らないんじゃ？

BGGAのクロージャの構文、セミコロンがついたりつかなかったりで
局所リターン文だったり単なる式文だったりっつーのはバグの原因になりそうな。
ラムダ式っぽく使うならreturn書きたくないってのもわかるんだけど……
その点、C#の構文はよくできてると思う。

0931デフォルトの名無しさん

2007/12/30(日) 00:55:17

その程度ならecma262で十分。

0932デフォルトの名無しさん

2007/12/30(日) 01:05:59

>>930
それだけじゃなくて、C#3.0のラムダ式で int a みたいにパラメタ型を明示する場合はパラメータリストに括弧が必要なはず。

0933デフォルトの名無しさん

2007/12/30(日) 03:15:35

>>926
それだとクラスを返しても全く同じだけど、どう違いをみせたいわけ？

0934デフォルトの名無しさん

2007/12/30(日) 10:22:01

>>933
戻り値のためにクラスをわざわざ定義するのがめんどいんじゃね？
シンタックスシュガーとしてやってくれると、ちょっと便利かもね、と。

0935デフォルトの名無しさん

2007/12/30(日) 10:52:00

>>928
ちょっと前に探したときは見当たらなかった。

0936デフォルトの名無しさん

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との連携除いても、結構いい型システム持っているけど、
単独ではすぐに落ちちゃうと思う。

0937デフォルトの名無しさん

2007/12/31(月) 16:42:52

>>934
同じくタプルとかも賛成なんだけど、どうもそういうのはJavaぽくないみたい。
面倒だしとかじゃ「違う言語で」とかだから、だから「どう違いをみせたいわけ？」って聞いてる。

少なくとも君の要求ていどならわざわざ文法とか複雑にしなくとも、
Object[] func()
でこと足りるしｗ

0938デフォルトの名無しさん

2007/12/31(月) 16:58:01

多値用のGenericsを標準で用意してくれると嬉しいんだけどね。
こっちで用意してもいいけど、それ専用のjarってのもちょっとね。

0939デフォルトの名無しさん

2007/12/31(月) 18:28:14

前も出たなこの話題w
俺にいわせりゃ多値引数はあるのに多値返却がないのはおかしいんだけどな
クロージャとかの方が違う言語でやってほしいよ。javaがシンプルさとかけ離れていく

0940デフォルトの名無しさん

2007/12/31(月) 18:44:28

クロージャって匿名クラスで作るんだろ？
クロージャの生成側のローカル変数は、その時点で固定になるのかな？

0941デフォルトの名無しさん

2007/12/31(月) 19:08:51

>>940
そのやりかたが2つくらい出てきてどっちにするかまだ決まってなかったんじゃなかったっけ？

0942デフォルトの名無しさん

2007/12/31(月) 19:23:38

>>769 あたりか。

0943デフォルトの名無しさん

2007/12/31(月) 19:32:57

あら、割と近めにあったのね。すまんこつ。

0944デフォルトの名無しさん

2007/12/31(月) 19:35:51

可変長引数を多値引数って言うのは初めてみたかも。

0945デフォルトの名無しさん

2007/12/31(月) 20:18:52

可変長引数のこと言ってたのか。

0946デフォルトの名無しさん

2007/12/31(月) 20:21:18

たぶん。

いや、はじめてみた言葉だから間違ってるかも知らんけど。

0947デフォルトの名無しさん

2007/12/31(月) 20:32:39

すまん今作った＞多値引数
とっさに出てこなかったんだよ

0948デフォルトの名無しさん

2007/12/31(月) 20:39:13

オーバーロードのことじゃなくて？

0949デフォルトの名無しさん

2007/12/31(月) 20:44:29

単純に引数を複数渡せるってだけの話だろ

0950デフォルトの名無しさん

2008/01/01(火) 03:36:41

>>949が正解だろ。
単純に引数(インプット)には複数の値を渡せるのに、
返値(アウトプット)が一つしか返せないのはおかしい、という話。

そもそも、大元の関数型言語が(厳密には違うが)一入力一出力だったのを、
手続き型言語で使いやすいよう多入力にしたのが原因。
OOPの思想が確立したときに多出力にすればよかったのだが、折しもCベースのC++が主流だったのでそのまま。
またCPUの最適化の関係もあり、ずるずるとJava, C#・・・と今に至る。

もしJavaで多出力をサポートするなら、
rubyやpythonの返値の扱い（タプル関連)で、シンタックスシュガーが複雑になりすぎてる感があるので、(特にruby)
Javaが簡潔かつわかりやすい書式（もしくはタプルに代わる概念)を策定して欲しい、と思う。

0951デフォルトの名無しさん

2008/01/01(火) 10:04:29

単純に引数1個に制限すれば、対称になって>>950の気は済むってこと？

0952デフォルトの名無しさん

2008/01/01(火) 13:43:46

もはや return は継続の呼び出しで良くね？

0953デフォルトの名無しさん

2008/01/02(水) 13:56:26

＞Javaが簡潔かつわかりやすい書式（もしくはタプルに代わる概念)を策定して欲しい、と思う。

結局それかよ。それを策定するのが難しいからないんだろ！
おまえが考えて提案したらどうだ？当然英語はできるよな？
面倒って言うのが理由なら、あまり期待しないほうがいいじゃないか。
それと>>950はツッコミどころが多すぎだけど、
JavaはC++辺りと違って理念が実稼動重視（現実的)だから。

>>951もいいと思うよ。でも

Object[] func(Object[]);

で十分。JDK1.0 OK
有用であるが、使うかどうかは任意。

0954デフォルトの名無しさん

2008/01/02(水) 14:05:23

>>953書いて思ったけど、
というか普通にポインタ(C, C++)理解してるかってことに行き着くと思うよ。
本質的には、ポインタとかデータ構造とかそういうところ。

0955デフォルトの名無しさん

2008/01/02(水) 16:52:28

ポインタ関係ないな。
参照でいい。

0956デフォルトの名無しさん

2008/01/02(水) 17:21:18

It is assumed that many value return was realized by JAVA and on earth wants to do what?

0957デフォルトの名無しさん

2008/01/02(水) 19:02:07

新年早々とんだ釣りだw

0958デフォルトの名無しさん

2008/01/02(水) 19:15:55

そうするに偉そうなこといってる>>953はようやくポインタを理解したガキだってこと？
Object[]で戻していいが型の安全を言語側で保証できたらいいねって話なんだが

0959デフォルトの名無しさん

2008/01/02(水) 19:33:42

>>958
痛いおまえはｗｗ晒しあげｗｗ

0960デフォルトの名無しさん

2008/01/02(水) 19:42:24

また宗教ですか？

0961デフォルトの名無しさん

2008/01/02(水) 19:49:45

>>958
当然英語はできるよな？

0962958

2008/01/02(水) 19:59:22

おいおいなんだこれ('A`)
>JavaはC++辺りと違って理念が実稼動重視（現実的)だから。
>というか普通にポインタ(C, C++)理解してるかってことに行き着くと思うよ。
こういうのはスルーして俺に総ツッコミかよw

0963デフォルトの名無しさん

2008/01/02(水) 20:00:23

ストールマンのお友達ですか？

0964デフォルトの名無しさん

2008/01/02(水) 20:03:50

>>958
>>962
英語は当然できるんですか？

0965デフォルトの名無しさん

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が何を言ってるのかはさっぱりわからんが、他人の英語の能力に並々ならぬ関心があることだけはわかった。

0966デフォルトの名無しさん

2008/01/02(水) 23:04:05

>>953
> それと>>950はツッコミどころが多すぎだけど、
> JavaはC++辺りと違って理念が実稼動重視（現実的)だから。

C言語のソースがそのままコンパイルできるC++を差し置いてJavaのどこが”実稼働重視(現実的)”なんだww
もしかしてC++をまったくさわったことがないんだろうか？

それと>>950のツッコミどころとやらを説明よろしくww

0967958

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は俺じゃねーけど）

0968デフォルトの名無しさん

2008/01/03(木) 00:35:05

他でやれよもう。

0969デフォルトの名無しさん

2008/01/03(木) 01:59:17

苦労じゃのう

0970デフォルトの名無しさん

2008/01/03(木) 06:43:34

ストールマンじゃないです。
ゴズリンと友達です。

0971デフォルトの名無しさん

2008/01/03(木) 06:48:51

英語で会話できるようになるのは、日本人の夢なのです！
ジーニアス、ジーニアス！

0972デフォルトの名無しさん

2008/01/03(木) 06:51:34

>>966を読んでみても、相当痛いやつだなということだけは分かるw
30台は間違えないねｗ

この様子ならすぐ1000行くけど？どうする？やっちゃう？

0973デフォルトの名無しさん

2008/01/03(木) 07:30:05

>>962
>>966
おまえに勝ち目はないなｗ
そろそろ目を覚ませよｗ

0974デフォルトの名無しさん

2008/01/03(木) 07:40:36

馬鹿の方が声がでかいのは、ゴミ溜めではよくあること。

0975デフォルトの名無しさん

2008/01/03(木) 09:02:58

それをどうするかが問題なんじゃないか？

0976デフォルトの名無しさん

2008/01/03(木) 10:55:17

また宗教ですか？

0977デフォルトの名無しさん

2008/01/03(木) 11:32:48

英語は出来て当然です。

0978958

2008/01/03(木) 12:24:52

ごめんなさい勝ち目はありませんでした。
今目を覚ましました。

0979デフォルトの名無しさん

2008/01/03(木) 12:30:35

次スレ
[Java SE 7] 次世代Javaの動向 6 [dolphin]
http://pc11.2ch.net/test/read.cgi/tech/1199330977/

0980デフォルトの名無しさん

2008/01/03(木) 12:43:57

「間違いない」を「間違えない」と書くやつがまだいるのか
どこの方言だ？

0981デフォルトの名無しさん

2008/01/03(木) 15:46:40

>>978
早ｗ

0982デフォルトの名無しさん

2008/01/03(木) 15:57:34

英語は出来て当然です。

0983デフォルトの名無しさん

2008/01/03(木) 15:58:57

今目ってなに？

0984デフォルトの名無しさん

2008/01/03(木) 15:59:01

技術書の英語は読みやすいからな
詩を書けと言うと無理だが

0985デフォルトの名無しさん

2008/01/03(木) 16:08:34

英語って読むだけじゃなくて書けないとダメなんじゃないか？おじさん英語じゃあるまいしw

0986デフォルトの名無しさん

2008/01/03(木) 19:00:42

>>984
Full in care, car was to became miss note.

0987デフォルトの名無しさん

2008/01/05(土) 01:02:20

This if a pen.

0988デフォルトの名無しさん

2008/01/05(土) 01:54:33

>>986
To be,To be,Ten made To be

0989デフォルトの名無しさん

2008/01/05(土) 16:28:25

エリート狂想曲ﾅﾂｶｼｽ

0990デフォルトの名無しさん

2008/01/06(日) 10:35:13

てｓｔ

0991デフォルトの名無しさん

2008/01/06(日) 23:36:15

あれで夢精を覚えた

レス数が950を超えています。1000を超えると書き込みができなくなります。