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

【Java】次世代Java・ ..

876:デフォルトの名無しさん
06/02/13 00:24:16
javadoc の新タグは以下のwikiでなんかやってるみたい。
URLﾘﾝｸ(www.javac.info)

877:デフォルトの名無しさん
06/02/13 00:30:19
An easy way to enter the Mustang Regression contest
URLﾘﾝｸ(weblogs.java.net)

regressionコンテストの簡単な参加方法
既存の 1.5update6 で動くアプリを JDK 6で動かしてみてくれ、
そんで動かなかったらアプリの問題か JDKの問題か考えてくれ、
もしJDKの問題だったら報告お願いって感じらしい。

878:デフォルトの名無しさん
06/02/13 00:34:26
1.4.2から5.0ベータで結構動作が異なることが多かった
JavaSoundとJava2Dまわりは穴かもしれんな

正式版でも結構違うけど

879:デフォルトの名無しさん
06/02/13 08:43:24
>>872
Ultra20 ってまた微妙なもんプレゼントですなぁ
正直あんまし欲しくない～　うるさいしｗ

>>877
apache の poi の日本語取扱の挙動がおかしくなることは知っている
が、Ultra20欲しくないので誰か報告してちょうだい～

880:デフォルトの名無しさん
06/02/13 10:03:58
>>879
> そんで動かなかったらアプリの問題か JDKの問題か考えてくれ、

881:デフォルトの名無しさん
06/02/13 10:25:15
>>880
その一文の敷居高すぎだよな。

882:デフォルトの名無しさん
06/02/13 10:52:49
たしかに

883:デフォルトの名無しさん
06/02/13 12:58:12
普通だよ。思ったように動かないって言うだけなら技術者じゃなくてもできるし。

こーゆー事をやるのが普通だと思ってる人たちにとっては敷居高いのかもしれんけど。
URLﾘﾝｸ(monoki.fc2web.com)
URLﾘﾝｸ(monoki.fc2web.com)

884:デフォルトの名無しさん
06/02/13 20:56:04
正直言うと、そのサイトをさらすことに何の意味があるのかわからない。

アプリの問題か JDKの問題かなんてアプリ作者（プログラマ＝技術者）しかわからんだろ。

885:デフォルトの名無しさん
06/02/13 22:50:16
作者にも分からんかも

886:デフォルトの名無しさん
06/02/13 22:56:18
第三者でも分かる事もあるけどね

887:デフォルトの名無しさん
06/02/14 08:01:54
敷居が高い
『不義理・不面目なことなどがあって、その人の家に行きにくい』

あってるじゃん。

888:デフォルトの名無しさん
06/02/15 14:16:31
Mustang beta is out!
URLﾘﾝｸ(mustang.dev.java.net)

889:デフォルトの名無しさん
06/02/15 17:01:15
>>888
それってb71よりも新しい？

890:デフォルトの名無しさん
06/02/15 19:37:11
>>889
>>854

891:デフォルトの名無しさん
06/02/16 12:58:30
じゃ、結局古いってことか
安定はしているけど古いってか

892:デフォルトの名無しさん
06/02/17 13:46:40
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)

これは新しいのかな？

893:デフォルトの名無しさん
06/02/17 13:59:55
オレの 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)

894:デフォルトの名無しさん
06/02/18 12:02:24
>>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)

895:デフォルトの名無しさん
06/02/18 12:03:30
beta 版のダウンロードはこちらからどーぞ。
URLﾘﾝｸ(java.sun.com)
URLﾘﾝｸ(java.sun.com) （日本語）

896:デフォルトの名無しさん
06/02/18 14:43:02
Vista の Look&Feel ってどうやって変更するの？

897:デフォルトの名無しさん
06/02/18 15:00:49
XPLAFと同じでそのOS上で動かさないと駄目では？
設定でXPLAFはクラシックLAFにかえれるけど、VISTAも同じではないかな

898:デフォルトの名無しさん
06/02/18 21:05:46
>>892
バージョン番号の話。
URLﾘﾝｸ(forums.java.net)

