J2SE 1.5のアルファ版が登場 53
ストーリー by yoosee
君よ、人柱たれ 部門より
君よ、人柱たれ 部門より
tnk曰く、"IT Proの記事が報じたところによると，Sun MicrosystemsからJ2SE（Java 2 Platform, Standard Edition）の次期バージョン，J2SE 1.5の Early Access 版が公開された。J2SE 1.5 (コード名「Tiger」)は，いままでわりと保守的な更新を続けてきたJavaにおいては，かつて例のない大きな改良が加えられる。C++のtempleteに相当するGenerics機能（JSR-014）のような，長いこと待望された機能が追加されるほか，Autoboxing/Unboxingなど（JSR-201）のようにC#/.NETを意識したかのような機能追加もある。GC の変更や JMX の採用も大きなトピックだ。実際の完成/普及までには時間がかかるだろうが，期待と不安のいりまじる新バージョンである。人柱希望者はおためしあれ。"
Swing (スコア:1, 参考になる)
うちのマシンはクラシックスタイルなのに。
Metalで動いていたアプリケーションも変な感じ。
デフォルトLookAndFeelは、コンパネで変更できるといいのになぁ。
Re:Swing (スコア:0)
Re:Swing (スコア:0)
Re:Swing (スコア:0)
仕事でGUIアプリケーションを作る際に、Javaという選択肢が増えました。
デフォルトのLookAndFeelがWindowsと違うと、Javaを知らない一般のユーザーは戸惑うことが多く、今まではSwingを使うことは難しかったのです。
Re:Swing (スコア:0)
起動時に java -Dswing.defaultlaf=... とかやれば変えられんかったっけ？
恒久的に設定したければ /lib/swing.properties だったかを作ればできたような…
Re:Swing (スコア:1, 参考になる)
%JAVA_HOME%/lib/swing.properties だった。
しゃ～ぷ (スコア:0)
# ネタ投入
Re:しゃ～ぷ (スコア:2, 参考になる)
追加された言語仕様も便利なのですが(→J2SE 1.5 虎の穴 Java 2 Platform, Standard Edition v1.5 の新機能 [airnet.ne.jp])
SwingのWindowsへの適合度合いが上がったのと、動作が速くなったのが
いい感じであります。
JavaでWindowsアプリを作ってもいいかも。
Re:しゃ～ぷ (スコア:0)
じゃ、追い越すと、Ｄになって…Delphiですか？
Re:しゃ～ぷ (スコア:1)
Re:しゃ～ぷ (スコア:1)
で、中間コード版のD#とか。(意味無し)
Re:しゃ～ぷ (スコア:0)
その頃は、Javaはまだ怖いしC++は嫌いだしという消極的理由で使ってました。
現時点でDelphiの売りってありますか？
#あえて煽り気味
Re:しゃ～ぷ (スコア:4, おもしろおかしい)
爆速コンパイルでターンアラウンドが短くて、終電ギリギリまで粘れるとか、
今頃 Win95 向けの仕事がきてもなかなか逃げられないとか、
Borland には MSDN がないので年貢が安いとか、
入門書レベル以上の本が少ないので本代が抑えられるとか、
Internet 上でも情報が爆発していないので何箇所かを
watch していれば、それなりにポイント情報が集まるとか、
某MLで次の優待販売見送りという投稿が頻発するとか、
Delphi 7 の次の修正差分はいつでるんだろう？とか。
ううむ、応援しているつもりなのだが、なんかちがうな。
Re:しゃ～ぷ (スコア:0)
JBuilder とか含めると、半年で、MSDN でも十分元取れる位払っているのに去年気づきました...
何も言わずに承認する上司も偉いけど。
Re:しゃ～ぷ (スコア:0)
PASCALで書けるってのは、最大の売りだと思うなぁ。
それしか売りがないとも言うけど。
Re:しゃ～ぷ (スコア:2, すばらしい洞察)
俺としては、PASCALであることはむしろ、盲腸みたいな古臭い部分、と捉えています。
＃そうでないとそもそもこの商品は存在しなかった、という指摘はさておくとして。
それこそJavaと比較して痛感することなんですが、
PASCALは、Object指向言語として使うには、構文上の「順序」の縛りがキツすぎます。
2つの関数やプロシジャが「相互参照(=相互呼び出し)」することは、ぶっちゃけ言えば稀なので、
その際に順序の縛りの限界を超えるための特殊な書き方を強いられる(フォワード宣言でしたっけ)
のは我慢できるんですが、
2つのクラス(というか元を正せばデータ構造)が「相互参照」することは非常に頻繁にある出来事なので、
特殊な書き方がいちいち強いられるのは、苦痛でしかないです。
その点、Javaのようにクラスやメソッドや属性の記述順序を一切気にしなくて良い言語仕様のほうが、
ずっと使いやすいんです。
強型言語の範囲内でも順序の縛りを減らすのが可能であることは、それこそJavaが実現できていることからも明らかであり、
「強型言語→PASCAL(のやりかた)」という古典的な常套句は、今では古すぎると言えそうです。
他にも細かい所は一杯…。
総じて、元の(Turbo)PascalとDelphiとの差の部分は、大抵どれも「お、いいねえ」という感じがするんですが、
Pascalから引きずってる部分については、あんまり良い印象を受けたことがないです。
で、JavaとDelphiの両方を見て(Delphiと同じ作者が)作った言語が、C#なんだろうなーと(^^;
個人的には、なんでBorlandは自分で新たに言語を作らなかったのか？と疑問です。それこそMSがVBを出してるように。
まあ、Pascalという技術的資産(および文化的伝統？)が同社内には有ったんだろうな
(そして、それ以外は無かったんだろうな…)と邪推しています。
＃あと、Delphi(くらいの時代の言語)にコレを言うのは酷なんですが、
＃本格的にObject指向する言語では、やっぱりガベコレが無いとキツいです。
＃DelphiではWidgetとかのメモリ管理のSolutionはキチンと有るんですが、それ以外のObjectのほうが人力管理しかないんで、
＃そういう部分にばんばんObjectを使う気力が萎えるんですよね…
＃メモリ管理を自分でしなくて済むかどうかは、重力の有無みたいなものだという気がしています。
Re:しゃ～ぷ (スコア:0)
そんな七面倒臭いことを言つてるなら、なぜ今でも
Javaなんか使うのかよくワカラン。
SmalltalkなりClosなりを使つたほうが
ずつとすつきりするだらうに。
Re:しゃ～ぷ (スコア:1)
「使う」の主語がもし俺G7だというならばですが、
「(俺が)使う」とは言っていません(^^;＃確かに使ってもいるけど、それはここでは無関係です。
JavaとDelphiって、成立年代が近いとか、
どちらもコンパイラ型だ(ターゲットは違いますが)とか、
Object変数が参照オンリーだとか、一方プリミティブ型が有るとか、
通じるものが色々あるんで、
ちょうど「比べるのに都合がいい」組み合わせなんです。
特に順序縛りの問題は、この2つの言語を比較するのが
一番説明し易いんですよね。
>SmalltalkなりClosなり
箱庭かどうかはさておくとして、Smalltalkとかの
弱型かつインタプリタな…つまり「各種のマッチングを実行時に動的に取る」
ような言語(処理系)は、ここで一緒に論じても無意味かと。
ただ、総じての評価という意味では、
俺としては最近はかなり弱型な言語に傾いているので、
それ系の言語使えばDelphiだのjavaだのの問題を丸ごと忘れられるぞ、
という指摘が俺としても有りではありますが。
で、箱庭問題や自国愛(藁)や落とし所の気に入り度とかでいえば、
俺はRubyが今のところ一番っすね。
そういやRubyは最近マーチンファウラーたん(^^;も使ってるそうで…
＃あとBlock(イテレータ)みたいなものが無い言語はもう嫌です(^^;
＃Tigerの [airnet.ne.jp]もなんかRubyとかに比べれば(汎用性の低さという意味で)イマイチっぽく見えますし。
＃てか、どんなInterfaceをどう使うかをユーザが用意できたりは、しないんだろうか？
＃get(i)を使わないから遅いっていうなら、get(i)を使うかどうかを選択するシクミが有れば良かったわけで。
Re:しゃ～ぷ (スコア:0)
Re:しゃ～ぷ (スコア:1)
櫻庭さんの拡張 for の解説記事のページ [airnet.ne.jp]のマイクロベンチマークですが、
私のマシンでは ComparisonTest1 をそのまま使用した場合、となりましたが、for 文と拡張 for 文の順番を入れ替えた場合となりました。
(拡張 for 文の方が若干遅いのは、測定誤差か Iterator の生成コストだと思われます)
同様に、ComparisonTest2 もそのまま使用した場合、となりましたが、for 文と拡張 for 文の順番を入れ替えた場合となりました。
Re:しゃ～ぷ (スコア:0)
>＃本格的にObject指向する言語では、やっぱりガベコレが無いとキツいです。
>＃DelphiではWidgetとかのメモリ管理のSolutionはキチンと有るんですが、それ以外のObjectのほうが人力管理しかないんで、
>＃そういう部分にばんばんObjectを使う気力が萎えるんですよね…
>＃メモリ管理を自分でしなくて済むかどうかは、重力の有無みたいなものだという気がしています。
Re:しゃ～ぷ (スコア:1)
す、すばらしい！！！
＃もし(ライセンス的に)可能なら職場でも紹介して…あわよくば仕事も楽になるんでなぃかぃ？
ところでこれ、Object間の参照切れへの対策への対策…
つまり例えばNotificationとか…はどうなってるのかな？
あとで読んでみます。わくわく。
Re:しゃ～ぷ (スコア:0)
構文チェックがイヤなくらい強力なとこかな。
Re:しゃ～ぷ (スコア:0)
(それならC++Builderでもいいけど)
MFCが嫌いで、SDK生も嫌、.netも使いたくない場合は
今でもDelphiを使うメリットは十分にあります。
＃今後が不安ではあるが・・・。
Re:しゃ～ぷ (スコア:0)
Re:しゃ～ぷ (スコア:2, 興味深い)
と書きたいところですが、お互い最初から言語仕様もコンセプトも似すぎてるので
このままでは清々しいほど潰しあいになりそうな予感。（もうなってるか）
# JavaからC#に乗り換えてしばらく経つけどID
--- （´-`）｡oO(平和な日常は私を鈍くする) ---
Re:しゃ～ぷ (スコア:1)
開発者の方も「C#は無視できない。autoboxingなどは良いアイデアだから
直接取り入れる。」とか言ってたような。今回のJavaは全然違う言語の様な
感じがしますが、追加機能は的を射ているしコンパイル後にバイトコードが
互換性がとれているところが素敵です。
個人的には、C#の方がシンプルで使いやすいと感じます。見た目も格好良いし、
プログラマはOS非依存を謳いながらXP,Longhornの新機能を堪能できます（？）。
が、バージョン互換性のないものがガスガス出るので、まともに追いかけると、
血の出る思いをするでしょうね。
＃Alpha版の情報をITProの記事にして大丈夫だったんだろうか
Re:しゃ～ぷ (スコア:0)
Re:しゃ～ぷ (スコア:1)
Javaがはやりだした頃と同じ雰囲気がします。
しかし、VBの仕事は自然と.NETに移行するだろうから、
そのタイミングでC#の仕事が増えるのではと期待してますが。
# 仕事ではASPばかりで「VBス」と聞くだけで逃げたくなるけどID
--- （´-`）｡oO(平和な日常は私を鈍くする) ---
Re:しゃ～ぷ (スコア:0)
JAVAもC#も元の設計者って同じなんでしょ？
MSが引っこ抜いたと聞いてます。
Re:しゃ～ぷ (スコア:2, 参考になる)
C#設計者のことがAnders Hejlsbergならば彼はDelphiの設計者です。
Re:しゃ～ぷ (スコア:0)
彼は確かにDelphiの設計者ですがＭＳに移ってからはVisual J（だっけ？なくなった奴）の
開発をしてたんじゃなかったかなぁ・・・
その後C#に移ったの？？
日本のBorlandカンファレンスでDelphi自慢
Re:しゃ～ぷ (スコア:0)
デリゲートなんかはよくも悪くもMS的な機能だし、
その方針はC#に受け継がれているみたいね。
Re:しゃ～ぷ (スコア:0)
VB.NETコマンドラインコンパイラだって入ってるし、
C/C++コンパイラだってついてきちゃうんだぞ。
残念ながらインポートライブラリが皆無に等しいんだけどもね。
あと環境選ぶのは相手がMSなんだから諦めてね。
Re:しゃ～ぷ (スコア:0)
Java3 or Java++ or Java# ? (スコア:0)
ちょっと変えてほしいですね。
私としてはこれだけ普及した後にこれだけ変更したものが出るなんて、
ああ、またバージョン間で互換性のないコードが増える・・・とため息が。
＃1.3→1.4間でバイトコードレベルで互換性がないばっかりにえらい
＃ハマったことがあるので・・・
Re:Java3 or Java++ or Java# ? (スコア:1)
癖があるので順当(?)に行けば Java5 ですが...
Solaris 2.7/2.8/2.9 が Solaris7/8/9 とか。
Java 1.2 が Java2 とか。
Java2 1.3/1.4 ってのが謎。
FF-X2(ファイナルファンタジーテン・２)みたいなもんか。
Re:Java3 or Java++ or Java# ? (スコア:1)
Java2は言語仕様のバージョン。
1.3/1.4はJava SDK(Standard Development Kit)のバージョン。
Re:Java3 or Java++ or Java# ? (スコア:0)
# なんか誤解してる?!
Re:Java3 or Java++ or Java# ? (スコア:0)
保守リリースもどきだったから、ということで。
Re:Java3 or Java++ or Java# ? (スコア:0)
Re:Java3 or Java++ or Java# ? (スコア:2, 参考になる)
Re:Java3 or Java++ or Java# ? (スコア:0)
1.4のバイトコードだとpreverify通りませんから。
Re:Java3 or Java++ or Java# ? (スコア:0)
それは、JavaMEのツールに問題があるんでしょう。
Re:Java3 or Java++ or Java# ? (スコア:0)
>それは、JavaMEのツールに問題があるんでしょう。
そう？J2SEになったときは Assertionが入ってるから
バイトコードレベルで互換性がなくなってるはずだけど…
今回の改修はコンパイラレベルで対応してるはずだから
バイトコードの拡張はなかったはず。
Re:Java3 or Java++ or Java# ? (スコア:1)
Re:Java3 or Java++ or Java# ? (スコア:0)
1.4 でもデフォルトでは javac -source 1.3 相当なので
明示的に javac -source 1.4 Hoge.java とかしないと assert は使えませんが。
assert ってバイトコードではどーなってんだろ？
Re:Java3 or Java++ or Java# ? (スコア:0)
は、
if (assertionEnabled) {
if (!hoge) throw new AssertionError();
}
のようにバイトコード化されて、assertionEnabledがfalseの場合は、全体をJITが消すんじゃなかったっけ？
Re:Java3 or Java++ or Java# ? (スコア:0)
Re:Java3 or Java++ or Java# ? (スコア:0)
バージョン間で互換性の無いコードって、具体的には？
> ＃1.3→1.4間でバイトコードレベルで互換性がないばっかりにえらい
1.4 からデフォルトで javac -target 1.2 相当になった事を言ってるのだろうか？