【Java】次世代Java・J2SE1.6の動向【Mustang】

http://www.itmedia.co.jp/news/articles/0404/07/news018.html


マルチタスク実現へJava言語改良
Sun幹部によると、2005年に一般リリース予定の「J2SE 1.6」には、
Javaバーチャルマシン（JVM）のアプリケーション共有を強化する「分離」機能が備わり、
ローカライズコンピューティング処理実行のための分離が可能になるという。

米Sun Microsystemsは、Javaバーチャルマシン（JVM）内部での
アプリケーションマルチタスク実現に向けてJava言語の改良に取り組んでいる。
カリフォルニア州サンノゼで開催のClusterWorld Conference & Expoで4月6日、同社幹部が明らかにした。

SunのJavaアーキテクト、ムラリ・カウンディンヤ氏によると、
今秋β版が登場し、2005年に一般リリース予定の「J2SE 1.6」には、
JVMのアプリケーション共有を強化する「分離」機能が備わる。
この機能によってローカライズコンピューティング処理実行のための分離が
可能になり、第2のJVMを要求することなくJVM内部でマルチタスクが行えるようになるという。

　またJ2SE 1.6では、Javaプログラム間の高速通信を可能にする
Sockets Direct Protocolのサポートが計画されている。カウンディンヤ氏によると、
J2SEに施された改良は、その後間もなくJ2EEにも組み込まれる予定。

　1月にβ版がリリースされたJ2SE 1.5は、6月のJavaONEカンファレンスで正式リリースの
運びとなる見通し。J2SE 1.5では、Javaプログラミングの簡易化に焦点を当てている。

2

サンの収入源って何？

関連スレ (J2SE1.5)

Cから虎へ〜JDK1.5について！Part2
http://pc5.2ch.net/test/read.cgi/tech/1079438337/
隼(1.4)から虎(1.5)へ〜JDK1.5について！
http://pc5.2ch.net/test/read.cgi/tech/1056807119/

未来のJavaOS？

http://pc5.2ch.net/test/read.cgi/tech/1080961057/l50

>>6はネタスレか・・・

JavaChipやJavaOSってまだ制御系のみで使われてるレベル？
そろそろサーバー向けのJavaChipやJavaOSが出てきても良さそうなもんだが
1.5出さなくていいから1.6のリリースを前倒ししてくれんかのぉ＞Sun

確かに1.5いらん
1.6では文法を1.4に戻してほしい

1.4に戻して欲しいならそのまま1.4を使い続けていればいいだけのこと。

>>8
Javaによるリアルタイム処理が確立するまでまだまだ無理だのう

>>11
RTSJ仕様は固まっているし、プロダクト実装もある。

>>8

メモリがたくさん使えるサーバ環境なら無理してJavaChip作るよりGHzクラスの
CPUでHotSpot動かした方が楽だし速いんだと思う。

JavaChipって制限の多い携帯やPDAでこそ有効だと思う。

巨大なメモリ上でHotspot＋CopyGCで超贅沢高性能プログラミング。
性能が必要な場合の手抜き開発時におすすめ。

制御系でJavaって使われてるの？？
RTSJは知らないけど、Javaでリアルタイム処理は無理でしょう
GCも確実にコントロールできないし。
だいたい、Javaチップっていっても制御系で使える程のパフォーマンスは出ないと思うんだけど

そんな事より、GUI強化しろ！
インプット／アウトプットがしっかりしていないのに
中身ばかり改良されても使い物にならん

>>16
Swingは結構まともだと思うけど。少なくともイントラWebアプリなんぞと
いう糞なGUIより100倍マシでしょ。

なんでイントラWebアプリガはやるのか、わからん。
たいして安くならんだろうし、保守改修は面倒だし。

・GUI は馬鹿でも使えるように可能な限り簡単にしなくてはならない
・インストールやバージョンアップは言ってもしてくれない
という理由で。

これは全てのJavaアプリケーションをひとつのJVM
つまりひとつのプロセス空間で処理するっていう技術ですか？

JRM(JavaRealMachne)って話もあったよね。あれどこいったろ。
バイトコードが普及した頃に出しますとかいってなかったっけ？
バイトコード直接実行チップ。やっぱりハードウェア設計的に
問題があったのかね。ハードは難しいから、ソフト屋の妄想どおりには
いかないね。

>>20
ハードっていっても、結局開発言語で作るからソフトとあんまりかわらんのだけどね。
特殊な制約があるソフトだよ。

>>16
J2SE1.5に期待せい。
つーか、そもそもそういうのって言語仕様の話題から遠のいているし。

Java to gain multitasking improvements
Virtual machine to be fitted with application sharing
http://www.infoworld.com/article/04/04/06/HNjava16_1.html

VERSION CODE NAME RELEASE DATE
JDK 1.1.4SparklerSept 12, 1997
JDK 1.1.5PumpkinDec 3, 1997
JDK 1.1.6AbigailApril 24, 1998
JDK 1.1.7BrutusSept 28, 1998
JDK 1.1.8ChelseaApril 8, 1999
J2SE 1.2PlaygroundDec 4, 1998
J2SE 1.2.1(none)March 30, 1999
J2SE 1.2.2CricketJuly 8, 1999
J2SE 1.3KestrelMay 8, 2000
J2SE 1.3.1LadybirdMay 17, 2001
J2SE 1.4.0MerlinFeb 13, 2002
J2SE 1.4.1HopperSept 16, 2002
J2SE 1.4.2MantisJune 26, 2003

Future Releases
J2SE 1.5.0TigerNot yet released
J2SE 1.5.1Dragonfly (dragon)Not yet released
J2SE 1.6.0MustangNot yet released

パンサーとかタイガーとか負け組みにはネーミングの共通点があるのか？
圧されてるのを感じ取っているので、無意識にそういう強いものの名前を使うのだろうか？
虎の威をかる狐。

それをいったらM$のヘイルストームとかはどうなんだよw
やけに強がってるような名前だろw

.NETなんて名前、まさにドットネット戦略、,netドメインという虎の威をかる狐だね

>>20
それそのものなのか知らないけど関係有りそうなので張っとく。
火星探査車の制御に使ってるそうな。

ttp://www.co-nss.co.jp/topics/press-030722.html
ttp://www.mirai-city.org/blog/archives/000020.php

>>24
J2SE 1.5.1 ・・・ とんぼ

J2FF 1.0 まだぁ〜

Java2 Final Fantasy

J2RRもほしいぞな。

Java2RidgeRacer

ほしゅっとな

デリゲートほしい。

JSFバグあるぞ。はよなおせ

SEじゃない(・Ａ・)

J2SE1.4.2_05でたんだから落ち着けよお前ら

落ち着けるかぁ。
SE5はよ出せ。

>>34
この場合、JSFの仕様にバグがあるということ？

VERSION CODE NAME RELEASE DATE
JDK 1.1.4SparklerSept 12, 1997
JDK 1.1.5PumpkinDec 3, 1997
JDK 1.1.6AbigailApril 24, 1998
JDK 1.1.7BrutusSept 28, 1998
JDK 1.1.8ChelseaApril 8, 1999
J2SE 1.2PlaygroundDec 4, 1998
J2SE 1.2.1(none)March 30, 1999
J2SE 1.2.2CricketJuly 8, 1999
J2SE 1.3KestrelMay 8, 2000
J2SE 1.3.1LadybirdMay 17, 2001
J2SE 1.4.0MerlinFeb 13, 2002
J2SE 1.4.1HopperSept 16, 2002
J2SE 1.4.2MantisJune 26, 2003

Future Releases
J2SE 5.0TigerNot yet released
J2SE 5.1Dragonfly (dragon)Not yet released
J2SE 6.0MustangNot yet released

1.5が5.0
1.6が6.0になるってことか。

なるほど〜ん

よく、「JDKをインストール」っていうけど、JDKって1.1までなんだよね。

J2SE5はまたJDKという言葉を使おうとしているっぽい

ファイルはjdkだね。

1.6でなにが新しくなるの？当分1.4でいいかなって思ってるんだけど。

>>44
1.5のバグが取てようやく使い物になる･･･かもしれません。

>>44
バージョンの数字の振り方が、新しくなります。
1から43までの数字が、６つ並びます。

>>44
せめて1.5くらいは欲しいとは思わんのか？

1.6ではJava自体がまるでOSのように振る舞うとか

とりあえずウィンドウが3Dでおりたためるな。

>>47
>1.6ではJava自体がまるでOSのように振る舞うとか
VMを共有することだと思うんだけど始めバグだらけの悪寒

>>49
1.5 で既に導入されてるから 1.6 ではそれ程でもないと思われ。

1.6がやろうとしてることって、独自のカーネルを単一プロセス上で使いまわすってこと？

つまりVMWareΣΣ(ﾟдﾟｌｌｌ)

と、VirtualPC

ついでにVNC Server

>>50
1.5で導入されてたっけ？

ドルフィンではどんな機能が強化されるんだい？

超音波で、仲間とコミュニケーションが取れます。

エコーザドルフィンか

肥大化イラネ。

卓球の福原愛が肥大化すると、ソフトボールのピッチャーになりますね。

http://java.sun.com/j2se/1.5.0/ja/download.html

J2SE5.0 RC ｷﾀ━━━(ﾟ∀ﾟ)━━━!!!!!

hosyu

>60
ｷﾀ━━━（ﾟ∀ﾟ）━━━!!!! じゃねーよ。
メンテか？socket errorが返ってくるぞ。

>>62
ふつーに開けるが。

>63
JDKのDLでのお話。

>>64
ダウンロード普通に始まる。こちらfirefox0.9.3。

>65
そうか、騒がせて済まぬ。
ルータから環境を見直してみる。
Mozilla 1.7.3とIE6SP1で駄目だったから早とちりした。

新ＡＰＩもいいが、それまでの特に基本ＡＰＩを見直して更新せよ。
jakarta commonsにサジを投げるな。
演算子オーバーロードをもう追加せよ。

演算子オーバーロードは不要。

いや絶対に必要だ。
例えばコレクションクラスでList listやMap mapなら
list[0]とかmap[key]という風に取り出せれば、すっきりする。

>>69
いやん

>>69
JSPではすでにできるからいい。

そんなに必要だと思うならプリプロセッサ使うとか作るとかすれば？

三人も釣られてるよ……
オレは三人目なんだけどさ orz

まぁ話題もないし。
これ以上言語仕様が膨れると保守やリファクタリングがやりにくくなるから
仕様の追加は必要ないかな。

Map[key]の形が使いたいのってプレゼンテーション層だけの話なんで、そこらへんで対応すればいいや。

Javaの次期バージョン「Mustang」、2006年デビューへ
http://www.itmedia.co.jp/enterprise/articles/0410/01/news009.html

北ー

ついにSolarisとJavaの統合がなされるのですね

1.5正式版ｷﾀ━━━━━(ﾟ∀ﾟ)━━━━━!!

Windows版JDKとWTKってレジストリとか弄らないでそのままコピーするだけでも使える？
よその環境にコピーと環境変数変更だけで使いたいんだけど

なんか、バージョン5になっているんだが。。。見間違い？

Java2の次はJava5であってるよ。まあSUNだからな。Java2だって1.2だし。

>>79
JDKはできる。WTKはしらない。

>>80
気づくの遅すぎ。

5入れてみた人いる？使い勝手はどうよ。
ていうか入れて大丈夫なのか？

>>84
開発環境に入れるのなら問題ないんじゃない？
結構いろんなもんが速くなってていいよ。
メモリ使用量も少なくなってるし。

>>84
入れるのが不安なら入れなければ良いだけ。

>85
おお、やっぱり速くなってるのか。
ニュースでもVMをいじったらしいことが書かれてたから期待してたんだ。
重たいのはやっぱりネックだしなあ。

>86
そりゃそうだ。でも入れたらどうなったか聞いてみたいのが人情だろ。

「嫌ならやらなければいい」みたいな生産的じゃないレス多くなったな。

> 「嫌ならやらなければいい」
オレもそう思うし。

> 生産的じゃない
まぁ 2ch だしねぇ。あんたのレスも（オレのもだけど）生産的じゃないし。

>>81
> Java2の次はJava5であってるよ。
間違ってるよ。
http://java.sun.com/j2se/1.5.0/docs/index.html
> JavaTM 2 Platform Standard Edition 5.0 Development Kit (JDK 5.0).
ちゃんと Java2 って書いてあるよね。

今1.5ダウンロード中
しかし、今更「外部バージョンを５にしました」
本当に消費者を混乱させるのが得意だなぁ・・・

どうですか、C#に似た使い心地は？ﾌﾟｹﾞﾗ

>>91
3.1→95→98→Me→あぼーん
みたいなのよりマシかと。

>>89
「嫌ならやらなければいい」っていうのは、この言葉自体は正しいけど、「これってどうよ？」ていう質問の答えとしては不適切だと。

変更が多いから5にしました、っていうのは納得してやるけど、5の次が6というのは納得いかんぞ。
1.2→1.4よりも5→6の変更点の方が大きいのか？
1.4→5と同程度の変更点があるのか？

