.NET vs J2EE

IT業界の覇権争いにおいて今後最も注目されるのが
ServerSide分野だろう。現在のところSUNを中心と
するJavaが支配的だ。一方PCsoftからServerSide
への路線変更を急ぐMicroSoftはSUNからの訴訟に
よりJavaを捨てざるを得なくなった。しかし同社幹部
の「Meなんかどうでもいい。重要なのはDatacenterだ」
といった発言からもわかるようにServerSideへの進出
を重視している以上なんらかの対策を打たなくてはならない。
そこでJ2EEへの真っ向勝負として.NETをぶつけることになった。
CLR、C#、SOAPと魅力的な要素も多い。
これに対してJ2EEの切り札はEJBだ。

勉強すること多すぎ。どっちが普及するのだろうか。
（覚えるのはそっちだけにしたいしぃ〜）

>1
どれも使うだけならたいして難しくありません。

。。。という印象をもてるような人間以外は早いとこ
引退して欲しいです。

片方はでてもいないのに・・・

βがあるさ。

.net をインストールした。
これから試そう。

.net まるで分からん。
サンプルをコンパイルすることすらできん。
どれがコンパイラ？
これってコマンドラインで使うんでしょ？

20分ぐらいでねを上げるな

>>6
csc.exe, vbc.exe, jsc.exe

>>6
Ｃ＃の入門書的なものを買え。
売ってるだろ。

どっちもやれ。

>>1
１に限らないけど、C#にしても.NETにしてもＭＳだから騒いでるんだろ？
Javaの方はもう世に出てるんだし、そろそろＭＳに踊らされるのはやめにしない？
何でもいいから競合できる環境をメジャーにしないと、ますますひどい世界になりそうだよ。

サーバサイドでのJava独占ってのも、SUNだからなあ・・・。

>11
確かにMSだからっていうのはあるかもしれないが、JavaをSUNが
握っていることに不満をもってる企業が多いのも事実。
C#は標準化団体に提出されてるし標準化されればMSに踊らされてる
とも言い切れないのでは？
それにサーバー業界では今のとこSUNのが強いから競合できる環境
っていうのはこの場合逆に.NETを指すんじゃないの？

最近CからJavaへ転向したプログラマ。Javaのクラスライブラリを見ていると、
あれで一つの世界が出来ていることが分りました。なんていうか、UNIX/Cを
超えるものというか。。。
ところで.NETもそれと同じかもしくはそれより大きな世界を目指しているのですか？
また、MFCをUNIXに移植するという話はどうして出なかったのでしょうか？
私が知らないだけ？

>CLR、C#、SOAPと魅力的な要素も多い。

C#は知ってるけど、他はなに？

標準化されれば、ほんとに踊らされずに済むのかなあ。
クライアントであまりにも強すぎるんだから、
サーバでは同じ事になってほしくないな。
どうせ牛耳られるならＭＳ以外の会社の方がいい。

CLR:
Java のバイトコードのようなもの。Java と違って言語を選ばない。
と、いうことになってるけど
きっと C# と VB ぐらいだろうな実装されんのは。

SOAP:
XML と HTTP/SMTP を使ったリモート関数呼び出し。
CORBA のラッパみたいな感じで使う、らしい。
パフォーマンス悪そうだからすぐに消えるのでは。多分。

さっきJDK1.3をいれたら、1.3にはRMI-IIOPってのがあるのね。
RMIでCORBA-IIOPとインターフェースが取れるってのは楽でいいね。

>17
CLRはVMじゃないのかな。MSはCLR用実行ファイルへのコンパイラを
C#用、VB用その他いろいろ作るっていってる。（ほんとかな）
JVMだって別に言語は選ばない。JVMマシン語にコンパイルする処理系が
今はないだけ。
だれかつくってみたら？GCでメモリ管理するので、CやC++のソースを
コンパイルするわけには行かないだろうけど。

CORBAのラッパがSOAP？CORBAをラップするの？オブジェクトコールを
実現するための、全く別のアプローチじゃないかな？

CLRは、19さんの言うようにVMです。バイトコードはILコードと
対になってますね。
JavaVM上の別言語と言えば、smalltalkがあったはず、と思いサーチしてみたら、
http://www.objectlink.co.jp/PradaSmalltalk/PradaSmalltalk-JPN_1.html
というのが引っかかりました。多分ほかにもあったと思うけろ。

SOAPはCORBAよりも機能的にはずいぶんシンプルです。
というか『こんなもんで大丈夫か？』という不安が浮かびます。
とはいえ、DCOMやCORBAを使うのは大袈裟だな、という場合には
非常によいソリューションだとも思いますね。
Webとの親和性も高いし。実際やってみても簡単だったし。

「Runtime」なんだから当然Javaで言うrt.jar相当も含んでる訳だが。
まぁJavaで言うならJREがCLRに該当すると思えばいいんじゃない?

