現世代Javaの動向 1 - 暇つぶし2ch

現世代Javaの動向 1 ..

263:デフォルトの名無しさん
06/10/30 10:05:18
次世代のスレは糞みたいなやつが常駐してるので使い物にならん

264:デフォルトの名無しさん
06/10/30 17:03:18
>>263 だからここで愚痴るな。おまえは、やっぱりカスだな。

265:デフォルトの名無しさん
06/10/30 18:19:14
>>228
> そもそも一般人はローカルにZIP落として適当なフォルダに展開というのを嫌がる＆出来ない人もいる
> というのを認識したほうがいい
素朴な質問ですが、今時そんなことやらせてる会社ってあるのでしょうか
私の知っている会社は皆、キッティングなり配布なりでコマンド一発でOKなのですが

266:デフォルトの名無しさん
06/10/30 18:46:21
>>264
だからお前はここに来るなと

267:デフォルトの名無しさん
06/11/07 22:09:44
>>265
たとえ話として、数人でやるシェア・フリーソフトや会社内部・部署の
みで使うってのもありうるわけで…
ご自分の場合だけで考えるのはいけないですよね。

268:デフォルトの名無しさん
06/11/15 10:33:10
些末な例外は何にでもあるからな。

269:デフォルトの名無しさん
06/12/01 20:37:55
現世代って言うのか過去なのか一時JythonとかJRubyとかjava実装の言語がはやってたけど
あれは何が目的だったん？

270:デフォルトの名無しさん
06/12/01 22:13:55
・Yet Anotherな実装が欲しいが、一からつくんの面倒だしという発想
・一時期以降のJVMは結構速いから、使えば結構嬉しいかもという発想
・セキュリティ機構も活かせると面白いかもという研究ネタ
まあ色々ある。

271:デフォルトの名無しさん
06/12/02 00:05:20
現世代と言えば1.5になるのだろうか。

generics の erasure は・・・失敗だったような。

272:デフォルトの名無しさん
06/12/02 07:41:35
>>269
JRubyはRuby on Railsも動かしたりしてるし、PHPも動くし「一時」じゃ内希ガス

273:デフォルトの名無しさん
06/12/06 01:24:48
Javaって、GPLになったじゃない
だから、Troveみたいな標準より速いとかいうコレクション実装に差し替えちゃう
見たいな話とか出てこないのかな？

274:デフォルトの名無しさん
06/12/06 01:59:00
>>273
コレクションってクラスライブラリだよね？
OpenJDKでGPLv2になった部分の範囲外のような気がする。

まだ不勉強なので違ってたらごめん。

275:デフォルトの名無しさん
06/12/06 02:12:34
ライブラリはGPLの範囲外ですな

276:デフォルトの名無しさん
06/12/11 20:15:34
こんにちは、現世代Javaの仲間入りです。JDK6リリース。

URLﾘﾝｸ(java.sun.com)

277:デフォルトの名無しさん
06/12/11 21:22:27
>>276
まだ文残ってる
＞ご注意: 現時点で J2SE 5 Itanium ポートは利用できません。ダウンロードバンドルは後日リリースされる予定です。
結局5最後までItanium版出なかったなー

278:デフォルトの名無しさん
06/12/16 18:58:57
Summary of changes in Java SE 6u1 build b01
URLﾘﾝｸ(www.java.net)
URLﾘﾝｸ(download.java.net)

updateリリースに切り替わった。

279:デフォルトの名無しさん
07/01/16 21:09:27
Summary of changes in Java SE 6u1 build b02
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)

年明けなので、Copyright変えましたってのが
変更のほとんどである点がほほえましい

280:デフォルトの名無しさん
07/01/18 23:54:26
Java 6ってOpenGLをSwingで使えるんじゃなかったっけ？

281:デフォルトの名無しさん
07/01/19 00:26:48
Swingが（というかJava2Dが）OpenGLアクセラレーションできるようになってるが正解
まだバグも多いのでデフォにはできんけどな

5.0のときから一応出来るようにはなってるけどね
5.0でのOpenGLはほんとバグだらけでひどかった

282:デフォルトの名無しさん
07/01/21 05:01:11
CompilerAPIがわかんね
ファイル読み込んでクラス生成は出来ても、
文字列からのクラス生成ができね

283:デフォルトの名無しさん
07/01/21 05:51:51
仮想ファイルが使えるようになったんだっけ？

284:デフォルトの名無しさん
07/01/21 14:27:25
Compiler Tree API を隠しAPI扱いにするのはやめてほしかったなぁ。

バージョン名をパッケージ名前に含めることで下位互換性を保つことは可能だし、
なぜ隠しAPI扱いになったのか理解に苦しむ。

285:デフォルトの名無しさん
07/01/21 15:54:17
> Compiler Tree API を隠しAPI扱いにするのはやめてほしかったなぁ。
> なぜ隠しAPI扱いになったのか理解に苦しむ。
どっちなんだ……

286:デフォルトの名無しさん
07/01/21 15:59:04
キミはなにを言いたいの？
理解に苦しむ。

287:デフォルトの名無しさん
07/01/21 16:21:00
つーかCompiler API使えばクロージャ出来るじゃん・・・
わざわざ言語使用に入れんでも。

288:デフォルトの名無しさん
07/01/21 16:26:00
>>284
tree API は doclet API並に公開されてるし、compiler API は java の標準APIでしょ。

javax.lang.model の方で将来のバージョンに対する考慮はしてるみたいだし。

289:デフォルトの名無しさん
07/01/21 16:28:27
>>287
今までだってJavaCC 使うとか、自力で字句解析と構文解析すりゃできたよ。

290:デフォルトの名無しさん
07/01/21 16:32:30
>>287
サンプル書いてみろよｗ
口だけやろうがｗｗ

291:デフォルトの名無しさん
07/01/21 16:38:26
全部機械語で出来るじゃん・・・
わざわざ言語作らんでも。

こんな感じかな。