Solarisと一緒で、とっととバージョン上げてあぼーんしたいんだろ。(ｹﾞﾗ

>>95
6は実質J#だからじゃないのか？
SUNとMSは提携してるわけだし。

Javaは1が標準。
1.1がJava1
1.2がJava2
1.3がJava3
1.4がJava4
1.5がJava5
それだけのことがなぜわからん？

6でJ#と統合って言うのはありうるな。
その場合、どっちがコントロールしていくんだろ？

将来的にJavaも.NET上で動くようになる。
ネイティブで動かないなら、VM噛ますより直接.NETのコード吐いてほしい。

>>94
　>>84
　> ていうか入れて大丈夫なのか？
にたいして
　>>86
　> 入れるのが不安なら入れなければ良いだけ。
と言われただけだろ。

そこでJ#ですよ。

>>101
だから、答えになってないだろ。

>>102
J# って基本的には 1.1 レベルのクラスライブラリしか持ってないから
java.io.RandomAccessFile#setLength(long) が使えなかったりで萎え。

>>103
一応、答えにはなってるな。
もっとも、>>84 が聞きたい答えだったかは知らんが。

>>105
おいおい日本語大丈夫か？
「大丈夫なのか？」
の答えとしては
「大丈夫」か「大丈夫じゃない」かどっちかだろ。
お前は政治家か？

>>106
んじゃ、>>86 の代わりに答えておこう。
>>84 にとっては、大丈夫じゃない。

どうして？

>>108
他人に聞かないと判断できないほど無能だから。

ふーん。

>>86は「都合の悪い情報を表沙汰にされたくないからお前は入れるな」ってことだろ。

Java真理教では「セットアップは大丈夫か？」って聞くのもタブーなんだな。

カルトって怖いね

>>111
「都合の悪い情報」って何？

>>111
>>86 は「馬鹿は大人しくしてろ」って言ってるだけだと思われ。

>>112
そっか、セットアップで躓くような人もいるんだねぇ。

インストーラがこけて入れることすらできない。
入ったけど動かしてみたらバグだらけ。
既存のアプリの互換性壊滅。
スパイウェアの存在がバラされる。

>>117
原因わかったら BugParade にでも報告しといてね。

>>117
例えばどんなバグがあるの？

全体的に動きが遅いとか

>>120
ああ、それは重大なバグだ。

>>120
ふーん。それは困ったね。

>>117　まだー？

>>123
だから、全体的に動きが遅いんだよヽ(‘Д´)ﾉ

うんうん。.NETはあんなに速いのにそれに比べてJavaは、ってのはあるよねー。

それは困ったバグだねぇ。

Tigerの目玉機能ってパフォーマンス向上なんでしょ？されてないじゃん。

>>127
見える部分ばかりいじくりたがって、見えない縁の下の力持ちだる
基本部分＆根底部分をいつもおろそかにするＳＵＮの恒例ってことで。。。

縁の下の力持ちだる

>>127
メモリ効率も良くなってるし、Swingは速くなってるし、複数VM起動時は速くなってるし、それなりにパフォーマンスは向上してると思うが。

.NETが速いという発言は、.NET厨のものを含めはじめて見たような気がする。

それでも.NETよりはるかに遅い

よーく注目するとageてる人の共通点として・・・

>>133
ﾄﾞｯﾄﾈﾄ厨は溺れまいと必死だからなぁ。

>>130
早くなってるかコレ？1.4.2 と変わんねぇーよ。

1.5の話題は基本的にスレ違い。
Javaを叩きたいなら以下のスレでどーぞ。

【世代交代】どうしてJavaは死滅してしまったのか？
http://pc5.2ch.net/test/read.cgi/tech/1078838061/l50

では6.0の話を。
「　またJ2SE 1.6では、Javaプログラム間の高速通信を可能にする
Sockets Direct Protocolのサポートが計画されている。」
このSockets Direct Protocolって、Javaプログラム間でしか通信できないんですかね？
ServerSocketを開いて受信するのとどう違う話なんですかね？
リモートメソッド呼び出しができるとか？

>>137
ローカルのJavaプログラム間ではTCP/IPを使わないようにするってことでは？
リモートメソッド呼び出しはRMIで今までもできてる。

>>135
何で試してるの？

>>137
コレをサポートするって事じゃないかと思ってたが……
http://oss.hitachi.co.jp/crl/lwsockets-ja.html

Javaプログラム間のみでしか使えないとは一切書いてないし、速報記事のコピペだし。

>>139
1.5 の話題は 1.5のスレでやれ。

【JavaFive】C＃からJ2SE5.xへ進化【TigerShot】
http://pc5.2ch.net/test/read.cgi/tech/1094891986/l50

SE5でコンパイルしたクラスを1.4.2とかで実行できるの？

スレまちがえた、須磨祖

6からJ#と統合されるでしょ。
それで全部解決だよ。
統合されないと、.NETの上で動くVMの上で動くJavaのコードって感じで
想像しただけでも使えそうに無い。（longhorn以降ね）
間違いなく統合される。
で、速度もC#なみにはやくなる。

速度はJavaもC#も変わらんと思われ。

>>145
ベンチマークでは1.3の旧バージョンでもC#とほぼ同等だったよ。
新バージョンで改善されてれば、Javaの方が速いかもね。

寝言は寝て言え
http://pc5.2ch.net/test/read.cgi/tech/1080916113/668-670

int [] 100000に乱数つっこんで選択ソートかけた比較(Pen4 Windows2000 SP4)
9734 ミリ秒　v1.14/noOptimiz　Visual C# .NET Compiler version 7.10.3052.4
9437 ミリ秒 v1.14/optimiz Visual C# .NET Compiler version 7.10.3052.4
9421 ミリ秒 v2.0.40607 VS2005β

14172 ミリ秒 JAVA VM1.3.1_09 //JDK1.4.2　 ←(　´,_ゝ`)
　↑
(　´,_ゝ`)

http://msdn.microsoft.com/vstudio/art/javarc/middleware/image003.jpg

http://www.chamas.com/bench/
http://www.gotdotnet.com/team/compare/default.aspx
http://www.middlewareresearch.com/endeavors/030730J2EEDOTNET/endeavor.jsp ←登録して665KBのpdfファイル
http://www.rpmsoftware.com/rpm/download/rpm_dotnet.pdf

結論
j2eeは遅い

>>147
リンク先はJavaについて何も書いてないみたいだが、本人か？

JavaはC++より速い
http://sys-con.com/story/?storyid=45250
という記事もある。

マイクロベンチマークの有用性についてご存知かな？

素人学生に世間の現実を教えよう
java のプロジェクトは例外なくトラブる
java は遅くて使い物にならない
理論がどうとかじゃなくて現実はそうなっている

>>147
乱数突っ込んでる時点で、ソートの結果が毎回大きく違ってくると思うんだが。

>>149
Javaの方がC#より速いというベンチも多数あったはず。
しかし何故かC#の方が速いというベンチは企業がほとんどなんだよなー。

Java厨必死だな。ﾌﾟｹﾞﾗ

JavaとC#の速度差って、JITとプリコンパイルの速度差だろ？
基本的にはC#が速くて当然だと思うんだが。

その代わり、Javaのほうが起動が早かったり、
繰り返し実行されるうちに最適化されて高速化するのがメリットなんじゃないのか？

JITとプリコンパイルだとJITの方が速いよ。
統計情報を元に動的コンパイルの最適化行えるから。

Windows版JDKをインストールせずに解凍だけしたいんだけどどうすればいいの？

取って置きの方法を教えてやる。
USBメモリにJDKをインストール→OS再インストール
これで手元にはJDKの展開されたのがのこる。

IBMの1.4.2はただのzipファイルだからそのまま展開できる。

スレ勘違いしてた... orz

>>146-156
現行バージョンのベンチマークはスレ違い。
死滅スレにでも行ってやれ。

>>157-160
現行バージョンのインストールに関してはスレ違い。
初心者スレに行くなり死滅スレに行くなり好きにしろ。

Visual J# 2005はジェネリックの使用をサポートするそうですよｗ
やっぱりJ#とJavaは統合されるなｗ
ほかのプラットフォームではどうなんのかなｗ
ウインドウズのみになったりしてｗ

>>162
J# には generics なんぞいらん。既存の J# にプリプロセッサ組み合わせれば良いだけだし。
そんな事よりも java.io.RandomAccessFile#setLength(long) が無いのをどーにかしてくれ。

統合されないと、.NETの上で動くVMの上で動くJavaのコードって感じで
想像しただけでも使えそうに無い。（longhorn以降ね）
間違いなく統合される。

>>162
単に J# が C# により近づいてるだけに見えるんだが……

>>165
は？
今までC#がジェネリック使えてましたか。そうですか。
そりゃC#に似てきたんですねｗ
Java厨って想像だけで語り始めるんだよなぁｗ

>>166
次の C# では generics っつーか template っつーか忘れたけど使えるよね。
J# 2005では 値型も追加されるみたいだし。

次世代のJavaVMはC#で書くようになるのだろうか？
想像するだけで楽しい作業だね。

>>167
そうだね。
ということは、JavaもC#のような構造体をサポートするようになるねｗ
わくわくするねｗ
数年後にもう一度この書き込み見てごらんｗ

>>166
あと、J# 2005 で追加される type-safe enum は
J2SE 5.0 で追加された参照型の奴じゃなくて
C# みたいな値型の奴だってさ。

>>170
そこらへんのすり合わせはどうするんだろうね？
俺の予想では、Javaのほうが仕様変更する。

>>171
根拠のある予想だったら聞く価値もあるんだろうけどね。

統合されないと、.NETの上で動くVMの上で動くJavaのコードって感じで
想像しただけでも使えそうに無い。（longhorn以降ね）
間違いなく統合される。

>>173
システムコールっつーか OSの機能を呼ぶ時だけ、皮が一枚増えるだけ、の話だし。

>>174
現状：
JavaVMはネイティブなコード
その上でJavaアプリが走る。（遅い）

普通のアプリはネイティブなコード。（速い）

将来：
JavaVMは.NET上で走る。
Javaアプリは.NET上のJavaVM上で走る。（すごく遅い）

普通のアプリは.NET上で走る。（速い）

よく考えたら今と変わらないねｗ

>>173
っつか、J# が好きなのか .NET が好きなのか
.NET に統合される Java を想像するのが好きなのかは知らんけど
完全にスレ違いだから。

>>176
Mustangについて考えてるのだから、すれ違いじゃないよｗ
MustangはJ#と統合されるでしょｗ

>>177
Mustang について妄想するスレじゃないので。

>>177
Microsoft か Sun が公式に「MustangはJ#と統合される」と発表した場合は別だが。

>>178
妄想じゃないってｗ
なぜなら、
統合されないと、.NETの上で動くVMの上で動くJavaのコードって感じで
想像しただけでも使えそうに無い。（longhorn以降ね）
間違いなく統合される。

>>180
Microsoft か Sun が公式に「MustangはJ#と統合される」と発表した場合は別だが。

>>181
いずれ発表されるでしょｗ
もしかして統合されないと思ってるの？

>>182
じゃ、発表されてから来てくれ。

>>183
Mustang自体まだ出てないでしょｗ
色々と想像するスレでしょｗ

>>183
公式発表やら、JSR や Sun幹部のブログやらなどの情報源を元に想像するスレなので。

あ、レス番間違えた。
s/>>183/>>184/

>>185
公式発表を元に想像してるんだけど？
だいたい、統合しなきゃJava生き残れないでしょ？

>>187
Javaはウィンドウズだけで動くわけじゃないからなぁ
どちらかというと、ウィンドウズじゃない場合にJavaを採用するわけで。

>>187
どの公式発表を元に想像したんだ？

>>187
仲間がいそうなスレ見つけて age といたから、そっちに行ってね。
まぁ、○○○○な上に○○○○○っぽそうだから誘導しても無駄かもしれんが。

【ようこそ】　Java1.6＝J♯?　【MSワールドへ】
http://pc5.2ch.net/test/read.cgi/tech/1080961057/l50

しまった。ageちった。

>>187
どの公式発表を元に想像したんですか？

J2SE 1.6はGroovyの言語仕様を取り入れてスクリプト言語に大変身します。

C#2がeclipseで使えれば最高なんだけどね。
.net studioのくそっぷりには呆れる。
まあ、GUIが超そっこうで作れる点では.net studioすごいんだけど
それ以外が全てクソって・・・

ところでC#2っていつでるんだよ。
待たせすぎ

C#2.0って、もう出てるんじゃないの？

あとリファレンスも改善して欲しいな。
もうVBなんていらねーから
リファレンスをまともな記述に直してくれ。

MSは2階層以上の構造化されたライブラリーを仮定してないんだろうなｗ
まあ、低レベルユーザー指向だからこそ
下級ソフトが超即効で作れるわけで
高級ソフトはやっぱり.net framewokr が絡むと
厳しいよね。

という事で
高級ソフトウェアを作る場合はJava
低級ソフトウェアを作る場合はC#と分けるのが
賢い使い方かもね。
って、ビジネスでもそういう使い方されてるから
わざわざ指摘するまでもないか・・・

少なくとも、スレ違いを押してまで指摘することではないね。

LonghornになってもWin32アプリが動くことを知らない厨房がいるらしい（ｗ

>>170
オイオイ、頭大丈夫か？
一度アセンブリをデコンパイルしてみるといいぞ。

>>170
ほんと、何でtype safe enumがああいう実装になっているか考えたことある？
javaは、実行速度の最適化はコンパイラと実行環境に任せるって方針がハッキリしてきたから
むしろ プリミティブ型が邪魔になってきていると思う。
auto-boxingが、1.5で導入されてプリミティブ型とクラスの扱いの差がなくなってきたので
この際、mustangでは定数以外のプリミティブ型を全部隠蔽するような仕様変更(deprecated？)にならないかな？
今でも書けるけど、プリミティブ型の利用をとめられないでしょ。

比較が==でできないから不便だぞ、と。
たまにちゃんと動くけど。
(Integer)5 == (Integer)5 → true
(Integer)50 == (Integer)50 → true
(Integer)500 == (Integer)500 → false

>>201
ちゃんと理解してね

>>202
どういうこと？
なんで201の挙動になるかはわかってるけど。

>たまにちゃんと動くけど。
このへんが理解していないと思われ

>>201-204
Integerは数の小さいときはインスタンスを使いまわす実装になってるからってことだっけ？
Integer型とか、プリミティブ型のラッパークラスの == は、equal を呼ぶようにすれば大丈夫・・・じゃない？
final だから派生もできないし。
今の 1.5ではできないけどね。

>>204
実際に変数にどういう値が入るかはわからないから、たまにちゃんと動くんだよ。
なんで201の挙動になるかはわかってるって。
==をequalsにすると、インスタンスの比較したいときのための構文が必要になる。
挙動が変わるコードもあるだろうし。

>実際に変数にどういう値が入るかはわからないから、たまにちゃんと動くんだよ。

すごい内容だな

たまにちゃんと動くではなくて
trueもfalseも返すというのがすでに正しい動作なんだから
紛らわしいこと書くなよ

内容がスレ違いなんだから初心者スレいけよ

>>201 ずいぶんと釣れましたねー。

>>206-207
で、おまいら俺はスルーですか？
>>206
だからプリミティブ型のラッパークラスだけにって、>>205 に書いたけど。
プリミティブ型は、==とequalsの挙動が変わって困ること無いじゃないですか。
>>207
＞trueもfalseも返すというのがすでに正しい動作
君の言っていることも既に意味不明です。

>>208
え？釣りだったの？

>>207痛すぎ

>>209
釣る気はなかったんだけど・・・
ラッパークラスは==とequalsの挙動が変わって困ることはめったにないが、0ではないよ。
だれか困る人がいるはず。

>>211
その困るパターンが知りたい。
finalクラスなんだから、クラスが派生して使われるわけではないし困ることないと思うけど？

数字のラッパークラスは数字として使われるわけで、もしインスタンスの違いを比較するような
「同じ数字だけど別タイミングで作られた」なんかの付加情報を必要とするなら
そういう付加情報を持つ別クラスで扱ってやるべきだと思う。

>>212
ここでは、仕様を変更してかどうかという話なので。
こういう使い方をするべきとかそうではない、ということを議論してもしかたないよ。
すでに言語仕様として数年定着してるんだから、インスタンスの違いを比較するコードがあってもおかしくない。
スクリプトなど処理系のようなものを作るときには、必要になっているかもしれない。
自分たちの分野で不要だからといって、全ての分野で不要だとは思わないし。

>>213
しかし既に値の小さいときにインスタンスを使いまわすという実装になっているわけだから、
インスタンスの違いを比較するコードは動かないはず。

>>214
new Integer(5) == new Integer(5) → false

>>215
正直すまんかった

>>216
autoboxingの仕様だよ。
newは必ずインスタンスを生成する。

>>217
どうも何かとんでもなく間違った記憶があったらしい。
というわけで、やはり プリミティブ型はきれいな形でなくせそうにないですねぇ。

きれいになくなれば、それはそれでいいのだけど。
ムダに遅くなりそうだし。
そこまでのEoDはスクリプトでやればいい。

>>219
OK。んでは、これからpnutsでもダウソって来ますわ。

Groovyだろw

プリミティブを無くすんだってｗ
Java厨って面白いねｗ

またおまえか

そのうち世の中のすべてのものはオブジェクトとか言い出しそうｗ
素晴らしい世界ですねｗ

>>224
言い出したのはJavaではなく、それ以前のOO言語の中でもでてきています。
由緒正しいSmalltalk厨に聞いてきてください。
もちろん藻前もオブジェクトです。

>>225
OO厨の分際で実用言語C/C++、C#、etcと張り合おうって言うのが気に喰わない。
夢の中で理想追いかけとけ。
こっち来るな。

>>226
スレ違いなんだから、負け犬のように出てくのはオマエ。

>>227
お前らは板違い。
夢独り言板行ってスレ立てれよ。
こっち来るな。
正直、妄想は迷惑。
ここは技術板だ。

>>190
その○○○○, ○○○○○には一体何が入る？
きになる

>>228
そー思うなら削除依頼でも出してくれば？

>>201 の話ははじめて知りました。トリビアに応募してみようかな。

>>230
お前が出せよ。
何で俺らがお前の後始末しなきゃならないんだよ？

>>232
妄想とか言ってるのはオマエだから。

>>232
板違いだといってるのがオマエだから。

Javaを使った株ロボットプログラムコンテスト
大会期間は1ヶ月。
優勝賞金としてあなたのロボットがあげた利益をそのまま獲得できます！
ユニークなロボットには特別賞も！
ふるってご参加ください。

ttp://www.kaburobo.jp/

マルチうざ

締め切りまでの時間がなさすぎ。

>>237
よほど人気がなかったので、関係者があわててマルチしたんでしょう。
Mustangで誰か実装してやればよし。

175 ：デフォルトの名無しさん ：04/10/04 06:05:24
>>174
現状：
JavaVMはネイティブなコード
その上でJavaアプリが走る。（遅い）

普通のアプリはネイティブなコード。（速い）

将来：
JavaVMは.NET上で走る。
Javaアプリは.NET上のJavaVM上で走る。（すごく遅い）

普通のアプリは.NET上で走る。（速い）

よく考えたら今と変わらないねｗ


↑これどう思う？

Java6リリースまーだー？

またLonghornになったらWinからネイティブAPIが無くなると思ってる莫迦か。ageんな禿。

JVMはネイティブAPIで実装されるに決まってるだろ。CLR上にさらに
VM乗っけるって、莫迦かと。
Winの普通のアプリが将来全部CLR上で動くことになるんなら、Winアプリ全体が
今のJavaと同じになるってこった。 .netのCLR、今のJVMより遅いし悲劇的だな。

もうFAだから放置で。

厨房は上とか下とか好きですね。
プログラムはメモリ上に直線的に配置されてるんですけど。

>>241
JVMはおそらくC#で書かれるだろ。

>>243
今の JVM は C++ で書かれているのにWindows版だけ再開発のコストを払って、わざわざ C# で書き直すわけ？
おまけに Windows版とそれ以外で、2系統の VM を保守しなきゃいけないので保守も大変になるし。

と厨の妄言にﾏｼﾞﾚｽ

>>137
SDP(Scoket Direct Protocol)ってTCPの代替の
トランスポート層のプロトコル。SOCK_STREAMで使う。
http://www.rdmaconsortium.org/home/SDP_FAQ.htm

TCPは仕様上、実装でメモリコピーを結構やる必要がある。
1000Mbpsが当たり前のnetworkではこのコピーがボトルネックになる。
Java環境でも同様なので、SDPのサポートが望まれている。
(特にserializeする時は大量のdata転送が…)

>>140のページなんかにTCPじゃなくて、
TCP/IPとIPまで含まれているのはなんかの間違いだと思う。
SDPはIPv6と相性が良い。(IPv4だとSDPをフルに活かせない)

Mustangは特許侵害のため出せません。
http://www.itmedia.co.jp/enterprise/articles/0410/05/news005.html

>>243-244
ttp://sourceforge.net/projects/ikvm/
もう既にあるの知ってた？JavaでPython実装したりPerl実装してたりするやつがいるんだから
こういうことしてるやついるって。

>>246
> 「これは非常に広範な特許の主張のようであり、Javaを越えて
> （Microsoftの）.Netにも及ぶかもしれない」とハフ氏。

auto boxing/unboxingの話みたいだから、
Microsoftは既にお金払っている可能性もある。
非公開を条件にできるしね。

http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1='5206951'.WKU.&OS=PN/5206951&RS=PN/5206951
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1='5421012'.WKU.&OS=PN/5421012&RS=PN/5421012
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1='5,226,161'.WKU.&OS=PN/5,226,161&RS=PN/5,226,161

この辺はHaskell屋さんがGCとの絡みでかなり昔から研究していたから、
最初の侵害はHaskell .NETか?

つまり、Javaだけが破産あぼーん

>>249
5,206,951 を読んだけど autoboxing/unboxing の話じゃ無さそうだね。
っつか、どこ読んだら autoboxing/unboxing の話が出てるんだ？

kodak が Sun を提訴した2002年にはまだ Java には autoboxing は無かったような？？？
http://www.itmedia.co.jp/news/0202/14/e_kodak.html には、
それ以前にも3年間交渉したとか書いてあるし。

>>248
大雑把に言うと COM みたいなシステムの特許みたいだね。
.NET や Java に限らず、オブジェクト指向なスクリプト言語とかもやばそう。

autoboxingではないな。GC関連のような希ガス。
単語の流し読みしかしてないけど、GCのアルゴリズム？か？
でもOperationを強調してたりするところをみるとReflection？わけわかんねー。訴求の範囲がわからん。
1995年のものだけに、初代Javaから入ってる機能なのか・・・？英語読める人プリーズ。
Smalltalkの猛者はどこだー。

RMIだな。
RMIそのもの。RMIベースのシステム。RMIのAPI。かな?

APIは特許にならないから、
最後はOO baseじゃないケースかな。

RMIかよ。ここでHorbか・・・。

>>254
RMI だったら ネットワーク越し、システム間で、とかそーゆー表現があっても良さそうなもんだが。

それであれば、horbも同様にひっかかる可能性大。

>>258
>>254 が読み違えててRMI 関連の特許でない可能性も大。

IBMとHPはすでにコダックと契約済みってことなんで
Javaは生き残るな。最悪でも単にSunが退場するだけ。
つーか、まじ退場してほしい。

>>259
「他の参考文献」、見て美奈代。

>>260
ん？てことは、M$はまだ？
もしや、SUNとM$の夢のタッグ結成？

>>262
http://www.itmedia.co.jp/enterprise/articles/0410/05/news016.html

残念。Sunだけ。

同じ発明者が出している特開平1-126736が問題の
特許から引用されているから、そのあたりから
読んでいくとわかりやすいかもね。特開平
1-126736は「カストマイズ可能のコンピュータシステム
に関し、特に種々のプログラム間でデータ資源を
共用するメカニズムを備えたシステム」
ざーっと流し読みした感じだと、CORBAとか
SOMとかCOMとかが盛んだったころの類似技術の
一つって感じがする。

ぶひゃひゃひゃひゃひゃ。ざまーーーーーーーーみろ$un。ｗｗｗｗｗｗｗｗｗｗｗｗｗ

とっとと潰れろ潰れろ潰れろ潰れろ潰れろ潰れろ潰れろ。ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

Java使いの皆さんは特許も安心のJ#に移行しましょう。

今日も元気なＭＳ社員きてるな

2chに書き込みする以外にやる事がないんだろ

J#と統合されるから大丈夫ですよ。

SUNは、MSに技術供与することで利益を上げられる。
プログラマはVSを使って楽しく仕事が出来るようになる。
ユーザはネイティブなソフトウエアを手に入れることが出来る。
むろん、MSにとっても帝國の基盤を磐石のものと出来、言うことなし。

全員がハッピーになるストーリーです。

J#って何だっけ？なんか昔そんなのあったような気がしたけど。

> ユーザはネイティブなソフトウエアを手に入れることが出来る。
J# はネイティブコードは吐けないと思ったが。

ネイティブの定義がわからん

>>270
比較的新しい言語でJ#というのがあるのです。
Javaを吸収すると目されています。

>>271
ウインドウズネイティブということです。
ほかの環境では現在より不利になると思いますが、
大げさな言い方をすれば、一番層の厚いパーソナルコンピュータ上では
ウインドウズしか使われていませんから、特に問題ないでしょう。
携帯機器においては、BREWが主流となる流れなのでしょう。

>>273
目されてねぇよ
J#はJavaユーザーを.NETに取り込んでいずれはC#使わせようってだめだけに存在してんだから。

>>274
MSとSUNは提携しています。
そして、SUNが絶体絶命のピンチに陥ったとき、MSは手を差し伸べるでしょう。
MSには、そうしなければならない理由があると思うのです。

現在、Javaは絶滅の危機に瀕しており、MSの手助けが必要に見えます。
これが、J#とJavaが統合されると考える理由です。

万が一統合されなかった場合、Javaは絶滅すると思います。
そしてJ#もフェードアウトしていくでしょう。

>>260
これってSunが死ぬだけですむの？
俺ら関係ない？

>>276
訴訟の対象になるほど金があるか、コダックを怒らせるとかすれば関係あるんじゃないか？

.netも無関係じゃないんだが。

>>278
http://www.itmedia.co.jp/enterprise/articles/0410/05/news016.html

残念。Sunだけ。

>>278
無関係ではないが、問題はない、というのが正しいね。

Sunはこんなこともチェックしてなかったのか。
逃げ切れると思ったのかな。

>>281
5年間交渉係争してるんじゃないの？

いやでも実際思うのは、ソフトウェアの特許って
害のほうが大き過ぎて益が少な過ぎると思わない？
著作物は著作権が発生するわけで特許がなくてもソフトの値段がなくなるわけじゃない。
この際、ソフトウェアの特許全部なしにしてしまおうや。そうしたらみんなちょっとずつ幸せになれるって。

流石Java厨、いやｵﾌﾟｿ乞食だな

しかしアンチJavaはいちいちうざいなぁ。
他人の威を借りないと何も出来ないで、それでいて他人を非難して
スレを荒らしまわる。
本当に厨そのものだ。

コダック、Java特許訴訟で勝訴--判決に批判の声が噴出
http://japan.cnet.com/news/ent/story/0,2000047623,20074961,00.htm

こーゆー裁判に注目するのは >>284 の言うところのｵﾌﾟｿ乞食だけなんだよね。
今回の報道で注目されちゃってるから Sun に控訴(?)されたら Kodak は世論的に不利だろね。

頑張れ >>284 ﾌﾟﾛﾌﾟﾗ富豪の力を結集してソフトウェア特許を守るのだ！
……無理か。>>284 はﾌﾟﾛﾌﾟﾗ乞食(使ってるのは全部違法品)だろうし。

>>283
しかし、守るべき独創的な技術ももちろんあるわけで。
とりあえず特許をみとめておいて、あとは司法に丸投げという運用に問題があると思われ。
1960年代のSimulaまで特許侵害ということになるかもって、どんな特許やの？
Simula、うしろうしろ！

>>288
Simulaかよ！
独創的な技術もソフトウェアにして著作権で守ればええやん、って思ってしまうんですけど。
まあ、ソフトウェアに特許を認める認めない、いずれにせよ今のアメリカの無責任(後回し)的な
制度は早くつぶしてもらいたいな。アメリカ以外の国が迷惑こうむるだけだ。

どうでもいいけど1.6の話しようぜ

じゃあネタ投下。
１に書いてあるこれね。
「この機能によってローカライズコンピューティング処理実行のための分離が
可能になり、第2のJVMを要求することなくJVM内部でマルチタスクが行えるようになるという。」

JVM上に複数のプロセスというかJavaプログラムが起動するってことなんだろうけど、
「ローカライズコンピューティング処理実行のための分離」ってなんのことなのかさっぱり。
エライひと教えて。

ローカライズってのは、
分離されている処理単位内に影響が収まる、
局所化される(ローカライズ)、ってこと。

「この機能によって処理の局所化を担う分離が可能となり」くらいの意味。

具体例としては、クラス変数が別々になる、など。

>>292
例えば、一つのアプリで OutOfMemoryError 食らっても
同じVM共有してる他のアプリが止まらないようにする仕組みで
VM共有の肝となる技術の一つ、って感じで理解してるんだけど

「理解しているんだけど」ってどういう問いかけ?

途中で切れただけです。気にしないでください。

とうとう、1JVMをサービスやデーモンのように立てておいて
その空間を複数のJVMで使いまわしできるようになるんですよね。
やっぱり、System.exit()に手が入れられるのかな？
それとも特別なオプションつけたときだけ挙動が変わるとか？
LookingGlass〜クライアントアプリまでJavaでカバーできるようになるのか。
JavaStation再び、だね。
# 願わくば今度はこけませんように・・・

>>283
数年後にはJavaを駆逐した功績を認められるはず。
Javaが無くなり、みんな特許に感謝する。

J2MEで採用されると、
携帯電話で同時に複数の待ち受けアプリを動かすことができる。

将来的には
ハードウェア-OS-JVM(あるいはCLR)-アプリケーション
っていう構造が一般的になるかもね。

ハードウェアの違いをOSが吸収
アプリケーションの機械語の違いをVMが吸収。

いい時代になったもんだ。

そうなるとコンピューターの世界にも構造改革が必要だね。
シェルからなにから全てVM上で走らせるつもりのOSを作ると
幸せになれそうだ。

つまりJavaOS
やっと技術的に必要なものがでそろってきたかな。

ふーんLooking Glassねー、こんなのがあるんだぁ
どっかでムービーみれませんかね？

Looking GlassはXの上に作ってるのは
JavaOSを見込んでるからだろうね。
でもって、シェルをVM上で走らせる布石にもなってると。

マイクロソフトはどうするんだろうね。

ソフトハード統合OSにするか
ソフトハード分離OSにするか。

ソフトウェア工学的に美しいのは後者だけどね。

VMWareはどうなるんだろうな・・・
VMWare作ってる会社がJavaOSに関わっていけばいいと思うんだけど。

>>301
どうよ?
http://wwws.sun.com/software/looking_glass/demo.html

騒ぐほどのもんじゃないと思うけども。

>>269
J#、かなり未完成です。ライブラリもバグだらけです。ライブラリのバグは、致命的なレベルです。
コンパイラの設計は、良くここまでJVMとCLRの違いを吸収したと思い、よくできているとは思いますが
実用を考えて書かれたコードは、再コンパイルだけでは、なかなか動作しません。
（特に、String型、リソース、ClassLoaderあたりが重大。）
セキュリティモデルの違いも大きいです。
MicosoftがJ#に力を入れて、大部分のJavaコードがコンパイルできるようになったら
.NETは、Javaをあっというまに蹴散らすと思う。現状では、J#を使いこなすのはそれなりのテクニックが必要。

>>303
ありがと、
今すぐ完成したら凄いと思うんだけど、、
これが完成するころには、WindowsやMacはもっと凄くなってるんだろうね・・

>>304
> Javaをあっというまに蹴散らすと思う。

この文の"Java"は「100% pure Java」って意味ですか?

MicrosoftがLinux他で動く環境を作ってくれたらいいんだけどね。
Monoは駄目だしなぁ。

おれはMicrosoftが .NET を、Javaと同じようなレベルでプラットフォーム互換性を
持たせたいと思っているようには思えない。

ビジネス関係でJavaが採用されているのは(J2EEとか)、けっきょくこのプラット
フォーム互換性ゆえだよ。ある程度以上の開発だと、この「プラットフォームが
変わっても、多少の変更は必要とはいえ動かすことが出来る」というのは非常に
重要。必要ならMicrosoft以外のプラットフォーム（ばか高いUNIXサーバとか）に
移行できるという可能性が重要。これさえ保証できれば、多くの企業は別に
Javaじゃなくたって、なんでもいいわけですよ。５年後に保守切れしたときに、
別のプラットフォームも選択できると言う可搬性があれば。

もちろん、Write one, Run anywhereなんてただの神話だけども、はじめっから
「Microsoftプラットフォームでないと動きません」なんてよりよっぽどマシ。

この点をクリアしないと.NETはあくまでMicrosoftプラットフォームの技術ってことで
終わると思う。もちろん、Microsoftだから、結構シェアは取るとは思うけどね。

>>305
もう販売はじまってるよ

ついでに、オープンソースとして
世界中にぶちまける予定でもあるらしい

windows壊滅へのカウントダウンは既に始まっていたりする

すでにプラットフォーム互換の脅威が垣間見れていて
Eclipseしかり、その他のJava開発環境とか
StartSuite別名OpenOfficeなんてのは
LinuxとWindows両方で動いちゃってるわけで、
Linux用アプリを全てJavaで書き直した時にいったい何が起こるんだろうか？

>>311
Linuxって重いね、という厨があらわれる。
しかし、現実的にLinux用という位置付けでJava版を用意しているアプリは結構あるね。

>>310
6年ぐらい前から同じことが言われてるわけだが。
今カウントいくつなんだ？(ｹﾞﾗ

>>312
現実的な線でいいと思う
Linux用ＧＵＩツールを作れといわれたら真っ先に選択肢にあがるはず＞Ｊａｖａ

あと今日ＰＣショップみてみたら大手のＸＰ搭載マシンで
SunのJavaVM搭載してないメーカーは無かった

ＤＥＬＬやＨＰのニュースは有名だから知ってたけど国内もみんな搭載してるのな
冬モデルは1,4,2_05と９月下旬時点での最新だった

>>314
そうなると、もしかして、もう5.0搭載してるマシンもでてる？(ちょっとはやすぎか・・・)
1.6のスレで5.0の話題すんませんなぁ。

ところで、1.5のJ2SEのバージョンいくつになるんでしょう。 6.0？それとも 5.1？

>>313
ﾜﾛﾀ

ざらざらした書き味のボールペン。
作り手の論理では、ちゃんと書けるし圧倒的に安いんだから売れると思う。
俺は倍の値段の普通のボールペンを買うけどね。
ビジネス用だったら細かいことにこだわる必要ないって人もいる。
俺はビジネス用こそこだわるけどね。

>おれはMicrosoftが .NET を、Javaと同じようなレベルでプラットフォーム互換性を
>持たせたいと思っているようには思えない。

なにを当たり前のことを堂々と・・・

>>314
FAQに"Javaの消し方"がある。
善し悪しってこと。

>>315
> ところで、1.5のJ2SEのバージョンいくつになるんでしょう。 6.0？それとも 5.1？

< ところで、1.6のJ2SEのバージョンいくつになるんでしょう。 6.0？それとも 5.1？

の間違いなんでしょうなあ。

1.6 は 6.0、1.7 は 7.0 になるって(Sunのサイト内の)どっかで読んだような。

>>201
> 比較が==でできないから不便だぞ、と。
> たまにちゃんと動くけど。
> (Integer)5 == (Integer)5 → true
> (Integer)50 == (Integer)50 → true
> (Integer)500 == (Integer)500 → false

当たり前だろ

equals()を使うか一旦プリミティブ型に戻してから比較しろよ

>>322 あなた周りの人から空気よめないっていわれるでしょ？

バカめ、時間差が激しく、チャットでもない
文字だけのコミュニケーションの2chに空気なんてものがあると思ってるのか。

つまり、空気が読めないことを正当化しようとがんばっている、と。
どういう流れで201が出てるか確認したら？

だからどこに空気があるんだ。
お前の擦っている空気とそいつが吸っている空気が常に同じか？
例えばお前が北海道にいてそいつが沖縄にいたとき、
お前とそいつとが吸っている空気が同じだといえるか？

>>326
つまりバカなんだ。

>>322
真性の馬鹿？

ここにも小学生ﾊｹｰﾝ

Javaらしい厨スレ

まあ、タイガーショットがあるからいいじゃないか

>>324
バカめ、お前のせいでスレが止まったぞ
いい空気持ってるじゃないか

MustangとLooking Glassのタッグは楽しみだな
WinFX&Avalonとガチになるぐらい盛り上がって欲しいもんだ

きょうび「晒しage」て・・

>>332
> 盛り上がって欲しいもんだ

願望ですか。確信ではないのですね。ｗｗｗｗｗｗｗｗ

なんかの間違いで盛り上がると楽しいねぇ

そそ
ワクワクするような展開を期待しているのよ

で、正解は誰も知らないという

Mustang Snapshot Releases
ttps://j2se.dev.java.net/

早っ

こんな場所よく見つけたな

TSSでネタになってるし。
ttp://www.theserverside.com/

ソース公開しただけでオープンソース化っていうかなぁ、素人じゃあるまいし・・・。

Sun、Java 2 Standard Edition 6.0スナップショットをオープンソース化
ttp://www.itmedia.co.jp/enterprise/articles/0411/17/news020.html

オープンソースの定義ネタは飽きた。

>>343
あたまわるいね。

質問なのですがJavaでexeファイルを作ろうとする場合どのようにすればよろしいのでしょうか！？

別のスレで聞けばいいかと。
それか、
　new FileOutputStream("hoge.exe").close();
でがまんしる。

>>345
ボーランド社のＪＢｕｉｌｄｅｒで、ネイティブ単独実行exeファイルが
ワンタッチで作成できます。
これで普通のアプリケーションと同じように配布できますね。
JREインストールの有無は関係なくなります。
エクリプスやネットビーンズには、とても無い機能です。
これを機にＪビルダーに変えてもいいかもしれません。
タダより高いものはなしです。

最後の行をネタとして書いたのか本気で間違えてるのか
微妙なところが現状を良く表している

JBossで開発したアプリケーションをそのまま
WebLogicにデプロイできますか？

愚問。Javaは一度書けばどこでも動きます。

(　´･∀･`)へｰ

>>351
申し訳ございません。語句が脱落しておりました。
「Javaは一度『綺麗に』書けばどこでも『何とかすれば』動きます。」
1.6 いいねぇ。Tigerのearly accessがアンインストールできないってバグがあったのを
思い返せば十分実用だよ、と Mustangの上で動かした v2cから書き込み。

>>343
ねぇ、これはさすがにオープンソースじゃないよね？

> Javaもオープンソースであり、下記より開発環境を無料でダウンロードできます。
ttp://www.thinkit.co.jp/cert/compare/2/1/3.htm
要登録。登録して情報提供するのももったいないかも。
ダウンロード先もJava2SE1.4.2だし。
宣伝効果を狙って、晒されるようにしてるんだろうか？

>>352
どこがどういうふうにいいのかきぼんぬ

thinkitは@itの後追いでレベルも低いな

多重継承は？

>>356
不要。DI+AOPでほんとに用無しになった。

>>345
何のために作るんだ？
JETコンパイラや GNU Java Compilerとかではダメか？

マニフェストファイルを使ってExecutable Jarファイルを生成するだけでは飽き足らないか？
JavaWebStartに対応させてJNLPファイルを作るだけでは飽き足らないか？

JETコンパイラって速そうだな。

>>358
アイコンを付けたいとか、使い始めまではネイティブっぽくしたいってのは
あると思うぞ。

おれはMacユーザだけど、jarファイルをダブルクリックしたら起動できるとは
いえ、やっぱりちゃんとしたアイコンをつけて配布したいなー、とおもったら
やっぱりアプリケーション化するよ。

>>360
javaコマンド呼び出す小さなアプリで問題なし。
ウィンドウズなら、アイコン設定したショートカットをデスクトップに置くインストーラーで問題なし。

意外に知られていないjavaw

じゃあ、そっちで。

1.5のマニュアルの日本語化はまだー？

1.4の日本語版に差分だけ英語版で追加したものでいいから、欲しい。

JavaWebStartはJNLPファイルで
起動用アイコンの画像を指定できるぞ。
jarファイルを生で配布するなんてやめとけ。

webstartじゃぁスタンドアロンアプリじゃないしな

>>368
JavaWebStartはスタンドアロンアプリを配ることにも使えるぞ。

サーバに依存して動くアプリを配るにしても、
なるべく disconnected operation ができるように
工夫して作るもんじゃないのか？

いやそういう意味じゃなくて
webstartだとサンドボックスで動くんじゃないのか?

通常アプリケーションとの違いはそこだとおもうが

WebStartはアクセス範囲をポリシーファイルで自由に設定可能。
無制限のアクセス権（つまりネイティブアプリと同等）を要求するWebStartアプリも
たくさんあるよ。

それって警告画面でなかったか？

たしか一番最初だけ出るね。「実行しますか？」というのが。
それ以降は普通に起動する。

毎回起動時に出るよ

そんなのユーザーが安心してつかうとはかぎらんだろ
それくらいならJava起動するだけのexe作ったほうがいい
ついでにランタイムも同梱してJavaであることすら意識させないでね

>>374
おおーい。起動時に毎回出る「場合もある」だけでしょー。
1回の同意で以降は聞かれないっていうのもありなんだから。

exeを作る意味は？exeあってもどうせJavaのランタイムがないと動かんでしょ？
ランタイムを入れてるんだったらjnlpで起動しても初回の同意ダイアログさえクリアすれば問題ない。
exeファイルをマシンの中に持ってくるまでの作業よりも(ダウンロード＞解凍｜インストーラ実行)
よっぽど敷居低いでしょ？

セットアップが嫌という環境もあるわけだ
レジストリをいじられたくないとかね

とくに体験版とかで配布する場合とか圧縮だけのほうが喜ばれるぞい

WebStartアプリって署名なしですべての機能が使えたっけ？

JNLPAPIだけのようなきがしたが

>>376
JREを入れる時点で多少なりとレジストリへ書き込むだろ。
ttp://java.sun.com/j2se/1.4/ja/docs/ja/guide/plugin/developer_guide/version.html
とにかく、「圧縮だけのほうが喜ばれる」というのには賛成できないな。
俺は、得体の知れないサイトからダウソした生のjarとかexeとかでは，
トロイの木馬かもわからんから、起動するのは恐い。

377が書いているように、JNLP APIしか使わないようなソフトなら
署名も不要になるし、セキュリティ的な安心感を与えられる。
ちゃんとした.jnlpのほうが、ユーザに喜ばれると思うぞ。

まずJREが入っていること、という前提が難しいことに気がつけ

ちなみに>>376も>>377も俺な
JNLPAPIだけでもローカル資源アクセスは警告文でるぞ
プリントとファイルアクセスしか試してないがどちらもでる

「次回は聞かない」みたいなチェックボックスないんだっけ

>>379
客自身にJREをインストールさせられないような案件なら、
そもそもJavaを使うのを避けたほうがいいんじゃないか?
WinXP SP2以降は、JREをActiveXのセキュリティホールから
自動インストールさせる技も使えなくなったしな。

俺の場合、客先に導入されているPCがIBMで、
JREがプレインストールされていたから、悩まずに済んだけどな。

仕事で使う場合とそれ以外で使う場合とで分かれるな

仕事でならJREをセットアップさせるのは手間ではないが、
これも最近はJRE同根でやってる

JREのバージョン違いでの動作の不具合を防ぐためね

ゲーム等ではJREのセットアップを別にしておいてくださいというのは
手間もあって嫌がる人は多い

クロスプラットフォームでのゲーム作成という目的もあるから
JRE付属させるだけでいいのでJavaはそれなりに存在意義あるよ

>>382
ちょっと待て。言ってることが矛盾してるぞ。
結局ユーザにJREを入れさせるのが前提なんじゃねーか。
該当するJREをあらかじめインストールしてあるユーザからすれば、
わざわざ余計なもの同梱すんじゃねー糞が！ってとこだな。

警告文をユーザに見せるのがそんなに嫌か？
おまえみたいなセキュリティ意識の低いやつは、
セキュリティ意識の低いユーザと馴れ合ってるのがお似合いだな。

ちなみに、JavaWebStartには、アプリケーションの動作に必要な
バージョンのJREをユーザが持っていないときには、
自動でダウンロード・インストールしてくれる機能がある。
アプリにJREを同梱するだなんて時代は、とっくに終わってんだよ…

ようやく話題が次世代Javaっぽくなってきたのでアゲ

JREが入ってるのが前提ってのはおかしいな

毎回警告文がでるゲームとか使いたいというやつの気がしれん

webstartは場合によっては使えるものの
JNLPAPI以外はあいかわらずサンドボックス内じゃねーの？

JREっていつWindows標準搭載になるの？
デフォルトでインストール済みにしてよ。

>>385
コード署名しろ

すべて署名しろっていうのは結局すべてActiveXで作るのとかわらんな

署名しても認証局とかの問題で貧乏人は警告文でるだろ・・・

java.net内のこの辺について話せるスレはここですか
http://community.java.net/javatools/
http://community.java.net/javadesktop/

最初の1回はVerisignの証明書でコード署名してたって警告は出るだろ。

PKIはユーザ各自が安全と思われる経路でルート証明書を入手していることが前提。
んでもって、その証明書からの信用の連鎖をユーザが理解してリスクを受け入れる
ことで、サービスに関する責任の線引きをできるようにすることに意味がある。
これの価値がわからないか、面倒だと思う奴は、電子署名とか使わないほうがいいぞ。

JavaWebStartにも、ユーザが手作業でルート証明書をインポートする機能が用意されてある。
ルート証明書を自己署名で作って、安全と思われる経路でユーザに配る方法を、
自前で持っているのなら、Verisignとかに頼らずにこの機能を使うのが普通だと思う。
貧乏かどうかとかは関係無い(企業内で利用する場合とか)。

ちなみにJavaWebStartには、証明書の指紋をGUI上で確認する方法が無い。
手作業での証明書の受け渡し・インポートをさせるときに、
内容が本物であることを確かめにくい。PKIとしては不備だ思う。

1.5からのJavaWebStartのアプリケーションマネージャは、
編集→設定→セキュリティ→証明書→詳細 をすると、
cerの中身のバイナリが表示されるようになったので、
この画面をダンプして印刷してユーザに配布しておけば、
代用できるかもしれないけどな。

>>393
1.5から多少よくなったのか
ノーチェックだった
さんきゅ

>>392
企業内ならWbeStart使わないという手が一番だったけどな

セットアッププログラムでJRE埋め込みとスタートアップ部分作って
ネット経由で肝心の実行プログラムのダウンロード、実行という仕組み作ってる

再発明とかいうな
手間の問題とかJREのバージョン問題とかプログラムの追加と削除で
アンインストールができることとかいろいろあってな

>>394
つーか、1.5になってなお、鍵指紋を表示するフィールドが無い、
っていうことをには、わりとガッカリさせられている。
keytoolで鍵を作る過程でも、MD5,SHA1とかは、
フツーに表示されてるのにな…．1.6?に期待、なのかな…。

>>395
セットアッププログラムを配るというのなら、
ネイティブバイナリのインストーラで、
JREインストール+JavaWebStartでのアプリ導入・警告了承済の
構成状態を作ってやるほうが、バージョンアップとか、いろいろ
楽できると思うがな。

横道にそれてしまいますが、、、
これからの時代、クライアント上で動くプログラムが
「セキュリティチェックの為に警告ダイアログが出力される」という
動作自体が、便利といわれるか、不便といわれるかで
ニーズが分かれるような気がする。

例えば話ですが、
ウイルスバスターで個人情報保護設定で自分の名前やメールアドレスを
登録しておいたら、意外と不便でした。主に、登録フォーム系のページ
が大体引っかかる。んで、やり直しが発生。

まあ月並みだが便利さと安全性のトレードオフだろ。
.NETはどちらかというと便利さに重きをおいていて
Javaはどちらかというと安全性に重きをおいているという話。

>>397
そりゃ、Javaのセキュリティサンドボックスの話じゃなくて、
PICSとかP3Pとかの情報の入りと出のポリシの設定とか、
CC/PPとかのcontent negotiation系の技術に関わる話なんじゃないかな。

>>397
これからの時代は
セキュアプログラミングに対する意識が高まったことにより
安全性が重要視される。

セキュアプログラミングをしないで
セキュリティホールを作ってしまうと逮捕されてしまうことがあるらしいぞ。
恐ろしいことに。C/C++プログラマはソフトウェア開発で慎重にならなければならない
立場に追いやられてる。

問題は何度も何度も警告ダイアログでてきて
ほいほいOK押すもんだから
なんの意味もないということだ

もしくはまったく内容を確認せずに寄り付かなくなるかだな

java web start起動時のメッセージはかなり引くよ、
まるで全件委譲の誓約書にサインさせられるみたいなんだから。

1.5ってどうやって起動させるの？
1.4にあったあのアイコンが無いのですが・・・

>>403
そりゃJavaWebStartに限らないよ。
いろいろなソフトウェアをインストールするときに出てくるライセンス文書は、
真面目に読むと、かな〜り引くような内容が多いよ。

JavaWebStartのアレは、シロウトが読んでも、リスクがあるということが
ちゃんと理解できるような書き方をしている分だけ、良心的だと俺は思うよ。

まぁ、署名なし・securityなしとのやつと、
署名あり・all-permission,application-client-permissionsのやつとの間で，
何かもうちょっと、資源アクセス権限の許認可を、GUIで対話的にできるような
しくみがあったりしてもいいかなぁ…、とかは思うけどね。

>>404 まちがえた。
誤 application-client-permissions
正 j2ee-application-client-permissions

ごめん。こんどは数字をまちがえた。さっきのは404じゃなくて405。
ついでに404に回答すると、
JavaWebStartのアプリケーションマネージャなら、
jreのフォルダの中のjavawsフォルダの中にある、
javaws.exeで起動できるはず。

1.5の場合には「Javaアプリケーションキャッシュビューア」と言うらしい。
jre1.5.0\bin\javaws.exe

>>405
あれ？でも実際問題として、JavaWebStartで起動したアプリって、
それほどの権限もってるんだっけ？
つまり普通のexe並みの権限を？

>>403
警告のデザインをもっと工夫して
わかりやすくすればいいと思うけどな

すべてのjarに署名して、.jnlpに
<security>
<all-permissions/>
</security>
と書けば、exe並です。
っていうかふつうのJavaアプリケーションと同じ。

でもそれだと信頼できないActiveXのアプリを野放しにしているのと同じだからな
アプリケーションの変わりに使うというのならいいのだが
webstartはアプレットのように気軽にブラウザから起動できるので危険極まりない

それならばいったんダウンロードさせて各自の責任においてアプリケーションを起動したほうがまし

ダウンロードさせて各自の責任においてアプリケーションを起動

webstartじゃん。

>>412
あれ、まさしくその通りなんじゃないんだっけ？＜JavaWebStart

被った・・・。
秒単位で。

AllPermissionで使った場合でも、アプリケーションを配布してインストールさせる
必要がないってところがウリなんだろ。新バージョンをあげとけば、WebStartが
勝手に認識してダウンロードしてくれるし。

自分で保存先を選んでウイルススキャンして実行とかできるのにたいして
webstartはリンククリックしたらいきなり起動だからな
ユーザーはしらないでOKOKと押していくよ

アプレットやwebstartはサンドボックスの中でありながら影響のない部分で
アプリを動かせるのだけが強みかと

JNLPAPIみるかぎりアプレットでは制限厳しすぎたと思ってるようだけどね

まぁ野良署名つきがいいと思うのならActiveXでもいいしアプレットでもいいけどな

WebStartはベターアプレットを目指してるだけだから
JNLPAPIによるサンドボックス内の緩和とキャッシュ制御だけだと思うがな

基本的に署名はベリサインと握手せんといかん

ダウンロード＆実行と比べれば、どうでもいい話だな。

ワンクッションおくというのがいいという場合もある
あとはリソース読み込みがなぜかうまくいかないライブラリもそれなりにある
JavaSoundとか変な動きするのがちらほらと

ああインターネット配布を想定してたのか。なるほどね。
おれは企業内で社内アプリとか配布するのを想定してたから、
「ウイルス汚染されたもんを配布サーバに置いたらクビもんだろ」
とか思ってしまったよ。

JavaWebStartではendorsed mechanismが使えないから、
JRE同梱のXalan2のバグとかを回避できなくて、泣いた。

>>418
別に自前署名でも問題ないぞ。DLL使いたいがためにVerisign使うバカはいない。
ってか、Mustangのネタはどうなった。個人的にはJVMの共有が気になる。
JVM起動のフットプリントがさらに下がるわけだし。
Acrobatの常駐プロセスのっけてるのに気がつかんようなやつなら
「Java速くなった」って単純に喜べるようになるでしょ？

自前じゃ警告がなぁ
社内システムとかならそれでいいかもしれんが

いつでも安全にローカルディスク上から取り除く為の仕掛けを各プログラムによ
らないセントラルなシステムとしてJava自身(JavaVM？)が持つ。

そして、警告は実行時に逐次ポップアップしてユーザーに許可を問う。
例えば、ローカルディスクから読み出しを行う場合、「警告：〜がローカルディス
ク上のファイル××に対する読み出し権限を要求しています。許可しますか？」
といった具合。
ここでの許可不許可は全てセントラルなシステムに記録され、いつでもユーザー
によって変更する事ができるものとする。

こうなってれば俺としては安心して使えるんだが、どうだろう？

署名なしのJNLPAPIがほぼそれだけど？

>>426
あれ？そうなの？
どこかのスレにサンプルとして貼られてたURLをクリックしたら
最初に全ての権限を要求されたけど？
これだと、完全拒絶か完全黙認かの二択しかない。

あと、これってどこからアンインストールできるのか分からん。
真面目に調べれば直ぐにみつかる事なのかもしれないけど
大して邪魔にもならんから放ってる。
ただ第三者に自分が提供する場合を考えると、もうちょっとど
うにかならんか？と思う。

そりゃサンプルが全権限を要求したからだろうなあ。全権限要求するアプリには、
最初に警告がでる。

言ってるのは、ファイルとかにアクセスするたびに「許可しますか？」と聞いてきて、
許可したら、許可したってことを覚えておくってこと？
そうだとしたら、ちょっとうっとうしくないかな？

それよりはJNLPみたいに、ファイルＡには読み書き、ファイルＢには読み込みのみ、
開けるソケットは何番から何番、と一括で制御できるほうが。

全権要求は一般的なWebstartとはいえん
自分で適当にサンプル作ってやってみればわかる

プリンタ使うときやファイルの保存やロードのダイアログを出す直前に
確認のダイアログが出る

次からもこのダイアログを出すかどうかのチェックボックスもでる
ただし、アプリ終了したら次回もまた確認の画面はでるが

JNLPAPIの実装でやってるんだろうね
VMがずっと見張っているというのは厳しいからね

>>428
>言ってるのは、ファイルとかにアクセスするたびに「許可しますか？」と聞いてきて、
>許可したら、許可したってことを覚えておくってこと？
そう、とりあえず実行してみて、信用するか否かは動作を見ながら決める。
そして、許可した権限は何時でも好きな時に一覧として閲覧したり変更したりでき
ると、そんな感じ。

自分とこの看板に自信がある人なら、最初に全権を要求するとか、読み込みに関
するフリーパスを要求しても大丈夫だろうけど、そうでない(例えば、2ch発の名無
しさんアプリだったり？した)場合に、最初から敬遠されてしまっては意味がないか
ら、段階的に少しずつ要求したい(＆してほしい)。

勿論、最初にある程度纏まった要求を出す事＊も＊できていいと思う。
個別に毎回というのは、あくまで＋αとしてって事で

>>429
げっ、すれ違ったorz

個別に要求を出す事はできるのか・・・・・・
それじゃあ後は覚えててくれて、一覧で確認できて、それを変更する事も
できて、嫌になったら何時でも放り出せる様になってれば十分。

ダイアログが出せるなら、一覧から過去に要求を問うた事があるか否か
を調べて、ないならダイアログを出し、あるならその時に設定されたフラ
グを元に動作を決定すればいいだけだから、やろうと思えばやれると思
う。

まとめるとこんな感じであってますか？
■署名なし
　JNLP APIでのみ、ローカルリソースにアクセス可能。
　アクセス開始時に確認ダイアログがでて、以後は許可とすることができるが、
　起動しなおすとまた確認ダイアログがでるのでうざい。
■自己署名
　all-permissionにして、通常のJavaアプリとして操作可能。
　1回目の起動時のみ、確認ダイアログが表示される。
　「この証明書の信頼性を検証できません」というキツイメッセージ。
■Verisignで署名
　all-permissionにして、通常のJavaアプリとして操作可能。
　1回目の起動時のみ、確認ダイアログが表示される。
　自己署名よりもやさしいメッセージ。
■自己署名の証明書をルート証明書としてインストール
　Verisignで署名したのと同じような表示。
　証明書の安全な配布・インストール方法が必要なので面倒。
　1.5より前は、証明書の指紋をGUI上で確認する方法が無いので、
　インストールした証明書が本物かどうか確認できない。

>>432
乙！

だいたい、いいんじゃない。
all-permission じゃなくて all-permissions だけどな。

ちなみに俺は all-permissions と j2ee-application-client-permissions の
違いがよくわからん。教えてエロイ人。

webstartスレかと思うくらいの流れだが
6.0の話題はまったくないな

5.0も変更が大きすぎて今まで以上に以降が進んでいないように見える

6.0によるJVM共有の意義は、サーバ側Javaよりもむしろ、
クライアント側Javaのほうにある、ってことだろ。

そういう意味で、JavaWebStartを話題にするのは、
それなりに主旨に合ってると思うぞ。

MustangかDolphineかで、入るとか入らないとか言われている、
JDICについて貼っときます。

https://jdic.dev.java.net/

The JDesktop Integration Components (JDIC) project aims to make Java
technology-based applications ("Java applications") first-class citizens of
current desktop platforms without sacrificing platform independence.

JDIC provides Java applications with access to facilities provided by the native
desktop such as the mailer, the browser, and registered document viewing
applications. Additionally it provides the mechanisms by which Java applications
can integrate into the native desktop such as registering Java applications as
document viewers on the desktop, creating tray icons on the desktop, and
creating installer packages.

JDIC consists of a collection of Java packages (JDIC API), all with the package
name prefix org.jdesktop.jdic, and a JNLP application packaging tool (JDIC
Packager).

つーわけで、これもJNLPでdeployされるわけだ。

>>428,429
ttp://java.sun.com/products/javawebstart/docs/javadoc/
の、FileOpenServiceとかFileSaveServiceを見てくれ。

JNLPでは、どのファイルを開く・どのファイルに保存するかは
ユーザが選ぶするから安全、という考え方をするようだ。

よって、「他のプロセスが作ったディレクトリ/ファイルを共有して、
ディレクトリ単位での処理をする」というようなプログラムが書けない
ことになる(署名が必要になる。ちょっと不便。JNLP APIが改訂されないかな…)。

署名無しでクライアントローカルに永続データを作って、
アプリケーション間で共有して読み書きしたければ、
PersistenceServiceを使え、ということらしい。

javaws が CUIで使えるようになったらいいのになぁ・・・ってこういうの1.6ではどうでしょう。

>>437
429だけどなんで参照されたのかわからんが、当たり前のことかかれても

ユーザーで選択するから安全ってのはＷｅｂｓｔａｒｔが標準添付される前から
やってきた俺にとっては当たり前というか、まずはそこを解決したかったのが
ＷｅｂＳｔａｒｔという感じだが

>>439 なんか誤解させてしまってスマソ。

ようは、JNLP APIの、FileOpenServiceとかFileSaveServiceは、
JFileChooser#setFileSelectionModeメソッドでFILES_ONLYにした場合の
JFileChooserに相当する機能しか使えないけど、
DIRECTORIES_ONLYやFILES_AND_DIRECTORIESの機能も使いたい、ってこと。

java.io.Fileというクラスには、
javax.naming.Binding的な機能と、
javax.naming.Context的な機能などが，
いろいろに混ざっている。

で、これに対して、
javax.jnlp.FileContentsというクラスは、
javax.naming.Binding的な機能に相当するクラスとして作られている。
javax.naming.Context的な機能は取り除かれている。

java.io.Fileを生で使わせるのは危ないっていうのはわかる。
でも本当に危ないのは、
・java.io.Fileのコンストラクタが呼び出せる
・java.io.File#getParentが使える
の2点に限られるんじゃないのかなぁ？

javax.jnlp.FileOpenServiceやjavax.jnlp.FileSaveServiceから
ユーザの自己責任で生成されたオブジェクトに対して使うんだから、
javax.naming.Context的な機能も使わせてくれよ、って俺は思うんだよ。

つーわけで、javax.jnlp.FileContentsのサブクラスとして
javax.jnlp.FileContextなんていうのが作られることを1.6ではキボンヌ。

ああ、了解了解

ところで次のやつは6.0だよな？
内部バージョンも次からは6.0と聞いたが

ごめん、FileContents はインターフェイスだった。

内部バージョンって System.getProperty("java.version") とかで取れる奴の事？

public class Binder2nd<_Arg1, _Arg2, _Result, _Operation extends BinaryFunction<_Arg1, _Arg2 , _Result>>
implements UnaryFunction<_Arg1, _Result> {

protected _Operation op;
protected _Arg2 y;
public Binder2nd(_Operation __op, _Arg2 __y) {
op = __op;
y = __y;
}
public _Result execute(_Arg1 __x) {
return op.execute(__x, y);
}

public static <_A1, _A2, _R>
Binder2nd<_A1, _A2, _R, BinaryFunction<_A1, _A2, _R>> make(BinaryFunction<_A1, _A2, _R> __fn, _A2 __y) {
return new Binder2nd<_A1, _A2, _R, BinaryFunction<_A1, _A2, _R>>(__fn, __y);
}
}

これはもうJAVAじゃないな

期待あげ
6.0仕様公開らしいよ
ttp://jcp.org/en/jsr/detail?id=270

jsr203 NIO2入れて欲しかったなぁ。。。

6.0のソースコードgets.

このソースコード、ほんとにJVM入ってるの？

>>446
なんができるの？

NIOはネットワークソケット周りにＯＳのnon-blockingアクセスを使えるようにして高速化した。
メモリバッファをJVM内ではなくＯＳのネイティブなメモリ空間を使用したりするなど、なかなか
いい感じだった。

だけどNon-blocking I/Oはソケットにしかつかえないという制限もあった。メモリマップ・ファイル
とか意欲的な取り組みもあったけど、やはりキモはSocketのNon-blocking I/Oだった。

NIO2はファイル周りにも手を付けて、ＯＳの非同期ファイルアクセス機能を取り入れたり、
ファイル属性を扱えるようにしたり、NIOで未実装となったものも実装しちゃうぞ、となかな
か面白い試みで、実はJSRとしてあげられた段階では 1.5 Tigerに入れる、とか書いてた。

実際VoteもMacromedia以外はＯＫ出してるんだけど、6.0にも乗らないのかよ...

そうなのか。
いまさらNIOの質問だけど、NIOのメモリバッファって、JVMの設定とは別にメモリが使えることになるのかな。

allocateDirect()で確保されたバッファは、JVMのヒープじゃなくて、
プラットフォームのネイティブなメモリ空間として確保されるから、関係なかったはず。

ごめんソースが出せない...

サンクス。
なんとなく巨大なメモリが必要なときにつかえそうだってことがわかった。

>>450
ほとんどのケースで NIO 使わんほうが
効率いいけどな。

NIOというと
New I/Oと勘違いしそうだ

NIOっていったらNew I/Oじゃん。

Nice I/Oに決まってる。

>>454
天然？

Neo I/O

トリニティ助けてー

6.0のソースコード解読はムズい。
コメントが少なすぎてわけわからんよ

Non-blocking I/O
と
New I/O

New I/Oのパッケージ名が
java.nio
なら
Non-blocking I/O
は
java.nbio
になる？

Non-blocking I/OはNew I/Oの一機能にすぎんぞ。
だからjava.nio.channel.SocketChannelでサポートされてる。

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4057701
上記のは Evaluation に書いてあるんだけど、
ディスクの空きスペースを取得するAPIはMustangに追加されるみたい。

DirectByteBufferってJNI側で確保したメモリ領域をJavaから使えるようにするために用意したとしか思えん

ファイラー書いてるんで、お願いだから属性の取得、設定を追加して欲しい・・・

ごめん、ファイルの属性ね。

>>465
jconfig使えってのが定番の答えだねぇ。

JDICとかに要望出してみれば？

JConfigはフリーじゃないのが痛いけど、品質が確かなら
採用する価値ありそうだね。
JDICにも要望出してみるよ。
ありがとう。

そういやJDICってMustangに入るって噂あったけど入らないことに決まったの？

P.S. そろそろ Dolphine のスレたたないのかな？

>>469
入らないってのはどっから出てきた話？

お、生きてた。このスレ。
>>470
いや、2月にMustangの仕様がJSRに上がったけど
ttp://jcp.org/en/jsr/detail?id=270
英語を読む体力と根性がなくて・・・

>>471
JDIC自体がJSRに入ってないプロジェクトだったような。

1.6 てどう変わったの？

過去形ですかっΣΣ(ﾟдﾟlll)

>>473
今のクラスキャッシュ共有を推し進めて
ＶＭインスタンスの共有が行われるとか聞いた気がする。
System.exit() 問題にどう対応してるか見もの。

単純にOSのようになるだけじゃね？

>>475
それって、Sunの実装の話ではなくて、VM仕様の話として決まることなのかな？

これって下位互換どーなのよ？
最近、虎でたばっかなのに。

>>477
実装の話でしょ？
仕様でどうやって定義するんだ？

>>479
クラスローダーの仕様が変わるとかさ。
1.6(6.0)でどうかわるかっていう話が、仕様の話か実装も含めた話か、確認したかっただけ。

>>480
VM仕様はちゃんと精読しとらんけど、一部かわるかも。

どちらかと言うと今まで厳密に決まっていたものが
「実装依存」とか「未定義」に格下げされる方向で
仕様が書き換わる事があるのでは、と予測。

クライアントに本気で侵攻するなら、
いい加減SWingを諦めてSWTを標準に…。

Javaはもうインターフェイスだけにして後はすべてJNIで実装しろ

>>482
SWTが諦められてしまいましたが。

>>483
なんでわざわざ遅くなるやり方にするんだ？

>>482
eclipseを追っかけてたらそんなことはいえないだろ・・・
NetBeanの方がいつのまにか軽くなってるし
>>481
System.exit() がdeprecatedになって別のアプリ終了手段が用意されるに1票。
もしくはdeprecatedがなくとも、exit()はパーミションを持ったクラス(システムクラス)だけが
実行できるようになるのかなと予想。

＞eclipseを追っかけてたらそんなことはいえないだろ・・・
＞NetBeanの方がいつのまにか軽くなってるし
まじ？

Netbeansはたしかに軽いよ。

>>487
ま、ツールもなく資料もなく経験者もいないというデメリットに目をつぶって採用するメリットはまったくなくなった。

MustangはGroovyのためのプラットフォームになります。間違いない。

Groovyはやめて欲しい。。

オレも。
Groovy早めて欲しい。

Groovy…… 仕様固まったらやってみよう。
BSF対応してんだっけ？

Netbeansのアプリケーションサーバとの連携機能は神懸かり的にすばらしいと
思うけどなあ。

HTTPモニタがいいね。あとprofilerとかね。NetbeansだけでEJB作成（ウィザードで
選択してったら、リモートインターフェースとか配備記述子とか全部作ってくれる）や
サーブレット作成（New Servletを選んで必要項目を入力したら、クラスファイルの
ひな形を作った上でweb.xmlにサーブレット定義を挿入する）とかがデフォルトで
サポートされているところも結構いいと思う。

まあ仕事ではEclipseだが....

>>494
4.1はまだ正式版でてないよね？
EclipseもいいものだけどEclipseしか使ったこと無くてNetBeansけなすやつら多すぎ

あとはJBuilderのような親切な画面がほしい
そのへんはEclipseもNetBeansもまだまだ

Eclipseは、まだまだというか、いつまでたっても無理だろ。
JBuilderは結構な金取るわけだから、親切な画面くらいはないとね。
NetBeansはSunも本腰入れ始めたし、これから期待だ。

>>491-492はスルーかい

突っ込んだ方がいい？

突っ込んでみよう。
Groovy、「未完成」「コマンド名が長い」以外にマズーな部分て何?

497が突っ込んで欲しいのは、そういうまじめなところじゃないと思われ。

http://java.sun.com/developer/technicalArticles/J2SE/Desktop/mustang/

Improve Windows Look and Feel
　Use Microsoft's API for rendering portions of components.
　Make sure each of the components look and behave correctly.
　Ensure Swing's Windows look and feel looks good on Longhorn.

JTable sorting, filtering and highlighting

More/better graphics hardware acceleration on Windows

Improved text quality and capabilities

Japanese calendar support

Pop-up splash screen at beginning of Java startup

API to add a Java application to a system's app-launching panel/toolbar

Deployment Helper Browser Controls on Windows

このあたりが注目ポイントかな。

JWS の話が結構盛り上がってるね。
アプリケーションを exe にするときは、これが便利そう↓

http://www.paw.hi-ho.ne.jp/~ryo-h/exewrap/

> Pop-up splash screen at beginning of Java startup
> API to add a Java application to a system's app-launching panel/toolbar
この辺がJDICの成果物かな？

JWSなら、CUIの起動にも使えるようにして欲しい。
サーバ側も保守が楽になるから。

「分離」機能って、.NETのアプリケーションドメインのこと？

>>468
JDICに ファイル属性にアクセスするAPIの追加が提案されてる。
http://www.javadesktop.org/forums/thread.jspa?messageID=74483

あとは、ファイルシステムのイベントも取れるように考えてるらしい。
WindowsはそーゆーAPIネイティブで持ってるけど、
posixってそーゆーAPI持ってたっけか？

あまり知らない者の単純な疑問だけど、Javaって将来性あるの？
バージョンアップするたびにJVMはますます重くなるし、いまどき、
アプレットなんてJVMが起動するだけで半分くらいのPCが固まってしまうから、
気の利いたホームページはみんなFLASH使ってるし。
サーバー上では、スピードからいったら、Perlにまるっきし叶わないし、
別にC++で書いてもいいわけだし、ポータビリティーなんて大騒ぎしていた
けど、JVMの走るプラットフォームには、大抵Linuxが走るし、
何がいいのかわからない。

おまけに、Sunが1人で管理しようという姿勢が気に食わない。オープン
ソースにしたら、もっと改善されていくと思うのに・・・

>>506
無知蒙昧とはお前のことだー

>>507
構って君の相手をすんじゃねー

Appletそれ自体にはまだまだ使い道があると思うんだけど、WinXP SP2を
除けば大概のWindowsマシン上ではMS製JavaVMが動いてる。
こいつが困りもんなんだよな。
Applet側の要求に従って、利用するVMを動的に切り替えられるといいん
だけどな。

て言うか、ローカルディスクの残り容量を取得するAPIの追加マダー？

6.0はデスクトップに狙いが定まっているよな感じだね

>>506
学生？

あまりにも見事な釣りなのでレスするのもためらってしまう>>506

＞サーバー上では、スピードからいったら、Perlにまるっきし叶わないし、

このへんが秀逸ですな

大槻ケンヂがいるな

> 別にC++で書いてもいいわけだし

アセンブリで書いてもいいよ。

いや、真のプログラマならマシン命令を二進数で直打ちだろう。

>>513
気付いた人がいたーよ

>>515
俺のPCはキーボードなんて無いぞ。
2進法直打ち用のトグルスイッチが横一列に64個ならんどる。
これで64ビットプログラミングもチョチョイのチョイだ。
Javaなんてのは鼻垂らしの道具だな。

64個もスイッチがあれば、アルファベットの入力に支障はないが。

>>516
詳しく

>>519
お前は無知だ。
無知だ、無知だ、無知だ。
無知蒙昧とはお前のことだ。

>>509
そういや、俺のよく行くチャットサイトは、MSJavaじゃないと動かない。

>>520
あのー、大丈夫ですか？

バージョンアップ早杉。

むしろ遅すぎのような

>>521
流れ嫁

>>522
FORTRANに比べれば、早いね。

言語仕様だけじゃなくVMというものがある以上
OSのバージョンアップみたいなものだからな

時代に合わせて最適化等していくわけだし仕方あるまい

ttp://weblogs.java.net/blog/georgez/archive/2005/04/jdic_features_i.html

自レスだけど、MustangとJDICの絡みのドキュメソト見つけたから貼っとく。

>>506
ttp://shootout.alioth.debian.org/great/benchmark.php?test=all&lang=all&sort=fullcpu
なんか、JavaってPerlよりスコアいいらしいよ。
# ああ、スレ賑やかしの為だけにレスってしまたorz

C/C++>>Java>>Tcl>>Perl>>Python>>>>>>>Ruby


Javaの次にTclがハイスコアｗｗｗﾜﾛｽ
俺Tcl大好きｗｗｗ超ウレシイｗｗ

>>527
厨に燃料投下するのは止めてﾎｽｨ

>>506
絶対悪い口言われないからPHPにしときな

とりあえず日本語の練習してこい、と。

おまけに遅レスだし

>>530
今、気の利いたホームページを作ってるのでFLASH使ってるんですが、PHPにするにはどうしたらいいですか？

>>528-533（>>527の下半分も）
Mustangの話題じゃないなら別のスレでやれ。

>>534
はーい。(でも、別にわざわざする気は無いけど)
で、>>534 は何かMustangの話題提供してくれへんのかなー？

ttp://weblogs.java.net/blog/chet/archive/2005/05/graphics_accele.html
VRAMの利用と、専用チップに処理を振る並行処理もJava2Dに入ってくるらしい。
これって、ほんとにデスクトップアプリケーションで実用ソフト増えそうだね。
でも、個人的にはデスクトップで実用的に使うには
プロセス名が「javaw.exe」以外で見えるようになってくれるのが一番欲しい機能。
windowsならexewrapとか使えばなんとかなるけど、unix系だと全部javaだから引数見ないとわかんないのよねぇ。
windowsでファイアウォールルール書くときも困るし。
ネイティブコマンドラッパの作成標準ツールも欲しい、と。

まとめサイトまだ？

> プロセス名が「javaw.exe」以外で見えるようになってくれるのが一番欲しい機能。
自分でコード書いて、Mustangに寄贈してくれ。

>>527
>>501-502 で既出の内容、と。

>>535
ほれ。
http://weblogs.java.net/blog/stanleyh/archive/2005/04/deployment_good_1.html
JWSのセキュリティ警告のダイアログを刷新するんだってさ。

あと、話題捏造しなくて良いから。

これって Mustang には入らないんだっけ？
https://jdic.dev.java.net/nonav/incubator/fileutil/javadoc/org/jdesktop/jdic/fileutil/FileUtil.html
org.jdesktop.jdic.fileutil.FileUtil のインターフェイス（仮）だそうで。
getFreeSpace の戻り値が BigInteger になってるねぇ……
long で足りなくなる事って当分無いと思うんだけど。

あと、Solaris と Mac OS X での協力募集中だって。
http://www.javadesktop.org/forums/thread.jspa?messageID=78329

>>535
argv[0]にクラス名でも放り込んでexecするよーなwrapperがあればとりあえず何とか。>UNIX系の場合

シンボリックリンクで何とかならんのかｗ >> プロセス名

とうとう、SnapshotでJudeが動かなくなっちまった。
しかたねえ、5.0で動かすか。

Mustang の　b39のリリース差分のドキュメント見てたら
＞Provide a writer plug-in for the GIF file format
と。ようやくGIF対応らしい。

もうPNGでいいよ…

いちおう貼ってみるテスト
http://java.sun.com/developer/technicalArticles/J2SE/Desktop/Mustang_build39.html

あの、ネットワークには強いっていうか、Javaは向いてると
思うんですが、


HTML3.2しか対応してないってのはどういうことですか？？？
J2SE1.6では対応するんでしょうか？

JavaというかSwingの話か
ブラウザ開発はそれだけでもかなりの労力がかかるからねぇ
ブラウザを起動して南下させるのが無難

でも、Swingはコンポーネントの描画にHTMLつかえるのらくちんだよ
ラベルとかも2行に表示したかったら<br>とかつかえるし

>>547
ちなみに、HTML3.2しか対応して無いと不都合な事って具体的に何？

あと、JDIC で IE やら Mozilla やらのネイテイブのブラウザコンポーネントを
使えるように頑張ってるからそっちを使えば？

>>505
亀レスだが、POSIX.1b real time signalに、
I/O eventsをsignalで知らせる仕様がある。
fcntl(2)のF_SETSIGの機構と同じ。

むしろファイル属性の方が、
OSによって全く違うフレームワーク、スキーマなので問題が多いと思う。
例えばファイルタイプやアクセスコントロール。

あげまして

さてそろそろ、今年のJavaOne基調講演が始まるわけだが。
これまで参加したヒトはいます？

参加費用が高すぎてムリポ

学生にはつらい額

費用と英語の高い壁が．．．orz
今年もさくらばさんのJavaOne Reportsに期待

おい、JDK6.0最新開発バージョンで、Genricsの実行速度が向上しているぞ。

本来、Genricsを用いたコードでは、キャスト可能であるかをチェックするコードを、
Hostspotコンパイラが除去できるはずなのだが、JDK1.5では不十分であったように思う。

この試したバージョンでは、直接１つの型専用に書いた場合と、Genrics汎用クラスに型指定をした場合と
実行スピードが同じになっているぞ。

そもそも、キャストってどれくらいのオーバーヘッドになるのだろうかという素朴な疑問。

ダウンキャストがオーバヘッドに
なることは間違いないだろ。
Genericsを使えばあらかじめクラスが定められているんだし。
ダウンキャストはまずクラスを検索するだろ。
サブクラスが複数有ればそれだけ検索に時間がかかる。

すまんがよくしらんので適当に言ってみた。

EclipseのByteCode OutLineプラグインを
使えば何かわかるかもしれぬ

よくわからんがパフォーマンスが上がるのは良いことだ。
Generics 使ったこと無いけど。

>>556
性能にひびく部分は普通はコンパイルされて実行されるので、
機械語レベルで考える必要があって単純ではないが、オーバ
ヘッドは0じゃない。

Genericsが使えるような場面では、頻出の型をキャッシュする
などの最適化の結果、それぞれの文脈で、よくある型のキャス
トはポインタ比較+(分岐予測がほぼ当たる)条件分岐で済むの
で、CPUのパイプラインも乱れず、実行ユニットが有り余る近年
のスーパスカラCPUではミクロな視点では影響がないと言っても
良い。しかし、当たるべき分岐予測を理論通りに当てられる分
岐の数にはCPUの実装による制限があるので、マクロの視点
では影響がある。

>>557
キャストにコストがかかるのはいいとして、
Generics使って書く部分はキャストが無いように書ける部分ですよね？
だから、省略されるのは型チェックだけなんでは？
Genericsでも、サブクラス判定は入るだろうし。

サブクラスでないものを突っ込むコードを書いても、
コンパイル時にエラーとなり実行できないと思うが。

Σ(ﾟдﾟlll)　あ、・・・・・・・
・・・・・・・・・・・・・・・⊂⌒~⊃｡Д｡)⊃