.NET SDK(Beta)にはCLRサポートされたcl.exeが入ってるので、C++から
CLRのクラスを使う事もできるよ。文字列UnicodeだからいちいちL"hoge"
とか書かなきゃいけなくて面倒くさいけど。

ただ、サンプルのC++コード見ても自分でdeleteしてないんだよね。
CLRのクラス使う場合はC++からであっても勝手にGCされるという事なのか
まだいまいち理解できてない。

>>14
MFCはばりばりWin32に依存してるから、UNIXに移植するのは厳しいでしょ。

つーかX Window System自身はボタンだとかスクロールバーだとかという物すら管理
してないからGTK/QTといったToolKitが必要な訳で、MSがそれらを利用してMFCを実装
する事はないだろうし、かと言って新たにToolKitから作るのも無駄だし。
何より、MSがUNIX向けに積極的に動く理由自体無い訳で。

DCOMはどっかの(MSと仲がいい)会社が一部のUNIX(HP-UXだったかな)に移植している
という話は聞いた事があるけれど、実際に見た事も使っているという奴も聞いた事
ないね。
# まぁDCOMもまずレジストリサービスを移植しないと実現できんからなぁ...

割とみんなまともなこと書いてる。
プログラミングでいうと.NETのきもは、ASP.NET(ASP+)だ。
ちゃんとわかっている人は、ほとんどいないと思うけれど、これは、かなり、
強力なコンセプトを持っている。Visual InterDevで発表されたデザインタ
イムActiveXコントロールを、かなり、パワーアップしたものなんだけど、
InterDev同様、ASP.NETも失敗するような気がする。

>>2さんへ
>どれも使うだけならたいして難しくありません。
>。。。という印象をもてるような人間以外は早いとこ
>引退して欲しいです。

で、その人たちが引退して不足した労働需要を、2さんが寝ないで働いて補
ってくれんの?
新しい環境で、ちゃんと動作するプログラムをつくれるようになるまでにな
るのって、やっぱり大変だよ。だって、どの環境も、ちゃんと動かないんだ
もん。

ﾃﾞﾀﾗﾒ書いてスマン

ASP+はJava（servletやJSP）に対してなにかアドバンテージあるの？
なにもなかったらそりゃ失敗するよな。

ASP+は現時点のサーバーサイドJavaとは比較にならないくらい
先進的なアプローチをしている。
ようやく、一般化してきたJSPだが、Actve Server Pagesが、
3年も前から同じレベルのパラダイムのものを実用レベルで提供
してきたことを思いだしてほしい。

だけど、ASP.NETって、Webアーキテクチャの本質からずれてい
るので、成功しないと思う。

しかし、SUNはもう少し日本語化（特にドキュメント）に力入れないと．．．
MSサイドは日本語化早くて、英語ドキュソプログラマは全部そっち行くと予想。

開発環境の優れたＯＳが勝利する。

>>28
じゃあ、Mac OS Xも勝利する可能性がッ！？

それは無い。>29
５年前ならいざ知らず。

>>27
でも、.NETは、まだ発売もされてないし、サーバー側でMSが勝つ理由
はないでしょ。

>>26
JSPをちょっと擁護。
JSP は servlet 内から割と柔軟に呼び出すことができる。
servlet を介して二つの JSP を連結するとか。
ASP/COM の枠組みだと、servlet (=MVC の C )に
相当する部分がなく、ページ制御のコードを ASP に埋めこむ必要がある。
servlet/JSP/Bean の枠組みだと JSP は
純粋に HTML のテンプレートとして利用できて見通しが良い。

というか servlet から JSP を呼ぶように 何かから ASP を
呼べないんだろうか。と、ASP を使っていていつも思う。
別の発想が必要?

#あと ASP+ の資料のありか求む

>>32
この辺?
http://www.microsoft.com/japan/developer/net/aspplus/dnmag_aspplus.asp

CLRは、SunがなぜJAVAという言語ではなくVM上のバイトコードを規格化
しなかったのか、ずっと疑問視されてた部分をMSに取られた格好だね。

MSは妙に開発者を大事にするところがあるから、ライセンスは緩いものに
なると思う。そうなるとCLRはUnix系OS上にも実装されるのは必然。
そのときJAVAはどうなるんだろう？

Unix系のOSに実装されてもどうせWindowsのCLRはそのうち仕様拡張して
互換性が取れなくなるだろーね。とゆーかMSはマルチプラットホーム
には興味はないのでは。以上いいかげんな推測でしたー

>WindowsのCLRはそのうち仕様拡張して互換性が取れなくなるだろーね。
そこなんだけど、ECMAが絡んでるんだよ。ということはMSの勝手には
出来ないってことなんだよね。

C#とCLRをさんざん普及させておいて.netのフレームワークで儲ける
つもりなのかな？

