java体系的概念太多了，这只是最近看的很少一部分。

• 容器

  这是java web开发过程中非常强调的一个概念。顾名思义，在它的内部存放着某些东西，各种java对象，包括所谓的bean等等。java的容器也可以称其为一个应用服务，或一个框架，用户通过配置指定代码或者说对象、构件存放的路径，以及对象之间的关系、对象和容器直接的关系。这通常有一套标准，例如javaEE本身的servlet/jsp的规范，或容器本身特定的某些标准，你的配置和代码必须符合这种标准，才能被容器调用使用。标准有很多形式，xml的配置、java接口的实现、对象的继承、java的标注等等，他们决定了对象如何被容器调用、对象之间的关系、以及对象在容器中的运行状态。

  目前作为java web开发最常用的servlet/jsp容器是tomcat，企业应用服务器是jboss。spring框架虽然没有服务器的概念，但是从其包含、组织、调用java组件的特征来看，也可以说是容器了。

  回忆.net，虽然没有特别强调容器的概念，但是从程序的流程和组织架构来说，iis就是.net web程序运行的容器了。

• web生命周期

  在任何技术平台的web开发中，web的生命周期都是一个核心概念。由于web应用都是基于http协议和b/s模式，所以不论采用何种技术，其生命周期都是类似的。

  • 请求与响应：

    客户端请求-服务器端运算服务-响应，request->service->response，这个标准的http访问流程存在于任何一种web开发平台中。流程对应的对象引用和方法也都相似，HttpServletRequest封装http的请求，可以通过该对象获取请求相关的各种参数，HttpServletResponse封装对客户端的响应，通过该对象可以设置http流的各种响应数据，HttpServlet.service(HttpServletRequest req, HttpServletResponse res)则实现服务的计算内容，获取请求，再根据程序逻辑设置响应。

  • scope：

    web程序有其自有的运行环境和上下文，在java web开发中一般称其为scope（page|request|session|application）。

    • page 是最小运行环境，一个jsp page即一个servlet类实例，但是page scope并非指这个servlet实例的变量，它的有效范围是该servlet对象和某次http请求的交集，只能在当前请求当前页面有效。
    • request 是某次请求范围内有效，即使该请求在服务器端通过forward跨越多个servlet。
    • session（HttpSession） 是指某个用户会话的全过程，这是为了弥补无状态的http会话缺陷，通过cookie识别客户端并在服务器端添加状态的机制。
    • application（ServletContext） 是指在整个应用（context）范围内有效的程序环境。

    在这些scope中，request|session|application都可以通过setAttribute/getAttribute在有效范围内设置获取变量。这是一种常见的代码数据共享方式，不过存在线程安全问题，需要注意考虑并发情况。

  • 对象各自的生命周期：

    所有的对象都有其各自的生命周期，初始化-运行时-销毁。通常初始化和销毁是由容器控制，运行时会运行程序代码实现逻辑。同时，servlet还提供监听（listener）和过滤（filter）的机制，使程序能控制对象生命周期更广的范围。当然这些都必须实现指定的接口，并通过xml或标注等容器认可的方式配置编码，使容器能访问调用。