http://pcweb.mycom.co.jp/articles/2005/08/16/mustang/

>>563
どれもアノテーションをふんだんに利用しているな。
個人的にはSwing機能のUPとJava Web Startの改良に期待。
JWSはセキュリティの強化よりもあの警告をもう少しやんわりしたのにして欲しいよ。

javawsは-importオプションがバグバグなのを、なんとかしてほしいな。

コード署名用の証明書が自己署名のときの警告については、仕方がないだろう。
ちなみに貧乏人は、これ↓を試すと、あるいは幸せになれるかも。
http://www.crionics.com/products/opensource/faq/signFree.htm

日本語フォント太字・・・

>>565
bold って Tiger でずいぶんマシになったと思うけど。

×>>565 ○>>566 だった。

>>568
え、変わったの？
相変わらずホラー調で困ってるんだけど・・・・
http://uper.on.pc1.jp/upload/so/up4533png.html

>>569
もしかしてpeercast用のツールですか？

>>569
1.4.1 の出力と比べてみれば変わってるのがわかると思うよ。

1.4.2 は Tiger と似た出力になってる……
元からだったか、Tiger からバックポートされたのかわからんけど。

>>570
少し違うけど似たような用途の物です

>>571
まだまだ汚くて読めないよ
バージョン上がる度に期待しては裏切られ・・・