どう考えてもJavaの構文の方が綺麗だと思うのはおれだけ？

LISPの方が綺麗。>37
と煽ってみる。ACLマンセー

swich文のFALLTHROUGHができないつーのはなぁ...

Perlも使えるようになるのかな？
(ところでPerlはなんでswitch文がない？、関係なくてすまそ)

>>39
いやいや、出来なくしたのは英断。あれはバグ要因になりがちだから。
かといって、同様のことをgotoでしろっていうのもなー。そっちのほうが
明示的でいいとはいえるけど。
まあMSは昔からgotoをそれほど嫌ってはいないから、違和感はないれすね。
Javaがgotoを排したのと対照的。
んで、C#は、switchでstringを扱うことが出来るけろ。これは便利。

>>40
perlにswitch文がないのは、ブロック文{}でlastを使えば同様のことが
フレキシブルに出来るからですね。そういうやり方に慣れたほうが
よろしいとの判断から、あえて作らなかったんでしょう。

スレッドの趣旨から外れていくけど、
javaもラベル使ってブロックのケツにbreakできた気がするなあ。
gotoの替わりだとかいって．．．

Javaもラベル付きbreak出来ますね。逆にC#は出来ないんで、ちょと悲しかった。
まあJavaはswitch文あるんで、switchの代わりにラベル付きbreakでは書かないと思う・・。
たとえばこういう
SWITCH:{
if(a==1){ r=1; break SWITCH; }
if(a==2){ r=2; break SWITCH; }
if(a==3){ r=3; break SWITCH; }
}
でも、条件の部分が自由に書けるんで、こんな使い方を積極的にしてもいいかも。
Javaはbreak,continueで、Perlはlast,redoの対なんだけど、Javaの場合、
continueはループにしか使えないのがPerlと違いますね。
（今日やるまで、Javaのbreakもループにしか使えないと思ってた）
同じC系統の言語とはいえ、いろいろ違いますね。

言語の話もためになるから同時進行してもらって構わないが
本題について。
1がJavaの切り札って言ってるEJBなんだけど、書籍とか探しても
ないし、javaの雑誌にいくらか書いてあるけど、どうもわからん。
だれかEJBについて簡単に説明してはくれないかい？

雑誌の特集でもわからん場合、どう説明してほしいんだ？

使う側からは、別のVM上のオブジェクトが、
あたかも同じVM上にあるかのごとくに使えるというもの。
しかも、自分でJavaで書いたクラスとかと同じように使える。
別のVMがネットワークを介したりした別のマシン上にあれば、
それこそ、通信していないかのように（まあ、時間はちょっとはかかるよ）
使えるので、便利便利、って感じかな。

作る側から言えば、完全にJavaオンリーで書けて、
なおかつ、その手のオブジェクトがもつであろう基本的な機能、
セッション管理とか、SQLを使ったDBへのアクセス、
それらのリソースの確保や解放といったかなりの部分が
コーディング無しで実現する（まだ、発展途上だが、それでもかなり楽）。

いままでクライアント／サーバで苦労してきたのが馬鹿みたいな感じ。
だって、全部Javaで書けちまうし、ずっとNT上で開発して、
客のところのソラリスとかリナックスとかで動いちまう（しかもコンパイルはNT上）。
ここだけは、.NETには真似できないだろうな。

でも、確かにEJBは「切り札」かもしれないが、
J2EE自体はEJBを使わないWebアプリケーションも含めた総合的なもの。
単独でリリースされてたServletやJSPの開発環境も、
だんだんJ2EEとして統合されつつある感じだな。
もちろん、個別の開発も可能だし、まだまだ、
JSP、Servlet、JavaBean（EJBではない）っていう組み合わせでも、
小規模の開発では十分魅力的な開発が可能だと思う。
大規模なシステムへの運用しながらの移行なんていうのも可能で、
そこで、JavaBeanをEJBに入れ替えたりできれば、もう最高かな。

間違えた。46の名前は45だ。
それとも>44ということでもいいや。

>45 >46 ｻﾝｷｭ
ところでhttp://www.jboss.org/は使えるのかなぁ？

やっぱＪａｖａか。

.NETの肝は、CLRでしょう。
バイトコードの統一とゆう開発者にとって感動的な仕様。

後発であるゆえに明らかにＪＡＶＡよりも良い仕様になってると思う。
どれだけ早く、多くのプラットフォームにCLRを供給できるかが
.NETの成否を決めると思う。

言語のＣ＃は、おまけ的な物だと思う。
.NETとjavaの大きな違いは、開発者が言語を選べる事
ｐｅｒｌやＶＢが既に．ＮＥＴ対応を表明している。
利用者の多い言語を取り込む事は、開発者を増やす事になり
普及を早める。

ある意味強制オブジェクト指向言語のjavaを
全ての開発者が使うかな？

