【Java】　　EJBはもうおしまい　　【死滅】

1 ：仕様書無しさん：04/09/28 15:00:41

http://www.itmedia.co.jp/enterprise/articles/0409/28/news019.html

速報
2004/09/28 08:30 更新

Sun、単一のJavaプログラミングモデルを創設

　米Sun Microsystemsのエンジニアが、Enterprise JavaBeans (EJB）とJava Data Objects (JDO）を再編して、開発者のために単一のパーシスタントモデル「Plain Old Java Object」 (POJO）を創設することで合意した。

　　略

2 ：仕様書無しさん：04/09/28 15:15:05

まだまだDelphiに比べると悲惨度が足りない

3 ：仕様書無しさん：04/09/28 15:17:56

ほい、大本営発表。
http://java.sun.com/j2ee/letter/persistence.html

4 ：仕様書無しさん：04/09/28 15:18:01

EJBっつか、Sunが終わって大きい青い会社が今までどおりの形で引き継いでくれるよ。

5 ：仕様書無しさん：04/09/28 15:26:20

SunにはJavaなどという代物とはすっぱり手を引いて、
Solarisオプソとオプテロンサーバでがんばって欲しい。

6 ：仕様書無しさん：04/09/28 15:28:41

はっはっは～
j厨泣け泣け　ｸｿEJBははじめからこうなる運命は分かりきっていたよ

7 ：仕様書無しさん：04/09/28 15:34:35

ﾌﾞﾋﾞ出荷停止で烏合のﾌﾞﾋﾞは消えた。

が、Javaが消えるわけでない。

というか、変更が入るだけで単なるロードマップじゃないの？

8 ：仕様書無しさん：04/09/28 15:35:49

APサーバの出荷停止です。

9 ：仕様書無しさん：04/09/28 15:39:25

メモリ管理において、EJBよりJDOが優れていた、ということなのかな？

10 ：仕様書無しさん：04/09/28 15:43:20

　　　　　　r;ｧ'N;:::::::::::::,ｨ／　　　　　 >::::::::::ヽ
.　　　　〃　　ヽﾙ1'´　　　　　 ∠:::::::::::::::::i
　　　　 i′　　___,　-　,. = -一　￣ｌ:::::::::::::::ｌ
.　　　　　 ! , -＝=､´r'　　　　　　　　 l::::::/,ﾆ.ヽ
　　　　　　ｌ　　　　　　　　_,, -‐''二ゝ　ｌ::::l fﾞヽ |、ここはお前の日記帳じゃねえんだ
　　　　　ﾚー-- ､ヽヾﾆ-ｧ,ﾆ;＝、_　　 !:::l ） } ト
　　　　　　ヾ¨'７"ry､｀　ｰﾞ='ニ,,,｀　　 }::ヽ(ノ　チラシの裏にでも書いてろ
:ｰゝヽ､　　 !´ "￣ 'l,;;;;,,,.、　　　　　　　,i:::::::ﾐ
::::::::::::::::ヽ.-‐ ﾄ、　r'_{　　 __)｀ニゝ、　 ,,iﾘ::::::::ﾐ　　　
::::::::::::::::::::Vi／l:::V'´;ｯ`ﾆ´ｰ-ｯ-,､:::::`"::::::::::::::;ﾞ　, 　な！
:::::::::::::::::::::::::N. ﾞ､::::ヾ,.｀二ﾆ´∠,,.i::::::::::::::::::::/／／
:::::::::::::::::::::::::::::l　ヽ;:::::::::::::::::::::::::::::::::::::::::::／　／
::::::::::::::::::::::::::::::!　:|.＼;::::::::::::::::::::::::::::::／　／

11 ：仕様書無しさん：04/09/28 15:47:01

EJB3.0はどうなるんだ？

12 ：仕様書無しさん：04/09/28 15:48:15

>>11
継承だろ。
POJOのサブプロジェクト化して、以下続行。
ただし、DBアクセス部/EntityBeanの仕様は、JDOの影響を受けて、他の場所以上に大幅改変があるだろうな。

13 ：仕様書無しさん：04/09/28 16:01:30

そんな、

Delphiもあるし無くなったのはVBとMFCだけかよ。

14 ：仕様書無しさん：04/09/28 16:10:36

WebLogic8.1はどうなるのでしょう？

15 ：仕様書無しさん：04/09/28 16:29:55

>>14
死滅です。

16 ：仕様書無しさん：04/09/28 16:41:26

ブビブビいうアホが必ずJavaスレに現われる。なぜか？

JavaはC++とC#の間で板挟みになってるから
Java厨はVB厨との比較をしていないと不安で仕方ない。

webの分野はPerl/PHPのタッグが幅を効かせすぎて簡単には牙城を崩せないし
ゲームの分野も活躍できていない。
ブラウザーの中で動くプログラムはFlashのおかげで独占できていない。
逆コンパイルされやすいのでパッケージソフトでは採用されにくいときたもんだ。

エンタープライズです。WEBです。
エンタープライズ？EJBもこの有様。

Javaだけが独擅場となってる分野が無いのが悲惨
各分野で狭い隙間に居させてもらってるのが現状
この先どうなるか分かったものじゃない
VBでも見て安心してなきゃやってらんないね

17 ：仕様書無しさん：04/09/28 16:51:42

つか、サーバーサイドとJava Web Startは独断場

18 ：仕様書無しさん：04/09/28 16:57:34

ﾄﾞｶﾀ仕事の独壇場だな。(ｹﾞﾗ

19 ：仕様書無しさん：04/09/28 17:18:02

JET→DAO→RDO→ODBC→ADO→ADO+→ADOﾄﾞﾄﾈﾄ

より、ましなんでないの？

20 ：仕様書無しさん：04/09/28 17:27:07

そろそろ、どこかで新言語が生まれているに違いない。
乗り遅れるな、もまいら。

21 ：仕様書無しさん：04/09/28 17:33:44

>>19
ぜんぜん対象とするものが違うものを矢印でつなげられても・・・。
完全に比較するべきでないものも入っているし。
実はわかってないとか？

22 ：仕様書無しさん：04/09/28 17:34:33

DAO→ADOだけかな？

23 ：仕様書無しさん：04/09/28 18:01:12

EJBがこうなるのはみんな分かっていたんじゃない？
漏れは分かりきっていたからまともにやったことない。
CORBAもそうだけどね。JAVA系のベースとなる技術は全部だめだね。
JAVA系のIDEも全部だめだね。
知るためにCORBAも少しはやろうとしたけどね、やっているそばから
こいつは絶対主流にはならないなとやめたよ。ﾎﾝﾄ正解だった。
ぱんざーーーーーい。

24 ：仕様書無しさん：04/09/28 18:08:25

>>23
Java系の２つのアーキテクチャー内で調整が行われただけなのに、

WindowsDNAは死滅したけど

25 ：仕様書無しさん：04/09/28 20:13:43

WindowsDNAって何？関係ないし。
.netフレームワークには影響ないよ。
ひょっとしてDNAやってて切られた負け組みかな？

26 ：仕様書無しさん：04/09/28 22:15:51

ﾄﾞﾄﾈﾄがモッサリ重くて遅いため、
ベンダーが使わないから知ってる人が居ない位マイナーで、
サーバーは今さらJava置き換えられないし、
クライアントはﾌﾞﾋﾞランタイム程度。

ﾄﾞﾄﾈﾄ超負け組み

ここは久々のﾄﾞﾄﾈﾄ死滅ｽﾚでつか？

祭りは始まりますか？

27 ：仕様書無しさん：04/09/28 22:26:02

本当に死滅したのはEJB

28 ：仕様書無しさん：04/09/28 23:37:51

>>19
変じゃね？
RDO→ADO→ADOﾄﾞﾄﾈﾄで良いだろ
なんでDAOとRDOが繋がってんの？
いや、それよりJET→DAOって....

29 ：69式フリーPG ◆hND3Lufios ：04/09/29 00:15:03

あちゃー・・・。合掌。。。

つかEJBってﾃﾞｽﾏの種だったからよかったのでは。

30 ：仕様書無しさん：04/09/29 00:26:50

EJBが死んだなら結局COBOLはまだ生き残るんだな・・・
世間の流れを超越し、まだ生き続けるのか・・・恐ろしいな

31 ：仕様書無しさん：04/09/29 00:30:21

で、難民となったJava厨の行き先は？

32 ：69式フリーPG ◆hND3Lufios ：04/09/29 00:31:09

VisualJ#

33 ：仕様書無しさん：04/09/29 00:34:00

OpenEJBとかそんなのをマンパワーで作って帰ってくるんじゃね？

34 ：仕様書無しさん：04/09/29 01:20:17

EJBが消えるんで無くて統合されるんでしょ。
路線の修正なら良いじゃん。

某MSの言語やライブラリみたく消えるわけでなし。

35 ：仕様書無しさん：04/09/29 02:41:05

>>34
某MSの言語やライブラリは消えたんじゃないよ。
路線の修正の結果.NET Frameworkに統合されたんだよ。

36 ：仕様書無しさん：04/09/29 03:49:59

いまさらだな。
もっさりしたEJBよりもHibernateとかのORMツールの方が
全然使い勝手が良かったからね。
EJBがこうなることはみんな予想してたんじゃないの？

37 ：仕様書無しさん：04/09/29 09:47:24

Torqueを使ってたけど、最近、Hibernateに乗り換えた
EJBは分散オブジェクトのメカニズムまで含んでいるから
仕様が大きくて重くなるのは解るが、パフォーマンスが
出ないのはやっぱり痛い

38 ：仕様書無しさん：04/09/29 09:51:22

環境設定が少なくて、かつ、小さく作れる環境はどれよ。

39 ：仕様書無しさん：04/09/29 10:33:24

>>36
EJB、って遅かったか？
前に二つ並べて計測したら、
少なくともDataSourceから直にSQL投げて、
自分でマッピングするタイプのアプリと、パフォーマンスに違いなんてなかったと思うが。

どんな環境でやったんだ？
つくりがまずかった、ってことはないか？

40 ：仕様書無しさん：04/09/29 11:44:07

EJB捨ててJava Web Startすれば楽になりそう。

メンドウなのはSwingだけか。

41 ：仕様書無しさん：04/09/29 12:31:59

へー。Java Web StartってDBアクセスのAPIだったんだ。

42 ：仕様書無しさん：04/09/29 12:42:02

>>39
さんざん既出だが
コンパクトなテストコードではそんなに差はでないのがEJBの
恐ろしいところだよ　EJBが遅くなるのはコンポーネントクラスが
増加するにしたがってどんどん遅くなるペースが速まる

43 ：仕様書無しさん：04/09/29 12:44:59

起動時間はカウントしないのがJava流ですから。
APサーバーの起動もEJBのactivateもパフォーマンスのうちに入りません。

44 ：仕様書無しさん：04/09/29 12:45:21

kusosure Renpatsu De Ageruna!!

45 ：仕様書無しさん：04/09/29 13:58:55

EJB3.0の仕様をちょっと見てみたけど、どっちみち別物だなこりゃ。
すべて破棄して覚え直しに変わりなし。

46 ：仕様書無しさん：04/09/29 14:07:22

だったら.NETでも一から覚えた方が得だよな。(ｹﾞﾗ

47 ：仕様書無しさん：04/09/29 14:14:05

seasarでいいよ

48 ：仕様書無しさん：04/09/29 14:17:54

また混乱に便乗して糞フレームワーク乱立か。
Javaは救いようがねえな。

49 ：仕様書無しさん：04/09/29 14:47:45

sun認定Java資格はどうなるの～？

50 ：仕様書無しさん：04/09/29 14:51:30

もうすぐ会社ごとなくなるから

51 ：仕様書無しさん：04/09/29 15:27:35

seasarはフレームワークじゃないんだな。

まあ乱立は乱立か。

52 ：仕様書無しさん：04/09/29 19:23:01

Strutsはどうなの？

53 ：仕様書無しさん：04/09/29 19:43:52

JavaBeansはどうなるの？

54 ：仕様書無しさん：04/09/29 20:32:40

EJBもStrutsもSwingも糞だ。こうなることは前から目に見えていた。
あんな汚ねぇアーキテクチャが長続きするわけがない。
企業や雑誌屋の誇大宣伝に乗せられずに
Smalltalk以来の技法を地道に勉強する奴が勝ち組。

55 ：仕様書無しさん：04/09/29 20:47:02

つぎは間違いなくStrutsがあぼーんする。
現場の技術者は、Strutsのメンテナンス性がかなり悪いことに気づき始めている。
評論家でさえ、MVCをウェブアプリケーションに適用できるなどと言ふらした馬鹿は誰だと公然と批判し始めている。
Swingは代わりのものがないから仕方なく使っているようなもんで、
携帯以外のクライアントJavaが普及しなかったのはSwingが糞だったから。
あれをなんとかしないと、デスクトップでJavaが普及することはない。
J2EE関係なら、JavaMailが糞。
JSPは糞とは言わんが、わざわざJavaを勉強して使うほどのものでもない。
ASPやPHPで充分。
逆に生き残るのはXML関連の技術。
今まではあまり使い道が知られていなかったけど、ブロッグの普及で有名になったし、
SunだけではなくM$も資金と優秀な人材を投入しているので、簡単に見捨てられることはない。

56 ：仕様書無しさん：04/09/29 20:57:54

ちなみにXML関連でも、
JAXBやRELAXERのようなオブジェクトマッピングはおそらく失敗する
ネットワークで扱うデータが大きくなりゃあんなものは役に立たなくなる。
XML-DBも当分はRDBにとって代わることはないだろう。
単にパフォーマンスの問題だけじゃなくて、
ツリー状のデータの同期を取るのは熟練者以外には難しすぎる。

57 ：仕様書無しさん：04/09/29 21:22:26

>>55
とても興味深い。
>現場の技術者は、Strutsのメンテナンス性がかなり悪いことに気づき始めている。
>評論家でさえ、MVCをウェブアプリケーションに適用できるなどと言ふらした馬鹿は誰だと公然と批判し始めている。
申し訳ないが、出来たらソースなどを教えて貰えないだろうか？
ちなみにWebアプリはASPやPHPで十分というのは激しく同意。

58 ：仕様書無しさん：04/09/29 21:31:57

>>57
以下、Struts批判で物議を醸した記事のソース。
http://today.java.net/pub/a/today/2003/12/11/mvc.html

59 ：仕様書無しさん：04/09/29 21:36:45

十分ねえ。。。

60 ：仕様書無しさん：04/09/29 21:38:59

WebObjects最強！

61 ：仕様書無しさん：04/09/29 21:40:01

JSP/Servletで十分

62 ：仕様書無しさん：04/09/29 21:43:03

StrutsはJSFの登場ででとっくに死滅しただろ。

日　本　以　外　で　は　ね。

63 ：仕様書無しさん：04/09/29 21:57:15

>>55
Servlet APIが理解できるヤシならStrutsなんて数週間で習得できると思う
JSFも同様でしょ
生きるの死ぬのと大げさにいうほどのことじゃない

64 ：仕様書無しさん：04/09/29 22:23:34

EJBが死滅してくれて助かったよ
ようやくCORBAも滅んでくれるんだな

65 ：69式フリーPG ◆hND3Lufios ：04/09/29 23:42:16

俺もWebアプリはASP/PHPで十分というのは同意だな。
いかに無駄なことをせずにあっさりさっくり書けるかが重要。

66 ：仕様書無しさん：04/09/29 23:47:33

えー？でもASPはASP.netに比べるとメンテが面倒臭くね？

67 ：仕様書無しさん：04/09/29 23:49:09

十分ねえ。。。

68 ：仕様書無しさん：04/09/30 00:40:01

最近思うんだが、元ｺﾎﾞﾗがちょっとWebアプリをかじった程度で
オープン系技術者とかいって紛れ込んできていないか？

69 ：仕様書無しさん：04/09/30 00:55:15

今気づいたのかよ・・・

70 ：仕様書無しさん：04/09/30 01:06:07

つまり、J厨 == ｺﾎﾞﾗ？

71 ：仕様書無しさん：04/09/30 01:12:16

J厨はただのJ厨
J厨は単なる負け犬

72 ：仕様書無しさん：04/09/30 01:24:57

Java厨の大半は元COBOLerだろ？
EJB死滅だから
COBOL→Java→COBOLって事になるな。
Java厨ってあれか、鮭みたいなもんか。

73 ：仕様書無しさん：04/09/30 03:53:20

>>67
どうかしたのか？

74 ：仕様書無しさん：04/09/30 03:53:49

>>67
どうかしたのか？

75 ：仕様書無しさん：04/09/30 08:10:19

MVCでやるとき「馬鹿」だなと思う瞬間は
コントローラ==Servletじゃないの
Servlet==JSPだよね
.javaだとコンパイルするのがめんどい
.jspだとコンテナがコンパイルしてくれる
だからコントローラも.jspで作るスクリプトレットで囲んでね
セッションは定義済みオブジェクトで存在するからそのまま利用できる
漏れが分からないのが.jspでもできる事をなんでわさわざServletで
書く意味があるのかが知りたい。MVCを提唱した人ってj厨？

76 ：仕様書無しさん：04/09/30 08:45:59

Javaは知らないけど纏めてみる。

汎用機/ｺﾎﾞﾗｰ → Java厨@Webアプリ

AWT → Swing → 次候補無し
Struts → JSF
CORBA → EJB → ?
Applet → Java Web Start

77 ：仕様書無しさん：04/09/30 09:02:37

Javaを嫌いな理由
・周辺技術多すぎ

78 ：仕様書無しさん：04/09/30 09:13:09

>>76
本当に知らないんだな。

79 ：仕様書無しさん：04/09/30 09:24:46

Strutsはフレームワークというよりは、
単なるユーティリティとしての使い道しかないと気づいた連中が
JSFを作ったんだろ。
大体、元々SmalltalkのGUI用だったMVCをウェブアプリケーションに適用できるという
何の根拠も無い話を雑誌や書籍がこぞって持ち上げて、
にわかJavaプログラマがあり難がっていた状況が異常だった。
当分はCGIやPHPの開発者が無意識に使っている、
７０年も昔の理論である状態遷移モデルが使われ続けると思う。

80 ：仕様書無しさん：04/09/30 09:25:17

AWT → Swing → WindowsForms → Avalon
Struts → JSF → ASP.NET
CORBA → EJB → COM+ SWC
Applet → Java Web Start → NTD → ClickOnce

81 ：仕様書無しさん：04/09/30 09:31:26

CORBA → EJB → COM+ SWC → Indigo

82 ：仕様書無しさん：04/09/30 09:34:25

Javaには楽しみなネタもロードマップもないね。終わったな。

83 ：仕様書無しさん：04/09/30 09:38:32

だからJavaとﾄﾞﾄﾈﾄは対立するものであって派生ではない。

C（ネイティブ）・・・草木のようにライブラリ乱立。プラットフォームを越えて繁殖。
Java（managed）・・・草木のようにライブラリ乱立。プラットフォームを越えて繁殖。

VB/ActiveX（ネイティブ）・・・ライブラリはM$のみ。ﾌﾞﾋﾞ厨繁殖するが死滅。
C#/CLS（managed）・・・ライブラリはM$のみ。繁殖せずにOfficeマクロに終わる。

84 ：仕様書無しさん：04/09/30 09:43:44

そして時代はOS依存のベタなTCP/IPアプリに回帰したりしてなw

85 ：仕様書無しさん：04/09/30 09:46:19

TCP/IPとHTTPならJavaの出番だよな。(ｹﾞﾗ

86 ：仕様書無しさん：04/09/30 09:47:45

いや、そうなるだろ。OS依存かJava依存か別にして、
TCP/IP、HTTPでインストール不要なリッチクライアント時代に。

87 ：仕様書無しさん：04/09/30 09:47:46

>>83
ちょっとまて、それはあまりにも無知じゃないのか。
.NETはすでにLinuxやMacで動いているぞ。

88 ：仕様書無しさん：04/09/30 09:48:35

>>84
それが王道だ。javaはｱﾌｫ厨のために作られたメモリ管理セーフな
おもちゃ、それだけ。しょせんおもちゃでは業務は語れない。

89 ：仕様書無しさん：04/09/30 09:49:51

>>87
それが正しかったとしても制覇のレベルが違いすぎ。
組み込みと言えば何が無くてもC言語はある。
と思ってたら、それをカバーするようにJavaが携帯機器に入ったり、
火星（だっけ？）のマシンに入ったり。
ハイエンドもおさえたし。

90 ：仕様書無しさん：04/09/30 09:53:09

>>87
どこまで互換性があるか、だよね。
Hello worldをコンソールに表示できるぐらいなら、
Cのソースをコンパイルしなおすぐらいでいい。

91 ：仕様書無しさん：04/09/30 09:55:49

設計者の意図を超えてC言語、Javaは組み込みからハイエンドまで浸透して、ゴミも含めてライブラリとアプリが繁殖してしまったわけ。

片や、１企業が制覇をもくろんでお金流し込むも浸透せずスクラップ＆ビルドな言語。だからユーザが多くてもライブラリさえ繁殖しない。

92 ：仕様書無しさん：04/09/30 10:01:34

> １企業が制覇をもくろんでお金流し込むも浸透せずスクラップ＆ビルドな言語。だからユーザが多くてもライブラリさえ繁殖しない。

Javaって$unの独占所有物だもんね。
ライブラリも出ては消えるし。

93 ：仕様書無しさん：04/09/30 10:02:28

92はちゃんと91の内容を読みなさい。

94 ：仕様書無しさん：04/09/30 10:03:38

>>89
でも、携帯もほとんどCなんでしょ？
携帯のスレとか見てないの？

95 ：仕様書無しさん：04/09/30 10:04:18

.NETって、MSだから仕様はころころ変わるんじゃない？
2.0、2.1、3.0と。
3まで続くかどうか怪しいけどなー。

96 ：仕様書無しさん：04/09/30 10:05:43

>>95
ISO標準仕様です。

97 ：仕様書無しさん：04/09/30 10:05:52

>>94
そりゃCは昔から標準だし。
でもJavaも食い込んできてるよ。
携帯は開発納期が凄まじいまでに酷いらしいから、開発に
簡単な言語を求めてるのかもなー。

98 ：仕様書無しさん：04/09/30 10:07:11

>>94
数の話でなくて、Javaを作ったエンジニアの意図を超えて繁殖していってるという話。
で、使う場面によって、ネイティブ／クロスとか選択されれば良いだけで

99 ：仕様書無しさん：04/09/30 10:07:27

>>96
1.0と1.1で仕様が変わったのもISOが決めたんですか。
つーか、仕様の作成する側はISO関係ないんじゃ。

100 ：仕様書無しさん：04/09/30 10:08:57

ISOを使ってﾄﾞﾄﾈﾄを制覇させたい、という１企業の願いであって、
市場のとかISOが願ってISOにしたわけじゃない。

で、現状死んだ規格。

101 ：仕様書無しさん：04/09/30 10:09:44

Java厨にとってNGワードだろ、標準化は。(ｹﾞﾗ

102 ：仕様書無しさん：04/09/30 10:11:05

>ネイティブ／クロスとか選択されれば良いだけで
j厨に選択は不可能、無理難題すぎる

103 ：仕様書無しさん：04/09/30 10:11:31

Java・・・市場が標準規格を願ってるのにＳ∪∩がストップかけてる・・・勝ち組

ﾄﾞﾄﾈﾄ・・・ISOを使って市場を制覇させたい、という１企業の願い、が（ry・・・負け組

104 ：仕様書無しさん：04/09/30 10:12:31

またJava厨が火病起こしてるな。ｗ

105 ：仕様書無しさん：04/09/30 10:13:06

>標準規格を願ってるのにＳ∪∩がストップかけてる・

標準化されたら「んなもん遅くて使えね」と槍玉にされるのが怖いだけ

106 ：仕様書無しさん：04/09/30 10:14:02

ふーん。標準化すると負け組なんだ。

107 ：仕様書無しさん：04/09/30 10:14:19

とにかくこの業界にJava厨だけはﾎﾝﾄいらねえよ
Perl厨のほうがまだかわいいもんだ

108 ：仕様書無しさん：04/09/30 10:14:42

またこいつか。
一方的に悪口書いて、反論されても言い返せないから
一切スルー。
こいつって.NETも使えないんじゃないか？

109 ：仕様書無しさん：04/09/30 10:16:46

>>108
JavaWebスタートを起動するだけのスキルはあるみたいだけどな

110 ：仕様書無しさん：04/09/30 10:17:23

Perlは5年ほど使ってたが、大規模なのは無理だろ。
言語仕様をがらりと変えて、旧バージョンとの互換性を
捨てればいいんだが、それをやるとPerlじゃなくていいじゃん、
ということになってしまう。
バージョン6で結構言語仕様変えるらしいが、もうPythonや
Rubyには勝てないだろうな。

111 ：仕様書無しさん：04/09/30 10:17:37

低脳アホアンチはJavaも.NETも一切使えませんよ。(ｹﾞﾗ

112 ：仕様書無しさん：04/09/30 10:23:06

>>88
Javaと.NET両方とも嫌い（使えない）奴の存在が急浮上！

113 ：仕様書無しさん：04/09/30 10:25:00

C厨が裏で糸引いてるｗ

114 ：仕様書無しさん：04/09/30 10:27:51

このスレに書き込んでる奴って平均年齢高そう。
時間帯からいってハロワ出勤前のうさばらしか？

115 ：仕様書無しさん：04/09/30 11:33:44

マジレスするが

EJBで作ると幸せな気分になれる人手あげて

116 ：仕様書無しさん：04/09/30 11:36:48

>>113
VB厨の間違い

117 ：仕様書無しさん：04/09/30 11:42:06

Javaで作ると幸せな気分になれる人手あげて

118 ：仕様書無しさん：04/09/30 11:49:46

Java/Swingを使って作るのやだが、
Java Web StartアプリはEXEより平気で使える。

ﾄﾞﾄﾈﾄは重いだけ。安心感は無い。

119 ：仕様書無しさん：04/09/30 12:03:57

>Java Web StartアプリはEXEより平気で使える。
お　出たな！　起動するスキルがあるj厨

120 ：仕様書無しさん：04/09/30 12:19:52

> Java Web StartアプリはEXEより平気で使える。
よく、

アプリケーションは、あなたのローカルマシンおよびネットワークに
対して無制限のアクセスを要求しています。

このコードをインストールおよび実行しないことを強くお勧めします。

なんて言われるものを平気で使えるなｗ

121 ：仕様書無しさん：04/09/30 13:13:22

MVCて考え方はなんなの？
ＭＦＣでいうところのview-documentみたいなもの？

122 ：仕様書無しさん：04/09/30 13:17:20

MVCという考えの、一形態がＭＦＣでいうところのview-documentだろ。

VC++/MFCの場合、docをIDEが保持するためクッションにならないという最大の汚点があるだけで。

123 ：仕様書無しさん：04/09/30 13:24:28

> docをIDEが保持するため

ここは笑うところですか？

124 ：仕様書無しさん：04/09/30 13:32:39

ふーん。MFCってIDEがないと実行もできないんだ。

125 ：仕様書無しさん：04/09/30 13:34:00

123も124もVC++ﾂｶﾀｺﾄ無いの丸分かり。

ここがﾌﾞﾋﾞ厨の笑うとこ（嘲笑激藁

126 ：仕様書無しさん：04/09/30 22:38:25

今頃j2eeとejbを覚えさせられる羽目に・・・
何でこんな無駄な技術を覚えなくちゃならないのか・・・

127 ：仕様書無しさん：04/09/30 22:58:00

お金がもらえるから

128 ：仕様書無しさん：04/09/30 23:17:42

>>126

ejbごときも理解できない真性の馬鹿を見つけられるから

129 ：仕様書無しさん：04/09/30 23:35:16

自分発見のための仕事ってことか

130 ：仕様書無しさん：04/10/01 04:45:49

馬鹿が多すぎるからEJBを止めたのか、
無駄に複雑すぎるからEJBを止めたのか。

今まで「EJBも分からないの？プゲラ。いつまでもJavaBeanで満足してんなよ」
って言ってる奴が「これからはPOJOだよ！」っていつ言い出すかドキドキして待ってます。

131 ：仕様書無しさん：04/10/01 07:16:54

自分、EJBは使ってないけど、

EJBも分からないの？プゲラ。いつまでもJavaBeanで満足してんなよ。
そんなﾌﾞﾋﾞな香具師のため、これからはPOJOだよ！

132 ：仕様書無しさん：04/10/01 07:21:43

EJBも使ったことないの？ﾌﾟｹﾞﾗ
それでJava使った気になってるんだ。ﾊｹﾞﾜﾗ

133 ：仕様書無しさん：04/10/01 08:58:15

出た当初に仕様を見て、こいつは糞だということが
すぐに分かったのでEJBは１度も使ってない。
パフォーマンスが安定しない、大量のデータを扱う場面ではすぐ破綻する。
すでに２年前、Sunの技術者でさえ、ウェブアプリなら
EJB使うよりJDBCにダイレクトにアクセスする方がよい場合があると公言してたからな。
技術者はEJBの限界にとっくに気づいていたけど、営業の方が引っ込みがつかなかったってとこだろ。

134 ：仕様書無しさん：04/10/01 09:09:19

でも一度は分散環境でEJBの案件やってみたいな。

135 ：仕様書無しさん：04/10/01 09:12:08

>出た当初に仕様を見て、こいつは糞だということが
>すぐに分かったのでEJBは１度も使ってない。
漏れもその2だ

136 ：仕様書無しさん：04/10/01 09:18:33

またC厨の脳内妄想スレか

137 ：仕様書無しさん：04/10/01 09:20:45

>すでに２年前、Sunの技術者でさえ、ウェブアプリなら
>EJB使うよりJDBCにダイレクトにアクセスする方がよい場合があると公言してたからな。

ってウェブアプリ以外に使い道あるのかと問い詰めたい

138 ：仕様書無しさん：04/10/01 09:25:47

おしまいなんのはドトネトのほう

●なぜドトネト厨はそんなにJavaが嫌いなのか　7
http://pc5.2ch.net/test/read.cgi/prog/1096590283/
　

139 ：仕様書無しさん：04/10/01 10:51:40

なんでもかんでもすぐに手を出すのは問題だな