Mustang＋Windows Vistaあたりで改善されるかもね　＞Bold

Mustangビルドでは、いちおうアンチェリかけることができるはず。

>>574
アンチエイリアシング自体はずいぶん前からあったような。

Mustang で追加されたのって液晶を利用したアンチエイリアシングでしょ。
WindowsXP の ClearType みたいな奴。

MustangあたりでそろそろJava3Dもデフォルトで含んでほしいなぁ。
Web3DをやるのにJava3Dがデフォルトでないからってレンダラ部分まで手書きしてる所も多いし。

>Web3DをやるのにJava3Dがデフォルトでないからってレンダラ部分まで手書きしてる所も多いし。

別に入れればいいだけだろ。

Java3Dの配布形態考えれば>>577のような考えは出てこないだろうに

だから、使う奴が入れればいいだろ。

利用される機会が増えれば自然に入るものかと。
今はその段階にはないのでは？＜Java3D

そこでLooking Glassですよ

開発者にライブラリを入れさせるしくみとしては、Mavenを、
ユーザにライブラリを入れさせるしくみとしては、JavaWebStartを使うといいよ。
Maven JNLP Plug-inも便利．

サンドボックスでは問題がある場合も多いんじゃないかね?

そこでコード署名ですよ

http://www.crionics.com/products/opensource/faq/signFree.htm
これを使うと無料？