この際、java（言語）もCLRに対応させてもらうといいなぁ。

>>50
でもJavaのバイトコードだって理論上は言語に依存しないだろ？
今のところ対応してる言語があまり出てきてないだけで。

分かりやすく言うと
・JAVA
バイトコードの統一
プログラム言語の強制

・.NET
バイトコードの統一
プログラム言語は自由

仕様的には、間違いなく.NETの方が優れている
じゃなきゃ今更ださないでしょ。
問題は、CLRの普及のみ。

>>52
いや、だからJAVAにはプログラム言語の強制は無いんだって。

でも結局.NETバイトコードに対応する処理系は
もともとの言語としての性格よりも.NETとしての性格を強く持つような気がする。
ひところはやった"なんとか2c"みたいな感じで。まああれよりは便利だと思うが。

JAVA-VMはな。>53
それと厨房の評論なんか聞きたく無いんだけど。
言語なんか適材適所なんだからなんでもいいだろ。

>>51
理論上はね。
sunは、その仕様を公開する事をして来なかった
出来なかったと言うべきかも知れない。

何故なら、それを公開すると逆コンパイルを容易にするからです。
逆コンパイルが容易では、いくら開発しやすくても
開発者の権が守りにくく、それを使いにくくなります。

.NETは、その問題をクリアしたようです。

「クリアしたようです」ってどんな風に？
ちゃんと最後まで書け。

>>57
何かで読んだけど忘れた(笑)
それぐらい自分で調べてくれ。

だったら無責任な事書くな。
ちゃんと自分の言ったことに責任持てよ。クズ

忘れたんなら、おまえがもう一度ちゃんと調べて最後まで書け。

>>59
出来るだけ自分で調べるのは、プログラマの常識でしょ？

とにかく逆コンパイルされにくいようになってるんだってさ
俺には、逆コンパイルされにくいって事が重要で
それをどうやってるかには、あまり興味が無かったんで
もう忘れたよ。

＞61
技術の評価を自分でやるのもプログラマの常識だと思うが……

>56=58=61
あなたが出した話題でしょう。
ちゃんと書いてください。
できないなら56の発言を撤回してください。

んじゃ撤回でいいや（笑）

>>62
＞技術の評価を自分でやるのもプログラマの常識だと思うが……
自分で評価して勝手にここに自分の意見を書いただけさ。

自己満足ですハイ。
人の為に調べて書くほど暇じゃない。
以上

.NETは逆コンパイルが容易に出来るとか書かれてるぞ。
http://www.zdnet.co.jp/eweek/0007/17/00071701.html

.NETってあれじゃろ？
ホームレスが儲かりまくって美女と万札風呂に入るってやつ。
金が儲かり、あといい女ともやれる。とにかく凄いんじゃよ。

俺が読んだ物には逆コンパイルされ【にくい】って
書いてあった。
javaに比べたらされにくいんじゃない？
javaだってかなり逆コンパイルされやすいと有名な割には
その手の物あんまり出回ってないし。

中間コードだから、普通のアプリを逆アセンブルするよりは楽だろうけどね。

cocoaだっけ？

>>56
出来なかったんではなく、「必然性が無い(Javaで全部まかなえる)」と
言ってやらなかった＆外部がやるのを許してないだけでしょ。

URL忘れたけどBorlandの奴が「Javaがオープンなんて大嘘だ」とかぼや
いてたし。

>>68
そりゃ、公に配るとまずいじゃない。地下系ツール探すと結構引っかかるよ。
goggleのcacheに残ってる事もあるし。

「JavaVM仕様」とか言うそのものずばりの本があるような
気がするが…
しかも、ネットでも本文が公開されていたような気が・・

.NET Framework SDKに ILDasmっていう逆アセンブルするツールが
付いているくらいだから、その気になれば逆コンパイルも
容易にできちゃうんじゃない？

ブラウザも何らかの仕様変更があるのでしょうか？
M$はブラウザ市場も事実上独占しているのですから、
そのメリットも生かしてJava退治に励むことでしょう（藁

そういうことするなら、UNIX版IEを出してほしい（ﾜﾗ

ようするに56の発言はデタラメということでいいか？

>>74
是嫁
http://cocoa.2ch.net/test/read.cgi?bbs=unix&key=976510937