• jsp标签

  标签是web页面的表现中非常常见的技术，最原始的标签就是html模板内的变量替换，估计做web的人人都写过。java web的标签有jsp的标准标签、el、自定义标签，JSTL应该也属于自定义标签，只是后来作为标准发布了。

  • 繁杂的标签：

    jsp标准的标签实现，我个的感觉有些繁杂。java平台一向以自由著称，但是作为一种技术的标准，内容和实现应该尽量简洁，提供一种标准的实现方式即可，是否采用其它第三方库完全可以由用户自己选择。

    jsp的标准标签提供了jsp页面实现的基本功能，它包括基本的页面定义、servlet类程序定义、表达式、包含、异常等等，其他程序逻辑则通过代码片段来实现。继此之后，大家觉得在一个xml文档里面，java代码片段到处飞，看上去不太美观，因此jstl出来了。通过自定义标签，他试图把所有标准标签实现不了必须依靠代码片段实现的东西转换为标签，从而在jsp模板里消灭java代码片段。因此他实现了环境变量的设置和引用，异常，程序流转逻辑等等，甚至通过sql库实现数据库操作。我考虑了很久，除非那种没有任何性能要求，简单到只有1、2个的页面的应用，否则是不太可能采用这种方式来实现数据库操作的。而xml形式的程序逻辑标签（if|else|choose|when…）也过于繁琐，远不如代码片段简洁。

    I18N库倒是很简单实用，但是它的本地化文件数据格式太简单，只适合某些很简单的单词单句的本地化，如果有比较复杂的内容，估计这么简单的数据格式是无法满足要求的。不知道有没有接口可以对底层进行重写，否则实用价值有限。

  • el库：

    el是非常简洁漂亮的，基本上可以把他当作是某种脚本变量的引用，据说javaEE5以后官方也大力提倡使用。但是我觉得也挺逗，这不就和当初试图消灭jsp模板里面非xml风格元素的目标相冲突吗？el可完全不是xml风格，虽然他比java代码对文档的破坏性小，但他也仅仅是表达式，无法实现其他逻辑功能。

  • 自定义标签：

    通过tag api，或者通过简单的标签文件，用户可以创建自定义标签，这和asp.net中的自定义控件和用户控件如出一辙。在我以往的经验中，除了基于学习的目的，从来没有自己开发过控件，用户控件一般也只用于进行简单的包含，方便做缓存或部分逻辑控制。

    我感觉自定义标签和asp.net自定义控件的情况类似，多用于某些企业系统的开发，或者是某些商业库的实现。而在一般网站系统中去开发和自定义一套标签库是非常困难的，代价成本非常高。实现本身比较复杂，增加了开发人员学习成本，库的维护和发展得不到保障，增大了程序复杂度增大了运算资源的消耗。上面这些问题对于需求变化快、应用访问量非常高的网站应用来说是致命的，而对于一般的企业系统来讲影响比较小。

  • 代码和界面分离的传说：

    我相信所有做web的人——无论前端后端——都听过这么一个论述，如果web页面模板能够和后端程序完全分离，那么前端和后端能完全相互无干扰的工作，将大大提高工作效率。从理论上来说，如果能做到这一点确实能大大提高工作效率，然而能做到吗？所谓界面本身就是程序的一部分，他和程序逻辑是息息相关的。除非某个界面和程序完全没有关系，否则他必然存在某种形式的程序逻辑控制代码，不管这种代码是代码片段、xml还是简单表达式，又或者未来发明个别的什么东西。这是应用的需求和软件开发工作的实质决定的。

    又有某种说法，认为将程序控制实现为html格式类似的标签，可以帮助前端人员更容易识别和修改html模板，这个说法更不可信。我长期和设计师及前端人员合作，事实上除极个别极端情况，大多数人都很容易理解简单的程序语法，如变量或对象声明、简单的程序逻辑控制等。甚至很多设计师为了页面控制方便，自己写一些简单控制逻辑。这个学习成本很低，而且基本上所有的流行程序语言语法都类似。而仅jsp的标签库就有多少种？其表达形式何其花样百出？很多时候还存在需要设计师理解标签库设置界面外观等等情况，对设计师来说复杂度远远高于去了解一门程序语言的简单语法。

  对标签这种形式，我的态度是实现方式越简单，表现形式越简洁越好，不必完全拒绝程序代码，不要过于苛求xml文档化，过犹不及。对于jsp标签的现状，我觉得可以参考asp.net，通过继承或者实现分部类，把jsp的大部分代码逻辑放到后端java程序中去，分离代码和模板。或者强化el，有限制的实现某种jsp中的脚本语言，甚至嫁接一个别的脚本语言进来。嗯，都不错。

• bean就是组件

  在我未接触java之前，就总是听说javaBean和ejb，我不知道为什么要取名为bean，那应该只是源于java的某种趣味的称呼吧。bean就是对象，没有什么不同，只是他需要符合某些标准，以方便jsp或其他调用。看了这些标准，bean和.net中的组件是一个概念，没有什么区别。在jsp中访问bean很简单，就是一些现成的标签，设置一下bean的scope。我仍然觉得这种标签访问方式感觉很恶劣……

  关于ejb，我看的这本书简单讲了一个例子，如何创建并访问。ejb我感觉和bean的差别在2个方面，一是ejb是分布式组件，除业务逻辑类本身外，还需要按标准创建相关的接口、配置、部署，最后提供远程调用的能力。二是ejb的服务器应该会提供强大的管理功能，组件之间的关系、结构组合、性能优化、事务等等，这一部分我看的书没有提。书还是ejb2的例子，ejb3据说已经大大简化了，嗯，待学习了。

• jdbc：

  总的来说，jdbc和其他技术的数据接口没有太大差别，这种趋同是由数据库支持的底层机制所决定的，不会因上层平台技术改变。比较有趣的是，jdbc实现事务是把先取消自动提交事务，然后执行sql，再commit，失败则通过异常处理rollback。