標準で含めないから普及しない。普及しないから含めない。デフレスパイラルなわけで。
Java3Dが含まれない理由の一つに単に容量がデカイというのもあるらしい。

VBのインストーラみたいに必要なものは全て自動で1つにまとめて
利用者はSETUP.exeを実行するだけってなればいいのにね
Javaは一つのファイルにまとめる過程が非常に面倒

Javaのほうがランタイムは融通が利いて楽だけどな
ディレクトリつきでコピーするだけだし

>>586
maven javaapp

>>586
ん？
何のためにJARファイルがあるの？

java -jar ファイル名

でいいじゃん。
WebとかならWARファイルでいいし。

>>586
逆から見ると、いたる所にゴミをばら撒かれて迷惑とも言える。
アンインストールしてもゴミはほったらかし。

ま、そんな派手に行儀悪いアプリばっかりじゃないけどさ、
javaで配布するんなら、インストーラじゃないと
入れられないようなのって、そう多くないと思うぜ?

java.util.prefs.Preferences てレジストリ汚すよね。

それはmustangネタなのか？
レジストリ使うためのAPIを使いつつ、「レジストリ汚す」はないんじゃないか？

Netbeans4.2で使ってる、orj.jdesktop.layout の情報ってドコで手に入るんでしょ？

ここじゃネーノ？
ttp://jdic.dev.java.net/

>>593
ttp://swing-layout.dev.java.net/

Javaは、一度試みられたECMA、ISO等の標準化を再度行う予定はないのだろうか。
Win32と同様のIO・スレッドモデルを持つ環境でしか仕様を満たせないCLＩ仕様を
崇める人々が標準化標準化と粘着君なのですが。

リスクを負ってまで標準化するメリットはないってことじゃない？

Java SE 6: 新しいJava2DレンダリングエンジンとJOGLの統合


来年の夏頃にリリースされる予定のJava SE 6(開発コードMustang)では、
開発の目標の1つとしてデスクトップ環境の強化が掲げられている。そのう
ちのJava2D APIに関する拡張として、Java2DにおけるOpenGLレンダリング
の高速化がある。

Mustangでは、Java2DにおけるOpenGLのレンダリングを高速化するために
パイプライン処理の実装が見直される。既存のレンダリングエンジンでは複
数スレッドによるレンダリングを並行してネイティブのグラフィックライブラリ
で処理させるという実装方法が採用されていた。これに対して Mustangで
はシングルスレッドレンダリングを採用、複数のスレッドからのレンダリング
要求をパイプラインによって管理し、効率よくグラフィックライブラリに渡す
ようになる。このシングルスレッドレンダリングの実装はMustangの開発版
リリースbuild 27ですでに実装されており、J2SE 5.0の実装に対して大幅
なパフォーマンスの向上が確認されている。

一方、JavaプログラムでOpenGLを使うために古くから利用されているAPI
としてJOGL(Java Bindings for OpenGL)がある。JOGLはJSR 231で標準
化されているAPIで、JavaコードからOpenGLネイティブライブラリへのバイ
ンディングを提供する。JOGLではGLJPanelというOpenGLに対応した軽量
コンポーネントを提供しており、これを使用することでSwingアプリケーショ
ン内でOpenGLによる3Dグラフィックスの描画が可能になる。しかし、既存
の実装ではこのGLJPanelを用いたレンダリングは非常にパフォーマンス
が悪いという問題があった。

続き

Java SE 6: 新しいJava2DレンダリングエンジンとJOGLの統合
http://pcweb.mycom.co.jp/news/2005/09/15/021.html

今月8日に公開されたMustang build 51において、JOGLのGLJPanelから、
新しいシングルスレッドレンダリングによる実装を利用するための機能が
実装された。これによって GLJPanelのパフォーマンスは大幅に向上し、
次のような効果が得られるという。

* OpenGLレンダリング上でのSwingコンポーネントのオーバレイ
* 様々なSwingウィジット上での3Dグラフィックスの利用
* Java2Dレンダリング上での3D OpenGLグラフィックスの描画
* OpenGLレンダリング上でのJava2Dグラフィックスの描画

なお、JOGLを利用したデモプログラムはjogl-demosプロジェクトサイト上で公開されている。