要するに、内部バージョンがbeta2となっているのは、beta2への開発版
という意味らしい。
b60以降しばらくはrcになっていたけど、スケジュール変更でBeta2が出
ることになったから修正された。
>>893のLinux版は、多分修正し忘れだろうね。

899:デフォルトの名無しさん
06/02/20 16:32:42
Mustang build72 リリース

build71 からの変更点
URLﾘﾝｸ(mustang.dev.java.net)

900:デフォルトの名無しさん
06/02/21 11:20:25
見たか！俺は９００！
俺は至高！俺は吉良上野介！
俺は

901:デフォルトの名無しさん
06/02/21 14:23:37
うえのすけ

902:デフォルトの名無しさん
06/02/22 14:02:29
うえのすけべ

903:デフォルトの名無しさん
06/02/23 00:09:20
よしよしうえのすけべ

904:デフォルトの名無しさん
06/02/28 01:49:03
Mustang build73 リリース

build72 からの変更点
URLﾘﾝｸ(mustang.dev.java.net)

905:デフォルトの名無しさん
06/03/01 00:45:06
例の日本語印刷がおかしいのが直ってるな

906:デフォルトの名無しさん
06/03/02 14:40:11
なんかさ、>>904をインストールするたびに、

すでにインストールされてます
再インストールしますか？

ってでちゃうんだよね。

もー仕方がないのかねえ

907:デフォルトの名無しさん
06/03/04 20:27:28
>>906
以前、毎回再インストールするのが面倒すぎてウンザリだっていう投稿が
フォーラムかどこかにもあった。確かに面倒。

Mustang build74リリース

build73 からの変更点
URLﾘﾝｸ(mustang.dev.java.net)

908:879
06/03/12 02:10:41
>>880
正直時間がないから追及しきれんのよ。

Locale周りのデフォルトが変わったのかもしれんし、
もし、そうなら5.0までのデフォルトに合わせてるpoiが悪いとも言い切れない。
さらにデフォルト変えちゃったのがバグかもしれんし。

5.0で動くんだから俺は5.0で動かしてる。

>>907
毎回手でアンインストールしてた時代に比べれば格段に便利になって重宝してます・・・
一番いいのは、上書きしてくれればいいんだけど、クリーンインストールでないと
問題点が絞れなかったりするのかなぁと、今のところは仕方ないかと諦めてます。

↓勝手に出しちゃえ
Mustang build75リリース

build74 からの変更点
URLﾘﾝｸ(mustang.dev.java.net)

909:デフォルトの名無しさん
06/03/13 18:18:48
アンインストールして再びインストールし直すのは確かに苦痛かな。

っていうかレジストリ弄って古いバージョンの変数を削除して
さらにJavaをインストールしたディレクトリも削除してから
新しいビルドをインストールするという手でもうまくいくかな？

910:http://www.vector.co.jp/soft/win95/util/se072729.html
06/03/18 20:48:40
TextSS　のWindowsXP(Professional)64bit化おながいします

もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？

911:デフォルトの名無しさん
06/03/18 22:20:04
↑マルチ失せろ

912:デフォルトの名無しさん
06/03/19 20:41:41
Documentインタフェースを実現した
ODFDocumentクラスを6.0にねじ込んでください。
ソースごとそんな要望を送りつけてください。

913:デフォルトの名無しさん
06/03/19 20:57:42
>>912
ご自分でどうぞ。

Mustang build76リリース

build75 からの変更点
URLﾘﾝｸ(mustang.dev.java.net)

914:デフォルトの名無しさん
06/03/20 00:00:56
おろ、GroupLayout追加されたんだね。

915:デフォルトの名無しさん
06/03/20 00:08:09
いつかは標準でとりこむといっていたけど、JavaSE6で取り入れるとはおもわんかった。

916:デフォルトの名無しさん
06/03/20 02:40:45
えっ、だいぶ前からGroupLayoutってSE6で導入するって話を聞いてたんだけど漏れの勘違いだったのかな・・・？