あああ、分った。
56の発言の事ですけど、56さんはJavaPressの吉田弘一郎氏の記事を
読んだのです。多分。
そして、そこには確かにJavaの「バイトコードの守秘性」の問題が取り上
げられています。
そして、.NETの場合ですけど、３種類のJITモード、標準JIT、econoJIT、
PreJITがあります。このPreJITを指して吉田氏は
「通常のcompile&linkで、WindowsならばEXEファイルを生成します。
これを用いれば逆コンパイルを阻止できます」と書いているのです。
と言うわけですが・・・・、ちょっと違うようです。
MSによれば、PreJITは、「インストール時にILコードをコンパイルし、
ローカルディスクに保存させておくツール」だと。
この説明だと、プログラム配布時にはやはりILコードを流すということになり、
コード守秘性は高まりません。
意外でしたが、(.NET SDKインストール時)すでにPreJITは使われています。
WINNT下にあるAssenblyディレクトリに、多くのモジュールがキャッシュされてて、
システム用のモジュールがいくつかPreJITタイプになっています。
ここの領域は、キャッシュ専用領域みたいなもので、取り出したりできません。
こういう使われ方をする限り、PreJITは、コード守秘性には関係ないのです。

ええと、Javaの場合の逆コンパイル問題は、またこれはこれで面白い
んですけど・・。

>>77
そう、たぶんそれ。
つまり.NETならば一度作って、ILコードで配布がイヤならば
後はそれぞれのハードに合わせて
最終実行ファイルにしてから配布って事も可能なんだと・・。

結構オープンソースってあるけど、コード守秘性が無くなると
やっぱイヤだしなぁ・・。

流れがオープンソースになって行けば
ソフトを売って儲ける時代が終わるんだろうなぁ。

>>70
Javaの逆コンパイラって実は結構あるのかな？
なんてツール？

>79
俺が知ってるのはMochaってやつ
>78
そういう話だったらJavaもNative-compilerがでてきつつある。

で.NETフレームワークがWindows以外のOSに移植される可能性はあるのか？
そらりす、HP-UX、linux、macOS。。。。

吉田弘一郎がJavaPRESS最新号で、Javaのネイティブコンパイラについて
書いてます。
「いろいろあるよ。最近JETという優れたコンパイラができたよ。
でもSUNが作ってないのはいただけないよ。」
という感じでしょか。
確かに80さんが言うように、ネイティブコンパイラはあるんですけど、
本家のSUNが「Write once, run anywhere」を標榜し、PureJavaを
強調してるために、ネイティブコンパイラは日陰にいるようです。

んで、そのJETですけど、以前私も使ったことがあります。インストールにスゲー
時間がかかります（クラスファイルをコンパイルするため）。
非常に優秀だと思います。
http://excelsior-usa.com/home.html

ネイティブコンパイラに対する根本的な疑問はライセンスについてですね。

javaのコアパッケージは、ネイティブにコンパイルされるのですか？
もしされるとすれば、それは許される行為ですか？もしされないとすれば
ネイティブ化されるのは自前のコードのみですか？

>非常に優秀だと思います。
他のランタイムに依存したりしないのでしょうか？
exeのサイズはどれくらいになりますか？

ってことで、今ダウンロードしてます。

コアパッケージは軒並みコンパイルしてますね。
ですから、swingもRMIも問題なく動きます。
自作のSwingアプリをネイティブ化するのも、とても簡単でした。