292:デフォルトの名無しさん
07/01/21 17:26:09
>>290
ほらよ
import java.io.File;
import java.io.Writer;
import javax.tools.JavaCompilerTool;
import javax.tools.JavaFileManager;
import javax.tools.JavaFileObject;
import javax.tools.ToolProvider;
public class Main {
public static void main(String[] args) {
JavaCompilerTool javaCompilerTool = ToolProvider.defaultJavaCompiler();
JavaFileManager javaFileManager = javaCompilerTool
.getStandardFileManager();
try {
JavaFileObject javaFileObject = javaFileManager
.getFileForInput("bin/Tutorials.java");
Writer writer = javaFileObject.openWriter();
writer.write("public class Tutorials{"
+ "public static void main(String[] args){"
+ "System.out.println(\"We love JavaLobby :)\");"+ "}" + "}");
writer.close();
javaCompilerTool.setOutputDirectory(new File("bin"));
System.out.println(javaCompilerTool.run(null,new JavaFileObject[]{javaFileObject}).getDiagnostics());
Class.forName("Tutorials").getDeclaredMethod("main",
new Class[] { String[].class }).invoke(null,
new Object[] { null });
} catch (Exception e) {e.printStackTrace();
}}
}

293:デフォルトの名無しさん
07/01/21 17:32:04
どこからつっこめばいいのやらｗ
まずコンパイラぐらい通せよｗｗ

294:デフォルトの名無しさん
07/02/03 18:43:05
>>287
んなもん、Java6じゃなくてもできるわ。アホかｗｗｗ
クロージャの意味を、

「よ　く　理　解　し　て　か　ら　書　い　て　ね　。」

295:デフォルトの名無しさん
07/02/03 18:44:44
Compiler APIって、APTサポートの目的が強いんだろな。

296:デフォルトの名無しさん
07/02/13 14:12:37
JDK6 の日本語ドキュメント完成だってさ。
URLﾘﾝｸ(blogs.sun.com)

297:デフォルトの名無しさん
07/02/13 16:50:44
今回すごい遅かったな
やっぱり翻訳されたAPIドキュメントがあるのとないのとでは違うからねぇ

298:デフォルトの名無しさん
07/02/19 14:49:38
URLﾘﾝｸ(java.sun.com)
並列若い世代コレクタ
(　ﾟдﾟ)・・・・・・

何処に突っ込むべきなんだろう

299:デフォルトの名無しさん
07/02/19 15:15:38
昔から直訳ってのはよくある
カタカナのままのほうがわかりやすいとかもあるしね

有名どこではシリアライズとかパーシステンスとかだが、まぁこれはまだいいほう
マイナーなAPIだとすごいままだぞ

300:デフォルトの名無しさん
07/02/20 00:23:59
永続性っていう日本語は、なんとなくイメージしやすい気がする
直列化はいまだにピンとこない。

301:デフォルトの名無しさん
07/02/20 00:26:44
劣等GPLとかすばらしいよな

302:デフォルトの名無しさん
07/02/20 08:44:18
劣等パンダ

303:デフォルトの名無しさん
07/02/26 15:24:02
Rhino は javax.script.ScriptContext#setWriter で普通の Writer 渡すと
print 時にエラー吐いて死ぬ……

こんぐらいは、フレームワーク側で吸収して欲しいよーな。

304:デフォルトの名無しさん
07/03/08 17:11:51
>>302
レッサーパンダは火狐の夢を見るか？

305:デフォルトの名無しさん
07/03/09 13:49:06
>>303
そういう差異をラッパー書いてなくしてる俺は

>>304
赤トカゲはゴジラの夢をみるか？

ゴジラには勝ったけど寿命で消えたな。役目は果たした

306:デフォルトの名無しさん
07/03/09 22:55:21
お前ら現実を見ろよ

307:デフォルトの名無しさん
07/03/20 02:16:11
javaのレンダラ探してたら3DCGレンダラ見つかった。

URLﾘﾝｸ(sunflow.sourceforge.net)
javaでここまで実用的なソフトがあったとは

308:デフォルトの名無しさん
07/03/22 23:11:28
URLﾘﾝｸ(www.java.net)
壊れっぷりが素晴らしいな。6u1 Build b04が出るのは何時になるんだ？

309:デフォルトの名無しさん
07/03/22 23:57:41
それよりJavaSE6update1の一般向けリリースをささとだしてもらわんと
ライブラリのバグ以前にVMのバグがはいってるのはかなわん

310:デフォルトの名無しさん
07/03/23 00:07:16
>>308
壊れてるっても、単に CSS のリンク先を間違ってるとかそーゆー問題じゃね？

311:デフォルトの名無しさん
07/03/24 22:07:35
>>310
いや、イメージファイルのGETがforbiddenになってる。
わけわからん。

312:デフォルトの名無しさん
07/03/25 21:44:40
Jdk6で、nioのSocketChannel#connectで頻繁にJVMごと死ぬ(jvm.dll+0xd283d)。
ググるとlimewireでも同じ問題起きてるみたいなんで、さっさとjdk1.6.0-01出してくれ。

313:デフォルトの名無しさん
07/03/25 23:05:57
俺も今日は3回落ちた
性能はいいんだけどねえ…

314:デフォルトの名無しさん
07/03/25 23:51:40
まずはライブラリ以前にVMバグ修正をさっさと

315:デフォルトの名無しさん
07/03/26 02:34:41
1.5で打ち止めでいいよ。
これ以上いじるとグダグダになる。
.Netなんか最悪だぞ

316:デフォルトの名無しさん
07/03/26 05:28:33
>>312
そんなふうに次、次を求めるから不安定になる
必要なら
URLﾘﾝｸ(download.java.net)
こっから取ってくればいい

317:デフォルトの名無しさん
07/03/26 12:50:21
>>315
5.0は言語拡張はあるけど、ライブラリやVMにほとんど手が入ってなかったからね
その割には初期はバグバグだったり日本語バグ1年半くらい放置だったな

6は5.0以上にエンタープライズ分野のバージョンアップの恩恵は大きいから
必要とされてるだろうね

7はいまのところメリットが見えてない

1.4.1以上の混乱はまぁでないだろうね

318:デフォルトの名無しさん
07/03/26 13:04:27
>>316
すまん。言葉が足りんかった。
そこのでもやっぱ>>312のように落ちるんだわ。
だから、さっさと修正して,-01を出してくれってこと。
正確には、nioのSocketChannel関係のsun.*のJNI実装DLL内で、
アクセスバイオレーションで落ちるから、jvmそのものじゃないけど、
標準配布のパッケージ使ってて、ネイティブ内で落ちられるのは耐え難い。

じゃ、1.5.0に戻せば良いのかもしれんが、JTableのTableRowSorterつかってるから、
戻すのめんどくさい。