• 有趣的java

  搞java也一个多星期了，感觉java确实很繁杂，不论语法还是平台框架，很多东西不如.net平台简洁有效。但是java更加自由，整个开源世界存在很多框架、技术可供你自由选择——当然这种选择是需要成本的，有时候这也是一种痛苦。另外，对于软件构架，java更趋向于从技术和程序的角度，而.net趋向于从用户的角度，对于技术人员来讲，java的这种视角更加可贵。

想找基于java的web开发书，原来选定的几本oreilly的书后来看看，版本都太老了，而且内容比较分散，不适合入门阶段上手。无意在书店翻了翻这本，看了一遍目录感觉还不错，但是基于以往的恶劣经验，我很久没有看国产技术书籍了，有些犹豫。又详细看了一两章，回家又考虑再三，最后在amazon.cn买了。

花了4天时间，一口气看完，感觉挺不错。

优点

• 技术体系比较完整。关于java web开发基本的各方面技术都讲到了，重点是servlet/jsp及其在tomcat下的部署，内容详实。其他ejb、struts、ant、log4j等相关技术和工具也简单带过，使读者有初步的了解。
• 行文流畅，逻辑清晰。文字阅读都很流畅，没有什么晦涩的地方，理解没有什么问题——也许这和我以往.net web开发经验有关，不过文字叙述确实不错，就算没有太多的web开发经验应该也问题不大。
• 理论和实践并重。技术的讲述既有原理，也有代码实践，还包括servlet/jsp类的简单类图和源代码，方便理解。

吹毛求疵一下。这是一本教你如何上手servlet/jsp的书，一本教程，读完了你应该就可以上手做一些相关实践开发工作，但是在此之外，你也不太可能有其他更多的收获。作者就是站在一个普通的开发人员的角度，来讲述如何完成一系列工作，做一个合格的开发人员，仅此而已。和我们常看的那些国外的经典技术书籍相比，此书缺乏某种大的视角。我看完这本书，立刻又去翻了一下《JSP设计》，两者都是讲的相同的东西，但是阅读的体验大不相同。

嗯，最后，这是一本好书，如果你希望掌握java web开发的基本技能，这本书是一个不错的选择。

一本非常棒的书，不愧“head first”的称谓。清晰的条理，生动的图示，偶尔来点老外的幽默——其实中国人不太能理解，阅读体验非常舒畅。oreilly的这个系列应该都很熟悉了，优点多多估计大家都知道，就不提了，说点不优的吧。

• 如果你熟悉一门类似的静态面向对象语言（例如C#）那就不要看这个了，你会觉得有些罗嗦，因为大部分语言特性你都很清楚，没有必要看那么多示例、提示和比较等等；
• 如果你是想全面的了解java语言，估计你会很失望，这本书里面甚至没有讲“反射”；
• 如果你想找一本语法参考，那这不是你想要的（好像有点吹毛求疵……）；

好吧，基本来说，如果你没有C#的熟练经验，并且想学习java语言，那这几乎可以说是你必看的第一本书，因为他实在太……嗯，也没有别的语句了，实在太棒了。

当看完了这本——一个有足够coding经验的人大概需要2~3天，如果还想继续比较全面的了解java语言，那就看这个

很经典的java手册，全面描述了java的语言特性，简洁明了。可惜，中文版把后面的参考手册截了。出版社的本意是好的，大家可以少花钱，网上查查就行。 可惜Java网上文档的质量啊，实在不咋地，别的不说，就那个排版和字体，看起来真是头疼。

建议以后还是保留，不翻译也没关系。

• JAVA语言（Head First Java 好书，Jote大奖，但是居然没讲反射！ / Java技术手册 手册参考类 / Effective Java 实践技巧类 ）
• JSP/Servlet （Head First Servlet＆JSP / JSP设计 虽然04年的，但是经典，讲jsp2.0，也不算过时。）
• JavaEE概览 （JavaEE5 权威指南 – 这本书评价一般，不知道有没有其他javaEE概览的书推荐）
• MVC框架 （Struts：深入浅出Struts 电子书 / 深入浅出Struts 2 据说翻译的很差 ..）
• IOC框架（Spring or Guice：Spring in Action Guice只能看文档了）
• ORM框架（Hibernate：精通Hibernate 新书，oreilly的，应该不错。）

在网上搜了很久，好象也没有看见什么很经典的好书，一般来说总是存在版本过旧或翻译过烂的问题，失望。 后来也找到了不少好书，不过翻译过烂的问题总是存在的……

en，前3先搞搞，后3慢慢再来。

解决：
拷贝合适的中文字体到JAVA_HOME目录jre字体库fallback目录即可
sudo cp /usr/share/fonts/wqy/*  {$JAVA_HOME}/jre/lib/fonts/fallback/