隼(1.4)から虎(1.5)へ〜JDK1.5について！

　　　　　　　　　　　　　;∵;,".　　;；∴”:ﾟ・,'.ﾟД;∵ζ;,".
　　　　　　　　　　　　　　　　　;∵;,".;；∴”:ﾟ,'.　　）;∵;,".
　　　　　　　　　　　　　　　　　　;∵;,".　 /　　　ヽ
　　　　　　　　　　　─　＿-　 ;∵;,".　 ./　　 /| ..|
　　舞えやぁ！　　　-─_｀;,　　 　　　/ 　　 | ..| │←>>C#＆Anders Hejlsberg
　　　　　　　　　　　　ヽ　 ゝ　　″　 ／ |　　| ..|　|
　　　　　　　　　　　　 .|　 │　∵;／　／|　│　巛
　　　　　∧　∧　　　　|　　|　 ／　／　 |　 .| 　　　　　
　　　　（　ﾟ∀ﾟ）､　　　/ 　 /⌒　／ 　　.｛　│
　　　＿」＿ノ　丿　 /　. /　 　　　　　　 |　 |
　　（＿_＿＿／ヽ ノ　 ./ 　　　　　　　 （　　）
　／　／＼ 　　　 　 　/　　　　　　　　 　￣
(＿／　　 ..＼　　 /ノ
　　　　　　 　|　　 |
　　 　　　　 /　　/
　　　　　　../　　/
　　 　　 ／　 ／
　　　 ／　 ／
　 .　（＿_ノ
　　　　　　　　　　　　　　　　　　──────────
────────　　　　　　　　　　──────

　　　　　　　　　■■■■■
　　　　　　■■■　　　　　■■
　　　　　■■　　　　　　　　　■■
　　　■■■　　　　　　　　　■■■
　　　■■■　　　　　　　　　　■■
　　　■■■■　　　　　　　　　■■
　　　　■■■　　　　　　　　　■■
　　　　　　　　　　　　　　　　　■■
　　　　　　　　　　　　　　　　■■
　　　　　　　　　　　　　　　■■
　　　　　　　　　　　　　■■
　　　　　　　　　　　　■■
　　　　　　　　　　　■
　　　　　　　　　■■
　　　　　　　■■
　　　　　　■　　　 ∧ ∧　　　 　 ■　　■■■ 　　　■■■■　　■■■■■
　　　　■■　　　　(*ﾟーﾟ)　　　　 ■ 　■　　　　　　　■　　　　　　 ■　 ■　 ■　　
　　　■■　　　　　(∩∩)　 　 ■■　■　　■■■　■■■　　　　　　 ■
　　　■■■■■■■■■■■■　■　　 　■　　 ■　　　　　　　　　 ■
　　　■■■■■■■■■■■■ 　■■■■　　 ■■■■　　　　　■

リンク
http://servlet.java.sun.com/javaone/sf2003/conf/sessions/display-1540.en.jsp
http://java.sun.com/features/2003/05/bloch_qa.html

ｵﾅﾆｰｽﾚ立てんなよJava厨

Project Rape

別にスレを立てるなとは言わんが、まじめにやれや >>1

うっせぇﾎﾞｹ

前スレ
【祝】 JDK 1.4 βリリース
http://pc2.2ch.net/test/read.cgi/tech/990949654/

関連スレ
【猿が】JavaﾆGenericsﾊ不要 【ｿｰｽ汚す】
http://pc2.2ch.net/test/read.cgi/tech/1055519583/

何が変わったの？

　　　 　∧∧Λ
ﾋﾟｭ.ｰ　(　゜∇゜ ）つ ＜>>9　まあ、たとえば<Integer>とかが使える（゜∇゜）/
　　＝〔~∪￣￣〕 　　
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　「ウンマンコ」

>>9
C#っぽくなった

　　　　　　　　　　　　 ＿_
　　　　　　　　　 　 　 　 /〃　┼‐┼〃＿＿
　　　　　　　　　　　　　/＼　　　 ノ　　　　　　　　　　　　 　　 __
　　　　　　　　　　　　　　　　　　　　　　__　　, -――-、　　/＼ﾉ
　　　　　　　　　　　　　　　　　　　　　 ヽ/＼l::::::::::::::::::::＼ /: : /
　　　　　　　　　,..-―-､／）　　　　　　　|: : :|::::::::::::::::::::::／: : /
　　　　　／⌒Ｙ　　　　（_ノ　 /） 　 　 　 |: : :|:::::::::::::::::::::|: : : /
　　　　　￣l￣l､　　　　 ） ／｀〉　　　　　ヽ:: :|::::::::::::::::::::l: : :/
　　 　 　 　 l: : :｀ー--‐'‐'´: :/　 　 　　　　＼|∧ハ/l／: ::〈
　　　　　　　＼: : : : : : : : : :く　　　　　　　　　|: : : : : : : : : : ｀ー-┐　　,.､
　　　　　　　　　l: : : : : : : : : :｀ー―┐ ,､　　　|: : : : : : : : : : : : : : |二lニﾉ
　　　　　　　　　ヽ.: : : : : : : : : : : : : :|ニﾉ　　　|: : : : : : : : : : : : : : |
　　　　　　　　 　 ヽ: : : : : : : : : : : : :|　　　　　 ヽ: : : : : : : : : : : ／
　　　　　　　　　　　＼: : : : : : : : :／　　　　　　　＼ : : : : : : ／
　　　　　　　　　　　　 ￣￣￣￣　　　　ノ|　　　　　￣￣￣　　　　　　　ノ）
　　　　　　　　　　　　　　　　　　　ノしノ　 し'（　　　　　　　　　　　ノ)__ノ　（ノ(

23 名前：名無しさん米国がえり　[] 投稿日：03/06/24 22:32
JDK1.5入手してみましたが、すごいです。
多重継承、ASE（新国防省最強暗号）サポートはもちろんのこと
RAWｿｹｯﾄの実装なども考えられてるらしいです。
Disassemble対策もとられさらにC#に対抗して
Java/Fortran Java/Python(これは前からあるが) Java/Perl（JPLs）
Java/C などが発表されるそうです。
噂ですがSUNではないどこかの企業（赤X）がJAVA C#なるものを開発してるようです
簡単に言うと　JAVA2C#　ですね２００５年が楽しみです。
http://ex3.2ch.net/test/read.cgi/shar/1054887959/

>>13
マジで？
Javaで多重継承ができたら最高じゃん！

>>13
ぬっころす！

http://homepage.mac.com/hiroyuki44/

1.5 が Tiger って呼ばれてるのは知ってるけど、
1.4 は merlin だし 1.4.1 は hopper だし 1.4.2 は mantis だし。

隼(1.4)ってのは何？

http://homepage.mac.com/hiroyuki44/

http://homepage.mac.com/hiroyuki44/

http://homepage.mac.com/hiroyuki44/

J2SE1.4.2age

Javaをこれ以上複雑にしないでくれ。頼む。

>>11
> >>9
> C#っぽくなった
とてもそうとはおもえず。

むしろC#がJavaっぽいだろう。

>>22
C#ほどでもない。C#のように無駄に苦しまなくてすむ。

>>9
C#っぽくなった

ようやく半透明ウィンドウとか不定形ウィンドウをサポートするらしいね
で、タスクトレイへの格納ﾏﾀﾞｰ? (AA略

私を虎と呼ぶな。

>>27
(・∀・)寅さん!!

>>27
地獄へ落ちても忘れるな

>>27
ｱﾊﾟｶｯ

Unixの貧弱なGUIに合わせるから進化が遅い

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

（＾＾）

hoge

>>31
(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?
(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?
(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?
(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?
(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?
(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?(ﾟДﾟ)ﾊｧ?

56(ﾟДﾟ)ﾊｧ?

なにが変わるんだか書けよおら
↓

C#っぽくなった

C++っぽくなった

>>36
そこまでいうなら2chに聞かないで自分で調べろ。
どうせこのスレにいる奴はアンチJava厨なんだからよ。

Download JSR-000014 Adding Generics to Java Programming Language
ＳＵＮのＩＤつくれば
がだうんできるみたいです

>>40
はC++でいうところのテンプレートだそうです
Cマガ2002/２月号 ＜参照>(←禿のインタビュー付、Java厨なら必須)

JavaGemerisのことだろ

Generics

>>36
いかがでしょ？

New Java Language Features in J2SE 1.5
http://developer.java.sun.com/developer/community/chat/JavaLive/2003/jl0729.html

In the Generics language extension, the compiler inserts casts into your code in the generated bytecode (for example, to String in my previous example).
ダセー。キャストするんじゃねーか。センスねーな。C#のほうが数段上だわ、こりゃ。

必死だな。(藁

C#もテンプレートあるの？STLみたいなやつ？

>>45
お前はそこに書いてある意味をちゃんと理解していないだろ。

>>47
標準言語仕様にはない。

>>44
英語読めないよママ

ttp://www5.airnet.ne.jp/sakuraba/java/

>>48
どんな意味だか言ってみなよ。（ｗ

>>47
あるよ。Rotor+Gyroでな。Tigerなんかvaporwareだろ？（ｗ

>>53
>>49

Yukon、Longhornこそ21世紀開始早々類を見ないVaporware

static importはどうよ。

Javaが穢れて行く

>>56
可読性を下げるだけの糞仕様。
JavaのVB化。

えぇえ！
Javaって元から糞でしょ

>>54
>>www.ecma-international.org/

Java にしろ C# にしろ
「糞」だなどと言ってのける奴は、
理屈としても精神年齢的に見ても、
それを使ってる奴に対して「お前のかぁちゃんデベソ」と言ってるのと
何の違いも無い

> 何の違いも無い

けど、Javaが糞なことに変わりはない。(ｹﾞﾗ

C#ユーザに喧嘩売るスレですか？

C#は「Javaキラー」か「焼き直し」か
http://www.zdnet.co.jp/news/0007/04/sun.html
MSの切れ者技術者，Hejlsberg氏がC#を語る
http://www.zdnet.co.jp/news/0104/25/e_ms2.html

>>62
ｹﾞﾗ かぁ、、


かぁちゃんが実際でべそだったとしても
それをｹﾞﾗとか言って勝ち誇った気持ちになれる
神経がある意味うらやましいな。

http://msugai.fc2web.com/java/app/history.html
1991 James Gosling、オブジェクト指向言語 Oak 開発。
1994 Java ベースのウェブブラウザ WebRunner 開発。
1995. 05 Oak、Java に改称。 WebRunner、HotJava に改称。
1995. 09 Netscape 社、 SunMicrosystems 社とライセンス契約。
NetscapeNavigator2.0、 Java をサポート。
1995. 12 Microsoft 社、 SunMicrosystems 社とライセンス契約。
1996. 02 JDK 1.0 を公開
1997. 02 JDK 1.1 を公開
1998. 12 Java2 (JDK 1.2) を公開
2000. 05 SDK 1.3 SE を公開
2002. 03 SDK 1.4 SE を公開

１０年以上たってもこの成長のなさはなんですか（ｹﾞﾗ

>>60
>>49

>>67
>>jar地獄

>>68
？

>>66
成長っていうか、既存の技術を片っ端からラップしていったような感じ。
IBMの後押しがなけりゃここまでにはなってないわな。
IBMは４つOSもってたからJavaのお陰で大幅にアプリの開発・保守部隊を削減できた。
これはとてつもなくでかいこと。

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

Yukon、Longhornこそ21世紀開始早々類を見ないVaporware

もはや Windows の競争相手が Windows になってるからね。

>>73
より正確には、Windows に害悪を与える最大の敵が Windows そのもの
だったりして・・・

>>66
> １０年以上たってもこの成長のなさはなんですか（ｹﾞﾗ
貴様が想像するような成長をしてみろ。
技術者のこともなにも考えない勝手な成長がC#を生んだ。
VB厨がVB.NETやC#に移行するだけで苦労するのだ。

C#も.NETもVaporware といってもおかしくない。

>>75
JDK1.3から1.4への移行で苦労している漏れはどうしたらいいんですか？（泣

J2EE1.5のMetadataってそのまんまCOM Attributeじゃん。
.NETのMetadataの方をパクってくれよ。

http://www5b.biglobe.ne.jp/~ryo-kyo/

>>77
ブビ厨がC#へ移行するのに比べれはそれほどの苦労は無し。

Eclipseでリファクタリングも欠かさずやる。

>>77
どんな苦労？

いつでるんだよ

>>78
一番優れたところをパクらない(パクれない)。
中途半端すぎ。

ベイパーウェアってやつだな。WinFXとは大違い。

>>82
早くて来年の終わりくらい？

>>66
成長のなさって言ったってさぁ、
最初から完成してるようなものだし
Java２の「２」はJDK2.0（もしくは2.x）で終りってことなので
一歩一歩言い意味での枯れたものになりつつある
「枯れる」と言うことはネガティブなことではないんだよ

>>86
Ｊａｖａ３は絶対でないということでいいのでつか？

static importはマジで信じられん。
ただのimportでさえ名前衝突とか問題抱えてるのに、
脳味噌が沸いてるとしか思えん。

>>45
可哀想なC#厨の脳みそでは、
後方互換というものが理解できないらしい。
どうでもいいプログラムしか作ってない証拠だな。ぷ。

>>88
使わなければいいじゃん。

>>90
学生か趣味でやってるマイプロジェクトならそれでいいけどね。
ふつうチームで開発するし、そもそもアホが書き散らしたコードの
お守りしなきゃいかんかったりするし。

>>91
まだだれも使ってないだろ。
アホはstatic importをしばらく知らない。
プロジェクトなら、使わないようにルール決めればいい。

時間の問題。ルールに盛り込めるとは限らんし、
既存か過去のプロジェクトのコードはどうしょうもない。

http://java.sun.com/j2se/1.4.2/index.jsp
http://java.sun.com/j2se/1.5/index.jsp

>>93
っていうか、そんなに問題か？

問題の程度はともかく、今時これは方向が間違ってるだろ。
クラス名によって、なんの定数、メソッドというのを表してるし、
そもそもふつうのimportだって、*じゃなくてクラス名まで書きましょうと
言う流れなのに、いきなり書かれたらどこで定義された定数・関数か訳わかんなくなるし、
副作用を持つメソッドなんか目も当てられない。

>>96
そんな流れなのか？
Sun的には、記述を簡単にしようという流れのはずなんだが。

> いきなり書かれたらどこで定義された定数・関数か訳わかんなくなるし

じゃあimport使わずにFQNで書いたほうがいいよ。
コードの見通しわるくなると思うけど。
気になるなら、importにメソッド名まで書けばいいんじゃないの？

> 副作用を持つメソッドなんか目も当てられない

っていうのは意味がよくわからない。
解説してくれ。

JDK1.5のページができてるんだね。
ComingSoonがはやく取れますように

倒産するから一生出ないぞ。(ｹﾞﾗ

Sunって何？
倒産寸前でﾘﾅｸｿデスクトップを激安販売してる可哀想な人達か？(ﾌﾟﾌﾟﾌﾟ

ビジネスをドットコムして株価が大暴落した会社だな。(大爆笑

>>97
SUNは、VB厨みたいのも取り込もうとIDE対応を考えていると思うが、
単にタイプ数を減らすとかの流れとは違うと思われ。

ClassName.method()は、なんのクラス（ジャンル？）のメソッドか
強制的にわかるのでメリットと思う。（程度の問題ではあるが）

>>> 副作用を持つメソッドなんか目も当てられない
>っていうのは意味がよくわからない。
用途としてMath.max()や定数のような純粋な「関数」を想定していると思うが、
static メソッドにはふつうに副作用を持つことがあるだろ？
やるなら、ホントに、関数の概念を持ち込んでやるべきと思われ。

っつーか、名前の衝突を解決するどころか、増やしてどうするんだよ！
↓static importなんかより、こんなのが欲しい。
import net.nichan.tech.Tiger @ prog;
import de.nati.tank.Tiger @ tank;

　　　　　　　　:（略）
　　new Tiger@tank().lockOn( new Tiger@prog() );

>>102
> static importなんかより、こんなのが欲しい。

そのほうが、わけわからんソースになる気がするのだが。

Java厨はﾌﾞﾋﾞ厨以下だということだろ。(ｹﾞﾗ

自分がﾌﾞﾋﾞ厨だからといってそんなに必死にならなくても(藁

http://java.sun.com/

Javaのトップページのデザインが随分と変わってる。写真つきだ。

http://java.sun.com/j2se/index.jsp
しかも項目にDesktop Java　が追加されてる。

ビルジョイがいないから必死なんだろ。(ｹﾞﾗ

あいかわらず、日本語サイトでダウンロードできんがな。

新しい基本データ型が出来るって本当？

enumのこといってんのか？

>>110
嘘。

>>111
enum は基本型じゃない。 java.lang.Enum のサブクラス。

なんだ.NETのパクリか

>>113
そうだよ。で？

1.5アルファきたーーーーーーーーーーーーー。
http://www.javalobby.org/members/j2se15.jsp

追加
http://www.javalobby.org/thread.jspa?forumID=61&threadID=10482

誰でも自由にアルファ版を入手できないのか。
Javaってクローズドだね。(ﾌﾟｯ

BSD版まだ？

>>118
文句言ってないで移植してる連中に協力しろ。

正式版はいつでるの？

>>115
http://java.sun.com/developer/earlyAccess/j2sdk150_alpha/
どーせなら こっちの方が…

>>120
2004年の夏(予定)

http://java.sun.com/j2se/1.5/index.jsp
> J2SE 1.5 (the "Tiger" release) is the next major revision to the Java platform and language,
> scheduled for release in the summer of 2004.

download できるファイルが
j2sdk-1_5_0-beta-bin-b31-windows-i586-11_dec_2003.exe
なんだけど、2003年12月11日版って事なのかな？

WinFXには遠く及ばないな。

ｱﾌｫは放置で

Whidbey ＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞ Tiger

どうせ正式版待つまでもなく惨は倒産するよ

何かSwingが爆速に感じるんだが。元からこんなんだったっけ？

このまえやっと1.4.2にしたところなのにいいいい！！！！

Metal L&FがなんとなくMacっぽい

ｳﾋｮｰ(;ﾟ∀ﾟ)=3 こりゃすごいわ。

>>128
漏れもSwingのデモ動かしてみたけど、確かに1.4.2よりさらに良くなってる。
WhidbeyでWindowsForms動かすよりはるかに高速でつよ、と煽ってみる。

Metalの見た目が変更になってんの？

なんとかクリスマスリリースできたね。

1.5では新しくManagedImageってのが入るって聞いたような。
そのおかげかな？
2D,3Dの境目をなくすというのもあったような・・・
DirectXかOpenGLで実装しなおしたのかな。＜Swing

をいをいをい、誰か説明してくれ
じゃばろびー.orgってなんだ？
WebStartのデモな1.5のウィジェットなのか？

これはマジですげーぞ！！！！！！！！！！2004年まで待てるかっちゅーねん
さっさとこのウィジェットだけでもだぜ

1.4.1と1.5.0alphaでJFCデモを比べているのだが、面白いな。
パフォーマンス部分のパネルとか。
サンプルにバグっぽい挙動も見える。

これって色々言っちゃダメなんだっけ？
Notice を全部読んではいないんだが、「Private」と Bold で書いてあったし。

>>132
Metal LookAndFeelのthemeにOceanが増え、それがデフォルトになっている模様。

今1.5試してるんだけど、WindowsLook&Feelのデフォルトフォントがやっとシステムフォントになったよ。
WindowsClassicLook&Feelのファイルチューザがネイティブと見分けがつかない良いできばえ
MetalLook&Feelもみやすくなったんだけど、やっぱりJavaフォントが見にくい。アンチエイリアスされんのかな

>>138
システムフォントになったな。
ただ一部違和感がある。

よくよく見てみたら、メニューのラベルがこうなってた。
　Win32一般→「ファイル(F)」
　JDK1.5→「ファイル (F)」

ローカライズのみの原因だろうが、ちょっと気になる

JDK1.5.0alpha + Eclipse 3.0(M5)

VMがクラッシュしました。やっぱり無理か

>>139
すっげー細かいね〜ちみ
俺もこれまでのSwingは全然ダメだと思っていたが、そこまではこだわらんわ・・
俺が気になるのは
・フレームを引き伸ばしたときに、WinLAFにしていても、METALのフレーム色で引き伸ばされる事
・WinXPLAFのファイルチューザーの左アイコンの文字がでかすぎる
・WinLAFのJTreeアイコンが相変わらずぼっさい
ぱっと触って、これだけ気になった。
簡単にFixできるんだから完成版までにはどうにかしてほしいもんだ

Oceanまぶしい。イマイチ。
絵にコクが無い。

JavaPlug-in、Operaにも対応して欲しいぞな。

c:\ > java
って入力してからのレスポンスがめちゃはえー！！！

class Test{
　　static public void main(String args[]){
　　　　Integer a = 3;
　　　　String[] b = {"aaa","bbb","ccc"};
　　　　System.out.println(a);
　　　　for(String s : b){
　　　　　　System.out.println(s);
　　　　}
　　}
}

がコンパイル通るのはいいね。
-source 1.5
が必要だけど。

NetBeansで使ったけど、1.5からの文法を使うとエディタにエラーが表示されまくりでちょっと気持ち悪い。
でも、ツールに勝った気になる。

実は1.3系で互換になるようにしか 1,4 を使ってなかったから、
javac や javadoc の -source オプションを思いつくのに手間取った。

auto boxing/unboxing (・∀・)ｲｲ!

Integer n1 = 100;
int n2 = n1;

記述のしやすさは確かにC#に迫ってるね。よいことだ。

っていうか、動きが速いんだよー。
だれか、ベンチマークして。

List<Integer> l = new ArrayList<Integer>();
l.add(5); l.add(13); l.add(3);
int total = 0;
for(int val : l){
　total += val;
}
System.out.println(total);
(・∀・)イイ

うおー便利だ

<>なの？

Win32のインストーラに出てくる「データベースフォルダ」って何？

速いか？それはなんともおもわんが、
今、自分で作ったSwingアプリを1.5で動かしてるんだが。。

ただ、lafが綺麗になったので、ソフトが生まれ変わったような気分にはなる。
ところで、Window.show()が推奨されないメソッドになったのか？これはどういう事だ

>>154はM$の刺客

> 推奨されないメソッドになった

またかよ
コロコロ変えるのは正直勘弁してほしい

>>154
Componentとかではずっと前からだから、一貫性が取れたと。


Javadocの作り方メモ
src.zipを解凍後、
C:\j2sdk1.5.0\src>C:\j2sdk1.5.0\bin\javadoc -J-Xmx512M -source 1.5 -d ../doc -subpackages com:java:javax:org:sunw

どっから落とせるの？
ユーザー登録しないといけないの？

>>121

なんだ、Javaが.NET化しただけか。(w

1.5 で Eclipse2.1.2 動かしてみたけど体感的に変わらん。
ところで java.util.List の以下のメソッド、誰か解説してくれ。

　boolean addAll(Collection<? extends E> c);

Eを保持するList （というか、List<E>だけど） には、
Eのサブクラスを保持するCollectionをAddAllできるってこと。

>>162
ん〜、それはこれではダメなのか？

　boolean addAll(Collection<E> c);

List<Integer> list = new ArrayList<Integer>();

この行で '(' または '[' がありません。 といわれるＹＯ

>>164
javac -source 1.5 Hoge.java

1.5をもって、C#には「言語仕様では」互角にまでもって行けたのかね?(実行環境は除く)
C#にはTemplateが無い。Javaにはdelegateが無い。

Javaが1.5になったからと言っても、コンシューマー市場に返り咲けるはずもなく。
エンタープライズ市場が主戦場になるのだろうが。それとても、実際は WebSphere や
WebLogic などのアプリケーション・サーバが正式対応して 1年後くらいから、やっと
普及してくることになる。
実際に仕事で使われるようになるには、あと 2年近くはかかると思うのだが。
（半年後には、MSなら v1.2での開発が主流か。仕事の案件はまだ少ないだろうが）
OSのみならず、MSとは全く違うのやり方があるのは良いことだとは思うが、もう少し
ペースが早くてもいいのではと思う。＞ Java

>>163
PとCに親子関係があっても、Foo<P>とFoo<C>に親子関係はありませんよ？

>>167
>もう少し ペースが早くてもいいのではと思う。＞ Java

やだ。

というより WeｂLogicの囲い込みが嫌なのだが。

1.5 はまだ業務では使わないでしょ。
1.3.1、1.4.2のような最終マイナーバージョン番号のリリースを待つ。
(だいたいテストフェーズにマイナーバージョンが打ち止めになるくらいがちょうどいい)

1.5 は 言語仕様が変わってるだけに 1.5.2 くらいまでは行きそう

>>165
thx!

>>168
理解すた。

ただ色々見てると、鬱になってきた。。。なんだこりゃ。
これが Java か？ ちょっと勉強してくる。

java.util.Collections

　public static <T extends Object & Comparable<? super T>> T
　　min(Collection<? extends T> coll) {

ところで上のほうにあった
http://www.javalobby.org/thread.jspa?forumID=61&threadID=10482
と、1.5とはどういう関係が！？
俺は、このWebStartデモが無茶苦茶気になるのだが

>エンタープライズ市場が主戦場になるのだろうが。それとても、実際は WebSphere や
ベンチでC++に一桁も落ち、
ライブラリも開発環境も貧弱なJavaを
わざわざサーバーで使うというのがわからん。
特にハードウェアの制御とか動画とか。

元のメソッド
　public static Object min(Collection coll);
　↓
とりあえずGenericsを導入してみる
　public static <T> T min(Collection<T> coll);
　↓
Comparable要るんだった
（Comparableはinterfaceなのでsuperclassを書く必要がある）
　public static <T extends Object & Comparable<T>> T min(Collection<T> coll);
　↓
Comparableの型パラメータはTの親クラスなら何でもいい
Collectionの型パラメータはTのサブクラスなら何でもいい
　public static <T extends Object & Comparable<? super T>> T min(Collection<? extends T> coll);

175は>>172宛てね。書き忘れた。

言語仕様なんか変わったって覚えるの面倒だから、おれはこれまで通りで組むぜ〜
それより、1.5のLAFのデキは本当に良い
というか、最初からこうしとけっつーの

look and feelってLAFって略すのか。。PnP、DnD、LnFとくると思ったのに。。

なんで急にレスが延びてるのかと思ったら
ようやく物が出てきたのね

それほど、みんなコレクションからの要素取り出し時のキャストには嫌気がさしていたと言うことですよ。

これって構文糖なの?
つまりコンパイルだけ-source 1.5で行って新しいライブラリを
使わなければキャスト相当のJavaバイトコードに変換されて
古いVMでも動くの?

>>181
javap すれ。
jad とか

できれば仕様としてお墨付きがほしいなあ
単純なサンプルでは問題ないように見えても
複雑なコード書いた途端に見たこともない命令に展開されても嫌だし
で、ちょっとぐぐってみたけど既存のJVMとの上位互換性は
保証されてるみたいね

コンパイラが変わるだけだよね？
VMは変わんないよね？

最適化は変わるかもしれないけどVM仕様は変わらないみたい

シンプルさが売りのJavaとは思えない汚いGenerics構文ですね。(ﾌﾟｯ
C#の方がまともだな。www

>>157
javadoc作れますた。ありが�d。
個人的には java.util.concurrent が面白そう。ThreadPoolがあるよ。ヽ(´ー｀)ノ

MetadataはまだAPIに実装されてないみたいね。
@Remote ってやってみたけど怒られちゃったよ。(´･ω･`)

> java.rmi.Remote is not an annotation type

物はいちおう作れるみたいね。

import java.lang.annotation.Target;
import java.lang.annotation.VisibilityLevel;

public @Target(TYPE) @interface Author {

　　String value();
}

// 使用例
public @Author("nanashi") class Test {
}

おいおい、まんまC#じゃん。Javaも堕ちたな。

なぜ今までこれらの拡張をやらなかったのだろうか？
単に技術力が無かったとは思えない。
今までやっていたことといえば、WindowsからJavaを消して
WindowsにJavaを搭載させようと裁判をおこしていただけ。
技術力でJavaを脅かす物はないとあぐらをかいていたのだろうな。
重い腰をあげてJavaがまともな物になっていくのはC#のおかげだな。

C#を散々否定してたJava厨の意見を聞きたい

generics の議論が始まったのって相当前だと思うけど。

JDK1.5で追加されるのはgenericsだけじゃないよ。

enum と autoboxing？

どっちも.NETで導入されてから焦って入れたっぽいなぁ

【やったね】Ｃ＃最強伝説 第2章【ゲイツ】
http://pc2.2ch.net/test/read.cgi/tech/1070469339/
こちらへどうぞ。

MessageFormat.format もすごく便利になったね。ヽ(´ー｀)ノ
可変引数だし、primitiveもそのまま突っ込めるし。

3年遅れでやっとC#に追いついたのか。(ﾌﾟ
また引き離されるけどな。(ｹﾞﾗ

今更って感じの機能ばっかりだね。(ﾌﾟﾌﾟﾌﾟﾌﾟ
で、実戦でいつ普及するの？
.NETは今現在広まってるけどな。(w

>>200
広まっている？ どうやって？
WindowsUpdateも知らない一般人に広まっているとは思えないが。

>>201
相手にするだけ無駄

Javaって今後.NET上で動くんだろ？

危機感 感じて荒らさなくてもいいのにな。

>>203
LonghornではWin32 APIの直接使用が禁止という噂が本当ならそうなるな

>>205
その噂が本当なら既存の Win32 アプリは Longhorn では動かない事になるような…

>>206
エミュモードで動きます

つまりJavaは今後エミュレータでしか動かないのか。

>>207
今までどおりにAPI呼ぶのをエミュとは是如何に。

Longhornが普及したらJavaも終わりだな

デリゲートとかもそのうち実装されるわけ？

結局Visual J++は最後まで正しかったということだな

Longhornは激重。メモリ1GBでも足りない。
Javaの方が快速な世の中になった。

個人的にVJはみんなからシカトされている存在かと思ってたんですが。
ちなみにＣ＃はスネオからラジコンを奪うジャイアン。

>>209
ネイティブなAPIは微妙に互換性なくなって
今までのアプリはVirtual PCのテクノロジを利用したエミュ上で動くとか。
Win32アプリとのパフォーマンスが逆転しないといつまでたっても.NET
普及しないし

ところで、KVMとVMって何がちがうの？
いつの日かMIDP-WebStartみたいなのができて、
それがPC上から実行できるようにならんのかな

いまやiアプリやMIDPのソフトウェア資産はSwingアプリより圧倒的に上だろうに

Varargs の記法はいいね。

void someMethod(Object ... arguments)

拡張for文はC#のマネしてほしかったYO

いくら真似をしてもオリジナルのC#を超えることはできてないけどな。(ｹﾞﾗ

>>216
KVM=小さくて、そのかわりAPIをちょっとしかサポートしないVM。

コンパイラのジェネリックスサポートって

class HogeList{
　private ArrayList impl = new ArrayList();
　public add(Hoge hoge){impl.add(hoge);}
//以下省略
}

…なんてクラスを書かないですむようになった、以外に
なんかいいことあるの？いや、それで充分って言い分は
分かるけどさ。

Kさん 好循環　　Aさん 悪循環　　
　（健康体）　　（喘息）

1.（神が喘息であるかないかを決める）

2.K 喘息でない人　A 喘息の人は
は体力がある　　　 体力がなくなる

3.K　　　　　　　 A 行動力、
　　　　　　　　　 五感（嗅覚）が鈍り感性が変化する

4.K&A 神は異常な感性の人間は本来人に迷惑をかけ
るから外に出てはいけないと思っている。

5.K 変化なし　　　A アトピーになる

6.K 正常な感性　　A 外に出なくなりさらに異常な感性になる

7.K 正常な人間 　 A 異常な人間（レッテル）

8.K&A 死

9.K&A　　　　　　来世

10.K&A 神は異常な人間は人に迷惑をかけるので行動
を抑制する必要があると思っている。

11.K&A 神が喘息であるかないかを決める

12.K 喘息でない　　A 喘息である

13.K&A　　　　1.に戻る

これは事実。広めようぜ

解決法：体力をつけると感覚が正常に戻り、
　　　　アトピーも快癒に向かう。
　　　　目安としてグランドを10週くらい。
あとはウォーキング
　　　　2.3時間を目安にウインドーショッピングや本屋めぐり

まだ1.3だ・・・。

J2SE1.5が気になって必死に煽ってるm$マンがいるのか

C:\j2sdk1.5.0\binにいろいろなツールが追加されてますな。
HtmlConverter.exeを起動してみた。GUIが起動。すでに日本語版も作られている。
デザインも以前のGUIとくらべすっきりして明るくていい感じ。ちゃんと壁紙も用意しているっぽい

ユーザー登録しないと1.5は落とせないの？

>>227
うんたぶん。登録は無料だったよ。

海外掲示板用オフラインリーダーを作るスレ
http://pc2.2ch.net/test/read.cgi/tech/1072883528/

海外でよく使われていうる掲示板スクリプト
専用のオフラインリーダー作って下さい。

必要な条件はID、PASSを管理できること、
OpenJaneみたいな三面型の見た目。
簡単にローカライズできるように言語ファイルを採用

もはやJavaでは盛り上がらないということか

JDK1.5 alpha については、
public な場でいろいろい言うのはまだ駄目なんだが。

だから惨はあのM$よりも閉鎖的で駄目なんだよな。

>>public な場でいろいろい言うのはまだ駄目なんだが。
シラネーよそんなもん

言うまでも無い事ですが、ここは便所の落書きです。

1.5 の Swing すげー。操作中の体感は 1.4.2 とあまり変わらない気がするけど、
しばらく放置してたウィンドウをアクティブにしても、すぐに反応するよ！！
感動した。

>>187
concurrentについてはまだ変更ある模様、API自体に及ぶのかどうかは知らん。
http://gee.cs.oswego.edu/dl/concurrency-interest/index.html

>>216
MIDPもdojaもエミュレータあるんじゃ？

なんでMIDPやdojaは「エミュレータ」って呼ばれるでしょうね。
VMでいいじゃんね
MIDPがエミュレータならJ2SEもエミュレータじゃん

>>237
本来は携帯等の端末で動くものをPC上で実行できるようにしてるからじゃね？

1.5のダウンロードページにあった、パブリックな場所では議論しないでくれって
書いてあったのが消えたんでage。

んなことが本当にかいてあるのかと。
つか、藻前らはそれに反してここpublicな2chですでに議論してるやろが

ここはpublicなのか・・・。
えらい出世したな。

公共便所の落書き

公衆便所の落書き(2chの書き込み)は誰でも読めるから十分 public だと思うが。

(　´_ゝ`）フーン

privateかpublicのどちらかと言われたらpublicだろうな

まぁ、ここで2chがpublicかどうか、という議論をしてもしかたないな。

protect辺りで妥協してみんのはど？

(Javaの)package privateあたりが妥当かと。

おい、今からstatic import潰そうぜ

>>249
使わなければいいだけの話。

仕事で使うならそうも言ってられないだろ。
酷いコード書かれて、自分が直すケースなんかあるだろうし。

酷いコード書く人は、static importなんか可愛く見えるような記述をするので、あんまり影響ないような気がする。

例 : 数値を保持するのにStringBufferを使う。

>>252
StringBufferじゃなくてStringだったけど、
この前そういうコード読まされて泣きそうになったよ。
メソッドの引数に二つの数値を指定するのに、引数が
"123,456"って形式の文字列でさ。
普通に引数増やせばいいだろうが・・・

おっと、ここは愚痴スレじゃなかったか。
でも、JDK1.5の新機能であんまり下手なコードはコンパイル通さないっての
入れてもらえないかね。

>>251
醜いコード書く人は、static import 知らないから大丈夫。

〜.* 使わなければstatic importも別にいいと思うけどね

メタデータってどんなん？

generics

>>256
http://www.jcp.org/en/jsr/detail?id=175

字がたくさんあって読むのがめんどくさいので、ちょっとした説明きぼんぬ。

そんぐらい自分で嫁

1.5ってどこにあるの？

>>261
1.0 と 2.0 の中間。

今勉強中。ダサッ。

まだ1.5導入してないんだが、
がいしゅつで1.5からシステムフォントになったって書いてあったけど、
Linuxでの豆腐文字も直るのかなぁ？
LinuxのGUIだと豆腐文字になるので、
コード上でフォント指定しなおして対応してるけど、どう？

> コード上でフォント指定しなおして対応してるけど、どう？
素直に font.properties 設定しろよ。

1.5のAPIドキュメントってどこでダウンロードできるの？

>>266
1.5 はまだ alpha版なので APIドキュメントが無いらしい。
beta版になったら APIドキュメントも公開されると思われ。

付属の src.zip 内のソースから javadoc で生成すれ。

>>267
そうかまだないのか。教えてくれてありがとう。

ほんとにgenericなんだね。JSRが出た頃は「ウソだよな」とか言ってたけど、
ほんとにつくちゃったんだね。

('･c_･` )

>>265
＞素直に font.properties 設定しろよ。

それってJavaの設定？Linuxの設定？（汗
そんな「素直」な方法があるのか？
Linuxのフォント設定を調べまくって弄繰り回した結果、
Javaコード指定しかダメなのかと思ったのだが。。。（つд｀）

>>268
> ほんとにgenericなんだね。JSRが出た頃は「ウソだよな」とか言ってたけど、
コンパイラの変更だけなら今でも当時でも専門家一人が一ヶ月〜三ヶ月ぐらいやれば出来るような…

むしろ詳細固めるのに5年くらいかけてる方がウソだろって感じがする。

テンプレ

本家
http://java.sun.com/j2se/1.5/index.jsp
ダウンロード
http://java.sun.com/developer/earlyAccess/j2sdk150_alpha/
コンパイル
javac -source 1.5 Hoge.java
API
src.zipを解凍後、
C:\j2sdk1.5.0\src>C:\j2sdk1.5.0\bin\javadoc -J-Xmx512M -source 1.5 -d ../doc -subpackages com:java:javax:org:sunw
メタデータ仕様
http://www.jcp.org/en/jsr/detail?id=175
デフォルトフォント指定
font.properties
デフォルトLAF指定
swing.properties

>>269
> それってJavaの設定？Linuxの設定？（汗
Java の設定。

>>272
ありがとう！試してみます。
Linux側のフォント設定ばっかりやってたのでダメでした。
話は戻るけど、
1.5ならWindowsのみならずLinuxでもこういう設定は不要なのだろうか？

>>270
安易に追加するより、じっくり洗練してくれた方がよい。
可能な限りシンプルで、可能な限りVMへの影響を少なくするには、
それくらい時間をかけても良いと思う。

>> > コード上でフォント指定しなおして対応してるけど、どう？
>> 素直に font.properties 設定しろよ。

マジレスするのもなんだが265もいるので一応いっとくと
font.propertiesいじるのはJavaソフト全体に影響するから
基本的にインストーラとかにやらせちゃいけなくて
希望に応じて顧客やユーザーにやらせるべきこと

決して「素直」ではない、というか奥の手。
ソフトでフォント設定するのが正解

ベータ出ましたYO!やっちゃいましょう！

>>275
本筋から外れた質問にマジレスありがとう。
font.propertiesいじるのはやっぱ奥の手だよね。。。
Winで書いたものがLinでそのまま動かないんじゃ、ガックリするし、
（※EUCにエンコードしてないとかいうことではなくて）
私のような素人レベルで渡す相手にそこまでしてくれっていうのもねぇ。。。
そういうめんどくさい問題が1.5で解決してるのかな？と思ったのです。

>>275
> 決して「素直」ではない、というか奥の手。
こらこら。
> > LinuxのGUIだと豆腐文字になるので、
とゆーよーな状態だったら font.properties 設定しろ、
というのはきわめて妥当。

フォントが汚いとかってんなら、
> ソフトでフォント設定するのが正解
でも良いかもしれんが。

>>278

おお、そうか！「豆腐文字」の意味をよく理解していなかった
そりゃfont.properties設定しなきゃいかんね。

つまりJavaのバグ（またはバグみたいなもの）か・・
1.5で解決している事を願う・・

> つまりJavaのバグ（またはバグみたいなもの）か・・
オマエは Linux 使わない方が幸せだと思われ。

1.5進展ないねー

>>281
内部的には新しいビルドがあるらしい。

クリスマスリリースで配布されてるアルファ版は
build 1.5.0-beta-b31 だけど BugParade には b32 のバグも出てきてるし。

1.5はgenerics使えるんですか？
generics使うと便利ですか？
実行速度に莫大な影響を与えたりしませんか？

使える型が限定されるから
ループ内では型チェックの手間が減ってむしろ逆に速くなるんでない？

Genericsをこんな使い方されたら迷惑。
http://pc.2ch.net/test/read.cgi/prog/1052298478/360

>>283
> 1.5はgenerics使えるんですか？
使える(ハズ)

> generics使うと便利ですか？
たぶん。

> 実行速度に莫大な影響を与えたりしませんか？
しない(ハズ)
開発速度は若干加速されるかもしんない。

っつーか、erasure でどーやって実行速度遅くなったり速くなったりするんだろ？

genericsには期待してる。
それとは別にaspectJがもうちっとまともに成って欲しいもんだ。

<>使うのが嫌。

C++だと仮想関数を使う変わりにテンプレートで柔軟性と一般性をあたえてカスタマイズ可能にしたり、インラインと組み合わせたりすると実行速度が速くなるけどJavaだと全部仮想関数なんだよね？
だから実行速度はほとんど関係ないのか。

すべて仮想関数って言っても
毎回vtbl引いてるわけではなく
呼び出している対象が明らかな場合は最適化されるから
あまり過敏になる必要はないと思うが

javaと他の言語の性能の違いについては、これが参考になる。
http://www.osnews.com/story.php?news_id=5602&page=3

Javaは三角関数がやけに遅いけど、他の操作はVC++と
大して変わらん。
この程度の差は、コード書く奴の力量でどうにでもなる話だろ。

/.の本家で出てたけど、trigがJavaで遅いように見えるのは
VC++はIntelのプロセッサの同等のオペレーションそのものを
はきだしてるのに対して、JavaはそれだとVMの数学仕様に合わなくなるから
別のことやってるからって書いてあったよ。

つうかJITされた後のJavaの速度はもうまるっきりネイティブコードだって
ことを知らないやつがいるよな。

>Javaは三角関数がやけに遅いけど、
それはライブラリのを使わずに
自分で実装すればいいよ。

テーラー展開マンセー！！

JNIを使って、確実にx86のfsin/fcos命令を使うようにすれば、VC++に追いつくか。
テーラー展開等、自力で計算しているうちはStrictMathと同じことをやってるわけだから、勝てなさそう。

>>292
http://developers.slashdot.org/article.pl?sid=04/01/09/1340223&tid=
このトピだね。なかなか面白い事が書いてあるなぁ。
勉強してみるか。

Performance comparison C++, C# and Java
http://www.tommti-systems.de/main-Dateien/reviews/languages/benchmarks.html

ちょっと変化球だけど、こういうのも。

Evaluating Java for Game Development
http://www.rolemaker.dk/articles/evaljava/Evaluating%20Java%20for%20Game%20Development.pdf

>>289
Javaのメソッドは仮想関数とは呼ばない。

もしかしてfinalをつけると処理速度が速くなるという迷信(都市伝説)
をいまだに信じているお方ですか。

>>299
ちゃんと解説してあげたら？
付けただけでは何も変わらんが、完全に無駄ってわけでもないぜ。

ttp://www-6.ibm.com/jp/developerworks/java/000818/j_pr29.html

CNIでトランスレートするとfinal以外は全部virtualになってるけどね。

>>299
自分が言いたかったのはC++だと継承と仮想関数を使う代わりにテンプレート使って柔軟性をある程度保ちながらら実行速度を速めることができるけど
Javaじゃテンプレート使っても速度的に速くはならんだろうから、そんなに多用しないんじゃないってこと｡

C++じゃ可読性が極端に落ちても効率もとめてテンプレート使ったりしていて嫌に成ることあるけど、Javaはそうならないだろうからいいと思うよ｡

>>303
なるほど。
Javaのテンプレートは、
どっちかというとドキュメント性や安全性の向上にフォーカスをおいたような機能だと私も考えてます。

テンプレートゆーな

総称

. のほうは安全で速くもなるみたい。

>>303
青いなボウズ。
テンプレートはコンパイルタイム・プログラミングのためにあるのさ。

>>308
C++のtemplateを使ったコンパイルタイムプログラミングって，読みづらい&デバッグしづらい
んだよね．
コンパイルタイムプログラミングとGenericsは分離するべきだと思う．>C++&D

効率よいコードの生成のための必要悪と思えばよい。
C++ではgenericかつ最適化の余地のあるコードを実現するのにtemplateがある。

もちろんどういうコードに展開されるかという想像力と検証がされないと
無駄な肥大化＆デバッグ大変なのは指摘のとおり。

Dはしらん。

genericを使ってもコードは効率よくならね―よ。
あれは、型が違うだけの同じようなコードを作る手間を
省いてくれるだけだ。

>>311
だから効率が良くなるのはJavaじゃなくて、C++で継承や仮想関数を減らす目的でテンプレートを使うとき。
Javaじゃ手間を省くためにインターフェイス使ってプログラミングしてコードの再利用性を高めるけど
C++じゃテンプレートを使ってインターフェイスが実現することをやったりするんだよ｡
仮想関数の使用が減るから早くなる｡

配列型プリミティプ型なんか必要悪でないかい？

未来の言語ではこれらがなくなるとか。
配列型がすべてコレクション型に。
これはさすがに現在のマシンスペックでは無理か。

>>312
>C++じゃテンプレートを使ってインターフェイスが実現することをやったりするんだよ｡
それがGenericsの正当な使い方とはとても。
デザインパターンも否定するんかいあんたは？


>仮想関数の使用が減るから早くなる｡
もしかしてまだ>>299の都市伝説の意味をわかっていないとか？

>>314
C++の話をしてるんだよ｡C++にはfinalなんてないよ。
Javaで早くなるとは言ってないだろ｡
Javaでは早くならんから、そんな使い方しないだろうからいいねといってるんだろ。
>>303でちゃんと言ってるだろ。

「効率」とか「早く」とかの言葉をもうちょっと丁寧に。
「何が」が抜けてて、互いに齟齬があるように見えることがあります。

>>314
ちと純粋に分からんので質問なんだが、final をつけても本当に速くならないのか？
仕組み的に、速くならないというのはおかしい気がするんだけど。

> 仕組み的に、速くならないというのはおかしい気がするんだけど。
オマエはJITコンパイラの仕組みを理解してるのか？

古いヴァージョンのJDKではfinalつけると速くなったが
改良が加えられ
今では速くしたいがためだけにfinalつけても無意味

>>319
古いバージョンって具体的には？

>>317
final付けてわざわざ教えてあげなくても、最近の賢いJITは
他にオーバーライドされてるメソッドが無ければ、勝手に最適化する。

ただ、それでもfinalには、オーバーライドによるメソッド呼び出しコストの
増加を防ぐという意味が残る。だから無駄ではない。

>>321
レスサンクス。
でも動的にロードされたクラスがオーバーライドしてたりしたらどうなんの？
基底クラスの仮想関数呼び出し部分が、final扱いでコンパイルとかされちゃうとまずくないのかな。

>>322
お前が気づくようなことがJITコンパイラ作ってる連中に気づかないわけないだろ
そのへんはうまいことやってんだよ

>>321
> ただ、それでもfinalには、オーバーライドによるメソッド呼び出しコストの
> 増加を防ぐという意味が残る。だから無駄ではない。
それは最近の HotSpot コンパイラとかのソースを読んだ上での結論か？
具体的に何種類の VM で final が無駄になってなかった？

>>322
ByteCodeVerifier かどっかで例外吐いて止まる仕様だと思われ。

>>323
なに煽ってんだが知らんが、"てにをは"くらい普通に使ってくれよな。

>>322
なるほど。ありがと〜。

ミス。
322でなくて>>324さんサンクスだった。

「すべてはコンパイラの実装依存」で終了。

>>322
俺が言ってるのは呼び出しコストね。
必ずしもインライン展開と関係あるとは限らない。
ただ、JIT自体、動的にコンパイルして既存のコードをリプレースするものだから、
動的ロードでまずくなるってことは無いはず。
それで例外はくようなVMは使えないっしょ。

>>324
良く読め。
「具体的に何種類のVMでfinalなメソッドをオーバーライドできなかった？」
って聞いてるぞオマエ。

>>328
では、とりあえず こちらの質問に答えてください。
> それは最近の HotSpot コンパイラとかのソースを読んだ上での結論か？

JDK 1.5 は言語仕様の変更ばかりが目立って聞こえてくるんだけど、
クラスライブラリにはなにか大きな追加・変更はあるの？

>>330
java.util.concurrent パッケージが大きいな。
Doug Lea 御大が熟成させてきたAPIがいよいよ標準に。

MBean も大きな追加だが、試用しただけで終わりそう。

100％都市伝説でもなかったというわけ？

>>332
何が？

>>333
いい加減放置しろよ。スレ違いだし。

>>332
うん。
でも、遅くなる可能性を排除できるってだけなので、
積極的な速度最適化ではないね。

ちなみに、オーバーライドしたメソッドが存在する場合、
親クラス(オーバーライドされた側)の参照で呼び出した場合は呼び出しコストが増加するけど、
子クラス(オーバーライドした側)の参照で呼び出した場合は増加しない。
つまり、呼び出すメソッドが末端である(オブジェクトを保持している参照のクラスより下位での
オーバーライドが存在しない)場合、finalと同等の呼び出しコストに最適化できるってこと。
最近のJITは賢いね。

>>331
ああ、あれ標準になるんだ。ﾏﾝｾｰ
JakartaCommonsのLangとCollectionsも標準にあるといいなあ。
これ以上rt.jarを大きくしてOKなのかという問題もあるが。

>>335
> つまり、呼び出すメソッドが末端である(オブジェクトを保持している参照のクラスより下位での
> オーバーライドが存在しない)
場合にメソッド呼び出しコストが低減する可能性があるのであって、
final であるかどうかは基本的には関係ない、と。

>>335
継承されてようがされていなかろうが、型チェック→vtable経由の間接callだから変わらんだろ。
JIT以前の問題。

ｷﾓｲ

ふと思ったんだけど
ソースをコンパイルしてバイトコードにおちて、
結局最後にバイトコードをネイティブにコンパイルするなら・・・

　バ　イ　ト　コ　ー　ド　な　ん　て　い　ら　ね　ー　じ　ゃ　ん　！

ソースを実行時にネイティブにコンパイルしてくれればいいんとちゃうの？

>>340
つまり、src.zip(圧縮時11MB、展開時42MB)を毎回コンパイルしろと。

全部ネイティブにするわけではなく、
実行中にプロファイリングが行われて、効果があるところがネイティブに落とされるわけ。

>>340
　>>341に加え，字句解析，構文解析，意味解析等の，自然言語処理に近い部分が
バイトコードを使うと不要になる．バイトコードがなかったら今の何倍も起動速度が遅くなる．

>>342
自然言語処理とは違うのだけどね。プログラミング言語の解析には、曖昧性の解決が必要ないので。

そんでも、java ***.javaのように.classファイルじゃなくて.javaファイルを指定すると、
関連するファイルを勝手にコンパイルして動いてくれるようなモードがあると、ちょっと便利だったかも。

>>321
> ただ、それでもfinalには、オーバーライドによるメソッド呼び出しコストの
> 増加を防ぐという意味が残る。だから無駄ではない。
かといってC++時代の癖が残っている香具師がやたらとfinalつけるのは
チーム開発では非常にウザイが。
継承は使わない方がいいとかトンデモ思考を周囲にばらまかれるのはちとな。

>>331
http://www-6.ibm.com/jp/developerworks/java/030214/j_j-jtp1126.html
これでJavaでリアルタイム処理の実現性がさらに大きくなったってか。

>>345
リアルタイム処理とは関係ないと思われ…

concurrentの導入によってマルチスレッドプログラミングのスタイルが
大幅に変わってしまうのか。

結城浩のJavaによるデザインパターン入門　マルチスレッド編を
まだちゃんとよんでいないのに。あのデザインパターンもこれで
一新されるのだろうか？

JDK1.5ではRunnableインターフェース、Threadクラスを
実装、継承したすべてのAPIに何かしらの変更が
加えられるのだろうか？
マルチスレッドを使っているからにはサーバサイドプログラミングの
スタイルが新しく生まれ変わる可能性もあるんだろうか？
J2EEプログラミングのスタイルもまるまるかわってしまいそうだ。

>>346
Java リアルタイム 仕様の実用化に一歩近づくのかな〜と思っただけで。
Javaはまだリアルタイム処理に弱いらしいので。

http://www.netgene.co.jp/java/embeddedJavaTutrial2_1.html#weakPoint

つまり、結論としては、.Netに移行ということで。

>>348
concurrent API はリアルタイム処理とは関係ないだろ。

>>347
> JDK1.5ではRunnableインターフェース、Threadクラスを
> 実装、継承したすべてのAPIに何かしらの変更が
> 加えられるのだろうか？

Runnable に変更必要あるのかな…
Thread は concurrent API とは無関係に例外関係が強化されるみたいだけど。

>>344
>継承は使わない方がいいとかトンデモ思考を周囲にばらまかれるのはちとな。

「安易に」継承は使わないほうがいい
というのであれば正しい。

>>349
おまいは邪魔だから消えなさい。

>>352
安易にfinalは使わないほうがいい、も正しいが。
finalと処理速度にこだわる香具師には
finalを使いこなす前にデザインパターンをしっかりと身につけて欲しいね。

必要な場合以外、継承は使わない
というのであれば正しい。

継承者は一子相伝。

必要ない場合以外finalを使わないことも正しい。
C++時代の悪い癖を残している者に対しては
これだけはいっておかなければならない。

「このクラスを継承して使うと悪いことがおこる」
この場合はfinalをつける。

「このクラスは継承して使ってね(しなくてもいいけど)」
この場合はfinalをつけない。

では、
「このクラスは継承させるつもりでは作っていない」
という場合、finalはつける? つけない?

>>358俺の場合。

「継承して使うと悪いことがおこる」＝final

「継承して使ってね」
・継承するのが前提＝abstract (abstract なメソッドがなくても)
・継承しなくてもいい＝つけない

「継承させるつもりで作ってない」＝final

継承させるつもりで作ってない＝継承して使うと悪いことがおこる
だと思うから

実際のコードで、メソッドにfinalつけてるのは、ほとんど見たことないなぁ。

>>345はリアルタイム処理を勘違いしていると思われ。

この業界でリアルタイムっていえば要求仕様に反応時間が含まれる処理のことだ。
で、代表的なニーズは機械の制御だ。
「メモリスワップしてたら旋盤の材料削りすぎちゃいました」は許されない。

割り込みからの反応時間を保証するために
あえてシングルタスクシングルスレッドな環境を選ぶのも
選択肢としてはありうる。

余談だが
昔は動画の再生にはリアルタイムOSが必要だと言われていたこともあったな。
CPUが速くなってマージンが増えたおかげでそんな話どっかに消えてしまったが。

Thread クラスに、
インタフェース Thread.UncaughtExceptionHandler が追加されている。
で、Thread クラスに setter/getter メソッドが増えている。

サーバを書くときに便利そう

テンプレートメソッドパターンとか不変クラスのように
なにがなんでも継承してはならないとき以外はfinalはつかわん。

継承しなくてもいいならfinalをつけるべきってーのはどうかと。
あとから継承したくなるときにそなえないと。

>>363
> 継承しなくてもいいならfinalをつけるべきってーのはどうかと。
> あとから継承したくなるときにそなえないと。
あとで継承したくなったら、その時にfinalを外せばよい。
finalなclass → 非finalなclass への変更はソースレベルではもちろん、
バイトコードのレベルでも互換性があることが保証されてる。

「継承されない」ことを前提にしたコードだと不都合がでるぞ。
つかそれって穴ってことじゃん。

>>364
finalなclassのクラスファイル中の
access_flagにはACC_FINALフラグが設定されているはずだが。

>>365
漏れは単に、「あとから継承したくなるときにそなえるためfinalを使わない」
ってのに反応しただけ。

>>366
で、ACC_FINALフラグが消えると、どういう場合に互換性がなくなるの?
# 「互換性があることが保証されてる」とは言ったが、
# 「同じバイトコードが吐き出される」とは一言も言っていないのだがなあ。

>>367
ん？どこの誰が finalなclass → 非finalなclass の場合なら
クラスファイルを入れ替えても実行結果は同じとか言ってるのかなぁ
ぱっと見はそう思えるがな、一部例外がある。

# もう一度良く考えてみよ
# 367の考えている意味でもクラスファイルに互換性があるという言葉遣いはちと使い方が違う気がするなぁ

ttp://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html#44987
> Changing a class that was declared final to no longer be declared final
> does not break compatibility with pre-existing binaries.

ﾌﾟ
Java言語仕様を鵜呑みにしているﾊﾞｶ発見

>>364
後から変更できるから、って考えでfinal付けるのはどうもしっくりこないなぁ。
final外しても既存のコードに影響が無いとはいえ。

finalは意図的に付けるもの(デフォルトじゃない)ので、強い意図が欲しいところ。

>>370
もう消えてくれ。

final の話を延々としてる二人も消えていいよ。

もうこねぇよ！うわぁぁぁん！

でもTigerがalphaじゃなくなって、守秘義務がなくなったらまたくるからなぁー
チキショーッ

>>364
> >>363
> > 継承しなくてもいいならfinalをつけるべきってーのはどうかと。
> > あとから継承したくなるときにそなえないと。
> あとで継承したくなったら、その時にfinalを外せばよい。

他人が作ったフレームワークを安易に変更するのはどうかと。

演算子のオーバーロードはできるようになりますか？

>>375
なりません。

さんきゅ。

……ちぇっ。

Sun 以外だったら演算子オーバロードをサポートするように拡張されたコンパイラ実装は存在する

演算子オーバロードなんて極一部のヲタ以外は望んでない。まずそれを知ってくれ

なきゃヤだ。

という人はC++選ぶしな。C#もできるんだっけか。

演算子オーバーロードのようなsyntax sugarで
使う言語を決めるような香具師はおらんとおもうが。

だからJavaはつまらない。

>>382
つまらないと思うんなら使わなきゃ良いだけ。

>>382
演算子オーバーロードがないだけで、つまらないといえるのか。
相当浅いな。

Generics in C#, Java, and C++
http://www.artima.com/intv/generics.html

演算子オーバーロードってどういう時便利なのかさっぱりわからん。
具体例で教えてくれ。cout << xxxx　とかは無しね。あれちっとも
便利でもわかりやすくもないんだが。

>>386
String + String
みたいに、
Object + Object
したいときなんか便利かな。
obj1.add(obj2);
より、
obj1 + obj2
って書いた方が見易い。

まぁ、あまり多用し過ぎると分り辛くなるんで、程々にしとかないと
いかん。この機能は両刃の剣。配列[]とか、==とかの意味を変えら
れるから、下手に使われると混乱するよ。

複素数型に +, -, *, / 等があると .add(), .sub(), .mul(), .div() より
直感的とか。主に数学方面での利用。

正直使うべき側面はあんまり多くないはずとは思うんだけど。

僕のようなC++からJavaへの移行組は、
演算子オーバーロードを使うことによる便利さの向上と可読性の低下の両方を知っているので、悩ましい。

>>387
> obj1 + obj2
> って書いた方が見易い。
で、 1 + 2 + "3" みたいに異なる型で演算子使った場合の規則が更に複雑になる、と。
Java は C++ と違って言語仕様で文字列連結演算子持ってるし。

http://java.sun.com/features/2003/05/steele_qa.html

演算子オーバーロードは技術的問題というよりも政治的・ビジネス的問題。
利点：数学分野のアプリをJavaで書きやすくなる。
欠点：C++で間違った使い方をたくさんされていることが証明済み。
Stringの+と同じようにBigIntegerとBigDecimalでだけ+-*/を
特別ケースとしてサポートするのはいいかもね。

あってる？

>>391
> If not, then maybe we should just make + and - and * and /
> work for the BigInteger and BigDecimal classes
の if not がどーゆーニュアンスで使われてるかよく分からないので、なんとも。

> Stringの+と同じようにBigIntegerとBigDecimalでだけ+-*/を
> 特別ケースとしてサポートするのはいいかもね
何も対策しないと演算子オーバーロードを使うためだけに
BigInteger とか BigDecimal を継承する馬鹿が出てくると思う。

なるほど、そういうときに final ですね。

>>393
BigInteger と BigDecimal を final class にするのは非互換の問題が大きすぎるので却下されると思われ。

おれもBigDecimalだけでもいいから
演算子で処理できるとうれしいなぁ。

イラネ。
Jakarta Velocityみたいなので我慢汁。

なんで String だけ特別扱いなの？
ところで obj1 + obj2 は普通にできるよね。
まあ、大概やりたいこととは違うんだけど。。。
オブジェクト同時の加算はシンプルに文字列連結にしたってことなのかな。

>ところで obj1 + obj2 は普通にできるよね。

できるかボケ

int obj1 = 0;
int obj2 = 0;
obj1 + obj2;

>>399
>オブジェクト同時の加算はシンプルに文字列連結にしたってことなのかな。

>>397-400
　String str = "test";
　Object obj = new Object();
に対して、
　str + obj
がコンパイル時に
　new StringBuffer(str).append(obj).toString()
へ変換されるだけだったと思う。

そんなもん>>397以外はみんな知っている

>>397
> なんで String だけ特別扱いなの？
特別扱いされてるから。
String が特別扱いされてる事例としては
・参照型で唯一、定数式の要素となる。
とかもあるし、今は思いだせんが他にもあったかも。

> オブジェクト同時の加算はシンプルに文字列連結にしたってことなのかな。
+ 演算子の左右のオペランドのうち、片方もしくは両方が String だった場合、
その + 演算子は文字列連結演算子になる。
片方が String でない場合は文字列変換によって String に変換される。

>>401
ちなみに、言語仕様では文字列連結の際に StringBuffer を使わなければならない、
とは一言も書いてないので 例えば java.lang.String#concat(String) とかに変換するコンパイラがあっても全く問題ない。

>>402
> そんなもん>>397以外はみんな知っている

ありが�d。 コンパイル時に最適化されるんですね。
Sun の JDK1.3、1.4 では obj1 + obj2 をコンパイルして Jad したら
もとの obj1 + obj2 に戻りました。 Jad の逆最適化すごいっす。
実行時に最適化されると勘違いしてますた。

jdk 1.5 beta 1 が出たそうだ。
なんか登録せんでもDLいけるぽ。

ここは既存のドキュメントをXML化するところではないだろう。
TeX文書をXMLで記述できるようにしXML文書からWebで公開できる文書に変換できるようにし
かつXML文書からPDF文書に変換し印刷できるようにすることのみを考えれば良い。

1.5のドキュメントをみた。

こりゃ既存のソースにリファクタリングが必要になってきただ。

あのクラスに新しいコンストラクタが追加されちょる。
その引数に新しいクラスが。
ストラテジーパターンみたいなことになってる。

不満があったので俺が昔作ったのと同じようなクラスが追加されとった。
ああ、あの俺様クラスも用済みか。
　

しかももう一つの新クラス

よくみるとEnum型だ

public static enum NewClass extends Enum<NewClass>

なんか記述がいやらしい。Enumはクラスだからよいとしてenumはちょっと

JVMTIか…
ここ一年ほど、JVMDIとJVMPI使って頑張って組んでたのにな…

あう、IA64がなくなってAMD64になってる。
いや別にいいんだけど。

楽しみにしていたprintfだったけど．．．

System.out.printf("%10.0f\n", 0.0);　　// " 0."
System.out.printf("%10.0f\n", 16.0);　// " 16"
System.out.printf("%10.0f\n", 32.5);　// " 33."
System.out.printf("%10.0f\n", new BigDecimal("0.000"));　// エラー

そういう実装か．．．

>>412の発言が納得いかないので

java.io.PrintStreamクラスのドキュメントとソースを調べてみたのだが

public PrintStream printf(String format, Object ... args) {
return format(format, args);
}

何さ？この記述。
ソースをたどってみると
結局シグネチャがほとんど変わらない
java.util.Formatter#format(Locale l, String format, Object ... args)に行き着いた。

args変数の使い方を見るとargs.length - 1とかargs[last]とかいう使い方をみると
Object[]型とあまり変わらないのでは？
FormatString fs = fsa[i];
fs.print((args == null ? null : args[last]), l);
FormatString内部インターフェースの
print()の引数を見るとただのObject型か

void print(Object arg, Locale l) throws IOException

やはり代わらないのか？

#Object[]はObjectのサブクラスかうむ、ややこしいのう。

>args変数の使い方を見るとargs.length - 1とかargs[last]とかいう使い方をみると
>Object[]型とあまり変わらないのでは？

そうだよ。単なるシンタックスシュガーです。

>>413
で、何が納得いかなかったの？

ちなみに、412が挙げた
System.out.printf("%10.0f\n", 0.0);　　// " 0."
には'.'が付くのね．．．

全部で１０桁、小数点以下０桁でフォーマットなんだから当たり前だろ？

>>417
gcc(?) の printf とは挙動が違うよーですね。

printf と 国際化はどう関わっているのだろうか。
「国際化するのが当たり前で、国際化しないのはあくまで悪い作法」という暗黙の前提が崩れていきそう。

java.lang.StringBuilder クラスが新規に追加されている。
シングルスレッド用のStringBufferパフォーマンスアップ版とのことだが、
言語仕様に変更はないのかな？

>>416
おまい、C言語やったことがないのか？10.0fの意味わかってないだろ

C:\users\test>javac -version -encoding UTF-8 j2sebeta\J2SE15Demo.java
javac 1.5.0-beta
j2sebeta\J2SE15Demo.java:13: シンボルを見つけられません。
シンボル: メソッド printf(java.lang.String,int)
場所 : java.io.PrintStream の クラス
ps.printf("%d", 0);
^
エラー 1 個

C:\users\test>


package j2seBeta;
import java.io.PrintStream;
public class J2SE15Demo {

　public static void main(String[] args){
　System.out.println("test");

　　PrintStream ps = new PrintStream(System.out);
　　ps.printf("%d", 0);
　｝



なんでだろ〜
}

やったことないのは>>421

>>422
俺のところでは動くよ。そのオプションだとassertもはねられるのでは？

あれでやってみたがassertは問題なかった。
source -1.5でやっと動いた。
なんなんだ？　デフォルトでsource -1.4扱いかYO!
さすがベータ版だ。

System.out.println("test");
int x0=0,y=1;
assert(x0 > y);
PrintStream ps = new PrintStream(System.out);
ps.printf("%d\n", 0);
int x = 0;
System.out.format("%d\n", x);

System.out.printf("%10.0f\n", 0.0); // " 0."
System.out.printf("%10.0f\n", 16.0); // " 16"
System.out.printf("%10.0f\n", 32.5); // " 33."
// System.out.printf("%10.0f\n", new BigDecimal("0.000"));

実行結果は以下
C:\users\test>java -cp . j2sebeta.J2SE15Demo
test
0
0
　　　　0.
　　　　16
　　　 33.

>>412
> 楽しみにしていたprintfだったけど．．．
>
> System.out.printf("%10.0f\n", 0.0);　　// " 0."
> System.out.printf("%10.0f\n", 16.0);　// " 16"
> System.out.printf("%10.0f\n", 32.5);　// " 33."
> System.out.printf("%10.0f\n", new BigDecimal("0.000"));　// エラー

の説明
BigDecimalだけエラーになると書いてあるように見えるがこれはエラーではなく例外だぞ。
しかもこの例外が、あたかもBigDecimal型特有のものであるかのように見せびらかしてる。
double型でやっても結果は同じだったぞ。
double d = 0.001d;
System.out.printf("%10.0\n", d);


Exception in thread "main" java.util.UnknownFormatConversionException: Conversio
n = '1'
at java.util.Formatter.checkText(Formatter.java:2235)
at java.util.Formatter.parse(Formatter.java:2217)
at java.util.Formatter.format(Formatter.java:2146)
at java.io.PrintStream.format(PrintStream.java:841)
at java.io.PrintStream.printf(PrintStream.java:742)
at j2sebeta.J2SE15Demo.main(J2SE15Demo.java:25)

これも駄目
float f = 0.001f;
System.out.printf("%10.0\n", f);

これも駄目
float f = 0.001f;
System.out.printf("%10.0\n", new Float(f));

fをつけわすれとって
System.out.printf("%10.0\n", d);
を
System.out.printf("%10.0f\n", d);
に戻したときはうまくいった

>>412
おそらくだ。
これは仕様ではないと思われ！
ベータ版だから例外がでると思われ。
ドキュメントのPrintstream#printf()のFormat syantaxをクリックしたら
これを見つけた。BigDecimalについて何かかいている。
http://java.sun.com/j2se/1.5.0/docs/api/java/util/Formatter.html#dndec

java.mathパッケージに新クラスMathContextが追加されとる。

DECIMAL32

こいつをつかって

BigDecimal value = new BigDecimal("0.001", MathContext.DECIMAL128);
とやるとC#の12bbitsのdecimal型同等の(参照)型になるかもしれぬ。
34桁表示が可能らしい。

int precision = 1000;
BigDecimal value = new BigDecimal("0.001", new MathContext(precision, RoundingMode.HALF_EVEN));

precisionという新たなフィールド(MathContext)が現れたわけだがscaleとどうちがうんだか。
scaleが小数点位置からばprecisionは最大桁数そのものを表しているだけなのかな。

BigDecimalに指数関数が使えるようになった！
BigDecimal#pow(int n)
けとint型整数乗のみでほとんどつかえない。

System.out.printf("%10.0f\n", 0.0);
System.out.printf("%10.0f\n", new BigDecimal("0"));

上は'.'が付加されて、下は付加されない。
これもベータだからかなぁ。

System.out.printf("%10.0f\n", new BigDecimal("0."));
とやれば小数点が追加される。
これはベータと関係なさそう。


こまかいことやりたければjava.util.DecimalFormatつかえばいいだけのような
気がするんだがそれじゃ不満？

なにやら
BigDecimal bd = new BigDecimal("0");
BigDecimal bd = new BigDecimal("0.");
BigDecimal bd = new BigDecimal("0.0");
のときは成功し
BigDecimal bd = new BigDecimal("0.00");
BigDecimal bd = new BigDecimal("0.000");
BigDecimal bd = new BigDecimal("0.0000");
などのときは例外が発生するようだ

ベータだな

BigDecimal bd = new BigDecimal("0.01");
とやると
Exception in thread "main" java.lang.IllegalArgumentException: Digits < 0
んなことが。桁数が0より小さい？　んなこたあねえ。明らかにベータだ。

BigDecimal bd = new BigDecimal("0.1");
BigDecimal bd = new BigDecimal("0.10");
BigDecimal bd = new BigDecimal("0.100")
BigDecimal bd = new BigDecimal("0.11");

のとときはまくいく。
明らかにベータというかバグだ。

これはうまくいった。
BigDecimal bd = new BigDecimal("0.10000000000000000000000000000065464684864864686468468487435413161324274987878979878974946847464134864");

BigDecimal bd = new BigDecimal("0.01");
こんなときは苦肉の策で

BigDecimal bd2 = new BigDecimal("0.01");
System.out.printf("%10.4f\n", bd2.doubleValue());

>>412
> System.out.printf("%10.0f\n", new BigDecimal("0.000"));　// エラー

おい。気がついたんだが
よくみると

%10.0fじゃねえか

それで0.000を表したい？
小数点以下には興味がないのにわざわざnew BigDecimal("0.000");

する必要があるのかと小一時間(ry

おめえのバグだゴルァ

Tiger Generics vs. Whidbey Generics
http://weblogs.asp.net/esanchez/archive/2004/02/07/69143.aspx

>>438
これって Java と C# の Generics 比較？
Java 遅！ 誰か解説ｷﾎﾞﾝﾇ！

>439

ArrayListの領域拡張と、Iteratorで回してる点が遅いんだろう

いずれにしてもJavaの欠陥なわけだが

>>440
それはどちらも同じ。
Tiger Genericsは実行効率を上げないがWhidbey Genericsは実行効率を上げる。

いずれにしても、というならば
いずれにしてもint型を使えてしまうことによってもたらされる型安全性破壊という副作用はC#の欠陥なのだが

>>443
それどういうこと？

>>439
前者は値型と参照型で速度比べてるんだから当然といえば当然かな。

速度気にするなら jakarta commons の primitives にある
org.apache.commons.collections.primitives.ArrayIntList とか使えば良いし。

intが使えるかIntegeが使えるかの違いだけですか。
あまりかわらんですな。

そのうちＨｏｔＳｐｏｔやJITが対Generics用に最適化かけてくれるようになるさーと勝手に期待
とくにＩＢＭあたりに。

使用頻度高い標準ライブラリの吐くバイトコードのパターンを検出して最適化かけるなら
実用上も効果高いと思うんだけど。

それともなんか言語仕様的に高速化しずらい要因でもあるんかいな。
その辺の解説詳しくきぼんぬ。>>442

>>444
Java だと struct 考えなくて良いのでより単純、という事だと思われ。

>>447
>>445

C#のintは参照型に返信することもあるし
巨大な値型をうっかり参照型に戻すことを忘れて
とんでもない処理速度低下を招くこともあるんだ罠

>442
そーいやGenericsの話だったな...
結局キャストしてるから遅いのか。

>>439
後者は JVM が interpreter モードで回してる時間が考慮されてないので無意味な比較かと。

あう、書き込み前に結論がでてたみたいっす。>>447
値型とObjectの違いっすか。

Genericsを使いたいような状況で操作対象が値型ですむ場合ってじつはそんなに
ないような気がするかも。

>>448
というよりC#の明示なしによる自動型変換は
Perlで整数型に文字列をつっこんでもコンパイラが文句を言わないくらい恐ろしいってところかな。

J2SE1.5正式版がでてから正式に評価してほしいところ。

しかしC#とJavaとではアプローチが違いすぎのが何かね。

C#は汚くてもいいからとにかく作ってしまえとにかく最適化してしまえ、
Javaは拡張性汎用性を慎重に考慮して即座に最適化のことを考えるべきかどうかは後回しってな
違いから最適化は後回しかもな。

>>447
> そのうちＨｏｔＳｐｏｔやJITが対Generics用に最適化かけてくれるようになるさーと勝手に期待
> とくにＩＢＭあたりに。

generics の情報って class file にどんだけ残ってるんだっけ？

無駄なboxing / unboxingを伴うかどうかの違いだろ？

Whidbeyの方は完全に解決。Tigerは所詮付け焼き刃で何も解決してない。

その結果がこの速度差なわけだ。

>>445
負け惜しみにも程があるな。www
だったらgenericsそのものが要らんな。commonsを使えばいいわけで。(ｹﾞﾗ

>>443
> いずれにしてもint型を使えてしまうことによってもたらされる型安全性破壊という副作用

具体例をどうぞ。どうやったらSystem.Int32の型安全性を破壊できるのか。

Generics in C#, Java, and C++ - Comparing C# and Java Generics (Page 2 of 3)
http://www.artima.com/intv/generics2.html

ここでヘジたんに突っ込まれております。

>>455
ﾊｧ?馬鹿も休み休み言えよ。
Generic型を中間コードのprimitiveに含めたCILと、互換性のためにGeneric型を普通のクラス扱いしてるJavaと
どっちが汚く無理矢理動かしてるか。

Pre-Alpha版のWhidbeyに負けてるJavaって恥ずかしいね。www

>>458
Java generics は基本的に collection にコンパイル時の型制限を導入するだけだから、
メタプログラムとかゆー意味での generics では無い。

メタプログラミングしたい人には辛抱ならんかもしれんが。

>>461
単純である事が美しい、という価値観で言えば Java のが綺麗だね。
汚い/綺麗って主観的なものだし。

>>462
方向性違うのが分かりきってるのに勝ち負けもなかろーに。

Whidbey C#

Console.WriteLine(typeof(List<int>));
実行結果 - System.Collections.Generic.List[System.Int32]

Tiger

System.out.println(ArrayList<Integer>.class);
コンパイルエラー


ﾌﾟ

>>466
> ArrayList<Integer>.class

言語仕様でこんなの許されてたっけか？

>>464
一般的にはそういう点はあるがgenericsについて言うと汚い、中途半端、速くない。
VMを守るという意味では綺麗かもしれないが。

要はJavaは欠陥言語ということでＦＡ？

基地外が暴れてるな

>>468
> 一般的にはそういう点はあるがgenericsについて言うと汚い、中途半端、速くない。
そーゆーのは「こうすればより綺麗、完全、速い」という意見が無ければ無意味。

>>469
言語仕様も調べずに批判する奴は欠陥があるということで。

Tigerで同じことやるにはどうすればいいの？

　Type t1 = typeof(Dictionary<int, string>);
　foreach (Type t in t1.GetGenericParameters()) {
　　　Console.WriteLine(t);
　}

実行結果
System.Int32
System.String

>>467
言語仕様上できないこと自体が大問題

>>473
できません。

っつーか erasure なんだから出来ると思うほうが頭がどうかしてる。

>>468
Java の利用層を考えると適切な中途半端さ(=制限)だと思うけど。

>>473
Javaの限界

>>476
>>473 ができないこともそう思う？

>>474
っつーか、問題あると思うなら Sun に「より良い案」でも提案してやれ。

より良い案「.NETを使え」

なんでもできることが便利に繋がるとは限らないという
C++の反省かからJavaは作られた。
つーか>>466ができると何が便利なんだ？

最近はVB.NETでできることもJavaでできないのか。ﾌﾟ

>>478
JVM の仕様を変えられるくらいならできなくてもいいと思うけど。

>>480
死滅スレでも行け。

>>481
CodeDomでソースを自動生成したり、Reflection.Emitで実行ファイルを動的生成する時に
Genericsを問題なく使えて効率的なものが生み出せる。

Javaの場合はGenericsを使えても実行効率は何も良くならないけどね。(ﾊｹﾞﾜﾗ

C#のほうはランタイムに手が入ったからジェネリクス使ったコード古いランタイムじゃ
うごかないんじゃない？

>>487
動かない。
J2SE1.4のコードがJ2SE1.3のVMで動かないのと同じ。

おまいは実行効率のためにGenericsつかうのか。
入門書のサンプル以外のプログラミング経験ないだろお前。

>>489
実行効率"も"上がる。

>>488
generics 使っても MSJVM で動くバイトコード吐けるけど。

>>486
Java の Generics は目的が違うと何度言えば。

>>488
CLRならside-by-sideで動かすRuntimeのバージョンを切り替えられるので問題なし。

>>485
ちなみに generics な型情報が無いと効率が落ちるって具体的には？

お前ら大事なことを忘れてる。

Tigerの目玉はGenericsだけではないぞ。

enhanced for loop、auto-boxing、metadata、これらを忘れるな！

> enhanced for loop、auto-boxing、metadata、

...。分かってて書いてるだろ。

>>495
今までJavaではサポートしてなかったんですか？ｗ

>>493
古いバージョンでは動かないことの解決になるんか？

>>497
サポートして無いよ。

知らなかったの？

お前らなあ、Javaはクロスプラットフォームなんだぞ。

.NETなんてWindowsでしか動かねーだろ。

>>500
既に Tiger とは関係ない話だな。

.NET 対 Java の罵倒合戦がやりたいなら他所いってやれ。

>>488
ソース上assertはあってもtarget1.3とかやれば古いVMでそのまま動かせるんじゃなかったっけ？
アサーションはできないけとリリースビルドと思えば。
Generics使ったソースはコンパイルオプションで古いランタイム向けのコードは吐けるん？

相変わらずMotifのデフォルトって太字なのね。
相変わらず２バイト文字圏の人のこと考えてないのね。(´･ω･`)ｼｮﾎﾞｰﾝ

Tigerって早くないじゃん。
1.4とあまり変わらない感じがするが。。。

>>502
assertion はこんなところ。
コンパイル時：
・1.4 で導入されたアサーションの意味(キーワードとして)で assert を使っている場合
→ 1.4 では -source 1.4 をつける必要あり。デフォルトでは 1.3 のソースと判断されコンパイルできず。
→ 1.3 以下ではコンパイルできず。
・メソッドや変数名(識別子として) assert を使っている場合
→ 1.4 では -source 1.4 をつけなければコンパイルできる。ただし警告される。
→ 1.3 以下では普通にコンパイルできる。

実行時:
・assert ありの class
→ 1.4 では -enableassertions をつけると有効になる。デフォルトでは無効。
→ 1.3 以下では java.lang.UnsupportedClassVersionError

メモ
- JavaとCLIで、VM上の配列を扱う仕組みは同じ。
　（実装の成熟が同じなら速度は同じになる。）

- C#は将来は、genericsのタイプ情報をメタデータとして保持して
　JITが中で配列を使う処理を実行時に吐き出す予定。

- genericsを使えるC#のサポートはまだ出ていない。
　（C#2.0とwhidbey）

- 今でも速度重視ならばプリミティブ配列、というのは
　どこでもやっていること。（メディアストリームの処理etc.）
　コレクション風にすることも普通に可能。（>>445氏も言ってる通り）

- ボクシングは暗黙キャストであり、C#とJavaに違いはなく、
　またgenericsの速度効率に関係ない。
　>>451や>>457は間違い。

Hejlsberg Talk About Generics in C# and Java
http://developers.slashdot.org/article.pl?sid=04/01/28/1444256&mode=thread&tid=108&tid=109&tid=126&tid=156&tid=187

Jakarta Team Releases New Jakarta Commons Primitives Package
http://www.theserverside.com/news/thread.jsp?thread_id=22331
あってます？

今回の言語仕様の変更は、全部javacが吸収してるだけだから、
早いとか早くないとかそういうのとは関係ないような

プリプロセッサは欲しかったなあ、
と思う今日この頃

test

>>508
マクロは可読性が落ちる原因だから。

プリプロセッサはいらないが
ジェネリクスが入ると型名がえらく長くなることもしばしばだから
typedef がほしいと思うこともある今日この頃。

Eclipse などの IDE のコード補完を使いましょうってことなのかもね。
って 1.5 の構文に対応してるっけか。

>>511
typedef のような別名のサポートは考慮されたが却下されたってどっかで読んだような。

なぜEVALをいれてくれなかったのだろう？

>>514
BeanShell とか使えば？

言語仕様でサポートする必要は全く無いと思うが。

>>514
なんのevalだ？
とある言語のevalを使いたければ

リフレクション、Runtimeクラスで解決できる。

>>508
余計な機能はC++と同じ過ちを繰り返すだけ

>>464
いや、ここで汚い./綺麗と議論していることは必ずしも主観的でないものが含まれている。

汚い　＝　コードの可読性のほかに、拡張性、再利用性、汎用性、移植性、メンテナンス性、ポータビリティが低い

>>461
> Generic型を中間コードのprimitiveに含めたCILと、互換性のためにGeneric型を普通のクラス扱いしてるJavaと
> どっちが汚く無理矢理動かしてるか。

「ﾊｧ?馬鹿も休み休み言えよ。 　」これはC#厨にそのまま言い返してやろう。
ﾊｧ?馬鹿も休み休み言えよ。
オブジェクト指向言語らしくprimitive型を禁止しているJavaと
オブジェクト指向らしさを破壊していGenericsをprimitive型扱いできるようにしてるC#と
どっちが無理矢理汚くしているか。

>>459
>>450

>>518
再利用性と拡張性、再利用性と可読性、拡張性と可読性等々はトレードオフになったりもする。
綺麗/汚いは客観的に決められん。

>>519
> オブジェクト指向言語らしくprimitive型を禁止しているJavaと
primitive型がある事自体、オ(以下略)

>>460
Anders Hejlsberg も詰めが甘いな。
まだまだプログラミング経験が浅い若造というか。

目に見えるものだけが真実だと思いこむ浅はかな厨みたいなところが。

>>521
>　トレードオフ
速度面でな

しかし未来のプログラミング言語では徐々にトレードオンな方向にいくだろう。

将来、汎用プログラミング言語でSmalltalkのように値型がなくなるとすれば
そのうち配列型がなくなりすべてコレクションだけで管理されるようになるかもしれないぞ。

for, if, while, do-while, switchもすべてメソッドやオブジェクトとして扱われる時代が
やってくるかもしれない。

そのときにはリフレクションAPIも大幅に改正されることのなろう。

>>524
> 速度面でな
綺麗/汚いは速度面とトレードオフになるだけでなく、
その要素として >>519 で列挙されたもの同士でもトレードオフになる。

>>525
それは別の言語の話だな。

他所逝ってやれ。

競争原理みたいなもので
お互いよいものができてくれれば満足です

>>519
C#にとってOOはオプションに過ぎんのよ。
事実、C#2.0の新機能の大半は関数型言語の影響。
OOがすべてのJavaとはスケールが違うのだよ。

かっくいーー >>PL/1, Ada

COBOLのEVALUATE文は導入されませんか？
switch文より便利だと思うのだが

>>529
モジュール分割とかはアスペクトの影響をうけているとはおもったが
関数型とはね。

そんなスケールを要求するんだったらC++でもやってなさいっていいたいな

>>531
state パターンとか使うんじゃダメなん？

stateパターンって本当に存在するのか？

>>534
State Pattern はあるよ。>>531 の用途に代用できるかは知らんが。

>>534
アフォかおまえは。結城本でも読んでろ

enum(列挙型)が値型でなくてよかったのう。

しかもenumがjava.lang.Enumクラスでジェネリック型
さすがよく考えたもんだねえ。

Javaのenumは慎重に考えられよくできてるねえ。
ええ感じだね

ポインタ導入してください。

>>538

最初っから有るじゃん。

Java の参照型はポインタで実装されてることが多いけど
ポインタでない実装でも構わないのだよ。

>>538
すでに導入されてる。

>>540
そういう馬鹿スパゲティコード生成機能は不要。
JNIでも使ってなさいってこった。

最近気が付いたんだけど、全部JNIにすると
ものすごく実用的なコードになる。

JINIとJNI

無駄に起動が遅いだけのアプリになるんじゃね？

>>540
そういう話はよく聞くが、実際にポインタじゃない実装をしてるVMはあるのか？

VisualAge for JavaのVMはSmalltalkで実装されて
いるらしいけど、中身はどうなってるんだろうな。

VMじゃなくIDEがアプリとして、じゃなかったか。

別に実装レベルの話じゃなくても、参照という用語にしてるだけで、あれってまんまポインタだろ?
Cみたいに算術演算の対象になったり既存オブジェクトのそれを得るってことが出来ないだけで。
(つまりPASCALでのそれと同じようなもん)

ポインタ論争は10度目くらいでもうお腹いっぱいなので
前橋スレにでもいってください。

<ぬるぽ>

演算子オーバーロードだけは却下。
あんなもん害悪だ。

1.5のjavacがやけに遅いのはBetaだから？

Javaだから

構造体は？

>>554

欲しいか?

>>555
頂戴おにぃちゃん

どこに欲しいんだい？

>>554
クラスがあれば不要。
値型自作機能も不要。

んだ。

typedefも不要ですかぁ。
あったら便利とか思わないですか。

組み込まれている機能と同等のものを、ユーザも作れるようにしたいという要求は自然だと思うのだが。

>>560
typedef なんか何に使うの？

JDK2.0はいつ出ますか？
JDK2.0になった時Javaはどう進化してると思いますか？

>>563
プログラミング言語 C++ 第6版とどっちが先に出るかな？

>>562
ジェネリックな型だとすごく長くなることがあるのでソースが見づらい。
typedef できれば見やすくなる。

>>565
同じ型なのに書く人によって名称が異なる事態が避けられる。
Java は foolproof なのだと思う。

>>565
> typedef できれば見やすくなる。
書いた人間だけは見やすくなる、というなら納得。

読む人間は typedef の宣言を探し回るハメになる。

つまり、Javaじゃなく、君がtypedefをサポートすればいいのさ。

>>560
イラネ。
素直にクラスでtype definite汁

>>565-566
そんなもんJavaでサポートする必要なし。

Jakarta Velocity使って自分で作れ。
それかコード自動生成機能とかでも使え

どうでもいいが、
1.2の段階でJava2とか言ってたけど、2.0になったらどうするんだろね。
Java10とか言うのかね？

大きく変われば順番でjava3なんじゃないの？
J3SDK、J3EE〜って感じになるだけかと

1.0から1.1もすごいかわったけど、1.0はある意味βだったしね

1.3でjavasound、1.4でXML標準サポートが個人的には一番大きかったかな

1.5は言語仕様の追加は大きいけど見た目には反映されないしねー
swingの標準UIがメタルじゃなくなったのはかなり大きいからそこは使いやすいかもしれない

>>571
ほんとーに、どーでもいい話だね。

JSR-199 Java Compiler API とか
JSR-203 More New I/O APIs for the Java Platform ("NIO.2") とかどーなってんだろ？

javarics

>>572
>swingの標準UIがメタルじゃなくなったのは

細かなことだけど、デフォルトの Look and Feel は Metal のままですよ。

Metal のデフォルトの Theme が Ocean ってものに変わったということらしいです。

ttp://java.sun.com/j2se/1.5.0/docs/relnotes/features.html#swing

2.0 では、deprecated なメソッドがすべて削除されているとみた。

今j2sdk1.4.2_01を使っているんですが、これとj2sdk1.5betaを使い分ける事は出来ますか？
出来るのであれば環境変数等はどう設定すればいいのでしょう。
教えてjavaい人。

>>571
そもそも、名前変える必要があるのかと、疑問が。

どっかのニュースで見たとおりSunが新しい言語を作っているとしたら、ありうるかも。
それか一気に名前が変わりまったく別名になるか

>>578
JAVA_HOME を変える。

>>578
Windowsでの話になってしまうがおおざっぱに説明すると

・コマンドライン
JAVA_HOMEがj2sdk1.4.2_01に設定され、%JAVA_HOME%/binにパスがすでにとおっているとき。

ドス窓を開くたびにset JAVA_HOME=c:\j2sdk1.5beta とかやっとく。
面倒ならテキストエディタを開き
set JAVA_HOME=c:\j2sdk1.5betaとかかれたバッチファイルを用意しそれをダブルクリックするか
コマンドラインから実行する。


・Apache Antを使用する場合。
1.5用のコンパイル、実行用のターゲットを作り、
　- javacタスク, javaタスクででfork属性を使う。
　- javacタスク, javaタスクででclasspath要素を使う。


・IDEを使用する。 Eclipseの場合。
- Eclipse起動オプションで1.5用に異なるディレクトリにワークスペースを選択する。
- 1.5用に新たにプロジェクトを作り、プロジェクトを右クリックしプロパティをいじくる。

NetBeansもオプションの設定だけだな
気軽に変えやすいのはJBuilderか

ＸはPersonalで商用利用できるのがいい

sdk1.5をインストールしてJAVA_HOMEやCLASSPATHやPATHなどを色々いじってみたんですが、
genericsを使用したテストプログラムがコンパイル出来ません。
インストールは正常に行われているはずで、DOS窓で
java -version
java version "1.5.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta-b32c)
Java HotSpot(TM) Client VM (build 1.5.0-beta-b32c, mixed mode)
と表示はされてるんですが。
何でダメなのかさっぱりわかりません。
教えてjavaい人

コンパイルオプションで1.5のソース読めるようにしないとダメ
現行の1.4だってデフォルトでは1.4のコードはコンパイルできないのだ

javac -source 1.5 Hoge.java

出来ました！
javac -source 1.5 ですよね。
javac -target 1.5 ってやってました。
1.5回吊ってきます。

ところで、PATHにj2sdk1.4.2_01\binとj2sdk1.5.0\binが両方、
CLASSPATHにj2re1.5.0\jre\libとj2re1.4.2_01\jre\libの両方、
が有るんですが、これはこのままでも問題無いでしょうか？
JAVA_HOMEはj2sdk1.5.0です。
すみませんjavaい人。

PATHは最初から順番に読まれる。
CLASSPATHにはJDKのクラスは書く必要なし。
PATHを書き換えるbatファイルでも作っとけばＯＫ。

問題

複数バージョンのJDKを同一マシンにインストールする場合の注意。

システムディレクトリ(Windows2000 なら C:\WINNT\SYSTEM32 だったかな?)に
java.exe と javaw.exe がインストールされるのだが、それらは削除しておくように。

bin ディレクトリに PATH を通さないと java を実行できないように強制しておくのら。

Program Files の配下の java ディレクトリや javasoft ディレクトリにも
java.exe はある。

実行パスは
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft
にうじゃうじゃ登録されている。

>>590
そいつらは PATH 通さなければ使われないからあんまし関係ない。

>>592
Applet はどれが使われるの？

>>593
インストール時にコントロールパネルに仕込まれた
コーヒーアイコンを開くと好きなのを選べる。

IDEA J2SE1.5 対応
ttp://www.intellij.com/idea/index.html

早いな。。。

>>594
ありがﾄﾝ。知らんかった。
ちょと関係ないけど jar ファイルの関連付け設定とかはないっすよね。

Eclipse の JDK1.5 Pllugin、2.1.2 用もでたね。
Generics も Enhanced For Loop も使えた。

>>597
プッラグインてなに？

１．５プラグインのセットの仕方がわからん。。。

>>599
1.JVMをJ2SDK1.5βにする。
2.プロジェクトに1.5用のフォルダを作る。
3.1.5pluginを有効にする。
4.プロジェクトのプロパティから1.5用のソース・出力フォルダを指定。
というので動いたよ。

1.5用のフォルダって
JDK1.5をインポートしたものですか？

>>601
>1.5用のフォルダって
プロジェクトを右クリック→新規作成→フォルダ（ソースフォルダではなく）
で作ったフォルダ。

俺の場合、それで作ったけど
プロパティ設定でsource指定とoutput指定の時点で
エラーがでるなぁ

JDK1.5 プッラグイン ダウソロード
ttp://www.genady.net/forum/viewtopic.php?t=57
イソスコ方法（イメージ有り） 2.1系も3.0系も同じ
ttp://www.genady.net/forum/viewtopic.php?t=33

Most notably, the new MouseInfo class makes it possible to determine
the mouse location on the desktop.
(最も特記するべきは、この新しい MouseInfo クラスである。
このクラスは、デスクトップ上でのマウスロケーションを取得することを可能にする。)

J2SE (TM) 1.5.0 New Features
http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html#awt

import java.awt.*;
public class MouseInfoTest {
  public static void main(String[] args) {
    while (true) {
      PointerInfo pointerInfo = MouseInfo.getPointerInfo();
      System.out.println( "X:" + pointerInfo.getLocation().getX() +
        ", Y:" + pointerInfo.getLocation().getY() );
      try {
        Thread.currentThread().sleep(3000);
      } catch (InterruptedException e) { }
    }
  }
}

// ついでにJavaコンポーネント外のマウスの動きも、
// なにかのイベントとしてリッスンできると便利そう。

Generics とか使って 1.5 でコンパイルしたものは JRE1.4 で
動くんですよね。でも、1.5 の新しいクラスを使った場合でも
1.4 で動くんでしょうか？

>>606
> 1.5 の新しいクラスを使った場合でも
基本的に無理。
Sun のライセンス無視して新しいクラスを 1.4 の環境に移植すれば使えない事もない。

>>606
>Generics とか使って 1.5 でコンパイルしたものは JRE1.4 で
>動くんですよね。
動く
>でも、1.5 の新しいクラスを使った場合でも
>1.4 で動くんでしょうか？
動かない
ライブラリを追加すれば動く場合もあるので、調べてみた方がいいかも。

というか、1.5ってJVM自体は1.4で、
所謂コンパイラコンパイラの部分で今回増えた機能を実現してるんだっけな。
なので、動くんじゃないかな、調べてないけど>>606

うろ覚えだけど、
-source 1.5 - target 1.4
ではコンパイルできなかったような．．．

>>610
> -source 1.5 - target 1.4
"- target 1.4" では不正なパラメータとか言われるんでは？

>>609
> というか、1.5ってJVM自体は1.4で、
JVM も 1.4 から進歩してるようだが。

>>612
そうだったっけ？
コンパイルした後のclassをデコンパイルすると1.4でいけそうな感じがしたんだが。
なんかトリックつかえないのかな。

基本的に無理そうですね。String クラスでも 1.5 で追加された
メソッドが結構ありますが、自分で明示的に呼ばなくて
どこからも呼ばれない保証が無いですもんね。

>>609
1.5のJVMと1.4のJVMにはある程度の互換性がある、というのは正しいが
1.5のJVMと1.4のJVMは同じである、というのは間違い。

>>614
自分のソース内で 1.5 で新規追加されたメソッドを 1つも呼ばなければ
1.4 でも動く class ファイルを吐くことは可能。

そのための遅延結合だし。

> 所謂コンパイラコンパイラの部分で今回増えた機能を実現してるんだっけな。
…

>>609の使い方も疑問が残るが>>617はコンパイラコンパイラが何かわかってにないに一票

>>616
じゃ、1.5 で拡張された言語仕様の部分はイレイジャで変換されて
1.4 でも大丈夫だけど、追加されたクラスやメソッドは無理ということですね。

。。。Enum は言語仕様だけど Object の新規サブクラスなので
無理なのかな。

> >>609の使い方も疑問
疑問とかゆー問題では無いような気もする。

そもそも、Sun の javac は 1.2 から 1.4 までのソースを見る限り
おそらく手書きで、コンパイラコンパイラ使ってないと思われ。

>>619
> 1.4 でも大丈夫だけど、追加されたクラスやメソッドは無理ということですね。
そーなります。

> 無理なのかな。
そーなります。

何だ。結局互換性ないのか。
だったら.NET2.0みたいにエレガントな実装にすればいいものを。

バイトコードの仕様まで変わったの？
それを変えないためにGenericsが半端になったと思ってるんだけど。
ライブラリとVMを混同してるやつが多くね？

>>623
既存のクラスでは互換性あるけど。

IL 使ってんのに互換性無いっつーのはエレガントと言えるのだろうか？

s/>>623/>>622/

あーあほくさ

Javaって$unの独自仕様だから駄目だな。
CLIみたいに国際標準でないと信用できない。
Java Genericsの非互換性なんてまさにその一例。

> Javaって$unの独自仕様だから駄目だな。
仕様は公開されてるし、JavaCommunityProccess もオープンだけど。
JavaCommunityProccess が信用できない、というなら ECMA だって似たようなもんだと思うが。

> Java Genericsの非互換性なんてまさにその一例。
は？
いやまぁ、言語仕様変えてるのでソース非互換だけど。

>>628
> いやまぁ、言語仕様変えてるのでソース非互換だけど。
完全上位互換だが…

なんか変なのが一匹紛れ込んでるようだねぇ。

え？
JavaってIBMが作ったんじゃないの？

>>631
そうだったらもう少しまともにw

煽りはスルーで。

そういやそうか・・・

>>631
え？
それって .NET とかいう名前じゃなかったっけ？

OSXﾏﾝｾｰ

>>622-635
死滅スレ逝ってやれ。

>>605
これでXEyesをJavaで書けるようにもなったと。

J2SE 1.5 日本語 API ドキュメントっていつでるか予想してください。

PowerBook G5が出る頃

1.4 までのソースは 1.5 の Javac でもコンパイルできる。
1.4 までのバイトコードは 1.5 の VM でも (再コンパイルなしに) 実行できる。

1.5 のソースは
・1.5 での拡張仕様を使わない限り 1.4 までの Javac でもコンパイルできる。使う場合は無理。
・1.5 での拡張 API を使わない限り 1.4 までの Javac でもコンパイルできる。使う場合はライブラリを自分でインポートすれば可能。

1.5 のバイトコードは
・1.5 での拡張 API を使わない限り 1.4 までの VM でも実行できる。使う場合はライブラリを自分でインポートすれば可能。


互換性についてよくわかってないバカが湧いてますけど
言語仕様と API と VM の区別をきちんとつけてください。

JDKのデモ、
おおっ!!というような新しいのが欲しいなぁ

デモは自分で作ってみるのがいいさ。

>>641
>1.5 のバイトコードは
>・1.5 での拡張 API を使わない限り 1.4 までの VM でも実行できる。

1.5で-source 1.5付けてHello, worldコンパイルして1.4とかで実行してみ。
>Exception in thread "main" java.lang.UnsupportedClassVersionError: Hello (Unsupported major.minor version 49.0)
とか怒られるよ。

>>644
1.5alpha だと -source 1.5 -target 1.4 とか出来た。
っつーわけで、その挙動は正式版までの間に変更される可能性あり。

コードを組まず、線を引いたり積み木を組み立てる感覚でアプリを作れるソフトあります？
最終的にJavaやC++等のソースコードを自動生成・出力してくれるような奴なんだけど

>>646
MDAでもやったら？ってちゃんとした実装提供あったっけ？

RationalのXDEとか……50万円なんて価格だけど。

>>646
Sun の BeanBuilder とか。無料です。

>>646
Eclipse　+ Omondo なら全無料

>>646
Eclipse 使っているなら、>>650の方オススメ。
Omondo 使った試しなかったから、存在忘れてた。
未だにどのような作業画面なのか知らない。
（実は BeanBuilder も思い付きで、使っているわけではないです。）

その手のコード自動生成ツールって、まともなのをはき出してくれるのかな？
たいてい…（以下略

自動生成ツールに思い通りのコードを吐かせるための偏向したモデリングをしがち。

MDAは無駄。
モデリングと実装の設計は別。
家やビルを建てるのに、完成予想図にすべてを盛り込もうとするのと同じ、といえば分かるか?

だれも、図面上で釘の打ち方まで指示したくないだろ？

>>646
コード生成は無理だがLabViewってのがある

>>653
> モデリングと実装の設計は別。

論理モデリングと物理モデリングは別だろ。一緒くたにするな。

>>655
勝手に言葉作るな

寅さんでは、VM経由でLANカードのMACアドレスを取得できないかな？

Java厨のレベルの低さが垣間見えるスレですね

>>646
J2EE RIのデプロイツール
JBossのホットデプロイ

>>646
EJBそのものがまさに積み木を組み立てる感覚

EJB使ったことないのがバレバレな発言ですね

java.sun.com 落ちてる？

>>662
おちてっるぽい

まだ落ちてるのか。pingも反応ない。

夕方ごろまではまだPingも通ったんだけどな。
完全に逝っちゃったか。

IBMの攻撃？

IBM　の　こうげき！
IBM　の　かいしんのいちげき！
Sun　は　しんでしまった！

>>665
ping だけだったら反応あるけど。

>>665
中の人が対応始めたのか。復旧するまで帰れないとか。
対応してるのは外の人かな。

Javaは死滅しました。ということかな。

ウェブサーバもつながることはつながるけど、重すぎ。

>>668
おろ？ 反応するようになったね。もうすぐか。

世界中の香具師がつなごうとしてるから激重なだけ？

今日、祭りになるような事柄があるの？

つながりません

Tiger β２！！！




・・・だったらいいな

gcjでコンパイルオプションに -fno-bounds-check　というのをつけたら
行列計算が２倍速くなってC並みになったんだけど、
javacにも同じようなものはないですかね。

Javaでバウンドチェックを外す方法は本当はない。
ただ絶対に境界をミスらないという確証があって
本気でそれをやりたいならsun.misc.Unsafe。

朝9時からためしてるがいっこうにつながりません。
ミラーはないですか？SDKほしいんですが

http://www.google.co.jp/search?q=j2sdk-1_5_0-beta-windows-i586.exe&ie=UTF-8&oe=UTF-8&hl=ja&lr=

>>680
助かりました。ありがとうございます

>>677
JITコンパイラの論文とか読めば必要無い場合に境界チェックしない、
とかそのへんの話が出てくるかもしんない。

演算系ならserverVM使えば速くなるかも

寅さんでも、LANカードのMACアドレスは取れないのね。。。
でも、NetworkInterfaceクラスで、有効なカード名なんかの情報は
得られるんでつね。
MACアドレス取得するには、JNI使うしかないか。。。

>>684
http://pc2.2ch.net/test/read.cgi/tech/1077518664/102-105

>>677　なるほどありがとうございます。
>>683　たしかに　java -server hoge で５割速くなりました。
ただ、unsafeなgcjの方がさらに速かったので質問してみました。
数学ライブラリのjava移植を考えているのでスピード命なもので。

jniでsse3使え

んで、PC用のJavaチップはまだか

ttp://www.mit.msn.to/misc/j2sdk1.4.2.html

　表1 より，j2sdk1.4.2 は j2sdk1.4.1_02 に対して，Java HotSpot Client VM で約 1.08 倍，
　Java HotSpot Server VM で約 2.11 倍のパフォーマンス向上が得られることが分かる．

　j2sdk1.4.2 における Java HotSpot Client VM と Java HotSpot Server VM のパフォーマンスが
　大きく異なることから，SSE/SSE2 命令のサポートは Java HotSpot Server VM での新機能であるかもしれない．

　以上より，科学技術計算（特に浮動小数点演算を多用するもの）を実行する場合には，
　j2sdk1.4.2 の Java HotSpot Server VM を使用することで，実行速度の大きな向上が望めるかもしれない．

だそうだ

>>689
んで、起動速度が犠牲になると。

>>684
っちゅうかAPIレベルでTCP/IPより下のレイヤーをサポートするってこと？
いや、シリアルポートとかはあったけどさ。

>>690
SSE/SSE2命令を使うってだけなら、起動時間には差がでないんじゃない？

ServerVMは起動時に強く最適化するからコンパイルに時間がかかる。

鯖側アプリなんてのは、ライフサイクルが長いから、
起動時に時間かかっても連続稼働中のパフォが上がるならそれでﾖｼ

1.4.2_04

1.4.2_04ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!

修正箇所はどこだー！？

http://java.sun.com/j2se/1.4.2/ja/ReleaseNotes.html

j2se1.5β
http://java.sun.com/j2se/1.5.0/index.jsp
と
eclipse3.0M7
使ってる人いますか？

genericsとか使えるのでしょうか？
バグとかありますか？

>>699
それたしかエクリプススレで既出。
なんか入れればできるらしい。

>>699
というか、このスレでも既出なんだけどな。

隼(1.4)から虎(1.5)へ〜JDK1.5について！
http://pc2.2ch.net/test/read.cgi/tech/1056807119/597-604

ちなみにプラグインを入れてもコード補間がまだ不完全だったりする。
人柱になる覚悟がないなら止めとけ。

>>701
サンクス
無事導入できた。
コード補完は今のところ上手くいってる。

templateすごく便利だ。
なんで今まで無かったんだろう・・・

template?

何だよこれ。C#のまんまパクリじゃん。
Tigerﾏﾝｾｰしてる奴ってｹﾞｲｼの尻の穴なめてるような裏切り者だな。

>>705
それはまちがい。C# に遥かに及ばない。

チンケなtemplateもどきで満足できるとは、Javaとはずいぶんと安っぽいものだな。
C++が到達した STLの有用さ、boostの素晴らしさ、lokiの卓越さを前にして、5年もの
時間をかけたtemplateが自動cast機能程度とは。
恥ずかしいと思わないのだろうか？

>>707
定期煽り乙

Javaしか知らん奴にはただの煽りに見えるだろうが、>>707は事実。
それでも無いよりは嬉しい。

「Javaしか知らん奴」って>>708のことね。
Javaすら知ってるかどうか怪しいが（所詮名前だけ知ってるってとこだろうな。
正論を煽りと決め付けることによって真実から目を背けさせるのは重罪。
色んな意見を取り入れてこうやって成長していくのだから、それを否定する>>708はバカ。

定期煽り乙

ここも春の訪れが早いようで

JavaとC++の差
Javaのオープンソース系の人々 → よく頑張った人たち
C++のtemplate系の人々 → 頭の出来が全く違う人たち

情報科学の研究成果として取り入れられたtemplateは、やはり素晴らしい訳で。
当然の結果として、templateを使う側にもかなりのスキルが要求される。
「Modern C++ Design」で衝撃を受けることもできないようなクズばかりが、
Javaのtemplateを褒めているんだろうな。

>>707
Guy steel あたりに直接メールで言ってやれ。

> Javaのtemplateを褒めているんだろうな。
Java に template はありませんが。

templete と genericsの区別が分からないアフォはお帰りください。

Bruce Eckel's MindView, Inc: 3-10-04 Generics Aren't
http://mindview.net/WebLog/log-0050

Javaのgenericsが糞なのは外出杉。
しかもTigerの新文法はC#の出来損ない。

虎の威を借る狐が増えてるのも春だからかな。

どうせ1.5と過去バージョンの互換性なんてないんだろ。

>>719
オープンソースに頼り切りのJavaプログラマのことですか？

> public class Communicate {
> public <T> void speak(T speaker) {
> speaker.toString(); // Object methods work!
> }
>}
この御仁は interface Speaker があったときに
　Speaker speaker = someSpeakerInstance();
　spearker.toString();
がコンパイルエラーにならない事をご存知ないのかな？

Objectにキャストすればいいじゃん。
genericsの存在理由としては説得力ゼロ。

>>717
そこのサンプルソースって
Java だと普通は interface で解決させるんだけど…

つまりgenericsの必要性はゼロ。
Tigerで騒いでる奴はアフォ。C#の方が10000倍まとも。

> つまりgenericsの必要性はゼロ。
普通は必要性はあると思うけど…
使い方が分からん奴には必要性ゼロかもしらん。

お前ら死滅スレから出てくるなよ

派遣ドカタ用言語は仕様なんか変えてないで馬鹿でも使えるライブラリ量産してればいいんだよ。ｹﾞﾗﾌﾟﾌﾟﾌﾟ

そりゃ、コンパイラ解決による自動cast機能だから、十分に存在意義はある。
ダウンキャストは避けるべし、ってのは昔からの教訓だからな。
今まで放置しておいたJavaが腐っているだけのこと。

春が近いんだねぇ。

>>721
MSに依存しまくりの(ry

春だねぇ。

コンパイル時のことばっかり気にしてないで、
java.lang.reflectパッケージに追加されたクラス群を見てみな。
同じgenericsでも、C++のtemplateに含まれるものとの思想の違いが、
少しは理解できるかもよ。

>>732
ん？
その思想の違いを、お前の言葉で判りやすく説明してみろよ。

javaは先進を目指してる言語じゃないだろ、もともと。

言語仕様をコンパクトに抑えることが目的の一つだったはず。

>>733
見た？見てない？

>>732
どういう意味？

ＶＢＡのマクロのパスワードを解除するマクロカッターなるものが
あるそうですが、どういう風にしてパスワードを解除してるのか
知ってる人がいたら教えて。

また、本当に解除できるのかも教えて。

ﾀｲｰﾎ

>>732
俺も聞きたい。
時間があったら説明して欲しいな。

C++のテンプレートがすごいって言ってる人に教えてもらいたいんだけど、
Javaのgenericsにできないけど、C++のTemplateでできますって事は何？
STLはJavaのgenericsでだいたい同じ事ができるよね？
シリアライズがあるJavaの方が便利な気もするけど。

それからC#とJAVAを両方マスターしてる人に教えてもらいたいんだけど
C#とJAVA1.5の違いってデリゲーションだけですか？

・JavaGenericsとC++Templateの違いはどこか？
・C#とJavaの違いはどこか？

とりあえず、使う使わない、便利不便は別にして
整理してみません？
識者の方よろしくお願いします。
実行速度とかじゃなくて、機能面だけでお願いします。

とりあえず、参考になりそうなサイトです
http://www.mamezou.com/tec/Tips/javaGenericsVsCppTemplate/

<機能編>
・JavaGenericsとC++Templateの違いはどこか？
-閉じた多態(bounded polymorphism)と閉じていない多態(unbounded polymorphism)
・C#とJavaの違いはどこか？

<機能編>

・JavaGenericsとC++Templateの違いはどこか？
-閉じた多態(bounded polymorphism)と閉じていない多態(unbounded polymorphism)
-型パラメーターでnewできない<-これって必要なんですかね・・・

・C#とJavaの違いはどこか？

>>742
741 で挙げたサイトを読めば分かると思うんだけど。。。

C++とJavaの総称性の機能比較一覧
http://www.mamezou.com/tec/Tips/javaGenericsVsCppTemplate/article2.html#Section2
ってのが用意されてました。

これができる、あれができない
という観点で見ても意味がないという事に気づきました。
JAVAスタイルの設計に不要な機能があっても、意味が無いんですよね。
JAVAスタイルの設計において、過去の互換性を保つために
どこを犠牲にしたかを考える事がいいのかもしれません。

また非常に素晴らしいサイトを発見しました
http://www5.airnet.ne.jp/sakuraba/java/laboratory/J2SE1.5/contents.html

C++とJavaの総称
http://www.mamezou.com/tec/Tips/javaGenericsVsCppTemplate/

>>745
それなら、erasure ではない方法で Generics を実現していたなら、
どういうメリット・デメリットがあったかでいいかと。

C#いいかもって思ったり・・・

JAVAとC#の比較
http://objectclub.esm.co.jp/cs-vs-java//cs-vs-java.html

J2SE1.5の新機能
http://www5.airnet.ne.jp/sakuraba/java/laboratory/J2SE1.5/contents.html

C++とJavaの総称
http://www.mamezou.com/tec/Tips/javaGenericsVsCppTemplate/

>>747
そういう視点もありますね。

非常に個人的な意見ですが、
互換性よりも機能をとって欲しかったなー、と。

JavaGenerics概説
http://objectclub.esm.co.jp/JavaGenerics/
によると、
erasureによる欠点は

・Genericクラスの中で，型パラメータ(<T>)をnewできない． -- new T はだめ
・Genericクラスの中で，型パラメータ(<T>)にキャストができない． -- (T)object はだめ
・Genericクラスの中で，型パラメータに対する instanceof ができない．-- object instanceof T はだめ
・Genericクラスを型パラメータ(<T>)から継承できない．
・intなどの基本型を統一的に扱えない．
・例外クラス(Throwableのサブクラス)としてGenericクラスを定義できない

さて、この欠点はどれくらい大きいのでしょうか？

個人的な感想

>Genericクラスの中で，型パラメータ(<T>)をnewできない． -- new T はだめ
これは困りそうだ・・・
>Genericクラスの中で，型パラメータ(<T>)にキャストができない． -- (T)object はだめ
Genericsがあるから、不要なのでは？再帰的に問題になるのか？ｗ
>Genericクラスの中で，型パラメータに対する instanceof ができない．-- object instanceof T はだめ
そんなの当たり前のような・・・無いと困る理由がわからない？
>Genericクラスを型パラメータ(<T>)から継承できない．
難しい・・・やってみないと価値がわからない
>intなどの基本型を統一的に扱えない．
これは重要だ。
でも、確かboxingを導入するんだっけ？
>例外クラス(Throwableのサブクラス)としてGenericクラスを定義できない
わからない・・・

今気づいた事
VMの互換性というけれど
Javaは任意のプログラムを記述できる
ならば
任意のプログラムの表現はJavaバイトコードに変換できる
したがって、互換性による弊害はないはず？

たぶん、記述したクラスレベルの情報が失われるんでしょう。
よって、プログラムを書く分には問題ないけれど、
デバッガや、ＩＤＥを作る人達が困ると、こういう事なんじゃないかな？

C++のtemplateはマクロの延長で、生成的プログラミングのために設計されているのに対し、
Javaのgenericsはコードを生成せずに複数の型が扱えるように設計されている。
この違いは、RTTIへの意識の差が強く関係してるだろうね。
Javaが豊富なRTTIを持っているのに対し、C++は極めて貧弱。

確か数年前にBjarn StroustrupがC++用のちゃんとしたRTTIを設計しようとしてるって話を
聞いたんだけど、どうなったんだろう。

>>751
可能不可能ではなくメリットデメリット。

>>705
templateはC#のパクリじゃないよ。
今のＣ＃ではまだtemplate使えないでしょ。
C#, JavaのtemplareteはどちらＣ＋＋からのパクリともいえるね

>>713
C++のtemplateはスパゲティ化のリスクを伴う恐れがあるぞ。
それを理解できないクズがC++気取りでC++を褒めているんだろうな

>>750
> >Genericクラスの中で，型パラメータ(<T>)をnewできない． -- new T はだめ
> これは困りそうだ・・・
困らない。ちょっと記述が増えるだけ。
しかしこのほうが型安全性は保証される。

> >Genericクラスの中で，型パラメータ(<T>)にキャストができない． -- (T)object はだめ
> Genericsがあるから、不要なのでは？再帰的に問題になるのか？ｗ
> >Genericクラスの中で，型パラメータに対する instanceof ができない．-- object instanceof T はだめ
> そんなの当たり前のような・・・無いと困る理由がわからない？
> >Genericクラスを型パラメータ(<T>)から継承できない．
> 難しい・・・やってみないと価値がわからない
不要だ。なんでもありはリスクを伴う。Javaにtypedefや演算子オーバロードが機能がなくて良かったと
思うのはまさにこのときだよ。

> >intなどの基本型を統一的に扱えない．
> これは重要だ。
> でも、確かboxingを導入するんだっけ？
不要。new Integer(int)で何が不満か？　たいしたコード量にもなるまい。

> >例外クラス(Throwableのサブクラス)としてGenericクラスを定義できない
> わからない・・・
不要。リスキーなことは極力避けるべきだ。

>>756

750は個人的な感想と書いてるが。
要は、自分が何をやりたいか(何を求めてるか)が違うだけだろ。
750はC++のように扱いたい
756はあくまでC++のような複雑な言語仕様にしない＆誰でも安全なコードが書ける
といったJavaの性質を求めてる、という違い。

>>750
> >Genericクラスの中で，型パラメータ(<T>)をnewできない． -- new T はだめ
> これは困りそうだ・・・
無茶でしょ。

仮に generics の実装が erasure でなかったとしても
Java では特定の引数を持つコンストラクタを持つ事を強制できないので
new T() とかが出来るようにするのはかなりの言語仕様の変更を要する。

>>752
> この違いは、RTTIへの意識の差が強く関係してるだろうね。
他にも型パラメタに指定された型毎に新しいクラス作ってくと
JIT が生成するネイティブコードのサイズが馬鹿にならんとゆー問題もあるらしい。

>>758
C++ みたく閉じていない多態にすれば new T できるよ。
もっとも、>>759 の問題が顕著になるが。

閉じていない多態にすると、例えば interface 使うべきところで
template 使えたりとかオブジェクト指向原理主義から見ると
汚いソースが書きやすくなるのがアレだったのかも。

非常にすばらしい文献なので、まとめておきます。

JAVAとC#の比較
http://objectclub.esm.co.jp/cs-vs-java//cs-vs-java.html

J2SE1.5の新機能
http://www5.airnet.ne.jp/sakuraba/java/laboratory/J2SE1.5/contents.html

C++とJavaの総称
http://www.mamezou.com/tec/Tips/javaGenericsVsCppTemplate/

JavaGenerics概説
http://objectclub.esm.co.jp/JavaGenerics/

JavaがC#の言語仕様に追いついた感はありますが、
デリゲーションとインデクサの点でちょっと不満がある
ような気もします。
（この点はどうなんでしょうか？）

Javaのメリット
・winでもlinuxでも心配なく相互運用可能。
・オープン（無料って側面がでかいかも）な開発環境や
その他もろもろが使える。

C#のメリット
・言語仕様がちょっとお得。
・CLRが無くても動くwindows用コードが作れる？

>> ・CLRが無くても動くwindows用コードが作れる？
作れない。

>>762
デリゲーションは interface と、その実装クラスで置き換えられるので必要ないといえば必要ない。
インデクサはあれば使うけど無ければ get(index) set(index,obj) すればいーだけだし。

>>764
get(string), set(string,obj) も追加しとけ。