319:デフォルトの名無しさん
07/03/26 14:57:45
>>312
ここでやるより、BugDatabase 行った方が早いと思うよ。
BugDatabase で SocketChannel connect AccessViolation で探したけど無さそうだった。

>>312 では再現条件がハッキリしないし。

320:デフォルトの名無しさん
07/03/26 16:08:31
>>318
SwingXのJXTable使ったら？
URLﾘﾝｸ(swingx.dev.java.net)

321:デフォルトの名無しさん
07/03/26 17:04:06
>>318
そうか、開発版を許容できるなら話は早い
URLﾘﾝｸ(forums.java.net)
Forumだと結構Sunのエンジニアが相手にしてくれたりするよ。
BugParadeへの登録も内部からだと早いみたいだし。

322:デフォルトの名無しさん
07/03/29 11:08:09
1.6.0_01 age

323:デフォルトの名無しさん
07/03/29 16:09:28
やっときたか
URLﾘﾝｸ(java.sun.com)
これでそれなりに安定するだろうか

324:デフォルトの名無しさん
07/03/29 21:01:16
早速入れてみた
なんかちょっと速くなった気がするよ

325:デフォルトの名無しさん
07/03/29 23:05:03
たぶん気のせい

326:デフォルトの名無しさん
07/04/02 11:37:04
JInternalFrameのバグなおってねーな
触って1分でわかるバグなのになぜ放置かと
比較的よく使われるコンポーネントだと思うんだが

327:デフォルトの名無しさん
07/04/02 14:15:11
誰も指摘しなかったら直らない

328:デフォルトの名無しさん
07/04/02 21:43:35
>>326
BugIdいくつのやつ?

329:デフォルトの名無しさん
07/04/11 13:50:50
JRE6入れてみた
かっこ良くなって、すごく軽くなった

こりゃいいな

