110,536
社区成员
发帖
与我相关
我的任务
分享J2EE与.net 开发成本比较 [欢迎理性思考]
听说因为成本总是,中国移动决定将所以非BOSS系统全部采用.net 开发,不知道大家对此事有何想法,也请移动内部的朋友谈谈实际情况如何?
...全文
请发表友善的回复…
发表回复
boyxia 2005-05-19
- 打赏
- 举报
楼上在哪里混的？我才3800啊
TechEye 2005-05-19
- 打赏
- 举报
.NET程序员工资都有多少呢？？我4.5K，是不是比JAVA的低了很多？？
boyxia 2005-05-19
- 打赏
- 举报
支持楼上的说法，很多人不喜欢.net就是因为.net太方便了，太好学了，导致程序员工资很低，换个角度想想，如果你把很多精力都放在解决技术问题和代码问题上面，如此片面的思维模式而无法将思考放在针对软件本身整体构架和易用性两个很重要的因素上面，注定一辈子只能当软件蓝领，说不好听的是软家民工。如果大家很快突破语言障碍，不再在开发的工作量上被束缚，是不是可以突破自己，进行从程序员到构架师的升华呢？这是我喜欢.net的很重要的因素，期待vs.net 2005 .net 2.0，因为他能进行更好用更方便的开发。对于个人来讲，我记得有个统计数字，平均，java从初学到精通的周期是2年，而.net是1年甚至更短。差了一年，是什么概念？
个人意见，仅供参考。
个人意见，仅供参考。
online2005 2005-05-19
- 打赏
- 举报
在没有.net 时期 java 仰合了大多数人的心态 有很多成功的应用和案例 用java来完成 后来用java者大多在抄袭
.net出现后事情发生了变化 用java来完成应用和案例 已不能在束缚程序员 我们可以把更多精力放在
结构的设计上 这时候需要我们给出的是完整的解决方案
boyxia 2005-05-19
- 打赏
- 举报
和鸡翅膀兄弟讨论一下：
置疑翅膀兄.net开发项目的风险，请问兄弟所说的风险指得是哪些？我有些不明白，搞开发的人都知道，好的软件系统和语言无关，好程序员用asp或php也会开发出企业级的好系统，烂构架师设计的系统才会存在很多风险，而这些风险因素都程序无关，唯一和程序本身有关的风险就是测试工作没做好，没能保证程序的稳定和健壮。如果翅膀兄说得不是指软件本身的风险，那就指项目开发的高成本亏本风险，这就回到我前面所分析的开发成本的问题了。
做完了收收钱拍拍屁股走人，这个和软件企业的素质和企业文化有关，和程序语言本身有什么关系，难道阁下没看到过用java开发软件的公司也是收了钱不认帐的么？身边的例子太多了，我老婆他们单位买了一套java的oa软件，是人家开发好的，拿来改了改界面就买给她们单位了，开始用的感觉挺好，就付钱了，后来发现有些字段不是非要输入的，让软件公司把这些必输字段取消，他们却翻脸不认人说改不了什么的。这是个例，和软件公司有关，和java无关。体谅软件公司的这种做法，不得不这么做，如果用户钻可同漏洞要加些小功能呢？而且不肯额外付钱，已经折腾几个月投入了很多成本，连首款还没收到，你说是给他加还是不给加？不加没钱，加了亏本。就这么回事。
我所分析的java开发的周期长，是因为jsp本身而非语言本身所引起难度加大。开发项目的不见得都是个个java高手，一般都是几个高手分摊到各个项目组，然后还要担任培训和解答问题的职责，不给新手解答问题么？都是一个项目组的，他开发慢了你项目托后了，你会有什么好处么？这就是团队合作。考虑到这些因素，是不是要考虑培训投入的成本？就算都是资深的老程序员，页面的动作事件的控制不用javascript就用post不断的刷新页面方法来开发，javascript的开发效率低下，难调试，难精通是公认的，如果用post方式的话，更难控制，这和.net的针对控件的一系列事件进行控制的开发效率是不可同日而语的。因为有强大的vs.net在，注意我这里讨论的是开发效率而不是语言本身，vs.net和jbuilder开发工具的比较，足可以看得出开发效率的高低，因为这些开发软件不光是高深的算法，通用的函数，更多的是这些基本的针对页面的开发和控制。从而导致了java的开发周期要长一些。这就是我说得java开发周期长的依据。
我置疑翅膀兄所说的java开发周期未必会比.net 高出很多,相反程序质量可能会高一些这句话，质量的高低同样和语言甚至和开发环境都没有任何关系，只和人有关系，任何软件质量不好的情况都是因为开发水平引起的，如果java和.net水平同样很高，是不存在开发质量问题的。
关于永中OFFICE问题，希望翅膀兄讨论问题的时候不要局限于java和.net的功能强弱，java和.net开发的软件谁更强大一些，这和人有关，而不和语言有关，有人肯做的话.net肯定可以做出很好的类似软件，我们这里讨论的是针对软件企业和开发效率的，而不是针对语言和软件的本身。
java不断进步而.net也在不断进步，为什么说.net永远做不到java的优势这样的话呢？对于企业用户来讲java的主要优势除了跨平台还有什么呢？大家都说java能做大项目的，.net做中小项目，就是说java的跨平台特性，而.net无法在unix上跑，mono也只是个不成熟的东东而已，这样直接导致了.net给人的感觉就是跑在windows上的小系统。大家都知道，.net不可跨平台是因为微软的windows的策略导致的，而不是.net的本身引起的，如果有一天.net是微软的主要收入来源而非windows了，java威胁到.net的生存了，微软想让.net跨平台不容易么？mono这样的民间开发组织都可以开发出来，微软不能吗？都可以跨平台了，评什么说.net不可能做到java这样的优势？
置疑翅膀兄.net开发项目的风险，请问兄弟所说的风险指得是哪些？我有些不明白，搞开发的人都知道，好的软件系统和语言无关，好程序员用asp或php也会开发出企业级的好系统，烂构架师设计的系统才会存在很多风险，而这些风险因素都程序无关，唯一和程序本身有关的风险就是测试工作没做好，没能保证程序的稳定和健壮。如果翅膀兄说得不是指软件本身的风险，那就指项目开发的高成本亏本风险，这就回到我前面所分析的开发成本的问题了。
做完了收收钱拍拍屁股走人，这个和软件企业的素质和企业文化有关，和程序语言本身有什么关系，难道阁下没看到过用java开发软件的公司也是收了钱不认帐的么？身边的例子太多了，我老婆他们单位买了一套java的oa软件，是人家开发好的，拿来改了改界面就买给她们单位了，开始用的感觉挺好，就付钱了，后来发现有些字段不是非要输入的，让软件公司把这些必输字段取消，他们却翻脸不认人说改不了什么的。这是个例，和软件公司有关，和java无关。体谅软件公司的这种做法，不得不这么做，如果用户钻可同漏洞要加些小功能呢？而且不肯额外付钱，已经折腾几个月投入了很多成本，连首款还没收到，你说是给他加还是不给加？不加没钱，加了亏本。就这么回事。
我所分析的java开发的周期长，是因为jsp本身而非语言本身所引起难度加大。开发项目的不见得都是个个java高手，一般都是几个高手分摊到各个项目组，然后还要担任培训和解答问题的职责，不给新手解答问题么？都是一个项目组的，他开发慢了你项目托后了，你会有什么好处么？这就是团队合作。考虑到这些因素，是不是要考虑培训投入的成本？就算都是资深的老程序员，页面的动作事件的控制不用javascript就用post不断的刷新页面方法来开发，javascript的开发效率低下，难调试，难精通是公认的，如果用post方式的话，更难控制，这和.net的针对控件的一系列事件进行控制的开发效率是不可同日而语的。因为有强大的vs.net在，注意我这里讨论的是开发效率而不是语言本身，vs.net和jbuilder开发工具的比较，足可以看得出开发效率的高低，因为这些开发软件不光是高深的算法，通用的函数，更多的是这些基本的针对页面的开发和控制。从而导致了java的开发周期要长一些。这就是我说得java开发周期长的依据。
我置疑翅膀兄所说的java开发周期未必会比.net 高出很多,相反程序质量可能会高一些这句话，质量的高低同样和语言甚至和开发环境都没有任何关系，只和人有关系，任何软件质量不好的情况都是因为开发水平引起的，如果java和.net水平同样很高，是不存在开发质量问题的。
关于永中OFFICE问题，希望翅膀兄讨论问题的时候不要局限于java和.net的功能强弱，java和.net开发的软件谁更强大一些，这和人有关，而不和语言有关，有人肯做的话.net肯定可以做出很好的类似软件，我们这里讨论的是针对软件企业和开发效率的，而不是针对语言和软件的本身。
java不断进步而.net也在不断进步，为什么说.net永远做不到java的优势这样的话呢？对于企业用户来讲java的主要优势除了跨平台还有什么呢？大家都说java能做大项目的，.net做中小项目，就是说java的跨平台特性，而.net无法在unix上跑，mono也只是个不成熟的东东而已，这样直接导致了.net给人的感觉就是跑在windows上的小系统。大家都知道，.net不可跨平台是因为微软的windows的策略导致的，而不是.net的本身引起的，如果有一天.net是微软的主要收入来源而非windows了，java威胁到.net的生存了，微软想让.net跨平台不容易么？mono这样的民间开发组织都可以开发出来，微软不能吗？都可以跨平台了，评什么说.net不可能做到java这样的优势？
BlueMountain_1980 2005-05-19
- 打赏
- 举报
商业中所说的成本更多的时候和技术无关！！
PS:“Net入手简单，所以很多人在用，目前市场上的行情就是.net的比java的薪水低…………”类似的话语我在最近的面试中听到了不下于1000遍。 可是我觉得好多的项目被bug的维护不断的拖延工期恰恰就是企业这种“低成本”的思想在作怪。 如果你想高效率，健壮……我个人认为不管是java还是.net都很困难。因为这两种语言的留给程序员的控制权太少。（有时候我甚至觉得还不如用C++好用（虽然我从来没有用过C++做项目），比如说如果内存控制，如果你需要弱饮用，对象复苏，这个我觉得可不是个“低成本”）
PS:“Net入手简单，所以很多人在用，目前市场上的行情就是.net的比java的薪水低…………”类似的话语我在最近的面试中听到了不下于1000遍。 可是我觉得好多的项目被bug的维护不断的拖延工期恰恰就是企业这种“低成本”的思想在作怪。 如果你想高效率，健壮……我个人认为不管是java还是.net都很困难。因为这两种语言的留给程序员的控制权太少。（有时候我甚至觉得还不如用C++好用（虽然我从来没有用过C++做项目），比如说如果内存控制，如果你需要弱饮用，对象复苏，这个我觉得可不是个“低成本”）
wwg_yuyin 2005-05-19
- 打赏
- 举报
我太喜欢楼上兄弟
boyxia(>>无天刀绝 [抵制日货]<<)
的见解了,
boyxia(>>无天刀绝 [抵制日货]<<)
的见解了,
wwg_yuyin 2005-05-19
- 打赏
- 举报
我太喜欢楼上兄弟的见解了,绝!
mahongxi 2005-05-19
- 打赏
- 举报
我个人认为JAVA很多地方存在不足,但如果后备方案是microsoft的产品,我还是会多些理性思考.
但java在不断进步中,它会吸取.net优势,但.net 永远做不到java 的优势
但java在不断进步中,它会吸取.net优势,但.net 永远做不到java 的优势
mahongxi 2005-05-19
- 打赏
- 举报
我觉得 boyxia(>>无天刀绝 [抵制日货]<<) 的说法有些偏激,我也同意.net 做项目(或是说一定规模的项目)时,成本会低,但风险呢? 如果真的是"反正做完了,收了钱,谁还管以后的事儿",那真的是只能让客户和市场做出选择了.
再者,.net 是上手快,容易学习,但是隐性的一个问题就是,做JAVA的公司会招一些对JAVA掌握水平高于.net公司招聘的对.net掌握水平的程序员(SO,可以解释为什么JAVA程序员平均工资可能稍高一些),另外,由于对JAVA经验相对较高,当然对软件开发(这个是通用的)技术会更好一些,所以,开发周期未必会比.net 高出很多,相反程序质量可能会高一些.
再,单纯的说真实项目中java 开发周期长,我想也是没有明确依据的(不是建立在同等水平程序员前提下),可以看看永中OFFICE这个例子,几年的时间里做出那么好的OFFICE,.net未必办得到,况且它在linux也跑得那么快(第一次运行真的难以相信,JAVA可以有如此速度),和WINDOWS下那么一致.
再者,.net 是上手快,容易学习,但是隐性的一个问题就是,做JAVA的公司会招一些对JAVA掌握水平高于.net公司招聘的对.net掌握水平的程序员(SO,可以解释为什么JAVA程序员平均工资可能稍高一些),另外,由于对JAVA经验相对较高,当然对软件开发(这个是通用的)技术会更好一些,所以,开发周期未必会比.net 高出很多,相反程序质量可能会高一些.
再,单纯的说真实项目中java 开发周期长,我想也是没有明确依据的(不是建立在同等水平程序员前提下),可以看看永中OFFICE这个例子,几年的时间里做出那么好的OFFICE,.net未必办得到,况且它在linux也跑得那么快(第一次运行真的难以相信,JAVA可以有如此速度),和WINDOWS下那么一致.
mahongxi 2005-05-19
- 打赏
- 举报
深度分析：企业患IE上瘾症？被套牢且难自拔！
无论今日Mozilla/Firefox 等自由软件形式的浏览器如何盛行，但恐怕只能在一些包袱较小的个人与家庭使用，对机构与企业而言，他们恐怕有不得不持续用IE的理由与苦衷。
此话怎说？举例而言，IE使用不符合W3C 标准的CSS 呈现特效，使用很近似但其实还是与JavaScript有别的JScript ，或者因为擅改JVM 而导致正统Java Applet 无法兼容且正确地执行等，这些都还是小问题，真正的大问题在于ActiveX。
许多企业运用ActiveX 来开发自用的网页型用户端应用程序，这些程序几乎完全无法在非IE的浏览器上执行，不仅是Mozilla/Firefox ，就连挪威的Opera 、KOffice 中的KOnqueror/Safari （Apple 以KOnqueror 为基础所自研的Mac 用浏览器）等都无法执行，这正是企业持续死抱IE的原因。
什么是ActiveX ？
想了解ActiveX 的故事，且让我们穿越时光隧道，回到1995年。ActiveX 可以说这是微软为了抵制1995年的Java Applet 而提出，Java Applet是小型的Java应用程序，只要替Netscape Navigator浏览器加装Java外挂程序（Java Plug-In），就可以在浏览器内点击（click）网页链接的方式，下载应用程序到用户端的浏览器内，并在浏览器内执行，而在此之前浏览器的功用除了浏览之外还是浏览，纯粹是多媒体式的信息、文件阅读器（Viewer、Reader）而已，而不是一个软件执行平台。
由于Netscape Navigator浏览器有跨平台的特性，不光是Windows PC，就连OS/2、UNIX、Mac 等各式电脑都可以安装与使用Netscape Navigator，如果浏览器不再只是个多媒体网页阅读器，通过Java Plug-In而成为一个应用程序执行环境时，那么使用者就没有必要非用Windows PC，因为程序可以在任何电脑上使用、执行。
这个推论并无错误，但似乎言之过早且过于理想，加上当年此推论被硅谷的知名媒体过誉报道，以致微软大为紧张，深怕Windows 的高占有率优势一夕尽失，因此推出IE 2.0后不仅可兼容执行Java Applet ，还能够执行微软自行提出的ActiveX ，ActiveX 的运用原理与Java Applet相似，两者处于完全竞争、抗衡的局面。
后来，Java Applet 后续的走势并不佳，反而是ActiveX 逐渐抬头。初期许多人学习Java Applet 只是为了以程序方式让网页有更好的动画效果，并非真的希望用在程序开发，并且Sun 与协力软件企业也迟迟无法推出方便（尤其是所见即所得）的Java Applet 开发工具，以致于学习Java Applet 的人多在后期转投靠Macromedia的Flash。
另一个放弃Java Applet 的理由也是由于微软作梗，微软虽取得Sun 的授权而能在IE上使用Java Plug-In，以便执行Java Applet ，但之后微软自行修改与添加JVM 及Java开发工具（微软 J++），如此以微软方式开发成的Java Applet 只能在IE上执行，失去了在其他非IE浏览器上正常执行的能力，Sun 因此于1997年一状告上法庭，数年后Sun 胜诉，获赔10亿美金。
被微软改造过的Java Applet 不良影响还不仅如此，其他问题包括执行Java Applet 须耗用较多的运算资源、执行过慢、配套函式库与API 不够齐备等，导致Java Applet 愈来愈少人使用，反倒是ActiveX 获得开发者的青睐。
ActiveX 可装不可停，可停不可移
虽然ActiveX 打败了Java Applet ，但不表示Java Applet 全然逊于ActiveX ，至少在安全性上比ActiveX 优异。Java Applet 的执行环境具有一个“sandbox ”的安全机制，倘若Java Applet 应用程序试图自行进行用户端的I/O 存取，就会被sandbox 先行阻隔禁止，以策安全，这是ActiveX 缺乏之处。（注：依然有许多网页型应用程序是使用Java Applet 来运作，如ICQ2Go（ICQ 的网页型即时通信）、WinVNC（网页型远端遥控软件）、股票的成交回报跑马灯等。）
那么，企业到底在何种地方使用ActiveX 呢？包括一些视讯保全的观看、软件版本的在线查核与更新、在线杀毒、网络管理等，不胜枚举，上述这些还是软件企业所提供的套装应用程序，至于企业自身的撰写开发更是不在话下，若改用IE以外的浏览器，等于是放弃上述这些软件的购置、开发等投资。
因为已投入及惯用ActiveX 而无法放弃IE还算事小，更严重的是ActiveX 为今日常见的安全漏洞，许多前端使用者粗心大意，轻易准允远端不明的ActiveX 软件之下载、安装、执行，导致电脑遭瘫痪、入侵。这样的苦恼问题一直到Windows XP Service Pack 2 出现后才有解， SP2 允许使用者在IE中自行操作与指定哪些已安装的ActiveX 软件（也称附加元件）当停止执行，以此确保安全性。
不过，这就笔者来看，这个安全似乎相当迟来，1996年提出的ActiveX ，一直到2003年的SP2 才能防范，甚至用更高标准来看，IE截至目前为止都不允许使用者自行将已下载安装的ActiveX 程序进行卸载（Uninstall ），只能封锁不予执行，这样的防范似乎还是太消极。
上面我们谈到ActiveX 的一些问题，以及企业Web 程序已在不知不觉中被绑住。那么，企业真的将因为ActiveX 而永守IE吗？对此其实开放社区也正积极努力，提出了Mozilla ActiveX Plug-In 的项目，希望在Mozilla/Firefox 上可兼容使用与执行ActiveX ，不过目前成效有限，而且是先就Windows Media 方面的ActiveX 元件开始支持，以能够平顺浏览网页中的Windows Media 内容为优先，其他ActiveX 元件的支持仍在其次。由此看来，要让Mozilla/Firefox 全面兼容所有的ActiveX 元件，恐怕要一段很长的时间，近乎遥遥无期。
因此，最好的方式是用户自行改写转移，但笔者相信采取此策略的可能也是微乎其微。企业多半不愿将已完成的应用程序再行改写，一方面要耗额外的投入心力，另一方面没有更多的效益与诱因，同时改写也容易造成错误变数，还要进行严密的改写后之验证程序。这也是今日许多企业仍坚持使用旧的操作系统、旧的程序执行环境，原因就在于兼容原有已开发投入的应用程序。
观来望去，企业只有在一种情形下会认真考虑改写ActiveX ，那就是前端电脑完全没有执行Windows 应用程序，完全只用Web 型应用程序，那么企业不会只为了执行IE而购买Windows 授权，这时才会考虑换去ActiveX ，而改写自然会考虑改成Java Applet ，或完全转成后端执行的程序（如ASP 、JSP 等），不过会采取前端执行自然有其考虑，所以改写成Java Applet 的可能性必高于改写成ASP 、JSP 程序，或者企业体悟到未来信息环境应当是前端全无软件安装、布建（Deploy）的纯Web 存取环境，这时才会改换成ASP 、JSP。
ActiveX 确实是IE上瘾中的最大重症，其他轻微病症也在前面略有提及，另外还有https （即SSL ，Secure Socket Layer）的传输支持问题，目前许多网站都只能支持IE的SSL 传输，碰到非IE的SSL 传输就无法顺利运用，只能回退到无加密的http传输，这也同样是IE上瘾后的一大副作用。
所以，很明显的，想继续保有ActiveX 习惯与投资就必须持续使用IE，想持续使用免费的IE就必须付费取得Windows 授权，这有点像一个逆向操作的主题乐园，不需要门票就可进场，且每个游乐设施都可不用钱地任意享玩，但最后出口处要收取每人一万元的场地清洁费，关于此合算与否就留给企业自行评定。
注：颜国伟是台湾CNET投稿作者，为自由作家，专精于IT软硬件报道写作。
无论今日Mozilla/Firefox 等自由软件形式的浏览器如何盛行，但恐怕只能在一些包袱较小的个人与家庭使用，对机构与企业而言，他们恐怕有不得不持续用IE的理由与苦衷。
此话怎说？举例而言，IE使用不符合W3C 标准的CSS 呈现特效，使用很近似但其实还是与JavaScript有别的JScript ，或者因为擅改JVM 而导致正统Java Applet 无法兼容且正确地执行等，这些都还是小问题，真正的大问题在于ActiveX。
许多企业运用ActiveX 来开发自用的网页型用户端应用程序，这些程序几乎完全无法在非IE的浏览器上执行，不仅是Mozilla/Firefox ，就连挪威的Opera 、KOffice 中的KOnqueror/Safari （Apple 以KOnqueror 为基础所自研的Mac 用浏览器）等都无法执行，这正是企业持续死抱IE的原因。
什么是ActiveX ？
想了解ActiveX 的故事，且让我们穿越时光隧道，回到1995年。ActiveX 可以说这是微软为了抵制1995年的Java Applet 而提出，Java Applet是小型的Java应用程序，只要替Netscape Navigator浏览器加装Java外挂程序（Java Plug-In），就可以在浏览器内点击（click）网页链接的方式，下载应用程序到用户端的浏览器内，并在浏览器内执行，而在此之前浏览器的功用除了浏览之外还是浏览，纯粹是多媒体式的信息、文件阅读器（Viewer、Reader）而已，而不是一个软件执行平台。
由于Netscape Navigator浏览器有跨平台的特性，不光是Windows PC，就连OS/2、UNIX、Mac 等各式电脑都可以安装与使用Netscape Navigator，如果浏览器不再只是个多媒体网页阅读器，通过Java Plug-In而成为一个应用程序执行环境时，那么使用者就没有必要非用Windows PC，因为程序可以在任何电脑上使用、执行。
这个推论并无错误，但似乎言之过早且过于理想，加上当年此推论被硅谷的知名媒体过誉报道，以致微软大为紧张，深怕Windows 的高占有率优势一夕尽失，因此推出IE 2.0后不仅可兼容执行Java Applet ，还能够执行微软自行提出的ActiveX ，ActiveX 的运用原理与Java Applet相似，两者处于完全竞争、抗衡的局面。
后来，Java Applet 后续的走势并不佳，反而是ActiveX 逐渐抬头。初期许多人学习Java Applet 只是为了以程序方式让网页有更好的动画效果，并非真的希望用在程序开发，并且Sun 与协力软件企业也迟迟无法推出方便（尤其是所见即所得）的Java Applet 开发工具，以致于学习Java Applet 的人多在后期转投靠Macromedia的Flash。
另一个放弃Java Applet 的理由也是由于微软作梗，微软虽取得Sun 的授权而能在IE上使用Java Plug-In，以便执行Java Applet ，但之后微软自行修改与添加JVM 及Java开发工具（微软 J++），如此以微软方式开发成的Java Applet 只能在IE上执行，失去了在其他非IE浏览器上正常执行的能力，Sun 因此于1997年一状告上法庭，数年后Sun 胜诉，获赔10亿美金。
被微软改造过的Java Applet 不良影响还不仅如此，其他问题包括执行Java Applet 须耗用较多的运算资源、执行过慢、配套函式库与API 不够齐备等，导致Java Applet 愈来愈少人使用，反倒是ActiveX 获得开发者的青睐。
ActiveX 可装不可停，可停不可移
虽然ActiveX 打败了Java Applet ，但不表示Java Applet 全然逊于ActiveX ，至少在安全性上比ActiveX 优异。Java Applet 的执行环境具有一个“sandbox ”的安全机制，倘若Java Applet 应用程序试图自行进行用户端的I/O 存取，就会被sandbox 先行阻隔禁止，以策安全，这是ActiveX 缺乏之处。（注：依然有许多网页型应用程序是使用Java Applet 来运作，如ICQ2Go（ICQ 的网页型即时通信）、WinVNC（网页型远端遥控软件）、股票的成交回报跑马灯等。）
那么，企业到底在何种地方使用ActiveX 呢？包括一些视讯保全的观看、软件版本的在线查核与更新、在线杀毒、网络管理等，不胜枚举，上述这些还是软件企业所提供的套装应用程序，至于企业自身的撰写开发更是不在话下，若改用IE以外的浏览器，等于是放弃上述这些软件的购置、开发等投资。
因为已投入及惯用ActiveX 而无法放弃IE还算事小，更严重的是ActiveX 为今日常见的安全漏洞，许多前端使用者粗心大意，轻易准允远端不明的ActiveX 软件之下载、安装、执行，导致电脑遭瘫痪、入侵。这样的苦恼问题一直到Windows XP Service Pack 2 出现后才有解， SP2 允许使用者在IE中自行操作与指定哪些已安装的ActiveX 软件（也称附加元件）当停止执行，以此确保安全性。
不过，这就笔者来看，这个安全似乎相当迟来，1996年提出的ActiveX ，一直到2003年的SP2 才能防范，甚至用更高标准来看，IE截至目前为止都不允许使用者自行将已下载安装的ActiveX 程序进行卸载（Uninstall ），只能封锁不予执行，这样的防范似乎还是太消极。
上面我们谈到ActiveX 的一些问题，以及企业Web 程序已在不知不觉中被绑住。那么，企业真的将因为ActiveX 而永守IE吗？对此其实开放社区也正积极努力，提出了Mozilla ActiveX Plug-In 的项目，希望在Mozilla/Firefox 上可兼容使用与执行ActiveX ，不过目前成效有限，而且是先就Windows Media 方面的ActiveX 元件开始支持，以能够平顺浏览网页中的Windows Media 内容为优先，其他ActiveX 元件的支持仍在其次。由此看来，要让Mozilla/Firefox 全面兼容所有的ActiveX 元件，恐怕要一段很长的时间，近乎遥遥无期。
因此，最好的方式是用户自行改写转移，但笔者相信采取此策略的可能也是微乎其微。企业多半不愿将已完成的应用程序再行改写，一方面要耗额外的投入心力，另一方面没有更多的效益与诱因，同时改写也容易造成错误变数，还要进行严密的改写后之验证程序。这也是今日许多企业仍坚持使用旧的操作系统、旧的程序执行环境，原因就在于兼容原有已开发投入的应用程序。
观来望去，企业只有在一种情形下会认真考虑改写ActiveX ，那就是前端电脑完全没有执行Windows 应用程序，完全只用Web 型应用程序，那么企业不会只为了执行IE而购买Windows 授权，这时才会考虑换去ActiveX ，而改写自然会考虑改成Java Applet ，或完全转成后端执行的程序（如ASP 、JSP 等），不过会采取前端执行自然有其考虑，所以改写成Java Applet 的可能性必高于改写成ASP 、JSP 程序，或者企业体悟到未来信息环境应当是前端全无软件安装、布建（Deploy）的纯Web 存取环境，这时才会改换成ASP 、JSP。
ActiveX 确实是IE上瘾中的最大重症，其他轻微病症也在前面略有提及，另外还有https （即SSL ，Secure Socket Layer）的传输支持问题，目前许多网站都只能支持IE的SSL 传输，碰到非IE的SSL 传输就无法顺利运用，只能回退到无加密的http传输，这也同样是IE上瘾后的一大副作用。
所以，很明显的，想继续保有ActiveX 习惯与投资就必须持续使用IE，想持续使用免费的IE就必须付费取得Windows 授权，这有点像一个逆向操作的主题乐园，不需要门票就可进场，且每个游乐设施都可不用钱地任意享玩，但最后出口处要收取每人一万元的场地清洁费，关于此合算与否就留给企业自行评定。
注：颜国伟是台湾CNET投稿作者，为自由作家，专精于IT软硬件报道写作。
boyxia 2005-05-19
- 打赏
- 举报
java很成熟，不能说.net不成熟，.net软件市场份额现在日益扩大，如果不成熟的话不可能成长这么快的，没有成熟和不成熟，只有相对成熟和相对不成熟。说java好的人更多的考虑到了java的本身的优良特性和个人的利益，java程序员工资高，地位高，而对于软件企业来说呢？还是回到原来的问题，两者开发成本的比较，从程序开发，到测试修改错误，到后期需求变更，再到后期维护几个阶段。欢迎大家提出自己的见解。
zr1982930 2005-05-19
- 打赏
- 举报
关注一下！
conan19771130 2005-05-19
- 打赏
- 举报
个人觉得j2ee难点,开发速度慢点,.net开发速度令人满意,两者的代码执行速度都不是很快,欢迎指教
LoveMango 2005-05-19
- 打赏
- 举报
本人总觉得J2EE部署麻烦，.NET使用方便灵活，但.NET的BUG较多。
boyxia 2005-05-19
- 打赏
- 举报
锤子说得有道理，谢绝浮躁。要走的路还很长，找到适合自己的那条路就走到底吧。
速马 2005-05-19
- 打赏
- 举报
C + C# == nuclear bomb
- -!
- -!
lucbesson 2005-05-19
- 打赏
- 举报
高手们写的时候是否考虑到了java和c# ，谁出的更早哦 ？
谁更成熟。。。。。
谁更成熟。。。。。
zdleek 2005-05-19
- 打赏
- 举报
语言或许有一定的关系，
但是有时候是不好比较的
但是有时候是不好比较的
kqh0319 2005-05-19
- 打赏
- 举报
up.....
加载更多回复（51）