個人向けPCの性能が向上したことで、デスクトップアプリケーションにも充実した
表現能力が求められるようになってきた。このことはLG3D (Project Looking Glass)
などへの関心の高さにも現れている。今後もMustangにおけるデスクトップJavaへ
の取り組みに注目していきたい。

J2SE5.0でも一応Java2D描画のOpenGLサポートあるんだが
これがまともに機能しない

Java3D描画をONにすると描画品質がばらばらでお話にならないし
結局デフォのDirectDraw描画が一番ということになる

ただし、アクセラレーションされる描画はBlitのみ

Java2Dはアルファブレンドが通常合成しかないというのもイマイチ
加算合成がはいってきて拡大縮小回転までアクセラレーションがきけば
Javaはクライアントサイドも力が入っていますというのがわかるけどね

5.0は正直1.4で加速したクライアントサイドをストップさせた感じが強いなぁ

アクセラレーションとごろか回転とかアルファブレンド自体が無い生のDirectDrawよりマシ

build 48 のまんまだったので最新の build 52 を取ってきた。
その間に Summary of changes in Mustang をつらつら見てたら……

build 49 で JDIC の Desktop API が追加されてた。
http://download.java.net/jdk6/docs/api/java/awt/Desktop.html
これでOSで関連付けされてる方法で edit(File) とか open(File) とか出来る。
あとはデフォルトブラウザで browse(URL) できたりとか。

build 51 でパーミッション操作の API が追加された。
http://download.java.net/jdk6/docs/api/java/io/File.html
canExecute()、setExecutable()、setReadable()、setWritable() など。

>>601
APIだけはあったような
未実装だったが

>>596
JCP(Java Community Process)があるから、もうどうでもいいな。
http://jcp.org/en/home/index

一時の標準化よりも、将来のオープンな議論の枠組みの方が大切。
ECMA-234 Application Programming Interface for Windows (APIW) (December 1995)
なんてそれっきり放置だしね。たぶんC#, CLIも最初のだけであとは放置でしょう。

>>601
その辺の機能使いたきゃDirect 3D使えってことなんだよな

アルファブレンドはDirect３Dがくるまえから入れる予定だったのだが

Mustang build53が出たね

バイナリ
http://download.java.net/jdk6/binaries/

build52 からの変更点
https://mustang.dev.java.net/files/documents/2817/21109/mustang-b53.html

bug ID:4151279 Curves are not pleasing as JDK 1.1 がfixされたみたい。

正直、Javaは後方互換いらないから
０から作り直して欲しい。

作り直すくらいなら０でいいよ。

>>608
つ C#

>>610
シャープデベロップがもう少しがんがってくれれば、、、

Mustang build54 リリース

build53 からの変更点
https://mustang.dev.java.net/files/documents/2817/21538/mustang-b54.html

Mustang build55 リリース

build54 からの変更点
https://mustang.dev.java.net/files/documents/2817/21986/mustang-b55.html

Mustang build56 リリース

build55 からの変更点
https://mustang.dev.java.net/files/documents/2817/22311/mustang-b56.html

Mustang build57 リリース

build56 からの変更点
https://mustang.dev.java.net/files/documents/2817/22748/mustang-b57.html

ISO-2022-JP-2 コンバーターが JIS X 0212 補助漢字をサポートするようになったらしい。
後は java.io.Console に readPassword が追加されたとか。

毎度おつ

Mustang build58 リリース

build57 からの変更点
https://mustang.dev.java.net/files/documents/2817/23134/mustang-b58.html

今回は目立った点はないね

下がりすぎてるのであげとくか

Sun、開発コミュニティに "Java 6" セキュリティ機能の問題発見を求む

http://pcweb.mycom.co.jp/news/2005/11/01/015.html

Mustang build59 リリース

build58 からの変更点
https://mustang.dev.java.net/files/documents/2817/23494/mustang-b59.html

今回は nio関連と localization関連のbugfix中心みたい。

そーいや、いつからか com.sun.source 配下に Tree API ってのが追加されてる。
これ使えば annotation で、もっとイロイロできるようになるのかも？

今日JavaOneに行ってきたぜ。

スキンヘッドの櫻庭氏がMustangのことを解説してくれた。

発表前にFTPでMustangのサイトをアップしたと言っていたが
サイトが見つからない。
http://www.javainthebox.net/
このサイトのどこかにあるはずなのだが、どこだ？
アップしたといっておきながら実は勘違い、または忘れていたか？




【Conference】 JavaOne Tokyo 【Event】
http://pc8.2ch.net/test/read.cgi/prog/1131068950/

age忘れた。

ググっても見つからないな

Java (J2SE 6.0) Mustang（マスタング)の概要を先取り
http://www.oklab.org/java/features_in_mustang.htm


このサイトでは無い。

どこだじゃじゃ馬馴らしは

JSR223 Scripting for the Java Platform

標準でRhinoがついてくるのか・・・・・ﾊｧﾊｧ

Groovyはどうなった？？？

Groovyにも対応するようになるらしい


っていうかデフォルトでPHPやJavaScript記述ができるのは驚きだね

C#のインラインとは違って文字列の中に突っ込むのでOROやregexのように
エスケープが必要だが

http://www.javainthebox.net/laboratory/JavaSE6/index.html
Last-Modified: Tue, 08 Nov 2005 07:12:10 GMT

http://www.javainthebox.net/index.html
Last-Modified: Tue, 08 Nov 2005 16:19:39 GMT

トップページの更新を忘れてたんかね

>>626
でかした！

お主、JavaSE6というディレクトリ名を予想できたということか？

気がつけばトップページのWhat's Newも更新されリンクが張られている

>>627
トップページから行きました。

Last-Modifiedとサーバ時間のずれ(8分強)から、1時11分前後に更新された見たいです。

逆探知で2chからリンクが張られているのに気づいたか？
それともサイトが見つからないぞとメールが来たか？

だろうか

第一幕蛾ぶっ壊れてる？

そろそろJavaってプログラミング言語じゃなくなってきた感が強くね？
OS/言語一体型って感じでBASIC時代に逆戻り感みたいな。
誰かひろゆきに頼んでJava板作ってもらえよ。

>>632
1行目なら抽象的ながらも言いたいことは自ずとわかるが
2行目はかなり違和感がある。

Mustang使ったことが無い奴が
ただムスタングのニュース記事見ただけで憶測だけで
判断してレスしているかのように見えてならないな。

Mustangはまだ開発段階だが、商用に使わず研究教育目的で使うのであれば、
ダウンロードして試用することができる。
BASICに逆戻りしているように見えると思うなら、まずは使ってから言え。

今時は、実行環境がpoorなプログラミング言語なんてないよね。
伝統的な手続き型言語の流れを組むC++だってtypeidがある時代だしね。

アルゴリズム＋データ構造がプログラムだった時代は終ってる。

今は何の時代？何処へ向かってる？

今は
構造化手法 + オブジェクト指向 + アスペクト指向の時代

エージェント指向へと向かっている

その場その場でいいものをどんどん取り入れるという
ある意味行き当たりばったりな
アジャイル開発がトレンドかなと思う。

アジャイル = ペアプロ + テストファースト + リファクタリング

Mustang build60 リリース

build59 からの変更点
https://mustang.dev.java.net/files/documents/2817/23871/mustang-b60.html

今回はSwing周りが多いな

こんな記事が
New System Tray Functionality in Mustang
http://java.sun.com/developer/technicalArticles/J2SE/Desktop/mustang/systemtray/

JavaOneでMustangを乗りこなすポイントを教えますセッションの
講演をしていたじゃじゃ馬馴らしスキンヘッドの櫻庭氏が
MustangではJavaだけでタスクトレイをいじれるようになると
言っていたような気がする。

たのむからそこまで知ってるならじゃじゃ馬のページでも見てやってくれ

櫻庭氏、index.html は更新忘れじゃなく時間が無かったのか…

>>636-638
マルチパラダイムってことでいいんじゃないかと。

Mustang build61 リリース

build60 からの変更点
https://mustang.dev.java.net/files/documents/2817/24195/mustang-b61.html

LinuxでソースからMustangのコンパイルに成功した人います？

今回はバグ修正満載だね

１つのVMで複数のJavaアプリが動くようになったら、
共有メモリ見たいなこと簡単にできるのかな？
他のJavaアプリのウィンドウの制御とか簡単にできるのかな？

それってJavaじゃなくても基本的なプログラムとしてはやらないことなんじゃないの？
他のプロセスをどうこう

連携するのが前提ならポートあけるしねぇ

>>650
むしろ一つのVMの中でごった煮にせざるを得なかったようなものを、(例えば携帯電話)
別々のVMの中で実行して「いるかのように」扱えるのが、アイソレーションだと思われ

他のアプリケーションへの干渉とかよりも、たとえば複数のサーバプロセスを持つクライアント
なんかを、一つのJVM内で実現可能（つまりスレッドよりももっと隔離された形）ってことなんじゃ
ないかと想像してるんだけど。

互いに悪影響を及ぼさないように保護しつつ、且つもっと身近なプロセス間通信
も提供する・・みたいな程よい機能ってこと？

virtual machine の名が示すとおり、まさにひとつのCPUみたいな振る舞いをするってことかな

アプリごとに環境を切り分けたいならプロセスを分ければいいだけの話。
multitaskingの目的はメモリの節約。

Mustang build62 リリース

build61 からの変更点
https://mustang.dev.java.net/files/documents/2817/24932/mustang-b62.html

age

おつ

そういや有名だと思うがいまだに5.0の印刷バグがなおらんのはなんでだろ
5.0でて1年以上たつというのに1.4.2までは動いていた印刷サービスのSunのサンプルもおかしくなるしな

JavaSE６で直ってるんだろうか
2バイトキャラクタ表示しなければ問題が出ないというあたりが不安だ

報告した？

英語かけないし
日本語出せばいいだけだからとっくに報告あがってるんじゃないかな

キシダタソの本の印刷部分もアルファベットしか印刷してないしなぁ

LinuxでのGTKサポートイイね。
でもフォントなどはGTKそのままの設定ではなくJavaで描画してるからネイティブアプリにはやっぱ見えないな。

Fileでファイルの属性変更できるのイイね。
でもやるんだったらちゃんとユーザ、グループ、その他まで変更できるようにして欲しかった・・・。
結局その辺JNIに頼るしかないのか・・・。

>>661
あのサンプルの日本語が印刷されないんですか？
うちではWindows2000+JDK1.5.0_02+hp5160/PrimoPDFでとりあえずいけてます。

かんたんpdfがだめですね
MS版PDFであるMDIもダメです
ただ、通常は問題ないように見えるので解像度を下げると分かります

具体的にだめなフォントは全角数字と全角コロンがはいった文字列を扱うと一気にだめになるようです
ほかには全角シャープかな

これらがはいるとその文字列丸ごとベクタで描画するようになっているのですが、
これらが入らない場合はちゃんとそのフォントで描画されます
この微妙な差がフォント置き換えとかが入るとだめなようです

ほかにもフォント置き換えのレーザープリンタ系が全滅なのを確認しています
ドットインパクトもだめでした
インクジェット系は大丈夫なようです

"Easy Sample:１文字列の描画"にすると、PrimoPDFでもフォントが荒くなりました。
HP5160(インクジェット)での印刷は大丈夫です。

これ1.4.2までは問題なかったと思うんだけれどもなんでだろー。

あと、これらの文字列が入った印刷をしてると、割と頻繁に
VMごとお亡くなりになったりします

Bug 報告しなきゃ直らねえっぺよ

>>661
既に報告されていたとしても、その報告にvoteを追加するだけでも意義があると思う。

>>666
エンバグした可能性はある。
リリースノートに載ってるバグ修正の一覧読んでるとそういうの結構あるよ。

英文のサイトあるけないので無理

1.4からの印刷サービス以外にPrintJobでも同じ結果が出るな。

インクジェットの場合はDPIが細かいので目立たないだけな模様。
フォント置き換えが入るレーザープリンタでは最悪な結果になるな。

ベクタ処理された文字はあくまでも文字としてみていないから、
まったく同じフォントを指定してもデータによってフォントがばらばらになる。

プリンタドライバのバグって線は無いの？

>>672
PDF出力プリンタにも影響あるからねぇ。

つまりJavaのデスクトップアプリは1.4までということね。
5.0以降はデスクトップアプリはあきらめなさいと。