330:デフォルトの名無しさん
07/04/12 00:32:00
見積り中の案件、.Netに負けてしまった (´・ω・`)
せっかく1.6触れると思ったのに。

331:デフォルトの名無しさん
07/04/12 11:32:01
ランタイムの互換性のなさと起動の遅さはどうでも良いのか、
それとも客がただのMS信者か・・・。

どっちにしてもデスクトップアプリケーションじゃなけりゃ6はあまり関係ないよ。

332:デフォルトの名無しさん
07/04/12 12:10:16
６はWebStartの進化がすさまじいからな
アプリケーションの追加と削除とかデスクトップやプログラムにショートカットが作られたりな

でも、肝心のスタンドアロンアプリで対応してないのがあふぉかと

333:デフォルトの名無しさん
07/04/12 12:45:58
jarアーキテクチャを拡張すればOSにインストール可能っちゃ可能だな。

MEのjadのようにインストールプロトコル作ってそれを実装したツールが有ればいいか。

jnpl実装からフィードバックが利きそうだ。

linuxやjavaに慣れてる連中には激しくウザイな。
そういう連中にはバージョン管理機能くらい付けてくれんと利点がないな。

334:デフォルトの名無しさん
07/04/12 14:48:18
別に新しいバージョン取得して置き換えるだけだからかまわんと思うけど
Javaアプリ自体いままでバージョン管理してなかったんだし、問題はないだろ

335:デフォルトの名無しさん
07/04/12 21:47:59
>>332
アプリケーションの追加と削除とか、デスクトップへのショートカットは少なくとも5.0のときからあったよ。

336:デフォルトの名無しさん
07/04/14 15:36:26
SEのバージョンって1.4.2のが5.0より安定してるの？
会社が頑なにバージョン変えないようにしてるのが煩わしい。
ぶっちゃけ今SE6を使っても、以前のバージョンのバグは
改修されてると思うんだけど、これはアホい考え？

337:デフォルトの名無しさん
07/04/14 15:46:09
1.4.2だって5.0だってエンバグしたりしてるからどれが安定かというのはない
ただ新しいほうがセキュリティホールがうまってる確率が高いのと
サポート期間で有利

メインストリームになればバグ報告も増えて安定しやすいという利点は多いね
個人的には5.0は1.4.2より安定した感じはする
最初の1年半くらいはひどかったけど

6は今年後半くらいで目立ったバグは取れるんじゃないかなと予想

なにより来年7が出ると1.4のサポートがなくなるんでそういうのも考えながら選択すべし

338:デフォルトの名無しさん
07/04/14 16:32:41
>>336
ん。アホい。
改修されているバグと増えているバグと増えている機能と変わっている機能がある。

会社が頑なに変えないのは、バカが居るだけだろ。
ちゃんと評価して、6.0の利用をすればいいだけ。1.4.2が枯れているなんてのは幻想。
1.4.2で分かっているバグでも対応しないと決められたものもあるからな。

問題は、機能的に変わっているので新しく作るのではなく
今1.4で動いているのを5,6で動かそうとすると問題がでる。こういう用途であればやめたほうがいい。

339:デフォルトの名無しさん
07/04/14 16:45:32
> 1.4.2で分かっているバグでも対応しないと決められたものもあるからな。
「枯れてる」ってのは「不具合の多くが既知である」状態でしょ。
既知の不具合がどれだけ放置されていようが
不具合の多くが既知であれば「枯れてる」と言える。
極端に致命的でなければ。

まぁ、Sun はマイナーバージョンアップでも
不具合修正だけじゃなくて、わざわざ新機能盛り込んでエンバグしたりとか
阿呆な事やらかした実績があるから油断はできないが。

340:デフォルトの名無しさん
07/04/15 10:37:15
バグが直ることによって修正が必要になるアプリもあるからね。
1.4になったときswingのフォーカスバグが直って、1.3で作ったアプリを苦労して直したよ。
直すのに苦労したんじゃなくて検証が大変だったんだけどｗ

341:デフォルトの名無しさん
07/04/16 23:08:55
新機能が安定しないのはある程度仕方ないとしても、
しばしばデグレ起こすのは問題だよな。

342:デフォルトの名無しさん
07/04/16 23:15:03
すべてのリビジョンが取得できるからsunは良心的なほうだと思う。
バグが直った結果動かなくなるとかあるわけで。

343:デフォルトの名無しさん
07/04/17 03:26:11
URLﾘﾝｸ(bugs.sun.com)
> 183 Results Returned,

URLﾘﾝｸ(bugs.sun.com)
> 183 Results Returned,

これって Windows JVM だけリーク満載ってこと？

344:デフォルトの名無しさん
07/04/17 12:46:27
そもそもそこで検索されているバグはJVM本体ではなく
関連APIや関連アプリの話がほとんどのように見える

345:デフォルトの名無しさん
07/04/19 23:15:30
1.6のdocs-jaでかすぎﾜﾛﾀｗ
JDK(SE)本体よりでかいでやんの

346:デフォルトの名無しさん
07/04/19 23:37:14
5.0とあんまりかわらんけど？
別にjaでなくても大きいし

347:デフォルトの名無しさん
07/04/22 02:26:30
zipで12MBも違うが

348:デフォルトの名無しさん
07/06/30 14:51:48
　　　　　　　　　　　 _|_
　　　　　　　　　　／＿＼
　　　　　　　　　　￣|Ｕ￣　　
　　　∧＿∧　　　 /ミヽ、　
　　　(　･ω･)　　ノﾐｼ三　`~ﾟ
　　　(っ　≡つ＝つﾟ　　ﾟ　
　　　./　　　) ﾊﾞﾊﾞﾊﾞﾊﾞ
　　　( /￣∪
　　　　　　　　　　　 _|_
　　　　　　　　　　／＿＼
　　ﾋｭﾝ　　　　　￣|Ｕ￣　　
　∧＿∧　＿∧　 /ミヽ、　
(（(　･ω･)三ω･) ノヽ　 `~ﾟ　））
　　(_っっ=　_っっﾟ　　　ﾟ　
　　　ヽ　　　ノﾋｭﾝ
　　　( /￣∪

349:デフォルトの名無しさん
07/07/04 04:57:53
1.6.0_02 age

350:デフォルトの名無しさん
07/09/27 02:36:54
JavaFXの話題はここでいいんかな

スレ立てたほうがいいかな

351:デフォルトの名無しさん
07/09/27 03:09:06
いんじゃないココで？

352:デフォルトの名無しさん
07/09/28 01:04:53
スレ立てないわ、話題はふらないわで>>351涙目ｗｗｗｗ

353:デフォルトの名無しさん
07/10/01 00:01:44
きょうび何の検討もなく1.42であるべきだといいはる自称Java通がいて悲しくなった。

354:デフォルトの名無しさん
07/10/01 00:06:56
1.4系のサポート切れるのが近づいてるのは無視するんかねぇ
もう2世代前のメジャーバージョンじゃきっついな

2世代前というと・・・今から作るアプリはWindowsMEをターゲットにするべきといってるのと同じことだな

5.0の言語仕様についていけないやつじゃね？
大幅に安定したコードがかけるというのに・・・

355:デフォルトの名無しさん
07/10/01 01:19:51
>>353
理由を明確に説明させてやれ。
長い期間使うものであればあるほど危険であるというのは明白。
３年前ならともかく、今、5.0以降を使わないのはサポート的に危険。

JavaSE7のリリースと同時に1.4シリーズはSunがサポートを放棄します(EOL)
その自称Java痛がサポートしてくれるんでしょうか？と言ってください。

356:デフォルトの名無しさん
07/10/01 01:35:28
でかいところで、自社サポートやってる場合は、むしろ1.4.2の方がよかったりするんだろうか。
そういうレベルのところで、5.0は安定してきているんだろうか？

357:デフォルトの名無しさん
07/10/01 01:46:39
まあ、ケチを付けてる理由がむかーし個人的にぶつかった不具合一つで
それも既に解消していたりするんじゃないかと思うんだが・・・・
何の検討もなくって、所がもう・・・・

ただ、XML扱ってるとこは注意が必要かも、とは思う。
それでも、今から作るなら5.0以降だね。

358:デフォルトの名無しさん
07/10/01 03:34:50
バグフィックスにしてもポートは危険伴うし、1.4.2だから安定というものでもないよ
わりと1.4.2もエンバグくりかえしてるし

359:デフォルトの名無しさん
07/10/01 08:38:25
富士通とかでかいところは、自分ところでバグフィックスしてて、Sunのリリースでは修正されていないバグとかも修正されているという話を聞くけど。
そのレベルでは、Sunのリリースは使い物にならないとか。

360:デフォルトの名無しさん
07/10/01 10:45:09
富士通は自前のハードウェアでSolaris動かしているから、
Sunのハードウェアに適用できないパッチもある。
もちろん共通のバグを富士通がfixすることもあるのだが。

361:デフォルトの名無しさん
07/10/01 12:30:55
自分でソース治したいのならJDK6以上オススメ

昔は各社自前でJREもっていたんだが、結局一番使われるWindows版が安定していたというオチもある

362:デフォルトの名無しさん
07/10/01 15:26:27
次世代のようにこっちもビルド情報あった方がいいのかな、と
JDK6u5 build04
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(www.java.net)

Nimbusが入ってきているという噂があるのでこれから試してみるつもりです。

363:デフォルトの名無しさん
07/10/02 12:55:23
>>362
u3とu4はどこいったんだろ。欠番？

364:デフォルトの名無しさん
07/10/03 01:14:09
"Java SE 6 Update N"最新成果物登場 - 次期Java SE 6はフル改善
URLﾘﾝｸ(journal.mycom.co.jp)

現世代でこんなに変化があるとは思いませんでした。

365:デフォルトの名無しさん
07/10/03 06:03:46
6u3 release age

366:デフォルトの名無しさん
07/10/03 14:12:50
>>363
ビルド番号は、update release毎に刻まれているようです。
なので、u4はもうQAフェーズなのでは？

367:デフォルトの名無しさん
07/10/17 21:40:32
6u3の変更点は何処を見れば分かる？

368:デフォルトの名無しさん
07/10/17 22:47:18
リリースノートみればわかる
基本的にセキュリティアップデートだけだよ
バグが直るのはu4以降

369:デフォルトの名無しさん
07/10/18 01:19:10
>>368
ありがと

370:デフォルトの名無しさん
07/10/20 02:47:01
Update N っていつリリースされるんだろな？
期待してるんだけど。

371:デフォルトの名無しさん
07/10/20 10:09:05
Q.When will the Update N be available?
A. This update is expected to be released to the public around mid 2008.

URLﾘﾝｸ(jdk6.dev.java.net)
URLﾘﾝｸ(jdk6.dev.java.net)

372:デフォルトの名無しさん
07/10/21 02:16:47
Flashのインストール率は「ほぼ100％」
URLﾘﾝｸ(www.atmarkit.co.jp)

JREの普及率はどのくらいだろう？
なんの根拠も無いけど80%ぐらいかな

バージョンの比率も知りたい。
一般人の環境見てるとJRE1.1とか結構いるんだよねｗ

373:デフォルトの名無しさん
07/10/21 06:25:02
1.1ってのはMSのVMじゃないか？

374:デフォルトの名無しさん
07/10/21 10:16:01
>>372
JRE入ってないWindowsプレインストール機ってかなり多いからね。

375:デフォルトの名無しさん
07/10/21 17:42:49
一般的なメーカー製だと5.0とか結構はいってるけどな
IEが搭載しなくなったし、1.1よりは今はシェアあるだろ

376:デフォルトの名無しさん
07/10/21 17:44:00
flashはほぼはいってるが、バージョンで大きな差がありすぎるのが癌
ブラウザで広告が表示できてないのはよく見る

377:デフォルトの名無しさん
07/10/21 20:59:39
会社では、DELLかLenovoのを買うけど、ほぼ確実にJRE入っているなあ
個人ではショップブランドばかりで、OSすぐに入れ直すから、入っていないけど

378:デフォルトの名無しさん
07/10/22 09:16:48
富士通FMV-BIBLO/Vistaは入ってなかった。
MSはややこしい契約で縛る可能性があるからなあ。

379:デフォルトの名無しさん
07/10/25 01:21:41
>>372
URLﾘﾝｸ(www.adobe.com)
URLﾘﾝｸ(www.adobe.com)

380:デフォルトの名無しさん
07/10/25 10:12:42
Java、結構頑張ってんな

381:デフォルトの名無しさん
07/10/26 02:05:40
これ、ConsumerJREが入ったら一気に化けるだろ。

382:デフォルトの名無しさん
07/10/27 23:09:57
明るい未来を信じてます。

383:デフォルトの名無しさん
07/11/15 13:52:54
6uNの新しいビルドでたね

Nimbus周りのバグとJFileChooserの件が
治ったみたい

384:デフォルトの名無しさん
07/11/15 14:52:41
今スナップショットだっけ？
位置づけとしてはマイルストーン？

385:デフォルトの名無しさん
07/11/19 04:51:19
Java Web Startは、巨大な辞書ファイルをランダムアクセス
するようなアプリ配布には使えないのかな。
セキュリティマネージャを使ったのとか。
説明書読むと、すべてjarファイルになってることという条件がついてる。

386:デフォルトの名無しさん
07/11/19 04:56:23
jarにすりゃいいじゃん

387:デフォルトの名無しさん
07/11/19 07:54:45
うーむ、それはそうなんだけど・・・
修正しなきゃいかん部分がたくさんある。テストもやりなおしだなぁ。
でもま、やってみるわ。なんとかなるような気もしてきた。

388:デフォルトの名無しさん
07/11/19 12:01:34
>>386
その文章を理解するとは頭いいな

389:デフォルトの名無しさん
07/11/25 15:59:56
>>385
巨大な辞書ファイルはサーバーで持つべきでは？
何のためのWebだよ。

390:デフォルトの名無しさん
07/11/25 17:51:12
>>389
それしたらオフラインで使えないでしょ。
モバイルのユーザが不便じゃん。

391:デフォルトの名無しさん
07/11/25 17:59:34
でもさ、すべてをjarにする必要はないよ。
JWSはアプレットの延長じゃなくて、Javaアプリのインストーラーだから。
パーミッションでフルアクセスを許可してしまえばすべて解決。

392:デフォルトの名無しさん
07/11/26 14:27:43
>>391
の延長として。

JWSは、それだけでは使いづらいので
アプリケーションのインストーラもしくはランチャーとして使うのが便利だと思う。
ランチャーの仕組みとかは作らないと駄目だけど
リソース周りの自由度がちょっと上がる。
（どうキャッシュさせるかとか、実行中のアップデート確認とか）

393:デフォルトの名無しさん
07/11/27 20:05:50
JWSは機種依存しないインストーラーだからすげーありがたい。

ところでJWSが広く使われるようになると、ソフトの配布の方法が変わってくるよね。
みんなソフトの会社・作者のサイトから直接DLして、第二者、第三者からコピーを
もらう必要はなくなるし、ソフト制作サイドもコピーして配布される形態
を最初から作る必要がなくなって状況次第では楽できる選択肢だったりする。

でもGPLを適用したソフトだとライセンスにひっかかることはないのかな。
漏れはGPLにはどっちかというと否定的なんだけどさ。

394:デフォルトの名無しさん
07/11/28 01:14:24
JWSはjavaアプリケーションデプロイ仕様の一つの実装であってインストーラではない。

395:デフォルトの名無しさん
07/11/28 04:18:09
はいはい

396:デフォルトの名無しさん
07/11/28 12:55:56
JWSで使う証明書は、３つくらい選択肢がある。

(1). VeriSign や Thawte などの認証局から信頼できる証明書を取得する。
(2) Thawteの無料証明書を取得する。
(3) オレオレ証明書を自分で作成する。

1は正統な方法だが年間6～9万円くらいかかる。
フリーソフトの配布には現実的ではない。

(2)は(3)に毛がはえた程度の証明書だが、一見まともな証明書にみえる。

フリーソフトの配布には(2)と(3)を比べると(2)のほうが一見ふさわしいように思えるが、
ちょっと穴があるような気がするのよ。

JWSで起動する直前ダイアログが出て「この認証局をつねに信頼する」という
チェックボックスがあって、これにチェックを入れると次からこのダイアログは出ない。

アプリ起動のたびにダイアログがでるのはうざいから、ユーザはチェックを入れたくなる。
しかしチェックを入れると、結局(2)の認証局をすべて信頼するわけだから、他のサイトで
それを使っているJWSで動くアプリにも同じ条件が適用されてしまう。
(2)の無料認証局を使うと、他所のアプリも無条件で実行許可しちゃうと思われる。
(もしかしたらサイトごとにちゃんと管理してる？)

ところが(3)のオレオレ証明書の場合、公開しているサイトのみ許可するだけだから、
他のサイトは関係ない。
となったとき(2)より(3)のほうが、ユーザに配慮しているとはいえまいか？

397:デフォルトの名無しさん
07/11/28 13:13:16
社内アプリ等でちょっとしたものでオレオレが必要な場合
先にクライアントにオレオレCAを追加しておく

ということはよくやるかも

398:デフォルトの名無しさん
07/11/28 13:19:48
>>393
GPLのソフトを非GPLであるWindowsで動かしても問題ないのと同じ

399:デフォルトの名無しさん
07/11/28 13:45:03
JWSをインストーラとするアプリをGPL(もしくはその亜種)で公開すると、
実行可能なソースを公開しなきゃいけない規則はどうなるんだろう。

サーバにセットアップしないとインストールはできないけど、
それは知ったことじゃないでいいのかな。

それからGPLとはあまり関係ないけど、
二次三次と他者により複製されて、自分のサイト以外で再配布されはじめたとする。
そのアプリは定期的にオリジナルのサーバにアクセスして、更新データを受け取るような
仕組みをもっていたとする。

他のサイトで再配布されているそのアプリが、すべて自分のとこのオリジナルのサーバに
その更新情報を取得するためアクセスしてきたりする可能性もあるわな。
悩ましい。

まぁ、公開したアプリがそこまで普及するならある意味成功ともいえるけど。

400:デフォルトの名無しさん
07/11/28 13:52:41
>>399
ソースくれといったら渡すだけなのでメールでもFDでもCDでもどっかのページ上においてもいい

401:デフォルトの名無しさん
07/11/28 14:07:27
>>400
最初はWikipediaのGPLの項目を読んでそれでいいと思っていたんだけど、
GNUのサイトを読むと、どうもそれだけでは通用しないような感じもする。

GNUサイトのライセンスの解説は、あいまいな表現が多くて長い文面のわりに
なにいってのか要点が見えにくい。
伏魔殿のようになにしこまれてるかはっきりしないからGPLは用心してしまう。

402:デフォルトの名無しさん
07/11/28 14:08:29
jnlpへのリンクの隣にソースへのリンクを貼っとけばいいよ

自分以外のサイトで再配布された場合、その再配布サイトの人がソースを提供する義務を負うんでない？

403:デフォルトの名無しさん
07/11/28 14:18:05
>>402
それなら問題はないはず。

ただJWS専用のアプリだとソースをそのままコンパイルして実行とはいかないけどね。
サーバごとにセットアップだの場合によってはjarへの署名が必要になるかと。
でもその手続きについて著者は知ったことじゃないでいいと思うけど。

404:デフォルトの名無しさん
07/11/28 15:45:00
>>401
GPLってネットが普及する前からあっただろと

アナログでもとにかくOK
ソースいれたCD郵送とかの実費負担程度も要求してOK

そもそもネットだって金かかってるしな

だが、手間なのでネットで入手できるようにしておくのがいいというだけ

405:デフォルトの名無しさん
07/11/28 17:17:01
>>404
というようにも解釈はできる文言もあるが、次のような文言も用意されている。

URLﾘﾝｸ(www.gnu.org)
#Q
バイナリは私のインターネットサーバに置き、ソースは他のインターネットサイトに
置くということはできるでしょうか?

#A
GPLでは、あなたはソースコードをバイナリと「同じ場所から」コピーするための
アクセスを提供しなければならないと定めています。
すなわち、バイナリのとなりにソースを置けということです。
しかし、他のサイトと協定を結んで、必要なソースコードを入手可能にし続けてもらい、
バイナリの近傍にソースコードへのリンクやクロスリファレンスを張って置くならば、
私たちは「同じ場所から」と言ってよいと判断します。
(以下長いので省略)
----
これを普通に解釈すれば、郵送配布は認められないようにも受け取れるが、
別のとこではネットで配布していても、郵送の手段を用意しておかなきゃいかんともいっている。
ソースをバイナリに同梱しておけば一番問題がないともね。
今では普通あそうにはない話だが、郵送での配布を希望されたら、
拒否できない可能性もあるな。GPLは。

でも、このテーマはすれ違いっぽいから、このへんにしとくわ。

406:デフォルトの名無しさん
07/11/28 17:28:38
同じ場所からってのは配布元がソースとバイナリを一致させる必要があるということ

ネット環境につないでなければ配布しなくてもいいということにはならんだろ？

407:デフォルトの名無しさん
07/11/28 17:46:16
オレオレ解釈するのは自由だが、もめたときそれが通用するかどうかは俺にはなんともいえんよ。

408:デフォルトの名無しさん
07/11/28 18:08:37
>>404
拒否はできると思うんだが、郵送にかかる手間には対価を請求できる。
郵送しか手段がない相手が、どうやってバイナリを手に入れたかのほうが気になる。
郵送しか入手手段がない、というのならその前にその人はバイナリも郵送で手に入れているはずなんだよな。

で、JavaでGPLライブラリを使う場合だが、JNLPでライブラリだけリンクってのは
大変だから、ライブラリjarにソースを含めてもらうのがいいんじゃないかな？
LGPLじゃなくGPLのライブラリだとしたら、使ってるアプリもGPLのはずだから
ライセンスの同意とかはあまり気にしなくていいのかな？

409:デフォルトの名無しさん
07/11/28 18:14:42
jarにソースが入ってても、jnlpじゃダウンロードした中身を見れないんじゃないかなぁ
個別のjarに別のリンクを張るか、アプリにソース展開コマンドを用意して同梱のソースを取り出せるようにするとかしないと意味ない気がする

410:デフォルトの名無しさん
07/11/28 18:21:42
GPLv3だと、アプリのボタン押したらソースがDLできるようにするのを推奨
とかなかったっけ。

411:デフォルトの名無しさん
07/11/28 18:23:59
>>409
おいおい。親切すぎだろ。
tar.gz 形式で配布してるソースはアウトになっちゃうぞ。
ヘルプにライブラリからの取り出し方書いておけばOKだと思うぞ。

ん？ああ、クラスファイル固めたjarファイルにソースが入ってるって
書いてるように見えるな・・・・。

いや、ソース用のjarを別に用意して、JNLPファイルで1ライブラリとして
指定しておけば楽ちんだろうな、と思ったの。
キャッシュに入る訳だけど、キャッシュ内ではライブラリとソースのバージョンは一致するはずでしょ。

412:デフォルトの名無しさん
07/11/28 18:40:03
キャッシュの中のjarって見れる？
C:\Documents and Settings\....\Application Data\Sun\Java\Deployment\cache\6.0
の中を見ても、目的のファイルの探し方がわからん

413:デフォルトの名無しさん
07/11/28 19:00:19
>>412
！もう少し分かりやすく格納してたと思ったが、・・・記憶違い？
こりゃ・・・駄目だ。

もう、ライブラリ配布サイトのURLが表示される、くらいで勘弁してもらおう・・・・

414:デフォルトの名無しさん
07/12/04 20:08:23
JWSで動作するアプリがあって、そのユーザがサードパーティのプラグインをアプリにインストールして
使用できるというようなのをやりたいんだけど、そういうのって可能なんかな。
JNLPファイルの中で、あらかじめ使用するjarファイルをすべて宣言しておくしかないようだけど。

というのは、たとえJNLPファイルの中で、<permission-all>を指定してあっても、
後からJWSの管理外のコードベースから動的に読みこまれたクラスに対しては、
あいかわらずセキュリティマネージャの監視が効いてて、それを解除する方法がよくわからない。

415:デフォルトの名無しさん
07/12/04 20:22:31
Mavenとかそういうこと?

416:デフォルトの名無しさん
07/12/04 20:34:31
Maven使ったことないのでよくわからん。スマソ。

417:デフォルトの名無しさん
07/12/04 21:04:53
>>414
プラグインが必要としそうな入出力APIを本体アプリの方に持っておいて、プラグインからはそれを使う
AccessController#doPriviliegedをお忘れなく

418:デフォルトの名無しさん
07/12/04 22:08:28
>>415
Mavenは構築用だから関係ないんジャマイカ？

419:デフォルトの名無しさん
07/12/04 23:02:53
>>417
なるほど。
また仕事が増えてしまったけどw

> AccessController#doPriviliegedをお忘れなく

このクラスを使ったことがないので今から勉強しますです。

普通のアプリとして動かしていたときは、ポリシーファイルを使ってプラグインの権限に制限かけてたんだけど、
JWSでは多分その方法は使えそうにないですね。 ( ためしてないから確かなことはいえないけど )。

420:デフォルトの名無しさん
07/12/05 01:43:38
>>419
URLClassLoaderのgetPermissionsをオーバーライドして
PermissionCollectionにAllPermissionを追加したらいいかもしんない。

421:デフォルトの名無しさん
07/12/07 06:27:42
>>420
その方法で一応セキュマネを突破できた。
AllPermissionのまま使うわけにはいかないけど、あとは応用だからなんとでもなりそうです。
資料が少ないのでソース調べまくって悩んだ悩んだw
あんたただ者じゃないよ！
大感謝！

422:デフォルトの名無しさん
07/12/07 06:31:49
>>420
すごく勉強になった。ありがと。

423:デフォルトの名無しさん
07/12/07 14:51:30
JDK6u10 build08
URLﾘﾝｸ(download.java.net)
URLﾘﾝｸ(download.java.net)

変更点からすると、Netbeansの表示が
直っているかな・・・と思ったんですが直ってないですね。
まだまだ絞っていかないと駄目みたいですね。

424:デフォルトの名無しさん
07/12/07 18:11:17
とりあえずwebsphereで始めたらいいですか？

425:デフォルトの名無しさん
07/12/08 03:34:00
Nimbusの正式リリースも近そうだな。楽しみ。

426:デフォルトの名無しさん
08/01/12 16:12:05
うｐ毎回のようにリグレッションが出るのは何とかならないの？

427:デフォルトの名無しさん
08/01/12 16:13:34
なんともならない

428:デフォルトの名無しさん
08/01/12 21:58:41
バグのないプログラムが存在しないのは数学的に証明されてるからな。

429:デフォルトの名無しさん
08/01/12 22:20:20
バグのないプログラムなんていくらでも存在するがw

430:デフォルトの名無しさん
08/01/12 22:26:49
cabosを使おうと思っているのですが最新型のJavaをDLしているにもかかわらず

「ソフトウェアをロードできませんでした」

という表記がででいるのですが…

これってどうすればいいんでしょうか？

431:デフォルトの名無しさん
08/01/12 23:23:02
>>429
プログラムがバグってなくても仕様がバグったら(ry

432:デフォルトの名無しさん
08/01/12 23:23:42
>>429
プログラムがバグってなくても仕様がバグってたら(ry

433:デフォルトの名無しさん
08/01/12 23:37:17
プログラムじゃなくて、それを作った奴がバグってるだけ。
機械は忠実に実行してるだけだし、javaでもvbでも奴がアホならプログラムもアホになる。

434:デフォルトの名無しさん
08/01/12 23:43:27
>>428がバグってる件について

435:デフォルトの名無しさん
08/01/13 00:07:26
ググってみろ

436:デフォルトの名無しさん
08/01/13 01:45:04
こっちでやれ、ハゲが。

バグのないプログラムは存在しない
ｽﾚﾘﾝｸ(tech板)

437:デフォルトの名無しさん
08/01/13 01:46:41
ハゲがいないプログラマは存在しない

438:デフォルトの名無しさん
08/01/13 01:52:01
波平はハゲじゃないんだ！

439:デフォルトの名無しさん
08/01/13 14:38:13
update 4が出てる

440:デフォルトの名無しさん
08/01/13 18:31:50
英語版だけね

なぜか日本語版が出てないのに日本語のページはすでにupdate4になってるけど

441:デフォルトの名無しさん
08/01/13 21:13:21
そもそもJDKは国際化版はあっても日本語（オンリー）版ないし。

442:デフォルトの名無しさん
08/01/13 23:18:41
>>441揚げ足取りするなよ
マルチリンガル版がないのだよ

443:デフォルトの名無しさん
08/01/14 00:02:46
ん？置いてあるのってマルチリンガル版だけじゃないの？
Windowsに入れた時、ちゃんとインストーラでは日本語表示されてたような気がするが。

444:デフォルトの名無しさん
08/01/14 00:08:40
JREはenglishってかいてないか？

445:デフォルトの名無しさん
08/01/14 00:10:33
JREはローカライズするんじゃなかったっけ？

446:デフォルトの名無しさん
08/01/14 00:14:00
JDKは>>443。JREは知らん。

447:デフォルトの名無しさん
08/01/14 01:30:21
JDKのダウンロードページもEnglishと書いてあるな

今回急にダウンロードページのつくりが変わったからわけがわからん

448:デフォルトの名無しさん
08/01/14 08:09:16
>>447
Englishと書いてあるけど、置いてあるブツはUS版じゃないと思うんだが。

449:デフォルトの名無しさん
08/01/14 23:39:37
JDK6u4インストールしたがI18N化されてたぞ。毎度のごとくインストーラだけ。

450:デフォルトの名無しさん
08/01/15 00:21:01
インストールだけしてその後一切使ってないなら判らないかもしれないけど、
charsets.jarも入ってるし、コントロールパネルもjavacのエラーも日本語表示されるよ。

そーいや、コントロールパネルのカテゴリが「その他」から「プログラム」に移動してた。

451:デフォルトの名無しさん
08/01/15 00:29:53
URLﾘﾝｸ(bugs.sun.com) これかな

452:デフォルトの名無しさん
08/01/15 08:38:24
javaコマンドのメッセージが英語だったんだが。

453:デフォルトの名無しさん
08/01/15 12:03:42
javaコマンドのメッセージが日本語だった事ってあるの？

454:デフォルトの名無しさん
08/01/15 12:28:12
あるよ。
ただ、コマンドライン、システム・エンコーディング指定とか、
右往左往しすぎて今でも何が何だかよくわからん。

455:デフォルトの名無しさん
08/01/15 12:29:33
>>453
ないはず。少なくともSunの奴では。

456:デフォルトの名無しさん
08/01/16 14:10:22
Java Kernel(旧姓：Consumer JRE) の jre が出たらしい(もちろんテスト版)
URLﾘﾝｸ(jdk6.dev.java.net)
変更点は、リリースノートが不在のためまだ不明。
Mercurialに変わってビルドに問題が？

457:デフォルトの名無しさん
08/01/16 14:29:39
Java Kernelいらね。
実際、需要はどうだろうね？

458:デフォルトの名無しさん
08/01/16 15:33:32
>>456
インストーラがVista対応してないとか書いてある

459:デフォルトの名無しさん
08/01/20 22:28:34
そういやIcedTea 1.5が出てたな。
PPCアーキテクチャへの対応が主な成果だが、ゲーム機で動いたら遊びがいがあるのにな。

箱○で.netが使われてるからPS3上のlinuxで動けば面白いのに。

460:デフォルトの名無しさん
08/02/27 20:27:12
jdk6uN build12
URLﾘﾝｸ(jdk6.dev.java.net)
URLﾘﾝｸ(download.java.net)

ほとんどがBugFixのようでリリースは近いかな？？

461:デフォルトの名無しさん
08/02/27 21:02:00
>>460
リンク先のスケジュールに FCS Summer/Fall 08 って書いてあるんだが
リリース前倒しの情報かなんかあったっけ？

462:デフォルトの名無しさん
08/02/28 14:49:34
エスケープ解析ってどうなったの？

463:デフォルトの名無しさん
08/02/28 16:46:00
ServerVMで使えるよ。

464:デフォルトの名無しさん
08/02/29 04:54:52
有用そうだけど、話にも上がらなかったからもう消えた技術なのかと思ってたｗ

465:デフォルトの名無しさん
08/02/29 05:22:00
知らないうちに使われているのが一番だから

466:デフォルトの名無しさん
08/02/29 07:47:23
デファルトの起動オプションではおふじゃなかったか？

467:デフォルトの名無しさん
08/03/01 01:54:07
つ -XX:DoEscapeAnalysis

468:デフォルトの名無しさん
08/03/01 04:43:30
やっぱりオフじゃん。
確かスタックにnewオブジェクト置いても、すぐ解放みたいのだろ？
クライアント側(java.exe)にないと意味なくないか。
サーバー（といっていいのか）側の方が、クライアントより計算が多いなら別だが。
まあ、多分必要とされてないんだろうな（技術的には最適化みたいで大変そうだけど）。

469:デフォルトの名無しさん
08/03/01 13:36:28
サーバってのは、プログラムを24時間365日ずっと起動しっぱなしで、
何度も繰り返し大量のリクエストを捌くものだ
クライアントより計算（の量？）が多いってのは、確かだろう
多少時間をかけても入念に最適化してコンパイルしておく意義がある
クライアント側は、起動に時間かかると文句言うやつが多いからじゃないか

470:デフォルトの名無しさん
08/03/01 13:43:08
>>467
さりげなくうそおしえてるのわろた

471:デフォルトの名無しさん
08/03/01 14:02:33
（JVMの）起動に時間がかかるのは、ライブラリのロードとかが本質的なところじゃなかったか？
String以外なら、やりたいことはクライアント側で行列とかなんだけど、普通サーボー側ではやらんだろ。
もしかしてエスケープ解析が目指しているのは、これとは違う目的なのだろうか？

472:デフォルトの名無しさん
08/03/01 14:15:24
>>471
よくわからんのだけど(今のJVMの)エスケープ解析に最適化以外の目的がありえるの?
それともどんなケースで最適化が効くのかという話?

473:デフォルトの名無しさん
08/03/01 14:20:45
エスケープ解析すると、newしたオブジェクトがエスケープしてるかどうかがわかる
エスケープしないオブジェクトは、ヒープに割り当てる代わりにスタックやレジスタ上で済ますことができる
ヒープの割り当てが減ると、GCの回数が減る
GCがボトルネックになっている場合は、それで高速化できるかも
エスケープしないオブジェクトは、synchronizedを省略できる
synchronizedを多用してる場合は、それで高速化できるかも

474:デフォルトの名無しさん
08/03/01 14:23:47
>>472
意味不のレスを無理して理解しようとするな
スルーしろ

475:デフォルトの名無しさん
08/03/01 16:35:58
久々に話題振ってきてるのに、そりゃないよｗ

476:デフォルトの名無しさん
08/03/01 16:38:34
＞エスケープしないオブジェクトは、synchronizedを省略できる　
＞synchronizedを多用してる場合は、それで高速化できるかも　

並列処理と相性がいいらしいというのは、ここだったんですか。

477:デフォルトの名無しさん
08/03/01 16:46:51
たしかメソッドに渡してしまうとエスケープ解析対象外になるんじゃなかったか？
mat3=MyMatrix.mul　(mat1,mat2);
みたいなの。

でも思うんだけど、クラスが状態変更しないこと（immutable　class）が
保障されているならこのインスタンスもエスケープできるんじゃないか？
実装とか細かい動作はしらね―けど。
例えばclass　Stringとか、class　BigIntegerみたいなの。これと同じく、自作クラスの
class　MyMatrix　みたいなのでも出来て欲しいなと思って。

エスケープ解析とか、多分知ってる人いないし、見向きもしてないと思うけど。
特別に行列とかにこだわってんじゃないけどね。

次ページ