917:デフォルトの名無しさん
06/03/20 02:48:15
SE 6
毎週内容かわってるのですか？

918:デフォルトの名無しさん
06/03/20 03:03:05
リリースの追い込みに向けて減っていく傾向はなくもないｗ

919:デフォルトの名無しさん
06/03/20 03:53:33
>>916
いや、だいぶ前はSE6からって話だったけど、すぐにSE7からってことになってた。

920:デフォルトの名無しさん
06/03/21 00:51:33
Java SE 6でGroupLayoutが取り込まれても、Visual Editorが対応してくれないと・・・。

921:デフォルトの名無しさん
06/03/21 01:05:09
まだベータなんだから、eclipse 頼みの軟弱なやつ向けではないだろ。

922:デフォルトの名無しさん
06/03/21 01:05:43
Bug 6375459 に Origato ってコメント付けてんの日本人？

923:デフォルトの名無しさん
06/03/21 01:43:08
>920-921
NetBeans使えばいいじゃない

924:デフォルトの名無しさん
06/03/21 10:50:07
>>920
VisualEditorでバリバリGUI開発しているのか？
使い心地はどうだ？
感想頼む。
NetBeansが軽いと聞いて使っているのだが
VEは反応があまりにもおそすぎて使ってない。
プラグイン入れすぎというのもあるだろうけど

925:デフォルトの名無しさん
06/03/21 11:35:17
VEの問題は重さじゃないと思うな…とにかくスレ違いですね

926:デフォルトの名無しさん
06/03/23 02:25:26
>>924
そうでもない。SprintLayoutにも対応していないし、機能は限定されてる。
GridBagLayout使うときはGUIでパラメータ弄れて便利だけど、
やっぱりソースを手で調節しないといけない時もある。

>>925
すまん。でもGroupLayoutとかが主流になったら直コーディングは難しくなるし、
話すときは使ってるGUIビルダと絡めざるを得なくなりそうな気もする。

927:デフォルトの名無しさん
06/03/23 17:48:33
Java SE 6 Beta Maintenance Review公開
URLﾘﾝｸ(java.sun.com)

これは事実上J2SE 5.0仕様に対するメンテナンスレビューだとのことです。

928:デフォルトの名無しさん
06/03/23 22:53:14
よくわからない
5.0に対するメンテナンスレビューという意味がわからない

929:デフォルトの名無しさん
06/03/23 22:58:16
これが凄く気になった。
インストゥルメントというパッケージ。
まるで楽器演奏のみの歌詞がない曲やや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:

930:デフォルトの名無しさん
06/03/23 23:04:30
>>929
それ、5.0 からあるよ。例えば、バイトコードにカウンタ回すコードを埋め込むタイプの
カバレッジツールとかを作る人が、より便利になるようにするためのパッケージね。

URLClassLoadeer とか、そーゆーのとは違う。

931:デフォルトの名無しさん
06/03/23 23:05:57
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を入れたことによってプログラムが動かなくなる問題も
これで解消だ。

932:デフォルトの名無しさん
06/03/23 23:29:44
日本語の説明おいときますね。
　URLﾘﾝｸ(java.sun.com)
ClassFileTransformerが強力だが凶悪だと思う。

933:デフォルトの名無しさん
06/03/24 00:08:37
>>932
クラスファイルを変換するって

同じパッケージ名.クラス名だが

中身はバージョンが異なるクラスに動的にかえるってことかいな？

スクリプト言語や
プロトタイプベース・オブジェクト指向言語にみられるような、
動的オブジェクト指向言語のような使い方ができてしまうのかねえ。
オブジェクトを生成したあとからクラスにフィールドやメソッドを追加できる
みたいなことがJavaでもできてしまうってことかいな？

934:デフォルトの名無しさん
06/03/24 00:24:53
>>933
EclipseのPleiadesプラグインが使ってるね。