バグ報告 (ry

英語ができないことを誇らしげに言うなと。

つまりＪａｖａは日本人は使うなと。

何を粘着してるのかしらんが、開発ツールなんてそんなもんだろ
英語のできない開発者・エンジニアは使いものにならん

10年もたってるのに印刷もまともに使えないJavaカワイソス

捨てゼリフ乙。

この印刷バグってそんなに問題？
大した問題じゃない気がするが・・・（だからなかなか修正されないのか？）

>>680
「日本語がレーザープリンタで印刷されない」っていうのは問題だね。

>>681
レーザープリンタ使える環境ではないからわからんのだが、
このバグのせいで印刷されなくなるの？

イマイチ発生する症状がどんなものなのかわからないんだけど。

pdf出力とかレーザープリンタ、ドットインパクトプリンタが駄目。

日本語出さなければ大丈夫。

問題あるだろうな、企業向けなら特に。

だからここで愚痴たれたって改善されねーっつーの

>>683
駄目ってのは具体的にどうなるんだ？

PDF出力で試したら、フォントがびみょーに変わるだけだった。
レーザープリンタやドットインパクトだったらどうなるの？

>>684
でもな、発信することは大事だよ。

>>685
それJavaの内部でベクタデータとして描画してるだけ
つまりフォントとして扱っていない

レーザープリンタはフォントのコードを受け取って描画する
そのためにDPIが低くても非常に綺麗

Javaの日本語印刷問題は１２００DPIくらいにするとあんまり見分けはつかないけど
３００DPIくらいが普通のレーザーではフォントがそのまま描画される場合と
置き換えが発生した場合とで別物になる
pdf出力ソフトでDPIをさげてみるとなんじゃこりゃなデータが出来上がるよ

印刷が汚くなるだけでも使えないのに、これらのデータが入った印刷を続けてると
VMがおちるから、内部でめちゃくちゃになってるっぽい
1ページくらい印刷してプロセス終了してる限り問題はさほど深刻ではないように見えるけど
印刷系を含むプログラムが全滅するのはやばい

Mustang build63 リリース

build62 からの変更点
https://mustang.dev.java.net/files/documents/2817/25363/mustang-b63.html

>>687
VM落ちるのはともかく、何か頓珍漢な話だな。

>>687なんてPDFドライバの問題だろ?
PDFをAdobe Readerで見てもおかしいのか?

プラットフォームの印刷環境のセットアップがいかれてるだけだろ。

>>689
PDFドライバの問題？
PDF印刷ソフトいろいろとあるけどすべて全滅だよ

もちろんリーダーで見ておかしい

しかも俺だけじゃなくてJavade印刷やってる人みんなに聞いたら
みんな１００％発生してるし

バグを環境のせいにし始めてきたね
sunの社員かな

sun社員ならアメリカにスルーするだけだよ。
いいからとっとと報告汁

職場に一人くらいは英語書ける奴いるだろ。
そいつに頼め。

うちは全然問題ないなあ@Solaris

つまり、Windowsすてればいいといううことか！

＞sun社員
キン肉マンの悪魔超人を思い出したｗ

2世のsun社員カワイソス

ゆで世界に文句いうな。
http://homepage2.nifty.com/takaoya/atamayude.htm

ようするにPrintJobで2バイト文字を印刷すると、文字フォントを指定しての文字印刷でなくてOpenTypeで文字印刷を行ってしまうって事？
JDK1.4.2から印刷において解像度設定がただしく反映されるようになった事の弊害？

OpenTypeではないと思う
あとBufferedImageではdpiをどういじろうがおかしい描画にはならない
PrintJobに限らず印刷サービスもすべて駄目

だからとっとと報告汁。そこらに無料の翻訳サイトもあるだろが。

技術文書を翻訳するとすごいことになるんじゃ

「日本語を使った場合、1.4に比べて5.0の印刷品質が著しく悪い」とでも書いて、印刷イメージか印刷イメージへのリンクでも貼っ付けとけばとりあえず報告としちゃ十分じゃないか?
これくらいならExcite翻訳でもさほど変な訳は出さんと思うが。

というか、環境もはっきり書かないんだからネタだろ。
SunのJREかどうかすらはっきりしない。

いや、さすがにネタだとは思わないけどさ。

技術系英語なんて、専門用語以外は中学生英語で十分なんだよ。
もちろん、最近は機械翻訳もそれなりにあてになる。

でも「英語が駄目」とか言う奴は >>701 みたいに
なんだかんだと言い訳して逃げまくったあげく、
絶対に自分ではやらないの。

どこな職場にでもいるだろうけど、本当に使えない。

たしかに印刷品質が悪いどころじゃなくいのと
ページ数がある程度行くとVMごとおなくなりになるな。

まぁ、いいんじゃない？
日本ではJavaは死んだということで。

Javaは業務アプリには使えない
これが常識

困ってる奴らが問題を報告しなかったら当分直ることもないだろう。

俺は問題起きてないしな。

問題がでるのはSun製でWindows日本語版だけってことか

http://www.unicode.org/charts/PDF/UFF00.pdf

どうやらこのUNICODEブロックFFが含まれた文字列があると100%バグるみたい
全角アルファベットすべてと記号、半角カタカナ

サンプルプログラムきぼん。

Java1時代のPrintJob
Java2のPrinterJob
1.4からの印刷サービス

すべての印刷処理で再現
dpiの高いインクジェットだと微妙な違いが紙だと分かりにくいが
DPIを下げれるなら一目瞭然
フォント置き換えすれば一発で分かる
拡大して確認が容易なpdf出力系ソフトすべてでも再現

WindowsXP、SunJRE 5.0 update2,3,4,5,6で確認済み

>>712
Mustangに関係ない話題は他所でやってください。

どうせ次のバージョンでも印刷全滅なんだろ
プゲラ

最近は便所に落書きするとバグをなおしてくれんのか

何度言っても英語を書こうとしないだけでなく、煽り始めたか

とりあえずどっかに情報を書いとくのも大事なんじゃない？

ここじゃなくて、質問スレじゃないかな? 1.5だし(w

つうか、MustangのソースDLして自分で修正しろってことじゃないの？
ttp://d.hatena.ne.jp/kazama/20051206/p1

報告しろ、報告しないなら書くなとかいいつつ、サイトもなにも提示しないのもどうかと思う。

ってことでバグ報告/投票の方法
ttp://blogs.sun.com/roller/page/yk?entry=vote_vote_vote

印刷の問題ってセキュリティフィックスのためにバージョンあげたら動かなくなったという類でもあるから
さすがに一般ユーザーにそこまでやれというのは

(ﾟДﾟ)ﾊｧ?

確かにベクトルデータとして埋め込んでるな。
pdf出力したら文字選択できないわ。

一般ユーザーはここ来なくてイイよ。

勝利宣言キター

http://weblogs.java.net/blog/opinali/archive/2005/11/mustangs_hotspo_1.html
Mustang b59 から HotSpot client VM のレジスタ割り当ての最適化が改善されて、
Mustang b58 以前と比べて 1.5倍程度の速度で動くようになったらしい。

今まで何してたの？というくらい違うな

>>726
Java 6は期待できるな。

仕事ではまだ1.3使ってるけどなorz

>>728
1.4もそろそろ安定してきたんじゃないの？

印刷以外は、といいたいが

1.4.2でもつい最近の新しいやつで文字コードのバグとか埋め込んだとかあるんで
なんともいえないかと
これは次のバージョンで直ったはずだけど結構文字コード変換でリークとか多いよね

1.4.2_05で印刷が問題ないのを確認
5.0.u1でおかしいのを確認
5.0.u6でおかしいのを確認

心配になってきたのでJavaSE6での動作確認よろ

>>729
ありがとう。でもうち、保守・改装ばっかな部署なんだ……。
新規案件に出会ったとしても、上が5未対応の
フレームワークをおしつけてくることはまず確実だし。

先端技術フェチとしては大いに不満だ。

http://pcweb.mycom.co.jp/news/2005/12/13/020.html
serverVM に、エスケープ分析でエスケープしないと判断されたオブジェクトに対する
同期処理が除去されるような最適化が追加されたらしい。
デフォルトでは使用しないようになってるらしいので、
使用したい場合は -XX:+DoEscapeAnalysis とかしないといけないみたい。

Vector 使いまくってる人には朗報かも。

457 名前：デフォルトの名無しさん[sage] 投稿日：2005/12/16(金) 21:53:15
昔から使えなかったならともかく
最新バージョンで品質が恐ろしく低下だからただのバグだろ

>>447の実行結果
分かりやすいように72dpiでpdf出力しといた
http://49uper.com:8080/html/img-s/100275.png

こりゃバグだね

味があっていいじゃないか

バグなのはもうわかったけど、なんでマルチポストして喜んでるの？
そろそろｳｻﾞいよ。

>>734
上と下の関係は?

>>737
ソースコード参照

447 名前：デフォルトの名無しさん[sage] 投稿日：2005/12/16(金) 13:38:55
>>444
import java.awt.print.Printable;
import java.awt.print.PrinterJob;

public class NewMain implements Printable{

public static void main(String[] args) throws Exception{
PrinterJob pj = PrinterJob.getPrinterJob();
pj.setPrintable(new NewMain());
if(pj.printDialog()){
pj.print();
}
}

public int print(java.awt.Graphics graphics, java.awt.print.PageFormat pageFormat, int param)
throws java.awt.print.PrinterException {

if(param > 0){
return Printable.NO_SUCH_PAGE;
}

graphics.drawString("あいうえお　",100,100);//正常
graphics.drawString("あいうえお１",100,120);//ベクトルになる 1200DPIくらいになると一見綺麗

return Printable.PAGE_EXISTS;
}

}

490 名前：デフォルトの名無しさん[sage] 投稿日：2005/12/17(土) 01:53:35
面白いので>>447で出来上がるpdfそのものをアップしてみた

http://49uper.com:8080/html/img-s/100309.zip

なんかもうアレだな。
2ch に書くことがバグ報告になると思ってるフシがあるな。

Visual Studio 2005 ダウンロード開始記念キャンペーンの一環ですよ。
この機会にJavaなんていう時代遅れの環境からVisual Studio に乗り換えましょう！

JavaSE6では改善されてるの？

ここはスレ違いだから、もとのスレのURLでも貼っといてくれ。

スレ違いじゃないのでは?
次バージョンでの話題なんだから

>>712によれば、そうではない。

Mustang build64 リリース

build63 からの変更点
https://mustang.dev.java.net/files/documents/2817/25758/mustang-b64.html

>>731>>734>>739>>740
だからおまいはここにそれを書くことでどんな効果が得られることを期待しとるんだ。
「バグだ」「おかしい」というのを否定してるヤツは基本的におらんだろうが。(煽りはいるが)
「誰かぼくちんにかわって報告しといて〜」と言いたいのならそれでもかまわんから明にそう言え。
(言ったからって誰かがやってくれるとは限らんが)

なんだ6.0でもバグバグなのか

>>748
次バージョンで日本語がちゃんと書けるかどうかのチェックをして欲しい

というだけだろ

俺関係ないけど、普通にバグ報告誰かしてだされ。
俺も英語だめなんよ。
Windows以外のVMでは発生しないらしいね。

スクリプトを<input type="file">で鯖に送って、そっちで実行みたいな使い方はどう？

うちこれから業務系で5.0採用になったのだが印刷バグ確かに怖いな。
>>752の使い方も考えてみたが、鯖がVPNの先にあるんで無理。

さーて、1.4.2に下げてもらうか直っていれば無理して６を使うか
JNIで回避かだが、それぞれわりと厄介な問題がでるな。
Javaの人材集めたんで.NETへはさすがに・・・。

たぶん上の人間はこれ理解してない。
登場して1年以上たつんだからそろそろ枯れただろうといっておられる。
そもそも言語理解してないのが上なんで(ry

上が言語理解する必要はないだろ

最近は割と多いよね、言語経験ないSE。

開発環境を決めた時点で、どういうのが実装できるか、
実装できても困難で開発効率が悪いとかそういうのを把握してないと
だらだらと長引く。

しかしおれ業務系でJava使ってて帳票とか出力してたけど、
ジャギーだとかなんとかいうトラブルは無かったけどなあ。

サーバーサイドから帳票出力系の製品(SPFとか）つかってPDFを出力
する場合は関係ない話なの？ Swingだけ？

だったら当面問題ないんだけど。

SwingではなくてJavaから印刷した場合だけが問題になる模様。
iTextとか直接PDF出力は問題ないけど、NetBeansのソースコード印刷しただけで
発生するのでVMの問題だと思う。

Javaの印刷製品は1.1時代からのものは印刷品質が悪かったから
みんな独自実装してたり1.4までが対象なので大丈夫だったり。

pdf作成するのはいいけど、それをユーザーが開いて閉じてとなると
インターフェース的にわりと問題でやすいかな。
日本の企業の帳票は独自サイズが多いのでA4とか決まった規格以外が
急に問題として現れてくることもある。

リッチクライアント系は今のびてるところなんでこの壁にぶち当たってるところも
結構多いかもしれない。

スレ違いスマソ。

SolarisやLinuxは問題ないもんなあ。
Windowsでもfontを指定したら問題ないのがあるかもよ。

試してみたけどfontは論理フォント、物理フォントどちらでも同じ現象が出ていますね。
src.zipでは確認しようがないので内部でなんかしくじってると思われます。

原因追求はSunの担当者にまかせればいいんで、バグ報告よろしくです。

よろしくです

やっぱ英語は使えた方がいいな・・・なんとかせな・・・

つうかSunには日本語で報告できる窓口を用意して欲しいな。

日本語でバグ報告すりゃあいいじゃん。
向うが勝手に翻訳してくれるんじゃね？
日本人担当者くらいいるだろ（へらへら

日本語の掲示板で英語でくるやついるけど、その場合は英文が読めるからであって
あちらで日本語見たらやっぱり文字化けしてるんかね？
ソースコード添付ができないってのはある意味やばいかも

utf8だっけ？バグ報告ページ

ROMA-JI DE KAKE

印刷関連のレスは下記のスレでお願い

Javaでは作るのが困難なものを挙げるスレ
http://pc8.2ch.net/test/read.cgi/tech/1132425910/

1.6の話題でもあるんだろ？＞印刷

>>768
1.6 正式リリースまでは直らなくて良い問題なんか？

印刷はApache FOPでXHTMLやPDFに
変換してくれればいいや

pdf出力しか駄目ってのは業務系で困るだろ

「しか駄目」???

業務系だと、SVFとか使うからなあ

SVFもiWFMもろくなもんじゃないけどな。

Cat Typing
"J2SE 5.0の日本語印刷のバグについて

「J2SE 1.3.1_17がリリースされました。」というブログへのコメントより：
2chのプログラム板で話題の日本語印刷がまともにとおらない5.0はへは
業務で使ってるところははだれも選ばないと思います。update1からupdate6
まですべてとおりませんしね。1.4.2までは大丈夫です。 2chでも日本語でバグ
投票できないからどうしようかという流ればかりです。 "
http://blogs.sun.com/roller/page/yk/20051221


だれだこのブログにこんな大袈裟なコメント書いた香具師は。

Tomcat動かすだけのサービスに印刷が必要なものなんて
大してないぞ。JavaのGUIなんてサーバ系Javaに比べたら
まだ普及度は低いんだしそんな目くじらたてるほどのことじゃないだろ。

なにやらエントリを良く読んでみると
彼女のブログのコメント欄にバグ報告してもいいらしい。

大袈裟なコメント書くのが得意な人っているよね。

印刷できないのをたいしたことないというバカもいるよね。

件のblogのコメントを見る限り、良い方向に進んでいるようだ。
しかし、経緯を見る限り「バグが出る。使えねぇ」「英語ができないから
報告しない」じゃ全然意味がないことがよくわかるな。
せめて「報告したいが英語がダメなので協力してくれ」だったらもっと話は
早く進んだかもしれないのに。

複数のJava関係スレで鬼の首をとったかのように喚き回ったバカがいたからなぁ

おかげで、興味を持つ人が現れて修正の目途がついた。
ある意味、宣伝部隊乙って事で一件落着ｗ

MS側の人間かどうかわわからんが

UNICODEのフォント部分にやっぱりバグがあったようだね
でもこれ汎用ルーチンだよね？
ということはプリンタ以外でも実は文字が汚く描画されていたってことはあったのかな

Java7.0からは是非メモリリソースをケチケチに管理するJVMにしていただきたい

>>783
そんなの欲しがってるやついないし。

いるよ普通に。
64MBのノートとか使えたもんじゃない

OSがNT4でなら64Mでそれなりに快適にJava動いてるぞ
5.0は最低メモリ使用量が跳ね上がってるので進められん
コンパクトな1.3.1まであたりがオススメ

C++時代は共用体大好きっこだった俺としてはちょっと悲しい時流だよ

Cのときですら安全性では推奨されてなかっただろ

ハードとコンパイラ依存コードナツカシス

>>782
印刷フレームワークのルーチンだから関係ないと思うよ。

JSR-270 Early Draft Review
http://jcp.org/aboutJava/communityprocess/edr/jsr270/

そーいや、TrayIcon の開発は Mustang に移ったから、
JDIC ではもうやらねーよって話が出てた。

http://www.javadesktop.org/forums/thread.jspa?messageID=130970

The Java SE 6 (Mustang) Holiday Quiz
http://java.sun.com/developer/Quizzes/mustang_holiday/

>>775
別のスレでこんな書き込みがあるよ
http://pc8.2ch.net/test/read.cgi/tech/1132425910/563

バーチャルマシンで動く場合、ネイティブで動作してるC++によるプログラム相手に速度で勝てる見込みはありますか？

>>794
書く人による。プログラムによる。VMによる。ハードウェアによる。

勝てないこともないかもしれない

>>794
理屈上、アセンブラで書かれたプログラムはC++で書かれたプログラムより速い。
でも、現実的にはどうだろう？

アセンブラとC++の比較ほど明快ではないけれど、部分的に見ればこれに近い
事がVMとネイティブの関係に対しても言える。

>>787
> C++時代は共用体大好きっこだった俺としてはちょっと悲しい時流だよ

EffectiveJava嫁
共用体の代用をJavaで実現する方法が載っている

>>794
最近は数値計算もJavaでやる時代なんだが…Hotspotコンパイラのおかげで。
>>726によればさらに早くなったらしいし。

Integerのquicksortのプログラムを書いても、
JavaがC, C++より早いのが現状。(プログラムの起動は相変わらず遅いが…)
アセンブラでもJavaで書いたプログラムより書ける人は殆んどいないんじゃないか。

ただ、Javaの浮動小数点拡張は取り下げられたらしい。
http://math.nist.gov/javanumerics/
http://jcp.org/en/jsr/detail?id=084
http://www.oishi.info.waseda.ac.jp/~oishi/LINKS/java-numerics.html

java -server -Xcomp -jar hoge.jar
起動速度無視で、実行速度を最大にしたいときは、この起動オプション最強。

>>797
理屈上、profile-guidedな実行時最適化が可能なJavaの方がアセンブラより速い。

理屈ばっかだな

>>802
なにも見てないんだな

>>783
Java SE 7が出たころにはマシンスペックの余裕もたっぷり
増えているだろうからメモリにけちけちする必要はなくなるかもね

個々最近ムーアの法則が乱れてませんか？

>>794-795
すでに勝った香具師ならいるよslashdotでも話題になってた
# Slashdot での大論争。これは今までで一番愉快な
Java 対 C++ の議論に違いありません。
C++ 愛好家は必死に「不公平だ、こっちはメモリ管理を
手動でやらなきゃいけないのに」と主張しています。
公平を期するための彼らの提案は - System.gc() の
呼び出しを山ほど突っ込んで Java 側を遅くするというも
のでした（お気づきでない方のために。Java は System.gc()
を呼び出さなくてもメモリを回収します。 System.gc() の呼び
出しを追加してもメモリ回収の速度が遅くなるだけです）。
続く抗議もすべて、このベンチマークが Java をひいきしてい
るという一点に集中しているようでした。しかし奇妙なことに、
３年前までは当時の JVM をテストしても C++ の方が速いとい
う結果が出たものです。このノイズの山を掘り返せば、有意義
なコメントが見付かるかも知れません

# さらに続く議論。この事件から生じた騒動（または余分なキャラ）
で大儲けできた人がいるかも知れませんね

# Java と .NET のガベージコレクションに関する調査
# WebSphere は自動的に負荷分散の最適化を行うことで、ハードウェア要件の低減をねらいます
#
# Java 1.5 は 20% 高速化した模様
http://www.javanews.jp/javap/newsletter043.html

>>805
クロック数だけを見ずに
ちゃんとベンチマークしてみてるかい？
ハイパースレッディングから64bitsなどの技術進化に目を向けるといい。
あと、量子力学チップの研究が今行われている。
今は量子コンピュータが出る直前の段階だ。

そのまえに燃料電池に期待したい。
燃料電池が携帯電話開発に潤いを与える。

使える量子アルゴリズムって因数分解以外にあるの？
量子アルゴリズムがなくても量子コンピュータは効果的に使えるの？

クロック数をあげると単純に消費電力が増加するから、クロック数をあげずにパフォーマンスをあげるのが流行ってるね。

JavaのJIT, Hotspotは、ItaniumやCrusoeと相性いいはずだが、
どっちもJavaのサポートはいまいちだったね。

>>810
Pentium4で動かすVMですら実用的な速度を得られていたからね

>>810
Webコマースだとコード実行性能はボトルネックじゃないしねえ。

>>807
> あと、量子力学チップの研究が今行われている。
> 今は量子コンピュータが出る直前の段階だ。
おいおい、無知を晒け出すのもいい加減にしろよ。
お前は量子力学と言いたいだけだろ。

# つーか、807はトランジスタが量子力学で動いていることすら知らなそうだ。
# トンネル効果とか聞いたことある? > 807

スレ違いの馬鹿晒しあげ、ストップ！

>>813
トンネル効果といいたいだけだったんだね。

トンネル効果ぐらい量子力学どころか
一般常識だろ

すれ違いネタここで終了。次の話題↓

>>798
の見事なサンプルソースをうｐしてくれ

Mustangではclass verifierが速くなっているらしいけどどうよ?
http://blogs.sun.com/gbracha?entry=typechecking_jvml
https://jdk.dev.java.net/CTV/learn.html
http://www.jcp.org/en/jsr/detail?id=202

>>809
省エネ型メモリに交換するというのも流行ってたりするよ。
それからIDEケーブル対応HDDの使用をとりやめ
かわりにSerial ATAケーブル対応HDDに切り替えるとか。
最近のマシンは消費電力が押さえられている。
CPUだけは電力がやたらと高いけど。

>>813
江崎玲於奈が発見したものがどうかしたかい。
「量子力学」ではなく「量子力学チップ」といったわけだが。
ガリウム、アルミニウム、ヒ素の組み合わせで
電子を原子の中に閉じこめるという技術がもう8年も
前に東大で研究されていたんだよ。

>>818
晒しをお願いしないで
自分で嫁。ポリモーフィズムを使って代用しているだけだからな

>>821
専門外の話に無理に首を突っ込んでも、イタいだけだぞ。

> 「量子力学チップ」
どの論文誌にそんな名称のデバイスの話が載ってるのか、教えてほしいものですな。

> 電子を原子の中に閉じこめるという技術
ボーアの原子模型って知ってる?
原子ってのは原子核のまわりを電子が回っているんですよ。

>>823
おまえそんなに専門知識があるなら
高校物理程度の知識ひけらかしてどうする

燃料電池厨うざい。
素人が夢見るのは勝手だが、知ったかぶりでバラ色の脳内新技術語ってもらっても
議論にならない。

Ｊａｖａ厨は夢見がち

>>826
これをいいたいがための壮大なスレ違いの自演乙

>>826
あんなのと一緒にしないでくれよ。

量子コンピュータとか原子とか電子の話は他所でやってくれ

Java8からは量子コンピュータ対応

量子力学コンピュータだろ！ｗ

量子たん(;´Д｀)ﾊｧﾊｧ

すでに騎手の嫁だ。あきらめろ

佐野量子仮説

有馬記念の動向を議論するスレになりました。

動向も何もディープ以外に何が来るんだ？

Mustang build65 リリース

build64 からの変更点
https://mustang.dev.java.net/files/documents/2817/26231/mustang-b65.html

>>836
来なかった(´･ω･`)

>>836
（　´,_ゝ｀）ﾌﾟｯ

>>836
　　　　　　　　 　　 (⌒⌒)
　　　　　∧_ ∧ （　プッ　）
　　　　　( ´∀`　 ) ノノ〜′
　　　　 　　（⊃⌒*⌒⊂)
　　　　　　　/__ノωヽ__）

>>836
あれ万馬券でたの？

３連単は3万円くらいついてた気がする

>>823
とりあえず日経サイエンスのバックナンバーを
探して読んでみてくれ

くさいな

日経サイエンスかよ

正月はﾋﾞﾙﾄﾞないんだ・・・・ｼｮﾎﾞｰﾝ━━(´･ω･`)━━

Mustang build66 リリース

build65 からの変更点
https://mustang.dev.java.net/files/documents/2817/26990/mustang-b66.html

Mustang Release Contents (JSR 270): Early Draft Review
http://weblogs.java.net/blog/mreinhold/archive/2005/12/mustang_release.html

これみてて Array reallocation ってなんだろと思って JSR270 見てみたら
java.uti.Arrays に copyOf とか copyOfRange ってメソッドが追加されてた。

>>1で書いてある「マルチタスク」ってのは>>847で既に実装済みですか？

Mustang build67 リリース

build66 からの変更点
https://mustang.dev.java.net/files/documents/2817/27330/mustang-b67.html

Mustang build68 リリース

build67 からの変更点
https://mustang.dev.java.net/files/documents/2817/27723/mustang-b68.html

英語よめねー・・・勉強しようかな・・

勉強が必要なのではない。
練習しろ。

2月前半にbuild59をベースにしたBeta1が出るらしい。
http://weblogs.java.net/blog/ray_gans/archive/2006/01/where_we_are_wi.html

正式リリースは秋にずれ込んで、夏にはbeta2が出るらしい。
春にDolphineのプロジェクトがスタートするらしい。

結局2年ペースってわけか

「デリケートな部分に手を出すことにしたからちょっと遅れますよ」（意訳）

Mustang build69 リリース

build68 からの変更点
https://mustang.dev.java.net/files/documents/2817/28215/mustang-b69.html

Persistence APIってすでに含まれてる？

>>858
Java SEに？

PersistenceAPIをJavaSEに含めるのは、よそにVM作らせなくするための嫌がらせだな。

>>858
もしそうなったら、SunのJVMにはTopLinkが付いてくるのだろうか？

>>861
TopLinkしかないな。
そうならないだろうけど。

J2SEにPersistent APIの実装も含めることになったの?

>>863
JavaEE5の記事見てたら複数の媒体でそういう趣旨の内容が載ってたからどうなのかなと思って・・・

http://blogs.sun.com/roller/page/chats?entry=javaone_has_started1

また、Persistence API は、EJB と離れて動作することも許されているので、Standard Edition と組み合わせて O-R マッパ単独で利用することもできる。
ほとんどのベンダー、開発者はこの方向性に前向きなフィードバックを出しているという。

http://pcweb.mycom.co.jp/news/2005/06/29/029.html

EJBから切り放されたことによってPersistence API単体でも利用できるようになったため、今後はJava SEにも導入される予定だという。

http://www.javaworld.jp/print/?menu3=24028

Java Persistence APIは、Java SEでも提供される（標準APIに含まれる）予定となっており、今後はJava環境における標準的な永続化APIとなる。

>>864
なるほど参考になりました。ありがとう。

API仕様を見ていないのでよく知らないけど、
J2SEに含まれるのはインターフェースの部分で
実装は各自Hibernateとかのjarを持ってきて使うのかなと思った。
ちょうどJDBCみたいに。どうなんだろう。

RowSetみたいになるのかな。

>>865
たしかに、そうしないとPersistence APIの実装部分だけでかなりのサイズになってしまいそうだし

RowSetのリファレンスインプリもなんとかならんのかな・・・
あれは使おうと思っても使えん

たしかに、JDBCもインターフェースだけならJ2SEに含まれてるしね。

JDBCオプショナルパッケージ時代ナツカシス

ほとんどのところがJDBC2までしかドライバ対応してないのが痛いなぁ
JDBC3から別物なのに

http://weblogs.java.net/blog/aim/archive/2006/01/invitation_to_w.html
javadoc の変更に際して、下記の場所で
どんなふーに変更するかについて参考意見募集中だってさ。

http://java.sun.com/webapps/survey/display?survey_id=5382

Mustangに間に合わんかもしれんけど。

Mustang Regressions Challenge
https://mustang.dev.java.net/regchal/

MustangのRegressionを発見して報告しよう、というコンテストだそうです。
参加した全員にTシャツを、特に重要なものを報告した5人にUltra 20が送ら
れるらしい。期間は1/31から3/31まで。

Regressionsを発見して報告してそれが認められた人全員だと思う

>>873
そうですね。
誤解のある書き方をしてすみませんでした。

あと、ついでに
Mustang build70 リリース
build69 からの変更点
https://mustang.dev.java.net/files/documents/2817/28549/mustang-b70.html

Mustang build71 リリース

build70 からの変更点
https://mustang.dev.java.net/files/documents/2817/28875/mustang-b71.html

javadoc の新タグは以下のwikiでなんかやってるみたい。
http://www.javac.info/doc?n=JavaDoc.JavaDoc

An easy way to enter the Mustang Regression contest
http://weblogs.java.net/blog/robogeek/archive/2006/02/an_easy_way_to.html

regressionコンテストの簡単な参加方法
既存の 1.5update6 で動くアプリを JDK 6で動かしてみてくれ、
そんで動かなかったらアプリの問題か JDKの問題か考えてくれ、
もしJDKの問題だったら報告お願いって感じらしい。

1.4.2から5.0ベータで結構動作が異なることが多かった
JavaSoundとJava2Dまわりは穴かもしれんな

正式版でも結構違うけど

>>872
Ultra20 ってまた微妙なもんプレゼントですなぁ
正直あんまし欲しくない〜　うるさいしｗ

>>877
apache の poi の日本語取扱の挙動がおかしくなることは知っている
が、Ultra20欲しくないので誰か報告してちょうだい〜

>>879
> そんで動かなかったらアプリの問題か JDKの問題か考えてくれ、

>>880
その一文の敷居高すぎだよな。

たしかに

普通だよ。思ったように動かないって言うだけなら技術者じゃなくてもできるし。

こーゆー事をやるのが普通だと思ってる人たちにとっては敷居高いのかもしれんけど。
http://monoki.fc2web.com/diary/txt/computer/debugpatern.html#%82%C6%82%C9%82%A9%82%AD%83}%83C%83N%83%8D%83\%83t%83g%82%AA%88%AB%82%A2%82%B1%82%C6%82%C9%82%B5%82%C4%82%A8%82%B1%82%A4
http://monoki.fc2web.com/diary/txt/computer/debugpatern.html#%88%AB%82%A2%82%CC%82%CD%89%B4%82%B6%82%E1%82%C8%82%A2

正直言うと、そのサイトをさらすことに何の意味があるのかわからない。

アプリの問題か JDKの問題かなんてアプリ作者（プログラマ＝技術者）しかわからんだろ。

作者にも分からんかも

第三者でも分かる事もあるけどね

敷居が高い
『不義理・不面目なことなどがあって、その人の家に行きにくい』

あってるじゃん。

Mustang beta is out!
https://mustang.dev.java.net/

>>888
それってb71よりも新しい？

>>889
>>854

じゃ、結局古いってことか
安定はしているけど古いってか

1.6beta2落としてみた

>java -version
java version "1.6.0-beta2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-beta2-b72
Java HotSpot(TM) Client VM (build 1.6.0-beta2-b72, mixed mode, sharing)

これは新しいのかな？

オレの Linux 版ではこうだった

java version "1.6.0-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-rc-b71)
Java HotSpot(TM) Client VM (build 1.6.0-rc-b71, mixed mode, sharing)

>>888 が言ってる beta だとこーなるね。

java version "1.6.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-beta-b59g)
Java HotSpot(TM) Client VM (build 1.6.0-beta-b59g, mixed mode, sharing)

beta 版のダウンロードはこちらからどーぞ。
http://java.sun.com/javase/6/download.jsp
http://java.sun.com/javase/ja/6/download.html （日本語）

Vista の Look&Feel ってどうやって変更するの？

XPLAFと同じでそのOS上で動かさないと駄目では？
設定でXPLAFはクラシックLAFにかえれるけど、VISTAも同じではないかな

>>892
バージョン番号の話。
http://forums.java.net/jive/thread.jspa?threadID=2655

要するに、内部バージョンがbeta2となっているのは、beta2への開発版
という意味らしい。
b60以降しばらくはrcになっていたけど、スケジュール変更でBeta2が出
ることになったから修正された。
>>893のLinux版は、多分修正し忘れだろうね。

Mustang build72 リリース

build71 からの変更点
https://mustang.dev.java.net/files/documents/2817/29269/mustang-b72.html

見たか！俺は９００！
俺は至高！俺は吉良上野介！
俺は

うえのすけ

うえのすけべ

よしよしうえのすけべ

Mustang build73 リリース

build72 からの変更点
https://mustang.dev.java.net/files/documents/2817/29768/mustang-b73.html

例の日本語印刷がおかしいのが直ってるな

なんかさ、>>904をインストールするたびに、

すでにインストールされてます
再インストールしますか？

ってでちゃうんだよね。

もー仕方がないのかねえ

>>906
以前、毎回再インストールするのが面倒すぎてウンザリだっていう投稿が
フォーラムかどこかにもあった。確かに面倒。

Mustang build74リリース

build73 からの変更点
https://mustang.dev.java.net/files/documents/2817/30112/mustang-b74.html

>>880
正直時間がないから追及しきれんのよ。

Locale周りのデフォルトが変わったのかもしれんし、
もし、そうなら5.0までのデフォルトに合わせてるpoiが悪いとも言い切れない。
さらにデフォルト変えちゃったのがバグかもしれんし。

5.0で動くんだから俺は5.0で動かしてる。

>>907
毎回手でアンインストールしてた時代に比べれば格段に便利になって重宝してます・・・
一番いいのは、上書きしてくれればいいんだけど、クリーンインストールでないと
問題点が絞れなかったりするのかなぁと、今のところは仕方ないかと諦めてます。

↓勝手に出しちゃえ
Mustang build75リリース

build74 からの変更点
https://mustang.dev.java.net/files/documents/2817/30591/mustang-b75.html

アンインストールして再びインストールし直すのは確かに苦痛かな。

っていうかレジストリ弄って古いバージョンの変数を削除して
さらにJavaをインストールしたディレクトリも削除してから
新しいビルドをインストールするという手でもうまくいくかな？

TextSS　のWindowsXP(Professional)64bit化おながいします

もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？

↑マルチ失せろ

Documentインタフェースを実現した
ODFDocumentクラスを6.0にねじ込んでください。
ソースごとそんな要望を送りつけてください。

>>912
ご自分でどうぞ。

Mustang build76リリース

build75 からの変更点
https://mustang.dev.java.net/files/documents/2817/31069/mustang-b76.html

おろ、GroupLayout追加されたんだね。

いつかは標準でとりこむといっていたけど、JavaSE6で取り入れるとはおもわんかった。

えっ、だいぶ前からGroupLayoutってSE6で導入するって話を聞いてたんだけど漏れの勘違いだったのかな・・・？

SE 6
毎週内容かわってるのですか？

リリースの追い込みに向けて減っていく傾向はなくもないｗ

>>916
いや、だいぶ前はSE6からって話だったけど、すぐにSE7からってことになってた。

Java SE 6でGroupLayoutが取り込まれても、Visual Editorが対応してくれないと・・・。

まだベータなんだから、eclipse 頼みの軟弱なやつ向けではないだろ。

Bug 6375459 に Origato ってコメント付けてんの日本人？

>920-921
NetBeans使えばいいじゃない

>>920
VisualEditorでバリバリGUI開発しているのか？
使い心地はどうだ？
感想頼む。
NetBeansが軽いと聞いて使っているのだが
VEは反応があまりにもおそすぎて使ってない。
プラグイン入れすぎというのもあるだろうけど

VEの問題は重さじゃないと思うな…とにかくスレ違いですね

>>924
そうでもない。SprintLayoutにも対応していないし、機能は限定されてる。
GridBagLayout使うときはGUIでパラメータ弄れて便利だけど、
やっぱりソースを手で調節しないといけない時もある。

>>925
すまん。でもGroupLayoutとかが主流になったら直コーディングは難しくなるし、
話すときは使ってるGUIビルダと絡めざるを得なくなりそうな気もする。

Java SE 6 Beta Maintenance Review公開
http://java.sun.com/javase/6/jcp/beta/

これは事実上J2SE 5.0仕様に対するメンテナンスレビューだとのことです。

よくわからない
5.0に対するメンテナンスレビューという意味がわからない

これが凄く気になった。
インストゥルメントというパッケージ。
まるで楽器演奏のみの歌詞がない曲ややMIDIのインストゥルメントを想像してしまう。

クラスローダにJARファイルを動的に読み込ませることができるということだな？
っていうかクラスパスをRuntimeクラスを使って通さなくて済むって言うだけか？
Spring frameworkにも似たようなものがなかったっけか？

java.lang.instrument

java.lang.instrument: Ability to add .jar files to a classpath

When a tool, such as a profiler or management console, attaches to a running VM,
the tool will typically need to load its tool agent into the VM. If the agent is written
in the Java Language, then the .jar file that contains the agent classes must be added
to the system classpath at runtime. Furthermore, if the agent does bytecode instrumentation
(for example, if the tool does profiling or tracing), then it will need to add supporting instrumentation
classes onto the boot classpath and maybe also the system classpath.

This change adds two new methods to add .jar files to classpaths:

* java.lang.instrument.Instrumentation.appendToBootstrapClassLoaderSearch(JarFile jarfile)
* java.lang.instrument.Instrumentation.appendToSystemClassLoaderSearch(JarFile jarfile)

This change also adds a new error class to java.lang.instrument:

>>929
それ、5.0 からあるよ。例えば、バイトコードにカウンタ回すコードを埋め込むタイプの
カバレッジツールとかを作る人が、より便利になるようにするためのパッケージね。

URLClassLoadeer とか、そーゆーのとは違う。

java.lang.instrument: Allow an agent to be started during the "live phase"

これも気になる。
agent jarファイル？　まるでエージェント指向を思い浮かべてしまう。

そのJARの有効生存期間をコントロールできるってことか？
つまりJARファイルの中にあるクラスを読んだりメモリから消したりできると？
つまり、同じクラスだがバージョンの異なるクラスを素早く入れ替えることが
できると？
　だとしたらこれはかなり優れた進化かもしれない。
今までJakarta 系などのAPIを複数使っていてJARバージョンが異なることによって
依存関係で悩まされていた問題もこれで解決できる上に、
テストも非常に楽になる。
とくにチーム開発のとき
他社チームと共同で開発しているときに真価を発揮しそうだ。
Javaサーバアプリケーションの開発ではかなり重宝しそうだ。
Tomcatサーバに新しいJARファイルを組み込みたいとき、
古いJARファイルも胸像させたいときにこれをうまく使えば
クラスやパッケージが競合することに悩まされることなく安心してテストや
新しいJARファイルをばしばし導入することができる。
新しいJARを入れたことによってプログラムが動かなくなる問題も
これで解消だ。

日本語の説明おいときますね。
　ttp://java.sun.com/j2se/1.5.0/ja/docs/ja/api/java/lang/instrument/package-summary.html
ClassFileTransformerが強力だが凶悪だと思う。

>>932
クラスファイルを変換するって

同じパッケージ名.クラス名だが

中身はバージョンが異なるクラスに動的にかえるってことかいな？


スクリプト言語や
プロトタイプベース・オブジェクト指向言語にみられるような、
動的オブジェクト指向言語のような使い方ができてしまうのかねえ。
オブジェクトを生成したあとからクラスにフィールドやメソッドを追加できる
みたいなことがJavaでもできてしまうってことかいな？

>>933
EclipseのPleiadesプラグインが使ってるね。

>>933
http://java.sun.com/j2se/1.5.0/ja/docs/ja/api/java/lang/instrument/Instrumentation.html#redefineClasses(java.lang.instrument.ClassDefinition[])
> 再定義では、メソッドの本文、定数プール、および属性の変更が可能です。
> ただし、再定義では、フィールドまたはメソッドの追加、削除、あるいは名前の変更、
> メソッドのシグニチャーの変更、あるいは継承の変更はできません。
> これらの制約は、将来バージョンで解消される可能性があります。

>>933
InstrumentationにClassFileTransformerを追加しておくと、
クラスローダのdefineClassが実行される前に実行してくれる。
defineClassが実行される直前ではクラスのバイト列が既に解決済みなんだけど、
そのバイト列と対象のクラスローダがClassFileTransformerに渡される。
そのバイト列をClassFileTransformerで変換して返す事によって、
defineClassが本来とは違うバイト列で行われるっていうだけ。

で、GC可能なカスタムクラスローダで読み込んでいれば、
ロード済みのクラスもGCの対象になるので、GC後であれば再定義は可能だけど、
基本的には１度しか実行されないので、動的言語サポートとはいえない。
上でも説明が出てたけど、１度きりのロードだけなので、
コードカバレッジの計測とかアスペクトの組み込み等がいいかも。
OracleのTopLinkも使っていたような気がする。

あっ、でもプロパティ次第では動的に再定義も可能なんだけど、
Instrumentation関連で使用されるクラスは無理。
環境によってはサポートされない場合もある。

複数のClassFileTransformerを登録できるので、
オリジナルのバイト列　＞　コードカバレッジ計測機能付きバイト列　＞
アスペクト組み込みバイト列　＞　クラスローダでロード
ってシナリオも可能。

TigerならApache BCELが内部に組み込まれているので、
それを使ってもいいし、俺はJavassistを使っている。
CtMethod#instrumentで、コードカバレッジの計測コードの追加が
とても簡単なんだよね。

>>931
premainメソッドを実装したクラスの位置とか、再定義可能とか、
そんな感じのプロパティを記述したファイル（名前は忘れた）を
含んでいるJarファイルを
-javaagent:<jar名>=引数
と言う風にjavaコマンドの起動オプションで指定すると
エージェントが起動するよって話。
premainメソッドの定義クラスとかClassFileTransformerの実装などは、
別にJarに含む必要はない。

ジョイスティックはいつサポートされますか？

ジョイパッドの後ぐらいかな、たぶん。

ライトペンはサポートされますか？

ライトサーベルの後じゃない？

>>934
あれはアスペクト指向を使っていると書いてあったと
思うんだが、Java5のそのクラスだけでまかなっていたのか

>>937
> -javaagent:<jar名>=引数

思い出した。それがPleiadesで使ってたやつか。

よくよく考えてみると、
フィールドやメソッドを動的に変更する意義って
そうそう多くはないかもしれぬ。

Genericsを組み合わせてListやMapやSetなどをフィールドに入れておいて
あとから追加することができるから。

メソッドについてはリフレクションでまかなう？

>>942
アスペクト指向はプログラムの書き方の話だろ。
アスペクトの実現方法ひとつ。

>>944
フィールドやメソッドを動的に変更できるってのも面白いけど
動的に変更すると、今まで検査したバイトコードも
全部再検査しなきゃならなくなるような。

そーいや、Mustang でバイトコードベリファイアが変更になったのって
この辺の絡みもあるのかな、と妄想してみる。よく知らんけど。

いままではJavassistやASMでやってたことが標準になるわけだね。

>>947
それは違う。

JavassistやASMはバイト列を自分で取得して操作するものだけど、
Instrumentationはクラスのローディングを直前にハンドルするもの。
バイトコード操作のタイミングだけを提供してくれるAPIだね。

ちなみに、JavassistとかASMが無くてもTigerなら、
com.sun.org.apache.bcel.internal.*
というパッケージでApacheのBCELが提供されている。

>>946
ロードの事前なので、不適切なバイトコードならベリファイエラーになる。
Mustangで変更になるのはStackFrameMap属性が追加になるんだけど、
逆にバイトコード操作ライブラリの対応を待たないと、ベリファイでエラーになる。
起動オプションで古いベリファイアを使うことも可能。

>>948
StackMapTable属性の間違いね。ごめん。

ありが�dヽ( ´∀`)ﾉ

サーバを止めることなくパッチを当てることが簡単になるってことかな
プロセス間通信はまだ出来ないの？出来たら動的書き換えは強力なパラダイムだね
スクリプトエンジンと連携させてサクッとパッチが当てられる

>>948
com.sun.* って使っていいんだっけ？

なんちゅうか、>>936 以外は書いてること無茶苦茶やね。。。

使ってもいいが、VM依存のオプショナルパッケージであること
将来のバージョンで保証されないこと

これらをふまえてな

>>948
>>946 のは将来のバージョンにおいて、
redefineClasses とかでフィールドやらメソッドの
追加や削除や変更が認められる場合の話ね。

ちょっと考えたら、実行時に NoSuchMethodError とか
NoSuchFieldError 食らうだけだからバイトコード検査関係ないよな。

動的にメンバを追加できても、コンパイル時点ではシンボル解決できないので、
意外と使い道に悩むことが多いかなと思います。

ただし、事前にインターフェイスが存在していて、
クラスにインターフェイスを動的実装させてメソッド追加すれば、
インターフェイスを経由して楽に利用できます。
動的に実装させなくても、プロキシを使うパターンもありですね。

それと、JakartaのBeanUtilsのようなリフレクションのラッパーAPI向けに
動的にメンバを追加するというのはありかなと思います。

このAPIって、Mustangでは多少の変更があるものの、
（確実な再定義可能判定機能とか・・・）
Tigerから存在していてMustang特有の話じゃないので、
スレ違いかもしれませんね。
ダラダラと話を伸ばして、ゴメンナサイ。

>>953
それでいいんじゃねぇの？

なんだかちょっと難しいな。
つかってみないと良く分からないと言うか。
実行サンプル無いかな。
実例とか

さくらばさんのサイトとかいいかも。

Java In The Box
ttp://www.javainthebox.net/laboratory/J2SE1.5/MiscAPI/Instrumentation/Instrumentation.html

Mustang build77リリース

build76 からの変更点
https://www.dev.java.net/files/documents/2817/31663/mustang-b77.html

今回かなりの修正箇所だね

>>928
これ。
http://jcp.org/aboutJava/communityprocess/maintenance/jsr176/index.html

JCPには正式リリース後にMaintenanceのフェイズがある。
Mustang(JSR 270)はまだ正式リリースすらされてないのにメンテナンスなのはおかしいんだけど、
これは名前がMustangのMaintenance Reviewってなってるだけで、実質的にはJSR 176に対する
Maintenance Reviewなんだよってこと。

Mustang build78リリース

build77 からの変更点
https://www.dev.java.net/files/documents/2817/31952/mustang-b78.html

Mustang build79リリース

build78 からの変更点
https://mustang.dev.java.net/files/documents/2817/32495/mustang-b79.html

Mustang build80リリース

build79 からの変更点
https://www.dev.java.net/files/documents/2817/31863/latest_changes.html

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6415362
直ったらしい。
Mustang側にいつ入るのかな

えぇ！　なんだってぇ！？
vをおすとクラッシュするって？

しらなかった

4月頭頃に出したバグ(?)がb81で直ってた。なんか嬉しい。

update7っていつでるんだろうねぇ・・・