3.1 工作中主要使用什么ide环境？
java平台开发工具在工作中应用情况，调查显示sun netbeans占8.7%， bea weblogic workshop 占13.1%，intellij idea占3.2%，borland jbuilder占11.6%，ibm websphere studio application developer 或 rational application developer占9.2%， eclipse jdt占38.6% ，oracle jdeveloper占6.3%， 不使用ide7.7%， 其它ide占1.6% 。
图表 7 ide环境使用的分布状况 
eclipse在java开发工具中的霸主地位已经毋庸多言。这组调查数据真正的有趣之处在于：仍然有7.7%的开发者宣称自己不使用任何ide――笔者不禁越俎代庖地为他们的工作效率捏一把汗。另一项值得担忧的数据是11.6%的开发者首选jbuilder。borland公司在今年已经出售了整个ide部门，jbuilder的前途可谓多舛，这些开发者也很可能需要选择另一个ide。
作为个人意见，我要为intellij idea只有3.2%的首选比例打抱不平。个人而言，idea是我感觉最顺手的一款java ide，它对于开发效率的帮助相当显着――相比之下jbuilder和netbeans能够带来的帮助就有限得多了。而且尽管是商用软件，idea的授权协议对于开发者还算友好。从软件企业的角度，至少在我看来，购买idea比购买jbuilder要更划算。
3.2 考虑在未来更换到哪种开发工具
调查显示，未来考虑更换到以下开发工具sun netbeans占8.3%， bea weblogic workshop 占12.6%，intellij idea占2.5%，borland jbuilder占2.5%，ibm websphere studio application developer 或 rational application developer占4.9%， eclipse jdt占7.5% ，oracle jdeveloper占12.4%， 不打算更换开发工具占7.9%，其它占41.4%。
图表 8 更换开发工具的意向分布状况 
从这组调查数据来看，几乎所有java开发者都对自己使用的ide不满意――只有7.9%的开发者表示不打算更换ide工具。另一方面多达41.4%的开发者说不出究竟哪一款ide才能让自己满意――他们无奈地选择了“其他”，而不是任何一款常见的ide工具。大家都对java的开发效率有所不满，却又想不出有什么工具可以帮忙，这是否说明这是java语言本身固有的问题呢？
3.3 主要使用哪种java开发框架
调查显示，java开发人员主要使用的开发框架jsp占64.9%，struts占45.7%，hibernate占40.2%，spring mvc占19.4，ejb占18.7%，jsf占13.8%，移动终端操作系统占9.9%，spring web flow占8.3%，pojo占5.9%，appfuse占2.6%，trails占2.3%，stripes占1.9%，tapestry占1.9%，seam占1.8%，wicket占1.7%，rife占1.4%，其它占5.0%。
图表 java开发框架的使用分布状况
前几年曾经火热一时的“框架大战”已经安然落下了帷幕，各种框架都找到了自己应有的位置――成熟的不仅仅是java语言，还有java应用（尤其是javaee应用）的架构和解决方案。
struts和hibernate几乎已经成了javaee应用的常规配置，从调查数据上我们也能够得出同样的结论：超过45.7%的开发者用到struts，用到hibernate的开发者也有40%；而tapestry、seam、wicket、rife等框架都用者寥寥。在一个成熟的技术平台上，各个项目的技术方案会在很大程度上趋同――因为所有未知领域都已经被探明，各种问题都有对应的最佳实践，架构师们可以参考的成功案例越来越多。就拿javaee来说，今天的架构师们需要考虑的问题比之三年前已经简单多了，这就是成熟的价值。
曾经掀起“without ejb”风潮的spring框架最终与ejb分庭抗礼――两者分别占有19.4%和18.7%开发者的眼球。作为j2ee without ejb一书的译者，我得说这是个好现象：有些项目选择了spring，有些项目在分析之后认为ejb更适合自己。作为一种思潮，“without ejb”并不是真的要把ejb一棒打死，而是希望开发者们经过思考分析，找到自己需要的架构方案。
jsp经过几年风雨洗礼依然把持头把交椅，看来所有的框架表示层都离不开jsp而存在，而作为jsp的手足兄弟jsf也是仅次spring之后又一个后起之秀，jsf能否实现jsp的合理过渡我们还要侍目以待。
第4节 java技术应用状况
4.1 应用中主要用什么工具访问数据库
调查显示，在工作中访问数据库的常用的连接方式，jdbc直接访问占36.3%，hibernate占24.6%，简单的sql映射工具占14.9%，自制的持久化框架占11.3%，entity bean连接占4.6%，jdo占3.6%，其它的o、r映射工具占4.7%。
图表 访问数据库工具的分布状况
这是整个调查中最令人迷惑的一组数据：在问题6中，40.2%的开发者表示自己用到了hibernate；但根据这一组数据，只有24.6%的开发者使用hibernate来访问数据库，直接使用jdbc的却有36.3%。如果这些数据没有问题的话，另外那15.6%（40.2% -24.6%）的开发者究竟用hibernate来做什么呢？
抛开这个疑问，这组数据带来的好消息是只有4.6%的开发者仍然使用entity bean来访问数据。在整个ejb2的体系中，entity bean已经被证明是最弱的一环。如果再考虑ejb3的问世和遗留系统的存在，也许我们可以说：已经没有人再用ejb2 entity bean来开发应用程序了。
不过好消息总是伴随着坏消息。坏消息是：还有11.3%的开发者使用自制的持久化框架。数据持久化是一个非常重要、非常复杂而又非常通用的问题，耗费自己的时间和精力去解决这样的问题，一言以蔽之曰“吃力不讨好”。既然已经有hibernate等成熟的框架存在，除非是维护遗留系统，否则还是请不要重新发明轮子了吧。
11． 应用中主要用什么方式实现web用户界面？
调查显示有46.3%的开发人员使用基于“请求-响应”模型的web框架（例如struts/webwork/spring mvc等），基于事件模型的web框架（例如jsf和tapestry）占5.1%， 自制的web框架 ajax（javascript + xmlhttp）占16.0%，基于java技术的rich client（例如webstart、eclipse rcp等）占11.4%，基于非java技术的rich client（例如.net桌面应用）占2.2%，我不开发web应用占6.3%。
图表 实现web用户界面的应用状况 
和别的领域一样，在web框架这个领域需要的创新也很少。近半数的开发者采用最为传统的、基于“请求－响应”模型的web框架，例如struts、spring mvc、webwork（已并入struts）等。值得一提的是，有12.4%的开发者用到了ajax。在2006年里，ajax的应用在互联网上随处可见，java开发者们也必然会越来越多地接触到这方面的技术。
另外尚有22.3%的开发者表示自己使用自制的web框架或者干脆不使用任何web框架，这不能不说是一个遗憾。成熟的web框架（例如struts）已经足以解决几乎所有的问题――以相当简单的方式，在这种情况下仍然去自制轮子也许并不是一个好主意。
12． 未来您可能会转移到以下其它语言开发吗？ （多选）
调查显示不打算转移 占54.3%，转移到c/c++占23.1%，转移到.net占17.6， 转移到php等脚本语言占5.5%，转移到 ruby等动态语言占10.1%，转移到php等脚本语言的占5.5%，转移到delphi的占5.0%，转移到vb占2.5% ，其它占2.6%。
图表 12 转移到其它语言开发的意向分布状况 
以史为鉴能知兴衰。就在五六年前，c/c++还是应用开发的主流；但从前面的调查数据我们已经看到，很多从前的c/c++开发者转入了java阵营。这给我们一个提示：现在成熟稳定、如日中天的java，难道不会步上c/c++的后尘吗？
编程语言的衰亡并不意味着人们不再使用这种语言：cobol应用的数量远远超过java，众多的程序员仍然在使用cobol。一种编程语言的衰亡，表现为它所涉及的技术完全稳定，不再涌现大量的创新；它所适用的范围完全确定，人们不再尝试在新的领域应用它。由于缺乏创新，人们不再有热情去研究探索它，它在传播媒介（包括网站、图书等）出现的频率也逐渐降低；由于应用领域固定，它对人才的需求也趋于稳定，不再创造大量新的就业机会（另一方面，精通这门语言的开发者所受的竞争会更小，也更容易得到丰厚的回报）。cobol正是在这个意义上被认为是一种已经衰亡的语言，c/c++正在走上这条道路。那么java呢？
这是一个问题，我不打算在这里给出答案。我想说的是，软件开发领域的技术总是在飞快地变化，在变化面前每个人都有必要思考自己的出路。根据我们的调查数据，有54.3%的java开发者表示不打算转移到别的开发语言。我并不想断言这种选择（或者更准确地说，这种心理状态）是否明智，只是希望所有同行都牢记过去短短十年的历史，经过深思熟虑之后再作出判断。
闽公网安备 35060202000074号