935:デフォルトの名無しさん
06/03/24 00:37:10
>>933
URLﾘﾝｸ(java.sun.com)(java.lang.instrument.ClassDefinition[])
> 再定義では、メソッドの本文、定数プール、および属性の変更が可能です。
> ただし、再定義では、フィールドまたはメソッドの追加、削除、あるいは名前の変更、
> メソッドのシグニチャーの変更、あるいは継承の変更はできません。
> これらの制約は、将来バージョンで解消される可能性があります。

936:デフォルトの名無しさん
06/03/24 00:52:12
>>933
InstrumentationにClassFileTransformerを追加しておくと、
クラスローダのdefineClassが実行される前に実行してくれる。
defineClassが実行される直前ではクラスのバイト列が既に解決済みなんだけど、
そのバイト列と対象のクラスローダがClassFileTransformerに渡される。
そのバイト列をClassFileTransformerで変換して返す事によって、
defineClassが本来とは違うバイト列で行われるっていうだけ。

で、GC可能なカスタムクラスローダで読み込んでいれば、
ロード済みのクラスもGCの対象になるので、GC後であれば再定義は可能だけど、
基本的には１度しか実行されないので、動的言語サポートとはいえない。
上でも説明が出てたけど、１度きりのロードだけなので、
コードカバレッジの計測とかアスペクトの組み込み等がいいかも。
OracleのTopLinkも使っていたような気がする。

あっ、でもプロパティ次第では動的に再定義も可能なんだけど、
Instrumentation関連で使用されるクラスは無理。
環境によってはサポートされない場合もある。

複数のClassFileTransformerを登録できるので、
オリジナルのバイト列　＞　コードカバレッジ計測機能付きバイト列　＞
アスペクト組み込みバイト列　＞　クラスローダでロード
ってシナリオも可能。

TigerならApache BCELが内部に組み込まれているので、
それを使ってもいいし、俺はJavassistを使っている。
CtMethod#instrumentで、コードカバレッジの計測コードの追加が
とても簡単なんだよね。

937:936
06/03/24 00:52:51
>>931
premainメソッドを実装したクラスの位置とか、再定義可能とか、
そんな感じのプロパティを記述したファイル（名前は忘れた）を
含んでいるJarファイルを
-javaagent:<jar名>=引数
と言う風にjavaコマンドの起動オプションで指定すると
エージェントが起動するよって話。
premainメソッドの定義クラスとかClassFileTransformerの実装などは、
別にJarに含む必要はない。

938:デフォルトの名無しさん
06/03/24 01:00:45
ジョイスティックはいつサポートされますか？

939:デフォルトの名無しさん
06/03/24 01:03:32
ジョイパッドの後ぐらいかな、たぶん。

940:デフォルトの名無しさん
06/03/24 03:26:04
ライトペンはサポートされますか？

941:デフォルトの名無しさん
06/03/24 08:12:28
ライトサーベルの後じゃない？

942:デフォルトの名無しさん
06/03/24 09:19:37
>>934
あれはアスペクト指向を使っていると書いてあったと
思うんだが、Java5のそのクラスだけでまかなっていたのか

943:デフォルトの名無しさん
06/03/24 09:29:49
>>937
> -javaagent:<jar名>=引数

思い出した。それがPleiadesで使ってたやつか。

944:デフォルトの名無しさん
06/03/24 09:31:51
よくよく考えてみると、
フィールドやメソッドを動的に変更する意義って
そうそう多くはないかもしれぬ。

Genericsを組み合わせてListやMapやSetなどをフィールドに入れておいて
あとから追加することができるから。

メソッドについてはリフレクションでまかなう？

945:デフォルトの名無しさん
06/03/24 12:03:59
>>942
アスペクト指向はプログラムの書き方の話だろ。
アスペクトの実現方法ひとつ。

946:デフォルトの名無しさん
06/03/24 12:16:14
>>944
フィールドやメソッドを動的に変更できるってのも面白いけど
動的に変更すると、今まで検査したバイトコードも
全部再検査しなきゃならなくなるような。