ライセンス・・・そうですね。excelsirのページを見ても、
そういった記述を見つけることは出来ませんでした。
（見落としてるかもしれませんが・・）
SUNでは当然、JDKに対して修正、逆コンパイルをしちゃいかんよ、
って書いてます。
ということは、私はインストールしただけで違法な行為を
している可能性が・・・。(汗
excelsirの行為は、違法かどうかはっきりしません。
まあSUNが訴えたりするというのはちょっと考えられませんけど。
なんというか、その辺の問題は難しいですね。

JET

サンプルのコンパイルがうまくいかない奴がある。使い方がまだよくわかりません
が、
今自作のアプリをコンパイルしています。やたらとコンパイルに時間がかかりま
すね。動くかな？サードパーティのライブラリ（ソースなし）もガンガンコンパイ
ルしてて、ライセンスいーのかなー（わら。

やっと半分だ。

動いた動いた。でも、メニューやラベルの日本語が化け化け「□」に
なってる。sun.io.UnknownCharacterException これはどうやって
直すのかな。 あとバイナリーが7MBもあるよ。多分これはPerfectと
かいうオプションで小さくなるのかな？僕の目的は主に、JRE不要に
することなんだけど、7MBじゃ大して変わらないサイズだもんなー。

JETのウェブサイトだと、sun/io/ByteToCharSJISと CharToByteSJIS
をモジュールに組み込めっつーんだけど、組み込んだけどだめだよ。
なんか別の奴かな？

う、文字コード・・・。そういえば私のアプリは日本語がはいってませんでした。
んで、やってみれば、確かに□□□□って書かれますね。あうう。

-lookup = *.class = c:\jdk1.3\jre\lib\i18n.jar
!module JTestFrame.class
!module sun/io/ByteToCharSJIS.class
!module sun/io/CharToByteSJIS.class

って、やってみても、変わりません・・。
よーわからんので、Excelsiorに質問メール出してみましたけど・・。
あとで友達にも聞いてみよ。

その文字化けは sun/io/ByteToCharMS932, sun/io/CharToByteMS932 を
includeしたら直ったよ。 あと、これは僕が悪いんだと思うけど、
JNIが動かないよ。exeが7MBあるんだけど、これどうやって最適化する
のかな。

今、PERFECTモードでコンパイルしてるんだけど、死ぬほど時間かかるね。

MS932ですか。。。あ、出来た、サンクスです。

+perfectオプションやってみました。
猛烈に計算しながら・・・・・・・とっても大きいファイルができた！
なんやねん！？

perfect+ だと、JDKのコアクラスもネイティブコードに変換し（え？
今までしてなかったの？）exeのみで動くバイナリが作れて、さらに
最適化でサイズが小さくなるらしいんだけど...私のプロジェクトは
Perfectモードではコケてコンパイルできませんした。

結局JRE込みのインストーラ作った方がいいのかなぁ...

Javaアプリの配布方法について、別スレたてました。

http://piza.2ch.net/test/read.cgi?bbs=tech&key=980500769

JET使ってみたけど、それほど速くなったとは思えない。
メモリ消費量も変わらない。
SwingSet2でしか試してないが。

JAVAのバイトコードが公開されていないと思っている人がいるみたいだけど
公開されているから、C++のJAVAコンパイラのguavacとかがあるし、
Super CedeのようなJAVAコンパイラがある（あった）わけでしょう。
Spuer CedeはサンからJAVAのライセンスを受けておらずJAVAコンパイラ
を作り、exeファイルを作る機能まであった。
http://java.nikkeibp.co.jp/Java/News99/0120SuperCede.html
Super Cedeはもう無いけどね。
言語がJAVAに制限されているという意見もあるが、確かに現状はそれに近い。
一応、こういうのもある。
http://java.nikkeibp.co.jp/Java/News99/0913Halcyon.shtml
Visual BasicをJAVAコードに変換するツール。
JAVAコードが逆コンパイルされて危ないというが逆コンパイル防止技術は
すでに商用化されていてたとえばJBuilderの商用版は標準でその機能が
ある。
http://www.borland.co.jp/jbuilder/prodinfo/jb40feature_matrix01.html
に、「Javaソースコードの漏洩を抑止するソースコード隠蔽機能」と
いうのが書いてある。
逆コンパイル防止ソフトが単独で売っているのかどうかしらんけど。

>>96
逆コンパイル防止機能については、以前調べたけろ。
いわゆるObfuscationという奴だね。アプリもいろいろあります。

とはいえ、なかなかこれも単純じゃないよ。
つまり、逆コンパイラメーカーもそれに対処したモノをつくろうとしてるから。

しかもVMベリファイアが、あまりいじったコードは通過させない。
（これは、アプレットできついというハズだけど、アプリケーションでも
同様だと聞いた。最近のVMはそうだという憶測・・・・。）

んで、JBuilderのは、あまり高度な事をやってくれないみたい。
ヘルプを見たら、シンボルを分りづらい名前に変換するだけで、
可読性を低めるためのもの。

それからSuperCede、吉田弘一郎の記事にあるんだけど、
http://www.instantiations.com/jove/product/thejovesystem.htm
に買い取られています。
このJoveにSuperCedeの技術がどのくらい導入されたかは不明。

>>95
JETアプリの速度だけど、種類によっていろいろ違うみたい。
吉田氏が試したLINPACKベンチでは、HotSpotより２倍強速くなったって。
Cに比べて１割遅いだけだから、こういうモノは優秀みたいよ。
（ハノイの塔は、６倍くらい速い！）
Cで組んだモノより速いものもいくつかあります。
まあ実際のアプリで試してみるしかないのでしょう。

#JET質問メール、速攻で返事来た。やっぱりあれで良かったですね。
#にしても、対応はとてもいいですね。

Ｃより速くなることは理論上ありえない。
例えネイティブコードで書かれているJavaVM内の機能を使ったとしても５分。
Ｃより速くなるのはＣのコードが最適化されていないから。
要するに技術力不足！

>>99
理論上、ってどういう理論か知らんけど、実際の製品は"理論上"で
動いてるワケではないので、なにが言いたいか分らんよ。
VC++の最適化が、そのアプリでJEDコンパイラの最適化に負けただけ。
まあ実際のCソースとJavaソースを見比べたワケじゃないから
詳細な部分までは分らんが。
つーか、JEDはx86バイナリを吐くっていうのを理解してるかな？
それで、なぜ理論上そうなるか説明してくれ。

＞JEDはx86バイナリを吐く
なんだネイティブコードなのか・・・
それじゃＪａｖａじゃないじゃん。

100でJEDはJETの間違いけろ・・・。

HotSpotは、ネイティブコンパイラじゃないけど、
実行時解析をするので、ものによってはCより速いものもあるよ。
いや、これは本当の話だから。
ちょっと調べてみるといいよ。

99はスレをあまり読んでないっぽいなぁ。

http://www.zdnet.co.jp/news/0101/26/e_jump.html

>>103
プロファイラの情報を反映できるからね
これは普通のコンパイラ言語ではできない

ASP+は言語非依存らしいが、
PERLで作ったCGIもそのまま使えたりするのだろうか？

http://www.activestate.com/Products/NET/Perl.html
現在のところは、サブセットみたいだね。

HTMLにWindows Formなコントロール埋め込むのって
セキュリティどーなってるんでしょう？

>>103
>HotSpotは、ネイティブコンパイラじゃないけど、
>実行時解析をするので、ものによってはCより速いものもあるよ。

まだ無いよ。
これから先もできるかどうか知らん。
あるって言うならソースを示せ。

>>109
caspol.exeでいろいろ設定できるらしい。

http://www.gotdotnet.com/iesourcing.aspx

>>111
この4. Beta1 Onlyってあるとこ、
どーゆーことが書いてあるんでしょう？ なんか重要っぽいし。
私のヘボイ英語力では読解不能ダス(T_T

>>110
誤解が生じてるかもしれないんであれだけど、
「ものによってはCより速いものもある」っていうのは、
「ベンチマークの種類によってはCより速いものもある」っていう意味だから。
ソースは、あーーーJAVA PRESS Vol.16のJET紹介記事にある速度比較
をみてね。まあやり方によって多少の変動はあろうけど、傾向としては
だいたいあんなものでしょう。
その中では、バブルソート、ヒープソート、Sieve、フィボナッチ
がCより速い結果を出してますね。（CはVC++6.0最適化してる）
もちろん、Cのほうが速いものもいろいろあるよ。

全然話は変わるんだけど、先日JETの会社からメールが来て、
「改良したからこれで試してみてくれ」というバイナリが入ってた。
やってみたら、コンパイルオプション無しで日本語が出るようになったけろ。
なんというか、辺境の駄目プログラマのメールに律儀に対応してくれる
のには、頭が下がります。（そのうち正式版にも反映されると思うのだけど）
http://excelsior-usa.com/home.html

ど素人ですいませんがJ2EEってなんですか？
javaのなんか？

>>114
Java2 Executable Engine.

（；´Д｀）

マーケティングで、どこの市場を狙うだけ

答え：Cより速くなる事が理論的にありうる。
CではコンパイルされたCPUコードを逐次実行していくだけだが
最近のインタプリタ（これにはJITやレイトバインドや含む）は
実行時において、最適な実行方法を測定結果などから動的に決定
できる。各種演算についても次元数の少ないものや繰返しを行う
処理において、CPUの分岐予測とは別に予測を行うことも可能。
Javaとは別の視点ではあるがCrusoeやintentも同様の着想が見られる

# あなたが思うほど世界はそこにとどまってはいない、コンパイル技術は
# 常にCPUに対しできるだけ短い命令を生成することを行うだけではないのだ。

その予測を行うにもクロックサイクルが必要だけどどうなの？
118さん！

どちらも同じプロセッサ上で動作させるなら、Ｃとの差をつける
ために導入した最適化アルゴリズムそのものをＣに実装してしまえば
同じになることはあっても遅くなることはないので
Javaのほうが高速なんてのは夢物語と思われ。
高速っていうより、Javaは定型化されたパターンにして
その部分を徹底して最適化することでカバーするってことなので
原理的に速いわけじゃない。
徹底して最適化されたＣコードは速いぞ。
JavaがＣより速いって言うのは
アセンブラよりＣが速い、って言ってるのと同じことだと思うが。

まま。クルーソーの論文でも読んでから話しましょう。（俺は読んでないが

別の答え
cpu単体のベンチマークではなく、「アプリケーションの実効速度」ではどうだろうか。
例えば、火事場で一人一人がバケツで水を組んで火を消すより、バケツリレーを行った方が効率がいい。
ランタイムがそのような高度なスケジューリングを行えば、マクロな意味でCコンパイラより速いといえよう。
そんな賢いランタイムは無いが。

最近はコンパイル技術が進歩して下手にアセンブラで書くよりCの方が速い
ってこともある。

>>122,123
つーか、言ってることは同じなんで。
原理的にはアセンブラ以上に高速なコードはないし
（当然ながらすべてのコードはアセンブリコードに落ちるから）
要はいかに作業工程を研究された最適化しやすいパーツに
分解するかの問題に帰結するでしょ。
Java がプログラミング効率を総合的に上げるのはあってると
思うけど、同じレベルまで統合されたアルゴリズムを使えば
結果は同じ。
だからこそ、アセンブラとＣの速度を比較するのがすでに
終わった議論のように Java とＣの速度を比較するのも
不毛だと思うけどね。

原理的にアセンブラより Java のほうが速くなるなら、
とても興味があるのだけど。（その技法に）

全部アセンブラで記述すれば最速だ、といっているのと同じ。
んな馬鹿らしいことはでけません。

どこをどう読めばそういう話になるのさ？
アルゴリズムの話をしてんだよ？
理解してる？

ま、いいや。そのうちＣ＃とJavaの速度差の話でも
同じ議論を繰り返すことになるんだから。
Ｃ＃とJavaどっちが速い？ってね。
どっちみちJava擁護派のスレなんでここらへんで抜けるわ。

age

何度言ったら分かるんだ。
アセンブリ言語を アセンブルするのが、アセンブラだ。

なんかしょーもないスレがあがってるね。

Ｃ＃で作ったアプリと汎用機のアプリを通信させるためのミドル
ウェアはなんかある？
ＡＳＰのＶＢからはＣ＃呼ぶのは簡単？
ＡＳＰのサーバーってクラスタリングできる？
質問ばかりでごみんに。

>>129
小学舘「プログレッシブ英和中辞典」によると、
assembler language = assembly language
とあるぞ。
アセンブラで良いようだが.....

＃マイクロソフトがやると決めたことに対してはついていかなくてはなりません。
実際のところ批判なんてしてる余地、ないよね（藁

でも技術的に僅かに新しいこと意外に、J2EEに対する.NETのメリットなんてある？
SOAPとかUDDIとか言ったってJavaのランタイムはもうありますよ。

ビルディングブロックの共有化？
確かにJavaは多方面から期待されている分、共通のものが出てくるまでが遅い。
というよりライブラリ以外になかなか共通化されたものがない。
これは実はJavaのいいところだと思うけど・・・
MSが多少設計のいただけないものでも市場に出すスピードで勝るならそれにも
メリットはあるかな？

J2EEってどんな用途に向いてるの？
いまいちサーブレットからのDBアクセスしている限りじゃわからん。

大規模なもの以外に何かあるのかな？
中小レベルじゃJ2EEなんて意識しなくてもいいのかな？

>>134
JTA,JMA,JNDIを覚えよ。

133だけど、
やっぱりj2eeの勉強にはPetStoreが一番なの？
みんなは最初何で勉強したの？

133
んー、なぜかdeploytoolがうんまくうごいてくれない。

動きました！だけどPetStore、重すぎ。
j2eeってなんでこんなに遅いの？
そら、サーブレットより高度なことやってんだろうけど、
CPU100%にして処理してる割にはなんだかなー
これからいろいろと中を見て調べるか。

遅いことの原因のわかる人、ヒント下さい

ごめそ、自分、133じゃなくて134でした。

「J2EEが遅い」って意味不明。「J2EE SDKが遅い」って
意味なら、まともなAPサーバを使いましょう。

メモリさえ多めに積めば遅いなんてことは全然ないはず。

でも.NETだと同規模のプログラムでJavaの倍以上は速いよ。
Javaが遅いというのは、言語構造上避けられない事だから、
それに対して反論しているようでは仕方ない。

Javaのメリットはもっと別の所にあるんだよ。勉強しろ>>140

そういう用途だとシステム全体のパフォーマンスは
DBとかNetworkとかのI/O系に引っ張られがちだろが

スループットのすべてがUser Timeで決まると思ってんの？>>141
サーバ系の仕事したこと無いのかよ

だから、Javaでも全然遅くないって...
なんだよ倍以上って。いいかげんなこというなって。

Webアプリの話してるんじゃないの? 言語の差なんて
パフォーマンスにほとんど影響ないよ。
影響があるのは、HTTPリスナとか、コネクションプール
とか、スレッド管理とかの完成度の差。

>>143
そりゃそうだよなあ。

今時の鯖の性能で、Object変数が参照しか使えないかどうか
(かつてC++とかいう骨董言語が拘った点)なんてことは
たいした性能ファクターになるはずないもんなあ。
モバイルの小さく弱いデバイスとかいうなら
色々考えないとなるまいが。

今時なら、ライブラリとかの実装の出来の問題が支配的だと
考えるほうがマトモ、か。

J2EE vs. Microsoft.NET
http://www2.theserverside.com/resources/article.jsp?l=J2EE-vs-DOTNET

良スレだがあえて言いたい。
すくなくともJavaに関しては、吉田みたいなドキュンの言うことを間に受けるな。

>>145
なかなか面白そうな記事。

>>146
心情的には言わんとする事はわかるけどね。

というかIBMがCLRにJavaを載せればいいだけじゃん。
COBOL.NETっていうか？(wﾗ
ｿﾚﾖﾘﾓ、MSはJiniやJxtaのようなP2Pというかｴｰｼﾞｪﾝﾄ系技術を
そろそろ考えないと、ﾏｼﾞﾔﾊﾞですな。