1 名前:デフォルトの名無しさん mailto:sage [04/04/12 00:49] 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プログラミングの簡易化に焦点を当てている。
892 名前:デフォルトの名無しさん mailto:sage [2006/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 名前:デフォルトの名無しさん mailto:sage [2006/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 名前:デフォルトの名無しさん mailto:sage [2006/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 名前:デフォルトの名無しさん mailto:sage [2006/02/18(土) 12:03:30 ] beta 版のダウンロードはこちらからどーぞ。 java.sun.com/javase/6/download.jsp java.sun.com/javase/ja/6/download.html (日本語)
896 名前:デフォルトの名無しさん mailto:sage [2006/02/18(土) 14:43:02 ] Vista の Look&Feel ってどうやって変更するの?
897 名前:デフォルトの名無しさん mailto:sage [2006/02/18(土) 15:00:49 ] XPLAFと同じでそのOS上で動かさないと駄目では? 設定でXPLAFはクラシックLAFにかえれるけど、VISTAも同じではないかな
898 名前:デフォルトの名無しさん mailto:sage [2006/02/18(土) 21:05:46 ] >>892 バージョン番号の話。 forums.java.net/jive/thread.jspa?threadID=2655 要するに、内部バージョンがbeta2となっているのは、beta2への開発版 という意味らしい。 b60以降しばらくはrcになっていたけど、スケジュール変更でBeta2が出 ることになったから修正された。 >>893 のLinux版は、多分修正し忘れだろうね。
899 名前:デフォルトの名無しさん mailto:sage [2006/02/20(月) 16:32:42 ] Mustang build72 リリース build71 からの変更点 https://mustang.dev.java.net/files/documents/2817/29269/mustang-b72.html
900 名前:デフォルトの名無しさん mailto:sage [2006/02/21(火) 11:20:25 ] 見たか!俺は900! 俺は至高!俺は吉良上野介! 俺は
901 名前:デフォルトの名無しさん mailto:sage [2006/02/21(火) 14:23:37 ] うえのすけ
902 名前:デフォルトの名無しさん mailto:sage [2006/02/22(水) 14:02:29 ] うえのすけべ
903 名前:デフォルトの名無しさん mailto:sage [2006/02/23(木) 00:09:20 ] よしよしうえのすけべ
904 名前:デフォルトの名無しさん mailto:sage [2006/02/28(火) 01:49:03 ] Mustang build73 リリース build72 からの変更点 https://mustang.dev.java.net/files/documents/2817/29768/mustang-b73.html
905 名前:デフォルトの名無しさん mailto:sage [2006/03/01(水) 00:45:06 ] 例の日本語印刷がおかしいのが直ってるな
906 名前:デフォルトの名無しさん mailto:sage [2006/03/02(木) 14:40:11 ] なんかさ、>>904 をインストールするたびに、 すでにインストールされてます 再インストールしますか? ってでちゃうんだよね。 もー仕方がないのかねえ
907 名前:デフォルトの名無しさん mailto:sage [2006/03/04(土) 20:27:28 ] >>906 以前、毎回再インストールするのが面倒すぎてウンザリだっていう投稿が フォーラムかどこかにもあった。確かに面倒。 Mustang build74リリース build73 からの変更点 https://mustang.dev.java.net/files/documents/2817/30112/mustang-b74.html
908 名前:879 mailto:sage [2006/03/12(日) 02:10:41 ] >>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
909 名前:デフォルトの名無しさん [2006/03/13(月) 18:18:48 ] アンインストールして再びインストールし直すのは確かに苦痛かな。 っていうかレジストリ弄って古いバージョンの変数を削除して さらにJavaをインストールしたディレクトリも削除してから 新しいビルドをインストールするという手でもうまくいくかな?
910 名前:http://www.vector.co.jp/soft/win95/util/se072729.html mailto:http://msdn2.microsoft.com/ja-jp/library/h2k70f3s.aspx [2006/03/18(土) 20:48:40 ] TextSS のWindowsXP(Professional)64bit化おながいします もしくは64bitにネイティブ対応したテキスト置換ソフトありますか?
911 名前:デフォルトの名無しさん [2006/03/18(土) 22:20:04 ] ↑マルチ失せろ
912 名前:デフォルトの名無しさん mailto:sage [2006/03/19(日) 20:41:41 ] Documentインタフェースを実現した ODFDocumentクラスを6.0にねじ込んでください。 ソースごとそんな要望を送りつけてください。
913 名前:デフォルトの名無しさん mailto:sage [2006/03/19(日) 20:57:42 ] >>912 ご自分でどうぞ。 Mustang build76リリース build75 からの変更点 https://mustang.dev.java.net/files/documents/2817/31069/mustang-b76.html
914 名前:デフォルトの名無しさん mailto:sage [2006/03/20(月) 00:00:56 ] おろ、GroupLayout追加されたんだね。
915 名前:デフォルトの名無しさん mailto:sage [2006/03/20(月) 00:08:09 ] いつかは標準でとりこむといっていたけど、JavaSE6で取り入れるとはおもわんかった。
916 名前:デフォルトの名無しさん [2006/03/20(月) 02:40:45 ] えっ、だいぶ前からGroupLayoutってSE6で導入するって話を聞いてたんだけど漏れの勘違いだったのかな・・・?
917 名前:デフォルトの名無しさん [2006/03/20(月) 02:48:15 ] SE 6 毎週内容かわってるのですか?
918 名前:デフォルトの名無しさん mailto:sage [2006/03/20(月) 03:03:05 ] リリースの追い込みに向けて減っていく傾向はなくもないw
919 名前:デフォルトの名無しさん mailto:sage [2006/03/20(月) 03:53:33 ] >>916 いや、だいぶ前はSE6からって話だったけど、すぐにSE7からってことになってた。
920 名前:デフォルトの名無しさん mailto:sage [2006/03/21(火) 00:51:33 ] Java SE 6でGroupLayoutが取り込まれても、Visual Editorが対応してくれないと・・・。
921 名前:デフォルトの名無しさん mailto:sage [2006/03/21(火) 01:05:09 ] まだベータなんだから、eclipse 頼みの軟弱なやつ向けではないだろ。
922 名前:デフォルトの名無しさん mailto:sage [2006/03/21(火) 01:05:43 ] Bug 6375459 に Origato ってコメント付けてんの日本人?
923 名前:デフォルトの名無しさん mailto:sage [2006/03/21(火) 01:43:08 ] >920-921 NetBeans使えばいいじゃない
924 名前:デフォルトの名無しさん mailto:sage [2006/03/21(火) 10:50:07 ] >>920 VisualEditorでバリバリGUI開発しているのか? 使い心地はどうだ? 感想頼む。 NetBeansが軽いと聞いて使っているのだが VEは反応があまりにもおそすぎて使ってない。 プラグイン入れすぎというのもあるだろうけど
925 名前:デフォルトの名無しさん mailto:sage [2006/03/21(火) 11:35:17 ] VEの問題は重さじゃないと思うな…とにかくスレ違いですね
926 名前:デフォルトの名無しさん mailto:sage [2006/03/23(木) 02:25:26 ] >>924 そうでもない。SprintLayoutにも対応していないし、機能は限定されてる。 GridBagLayout使うときはGUIでパラメータ弄れて便利だけど、 やっぱりソースを手で調節しないといけない時もある。 >>925 すまん。でもGroupLayoutとかが主流になったら直コーディングは難しくなるし、 話すときは使ってるGUIビルダと絡めざるを得なくなりそうな気もする。
927 名前:デフォルトの名無しさん mailto:sage [2006/03/23(木) 17:48:33 ] Java SE 6 Beta Maintenance Review公開 java.sun.com/javase/6/jcp/beta/ これは事実上J2SE 5.0仕様に対するメンテナンスレビューだとのことです。
928 名前:デフォルトの名無しさん [2006/03/23(木) 22:53:14 ] よくわからない 5.0に対するメンテナンスレビューという意味がわからない
929 名前:デフォルトの名無しさん [2006/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 名前:デフォルトの名無しさん mailto:sage [2006/03/23(木) 23:04:30 ] >>929 それ、5.0 からあるよ。例えば、バイトコードにカウンタ回すコードを埋め込むタイプの カバレッジツールとかを作る人が、より便利になるようにするためのパッケージね。 URLClassLoadeer とか、そーゆーのとは違う。
931 名前:デフォルトの名無しさん [2006/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 名前:デフォルトの名無しさん mailto:sage [2006/03/23(木) 23:29:44 ] 日本語の説明おいときますね。 ttp://java.sun.com/j2se/1.5.0/ja/docs/ja/api/java/lang/instrument/package-summary.html ClassFileTransformerが強力だが凶悪だと思う。
933 名前:デフォルトの名無しさん [2006/03/24(金) 00:08:37 ] >>932 クラスファイルを変換するって 同じパッケージ名.クラス名だが 中身はバージョンが異なるクラスに動的にかえるってことかいな? スクリプト言語や プロトタイプベース・オブジェクト指向言語にみられるような、 動的オブジェクト指向言語のような使い方ができてしまうのかねえ。 オブジェクトを生成したあとからクラスにフィールドやメソッドを追加できる みたいなことがJavaでもできてしまうってことかいな?
934 名前:デフォルトの名無しさん mailto:sage [2006/03/24(金) 00:24:53 ] >>933 EclipseのPleiadesプラグインが使ってるね。
935 名前:デフォルトの名無しさん mailto:sage [2006/03/24(金) 00:37:10 ] >>933 java.sun.com/j2se/1.5.0/ja/docs/ja/api/java/lang/instrument/Instrumentation.html#redefineClasses (java.lang.instrument.ClassDefinition[]) > 再定義では、メソッドの本文、定数プール、および属性の変更が可能です。 > ただし、再定義では、フィールドまたはメソッドの追加、削除、あるいは名前の変更、 > メソッドのシグニチャーの変更、あるいは継承の変更はできません。 > これらの制約は、将来バージョンで解消される可能性があります。
936 名前:デフォルトの名無しさん mailto:sage [2006/03/24(金) 00:52:12 ] >>933 InstrumentationにClassFileTransformerを追加しておくと、 クラスローダのdefineClassが実行される前に実行してくれる。 defineClassが実行される直前ではクラスのバイト列が既に解決済みなんだけど、 そのバイト列と対象のクラスローダがClassFileTransformerに渡される。 そのバイト列をClassFileTransformerで変換して返す事によって、 defineClassが本来とは違うバイト列で行われるっていうだけ。 で、GC可能なカスタムクラスローダで読み込んでいれば、 ロード済みのクラスもGCの対象になるので、GC後であれば再定義は可能だけど、 基本的には1度しか実行されないので、動的言語サポートとはいえない。 上でも説明が出てたけど、1度きりのロードだけなので、 コードカバレッジの計測とかアスペクトの組み込み等がいいかも。 OracleのTopLinkも使っていたような気がする。 あっ、でもプロパティ次第では動的に再定義も可能なんだけど、 Instrumentation関連で使用されるクラスは無理。 環境によってはサポートされない場合もある。 複数のClassFileTransformerを登録できるので、 オリジナルのバイト列 > コードカバレッジ計測機能付きバイト列 > アスペクト組み込みバイト列 > クラスローダでロード ってシナリオも可能。 TigerならApache BCELが内部に組み込まれているので、 それを使ってもいいし、俺はJavassistを使っている。 CtMethod#instrumentで、コードカバレッジの計測コードの追加が とても簡単なんだよね。
937 名前:936 mailto:sage [2006/03/24(金) 00:52:51 ] >>931 premainメソッドを実装したクラスの位置とか、再定義可能とか、 そんな感じのプロパティを記述したファイル(名前は忘れた)を 含んでいるJarファイルを -javaagent:<jar名>=引数 と言う風にjavaコマンドの起動オプションで指定すると エージェントが起動するよって話。 premainメソッドの定義クラスとかClassFileTransformerの実装などは、 別にJarに含む必要はない。
938 名前:デフォルトの名無しさん mailto:sage [2006/03/24(金) 01:00:45 ] ジョイスティックはいつサポートされますか?
939 名前:デフォルトの名無しさん mailto:sage [2006/03/24(金) 01:03:32 ] ジョイパッドの後ぐらいかな、たぶん。
940 名前:デフォルトの名無しさん mailto:sage [2006/03/24(金) 03:26:04 ] ライトペンはサポートされますか?
941 名前:デフォルトの名無しさん mailto:sage [2006/03/24(金) 08:12:28 ] ライトサーベルの後じゃない?
942 名前:デフォルトの名無しさん mailto:sage [2006/03/24(金) 09:19:37 ] >>934 あれはアスペクト指向を使っていると書いてあったと 思うんだが、Java5のそのクラスだけでまかなっていたのか
943 名前:デフォルトの名無しさん mailto:sage [2006/03/24(金) 09:29:49 ] >>937 > -javaagent:<jar名>=引数 思い出した。それがPleiadesで使ってたやつか。
944 名前:デフォルトの名無しさん mailto:sage [2006/03/24(金) 09:31:51 ] よくよく考えてみると、 フィールドやメソッドを動的に変更する意義って そうそう多くはないかもしれぬ。 Genericsを組み合わせてListやMapやSetなどをフィールドに入れておいて あとから追加することができるから。 メソッドについてはリフレクションでまかなう?
945 名前:デフォルトの名無しさん mailto:sage [2006/03/24(金) 12:03:59 ] >>942 アスペクト指向はプログラムの書き方の話だろ。 アスペクトの実現方法ひとつ。
946 名前:デフォルトの名無しさん mailto:sage [2006/03/24(金) 12:16:14 ] >>944 フィールドやメソッドを動的に変更できるってのも面白いけど 動的に変更すると、今まで検査したバイトコードも 全部再検査しなきゃならなくなるような。 そーいや、Mustang でバイトコードベリファイアが変更になったのって この辺の絡みもあるのかな、と妄想してみる。よく知らんけど。
947 名前:デフォルトの名無しさん mailto:sage [2006/03/24(金) 13:21:07 ] いままではJavassistやASMでやってたことが標準になるわけだね。
948 名前:936 mailto:sage [2006/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 mailto:sage [2006/03/24(金) 19:25:20 ] >>948 StackMapTable属性の間違いね。ごめん。
950 名前:947 mailto:sage [2006/03/25(土) 02:04:15 ] ありがdヽ( ´∀`)ノ
951 名前:デフォルトの名無しさん mailto:sage [2006/03/25(土) 02:08:50 ] サーバを止めることなくパッチを当てることが簡単になるってことかな プロセス間通信はまだ出来ないの?出来たら動的書き換えは強力なパラダイムだね スクリプトエンジンと連携させてサクッとパッチが当てられる
952 名前:デフォルトの名無しさん mailto:sage [2006/03/25(土) 10:25:26 ] >>948 com.sun.* って使っていいんだっけ?
953 名前:デフォルトの名無しさん mailto:sage [2006/03/25(土) 11:07:36 ] なんちゅうか、>>936 以外は書いてること無茶苦茶やね。。。
954 名前:デフォルトの名無しさん mailto:sage [2006/03/25(土) 11:07:37 ] 使ってもいいが、VM依存のオプショナルパッケージであること 将来のバージョンで保証されないこと これらをふまえてな
955 名前:デフォルトの名無しさん mailto:sage [2006/03/25(土) 11:26:40 ] >>948 >>946 のは将来のバージョンにおいて、 redefineClasses とかでフィールドやらメソッドの 追加や削除や変更が認められる場合の話ね。 ちょっと考えたら、実行時に NoSuchMethodError とか NoSuchFieldError 食らうだけだからバイトコード検査関係ないよな。
956 名前:936 mailto:sage [2006/03/25(土) 12:29:21 ] 動的にメンバを追加できても、コンパイル時点ではシンボル解決できないので、 意外と使い道に悩むことが多いかなと思います。 ただし、事前にインターフェイスが存在していて、 クラスにインターフェイスを動的実装させてメソッド追加すれば、 インターフェイスを経由して楽に利用できます。 動的に実装させなくても、プロキシを使うパターンもありですね。 それと、JakartaのBeanUtilsのようなリフレクションのラッパーAPI向けに 動的にメンバを追加するというのはありかなと思います。 このAPIって、Mustangでは多少の変更があるものの、 (確実な再定義可能判定機能とか・・・) Tigerから存在していてMustang特有の話じゃないので、 スレ違いかもしれませんね。 ダラダラと話を伸ばして、ゴメンナサイ。
957 名前:デフォルトの名無しさん mailto:sage [2006/03/25(土) 16:41:00 ] >>953 それでいいんじゃねぇの?
958 名前:デフォルトの名無しさん [2006/03/26(日) 12:05:27 ] なんだかちょっと難しいな。 つかってみないと良く分からないと言うか。 実行サンプル無いかな。 実例とか
959 名前:936 mailto:sage [2006/03/26(日) 13:39:07 ] さくらばさんのサイトとかいいかも。 Java In The Box ttp://www.javainthebox.net/laboratory/J2SE1.5/MiscAPI/Instrumentation/Instrumentation.html
960 名前:デフォルトの名無しさん mailto:sage [2006/03/26(日) 14:08:08 ] Mustang build77リリース build76 からの変更点 https://www.dev.java.net/files/documents/2817/31663/mustang-b77.html
961 名前:デフォルトの名無しさん mailto:sage [2006/03/26(日) 15:33:35 ] 今回かなりの修正箇所だね
962 名前:デフォルトの名無しさん mailto:sage [2006/03/27(月) 23:08:42 ] >>928 これ。 jcp.org/aboutJava/communityprocess/maintenance/jsr176/index.html JCPには正式リリース後にMaintenanceのフェイズがある。 Mustang(JSR 270)はまだ正式リリースすらされてないのにメンテナンスなのはおかしいんだけど、 これは名前がMustangのMaintenance Reviewってなってるだけで、実質的にはJSR 176に対する Maintenance Reviewなんだよってこと。
963 名前:デフォルトの名無しさん mailto:sage [2006/04/02(日) 13:09:35 ] Mustang build78リリース build77 からの変更点 https://www.dev.java.net/files/documents/2817/31952/mustang-b78.html
964 名前:デフォルトの名無しさん mailto:sage [2006/04/11(火) 00:22:14 ] Mustang build79リリース build78 からの変更点 https://mustang.dev.java.net/files/documents/2817/32495/mustang-b79.html
965 名前:デフォルトの名無しさん mailto:sage [2006/04/16(日) 15:54:08 ] Mustang build80リリース build79 からの変更点 https://www.dev.java.net/files/documents/2817/31863/latest_changes.html
966 名前:デフォルトの名無しさん mailto:sage [2006/04/26(水) 21:06:49 ] bugs.sun.com/bugdatabase/view_bug.do?bug_id=6415362 直ったらしい。 Mustang側にいつ入るのかな
967 名前:デフォルトの名無しさん mailto:sage [2006/04/26(水) 21:23:58 ] えぇ! なんだってぇ!? vをおすとクラッシュするって? しらなかった
968 名前:デフォルトの名無しさん mailto:sage [2006/04/26(水) 22:19:23 ] 4月頭頃に出したバグ(?)がb81で直ってた。なんか嬉しい。
969 名前:デフォルトの名無しさん mailto:sage [2006/04/26(水) 22:36:01 ] update7っていつでるんだろうねぇ・・・
970 名前:デフォルトの名無しさん mailto:sage [2006/05/04(木) 23:08:04 ] ttp://jroller.com/page/gfx?entry=java_se_6_on_mac MacOSXもキタコレ
971 名前:デフォルトの名無しさん mailto:sage [2006/05/05(金) 16:13:15 ] 10.5でサポートすると思ってた。
972 名前:デフォルトの名無しさん mailto:sage [2006/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 名前:デフォルトの名無しさん mailto:sage [2006/05/06(土) 03:34:46 ] いつもJava対応で後手に回るAppleがついに・・・ ちょっとだけ追いついた?
974 名前:デフォルトの名無しさん mailto:sage [2006/05/06(土) 05:04:55 ] Mustang build83リリース build82 からの変更点 https://mustang.dev.java.net/files/documents/2817/34219/mustang-b83.html
975 名前:デフォルトの名無しさん mailto:sage [2006/05/08(月) 06:38:08 ] >>972 Cocoaのbindingの部分、 JNIとjavaで書かれているんだと思うけれど、 辞める引き替えに、ソースを出せないのかな?
976 名前:デフォルトの名無しさん [2006/05/15(月) 17:33:38 ] J# スレがとっくの昔に落ちてしまったからここで聞くけど、 J# のライブラリが JDK 1.1.4 互換だったりするのは なにか Sun との間のライセンスの問題? それとも単に Microsoft が Java 2 のライブラリを インプリメントするのをサボってるから??
977 名前:デフォルトの名無しさん mailto:sage [2006/05/15(月) 18:08:57 ] >>976 【初心者】Java質問・相談スレッド85【大歓迎】 pc8.2ch.net/test/read.cgi/tech/1147315998
978 名前:デフォルトの名無しさん mailto:sage [2006/05/15(月) 23:52:16 ] >>976 Java2の時代は既に決裂していなかったっけ? さぼっているという以前に有名な闘争に発展していたはず。
979 名前:デフォルトの名無しさん mailto:sage [2006/05/16(火) 20:10:33 ] >>976 Sun に勝手な拡張すんなボケって言われたから。 拡張できないんなら自分で作るよハゲっ つーことで C# を発明。 あとは >>977 のスレへ逝って。
980 名前:デフォルトの名無しさん mailto:sage [2006/05/17(水) 00:29:59 ] >>979 一行目と二行目の間に ゲイツ「Javaは人類の資産であってSunの私物じゃない」 を入れといてw
981 名前:デフォルトの名無しさん mailto:sage [2006/05/17(水) 00:35:01 ] >>980 おれ、あの問題についてはJava仕様と互換性と保たなかった MSに問題があったと思うんだよね。 互換性を保った上で、独自拡張を追加したって形では無かった からねえ。
982 名前:デフォルトの名無しさん mailto:sage [2006/05/17(水) 01:55:40 ] JNIに危機感持ったからねぇ
983 名前:デフォルトの名無しさん mailto:sage [2006/05/17(水) 03:36:55 ] (・∀・)ゲヘラヘラ マクネリに言わせれば・・・「もちろんMicrosoftのものでもないのは言うまでもない」ww
984 名前:デフォルトの名無しさん [2006/05/17(水) 21:35:20 ] 独自にやりたいんなら、スクラッチからコード組みゃあいーのに、 Sunとライセンス交わして買った(?)コード勝手に拡張したからねぇ。
985 名前:デフォルトの名無しさん mailto:sage [2006/05/17(水) 21:40:28 ] たしかMS JVMってSunのコード使ってないんジャマイカ? 少なくともVMのコアはMS製。当時は一番速かった。 ライセンス問題は「Java」という商標の問題だったはずだが。
986 名前:デフォルトの名無しさん mailto:sage [2006/05/17(水) 22:08:09 ] MSの除くと一番普及してたVMはシマンテックだな JITのおかげでベンチマークは早かったけど 例の起動時フリーズしてるのかと思うようなやつで Javaの地位を大きく下げることに成功した 1.1時代は大量にあったVM実装も1.2以降はほとんどなくなり SunのVMが普及し始める あの起動の遅さとかあったからHotSpotがでてきたんだけどな
987 名前:デフォルトの名無しさん [2006/05/17(水) 22:38:11 ] どうしてもJavaでなきゃ駄目な案件なんてない。 たいがいはPHPで済むし、それが駄目ならC++で組む。
988 名前:デフォルトの名無しさん mailto:sage [2006/05/17(水) 23:15:23 ] >>986 Javaの地位を大きく下げることに本当に成功してんのかとw Google Trendを見るとJavaの地位が高いのは明らかだし。
989 名前:デフォルトの名無しさん mailto:sage [2006/05/17(水) 23:15:27 ] >>987 いきなり、なんの話?
990 名前:デフォルトの名無しさん mailto:sage [2006/05/17(水) 23:17:07 ] >>988 俺は >>986 じゃないが、 あのときは、ボロカスだっただろ?
991 名前:デフォルトの名無しさん mailto:sage [2006/05/17(水) 23:23:39 ] ふーん。 今が早ければいいや。 それより、次スレどうしようっかな。 再利用できるスレってあるかな。 無ければ立てちゃおうか。 1.5のスレと一緒にまとめたタイトルにしよっか?
992 名前:デフォルトの名無しさん [2006/05/17(水) 23:24:27 ] >>989 次世代Javaはいらないという話でつ
993 名前:デフォルトの名無しさん mailto:sage [2006/05/17(水) 23:27:39 ] >>991 むしろ、1.7 dolphin とまとめた方が良いような?
994 名前:デフォルトの名無しさん mailto:sage [2006/05/17(水) 23:52:45 ] >>987 いやマジでPHP勘弁して。 PHPがというより、PHPプログラマのあの、保守性とか見通しの良さとか 考えてない、でもおれはphpでプログラマやってんだぜ、というのなんとかして。 はっきりいって、その辺でブイブイ言わせてるphpプログラマより、「やっと MVCが分かってきました」というJavaプログラマのほうがはるかにマシ。
995 名前:デフォルトの名無しさん mailto:sage [2006/05/18(木) 00:14:23 ] 「たいがいはPHPで組める」って、自分がその程度の仕事しかしてないんだよな。 業務アプリをPHPで組むっていうのは、システムなめてるとしか思えん。
996 名前:デフォルトの名無しさん mailto:sage [2006/05/18(木) 00:30:09 ] 次、どうする? Mustangで立てる?もう、早漏してDolphinで立てる?
997 名前:デフォルトの名無しさん mailto:sage [2006/05/18(木) 00:45:06 ] >>995 あなたさまはどんな仕事やってんの?
998 名前:デフォルトの名無しさん mailto:sage [2006/05/18(木) 01:01:19 ] 次世代Javaの動向 2でいいんじゃね
999 名前:デフォルトの名無しさん mailto:sage [2006/05/18(木) 01:02:24 ] これは? 【JavaFive】C#からJ2SE5.xへ進化【TigerShot】 pc8.2ch.net/test/read.cgi/tech/1094891986/
1000 名前:デフォルトの名無しさん mailto:sage [2006/05/18(木) 01:04:24 ] 次スレはこれにした。 次世代Javaの動向 2 pc8.2ch.net/test/read.cgi/tech/1147881822/
1001 名前:1001 [Over 1000 Thread] このスレッドは1000を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。