そーいや、Mustang でバイトコードベリファイアが変更になったのって
この辺の絡みもあるのかな、と妄想してみる。よく知らんけど。

947:デフォルトの名無しさん
06/03/24 13:21:07
いままではJavassistやASMでやってたことが標準になるわけだね。

948:936
06/03/24 19:24:16
>>947
それは違う。

JavassistやASMはバイト列を自分で取得して操作するものだけど、
Instrumentationはクラスのローディングを直前にハンドルするもの。
バイトコード操作のタイミングだけを提供してくれるAPIだね。

ちなみに、JavassistとかASMが無くてもTigerなら、
com.sun.org.apache.bcel.internal.*
というパッケージでApacheのBCELが提供されている。

>>946
ロードの事前なので、不適切なバイトコードならベリファイエラーになる。
Mustangで変更になるのはStackFrameMap属性が追加になるんだけど、
逆にバイトコード操作ライブラリの対応を待たないと、ベリファイでエラーになる。
起動オプションで古いベリファイアを使うことも可能。

949:936
06/03/24 19:25:20
>>948
StackMapTable属性の間違いね。ごめん。

950:947
06/03/25 02:04:15
ありが㌧ヽ( ´∀`)ﾉ

951:デフォルトの名無しさん
06/03/25 02:08:50
サーバを止めることなくパッチを当てることが簡単になるってことかな
プロセス間通信はまだ出来ないの？出来たら動的書き換えは強力なパラダイムだね
スクリプトエンジンと連携させてサクッとパッチが当てられる

952:デフォルトの名無しさん
06/03/25 10:25:26
>>948
com.sun.* って使っていいんだっけ？

953:デフォルトの名無しさん
06/03/25 11:07:36
なんちゅうか、>>936 以外は書いてること無茶苦茶やね。。。

954:デフォルトの名無しさん
06/03/25 11:07:37
使ってもいいが、VM依存のオプショナルパッケージであること
将来のバージョンで保証されないこと

これらをふまえてな

955:デフォルトの名無しさん
06/03/25 11:26:40
>>948
>>946 のは将来のバージョンにおいて、
redefineClasses とかでフィールドやらメソッドの
追加や削除や変更が認められる場合の話ね。

ちょっと考えたら、実行時に NoSuchMethodError とか
NoSuchFieldError 食らうだけだからバイトコード検査関係ないよな。

956:936
06/03/25 12:29:21
動的にメンバを追加できても、コンパイル時点ではシンボル解決できないので、
意外と使い道に悩むことが多いかなと思います。

ただし、事前にインターフェイスが存在していて、
クラスにインターフェイスを動的実装させてメソッド追加すれば、
インターフェイスを経由して楽に利用できます。
動的に実装させなくても、プロキシを使うパターンもありですね。

それと、JakartaのBeanUtilsのようなリフレクションのラッパーAPI向けに
動的にメンバを追加するというのはありかなと思います。

このAPIって、Mustangでは多少の変更があるものの、
（確実な再定義可能判定機能とか・・・）
Tigerから存在していてMustang特有の話じゃないので、
スレ違いかもしれませんね。
ダラダラと話を伸ばして、ゴメンナサイ。

957:デフォルトの名無しさん
06/03/25 16:41:00
>>953
それでいいんじゃねぇの？

958:デフォルトの名無しさん
06/03/26 12:05:27
なんだかちょっと難しいな。
つかってみないと良く分からないと言うか。
実行サンプル無いかな。
実例とか

959:936
06/03/26 13:39:07
さくらばさんのサイトとかいいかも。

Java In The Box
URLﾘﾝｸ(www.javainthebox.net)

960:デフォルトの名無しさん
06/03/26 14:08:08
Mustang build77リリース

build76 からの変更点
URLﾘﾝｸ(www.dev.java.net)

961:デフォルトの名無しさん
06/03/26 15:33:35
今回かなりの修正箇所だね

962:デフォルトの名無しさん
06/03/27 23:08:42
>>928
これ。
URLﾘﾝｸ(jcp.org)

JCPには正式リリース後にMaintenanceのフェイズがある。
Mustang(JSR 270)はまだ正式リリースすらされてないのにメンテナンスなのはおかしいんだけど、
これは名前がMustangのMaintenance Reviewってなってるだけで、実質的にはJSR 176に対する
Maintenance Reviewなんだよってこと。

963:デフォルトの名無しさん
06/04/02 13:09:35
Mustang build78リリース

build77 からの変更点
URLﾘﾝｸ(www.dev.java.net)

964:デフォルトの名無しさん
06/04/11 00:22:14
Mustang build79リリース

build78 からの変更点
URLﾘﾝｸ(mustang.dev.java.net)

965:デフォルトの名無しさん
06/04/16 15:54:08
Mustang build80リリース

build79 からの変更点
URLﾘﾝｸ(www.dev.java.net)

966:デフォルトの名無しさん
06/04/26 21:06:49
URLﾘﾝｸ(bugs.sun.com)
直ったらしい。
Mustang側にいつ入るのかな

967:デフォルトの名無しさん
06/04/26 21:23:58
えぇ！　なんだってぇ！？
vをおすとクラッシュするって？

しらなかった

968:デフォルトの名無しさん
06/04/26 22:19:23
4月頭頃に出したバグ(?)がb81で直ってた。なんか嬉しい。

969:デフォルトの名無しさん
06/04/26 22:36:01
update7っていつでるんだろうねぇ・・・

970:デフォルトの名無しさん
06/05/04 23:08:04
URLﾘﾝｸ(jroller.com)

MacOSXもｷﾀｺﾚ

971:デフォルトの名無しさん
06/05/05 16:13:15
10.5でサポートすると思ってた。

972:デフォルトの名無しさん
06/05/05 16:28:07
>>970
いつの話だよ…

ADCより
Java SE 6.0 Release 1 (Intel) (Disk Image) 89.5 MB 02 May 2006

しかしCocoa bindingなくなって、アプリ開発者はどうするんだろ…

973:デフォルトの名無しさん
06/05/06 03:34:46
いつもJava対応で後手に回るAppleがついに・・・
ちょっとだけ追いついた？

974:デフォルトの名無しさん
06/05/06 05:04:55
Mustang build83リリース

build82 からの変更点
URLﾘﾝｸ(mustang.dev.java.net)

975:デフォルトの名無しさん
06/05/08 06:38:08
>>972
Cocoaのbindingの部分、
JNIとjavaで書かれているんだと思うけれど、
辞める引き替えに、ソースを出せないのかな?

976:デフォルトの名無しさん
06/05/15 17:33:38
J# スレがとっくの昔に落ちてしまったからここで聞くけど、
J# のライブラリが JDK 1.1.4 互換だったりするのは
なにか Sun との間のライセンスの問題？
それとも単に Microsoft が Java 2 のライブラリを
インプリメントするのをサボってるから？？

977:デフォルトの名無しさん
06/05/15 18:08:57
>>976
【初心者】Java質問･相談スレッド85【大歓迎】
ｽﾚﾘﾝｸ(tech板)

978:デフォルトの名無しさん
06/05/15 23:52:16
>>976
Java2の時代は既に決裂していなかったっけ？
さぼっているという以前に有名な闘争に発展していたはず。

979:デフォルトの名無しさん
06/05/16 20:10:33
>>976
Sun に勝手な拡張すんなボケって言われたから。
拡張できないんなら自分で作るよハゲっ
つーことで C# を発明。
あとは >>977 のｽﾚへ逝って。

980:デフォルトの名無しさん
06/05/17 00:29:59
>>979
一行目と二行目の間に
ゲイツ「Javaは人類の資産であってSunの私物じゃない」
を入れといてw

981:デフォルトの名無しさん
06/05/17 00:35:01
>>980
おれ、あの問題についてはJava仕様と互換性と保たなかった
MSに問題があったと思うんだよね。
互換性を保った上で、独自拡張を追加したって形では無かった
からねえ。

982:デフォルトの名無しさん
06/05/17 01:55:40
JNIに危機感持ったからねぇ

983:デフォルトの名無しさん
06/05/17 03:36:55
(･∀･)ｹﾞﾍﾗﾍﾗ
マクネリに言わせれば・・・「もちろんMicrosoftのものでもないのは言うまでもない」ｗｗ

984:デフォルトの名無しさん
06/05/17 21:35:20
独自にやりたいんなら、スクラッチからコード組みゃあいーのに、
Sunとライセンス交わして買った(?)コード勝手に拡張したからねぇ。

985:デフォルトの名無しさん
06/05/17 21:40:28
たしかMS JVMってSunのコード使ってないんジャマイカ？
少なくともVMのコアはMS製。当時は一番速かった。
ライセンス問題は「Java」という商標の問題だったはずだが。

986:デフォルトの名無しさん
06/05/17 22:08:09
MSの除くと一番普及してたVMはシマンテックだな

JITのおかげでベンチマークは早かったけど
例の起動時フリーズしてるのかと思うようなやつで
Javaの地位を大きく下げることに成功した

1.1時代は大量にあったVM実装も1.2以降はほとんどなくなり
SunのVMが普及し始める

あの起動の遅さとかあったからHotSpotがでてきたんだけどな

987:デフォルトの名無しさん
06/05/17 22:38:11
どうしてもJavaでなきゃ駄目な案件なんてない。
たいがいはＰＨＰで済むし、それが駄目ならＣ＋＋で組む。

988:デフォルトの名無しさん
06/05/17 23:15:23
>>986
Javaの地位を大きく下げることに本当に成功してんのかとw

Google Trendを見るとJavaの地位が高いのは明らかだし。

989:デフォルトの名無しさん
06/05/17 23:15:27
>>987
いきなり、なんの話？

990:デフォルトの名無しさん
06/05/17 23:17:07
>>988
俺は >>986 じゃないが、
あのときは、ボロカスだっただろ？

991:デフォルトの名無しさん
06/05/17 23:23:39
ふーん。

今が早ければいいや。

それより、次スレどうしようっかな。

再利用できるスレってあるかな。
無ければ立てちゃおうか。

1.5のスレと一緒にまとめたタイトルにしよっか？

992:デフォルトの名無しさん
06/05/17 23:24:27
＞＞９８９

次世代Ｊａｖａはいらないという話でつ

993:デフォルトの名無しさん
06/05/17 23:27:39
>>991
むしろ、1.7 dolphin とまとめた方が良いような？

994:デフォルトの名無しさん
06/05/17 23:52:45
>>987
いやマジでPHP勘弁して。
PHPがというより、PHPプログラマのあの、保守性とか見通しの良さとか
考えてない、でもおれはphpでプログラマやってんだぜ、というのなんとかして。

はっきりいって、その辺でブイブイ言わせてるphpプログラマより、「やっと
MVCが分かってきました」というJavaプログラマのほうがはるかにマシ。

995:デフォルトの名無しさん
06/05/18 00:14:23
「たいがいはPHPで組める」って、自分がその程度の仕事しかしてないんだよな。
業務アプリをPHPで組むっていうのは、システムなめてるとしか思えん。

996:デフォルトの名無しさん
06/05/18 00:30:09
次、どうする？
Mustangで立てる？もう、早漏してDolphinで立てる？

997:デフォルトの名無しさん
06/05/18 00:45:06
>>995
あなたさまはどんな仕事やってんの？

998:デフォルトの名無しさん
06/05/18 01:01:19
次世代Javaの動向　２でいいんじゃね

999:デフォルトの名無しさん
06/05/18 01:02:24
これは？

【JavaFive】C＃からJ2SE5.xへ進化【TigerShot】
ｽﾚﾘﾝｸ(tech板)

1000:デフォルトの名無しさん
06/05/18 01:04:24
次スレはこれにした。

次世代Javaの動向　２
ｽﾚﾘﾝｸ(tech板)

1001:１００１
Over 1000 Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。