Eclipse包含很多插件，插件之间有复杂的依赖关系，如果使用单独下载安装的方式，容易遗失部分需要依赖的插件。
在Ecliipse的Software Update功能中安装插件，能够解决插件依赖的问题，但是在Eclipse 3.4之前的版本，Software Update不能够多线程同时下载，遇到网速较慢的更新站点时，需要漫长的等待，有时候安装一个插件，需要数个小时，甚至更久。
在Eclipse 3.4之后，Software Update有了很大的改变，可以多线程下载了，但是不能手工选择镜像，它会笨笨的选择一些很慢的站点，效果变得更差了，下载速度时快时慢，但是经常都比以前手工选择镜像要慢。经常选择一些只有数百B速度的下载站点，令人抓狂！
所以说，Eclipse 3.4的Software Update功能依然令失望。
期待数年，终于盼来了新版的Software Update功能，但是新版的更差了，哎。。。
摘要: 我们在开发中，经常需要遍历一个目录下的所有文件，常用的办法就是使用一个函数递归遍历是常用的办法。但是递归函数的缺点就是扩展不方便，当然你对这个函数加入一个参数FileHandler，这样扩展性稍好一些，但是仍然不够好，比如说，不能根据遍历的需要中途停止遍历，加入Filter等等。我实现了一个FileIterator，使得遍历一个目录下的文件如何遍历一个集合中的元素一般操作。
阅读全文
http://openjdk.java.net/上的Announcements:
2008/04/28
New Project approved: More New I/O APIs for the Java
Platform
包括内容：
- 4313887 New
I/O: Improved filesystem interface
- 4640544 New
I/O: Complete socket-channel functionality
- 4607272 New
I/O: Support asynchronous I/O
让人期待太久太久了，终于来了，Java在大规模并发、高性能方面又进一步，JSR 203应该会在JDK 7中实现，届时随着JDK 7的发布，将会有更多的基础软件使用Java实现，而且有极好的性能。
在磁盘I/O和网络大规模并发I/O方面都会得到更好的性能。
可以预见受益的程序：
1、WEB服务器 Tomcat、Jetty等，在Windows下，Java将可以使用IOCP，而不是现在nio所用的select，网络并发性能将会得到大幅度提升。在Linux下则应该改变不多，毕竟linux现在并发最好性能的网络I/O EPOLL，JDK 6.0 nio的缺省实现就是epoll。
2、数据库应用程序。如Derby、Berkeley DB Java Edition等使用Java实现的数据库，性能将会得到更好的提升，有望能够诞生和Oracle、SQL Server一样强大的100% Pure Java的数据库系统。
3、其他网络应用程序。例如DNS、LDAP等，随着MINA之类的框架更强大和JDK的原生支持，将会越来越多的服务器程序使用Java实现。
在新项目中，除了一些框架所依赖的配置文件使用XML外，基本没有使用XML。JSON基本替代了原来XML在程序内的位置。在以前，我们不愿意使用一种私有的格式，于是选择了XML。选择XML的理由，可能是大家都用它，所以我们也用它。
XML 是一种很好的技术，但是目前的情况来看，XML被滥用了，SOAP是XML被滥用的一种典型，程序内部的表示使用XML也是滥用的一种典型。看到的一种情况，一个对象toString使用XML格式输出，导致日志文件十分罗嗦，调试时，在watch窗口中看到一大堆<tag>。
在新项目中，认真考虑这种情况，找到了另外一种选择，那就是JSON。选择JSON的理由很充分：
1、JSON的解释性能要比XML要好，要简洁紧凑。
2、可读性要比XML好。JSON本身就是JavaScript的语法，和程序员的思维，而非文档编写的思维。
3、JavaScript原生支持，客户端浏览器不需要为此使用额外的解释器，在web环境中使用特别合适。
在java中使用json，目前需要注意一些情况：
1、目前开源的JSON-LIB代码质量不好，最好是在此基础之上修改一个版本，或者自己重新开发一个版本。
2、使用new Date的方式替代JSON-LIB中的{year:2007, month:12, ....}之类的方式
3、JSON-LIB中，object的propertyName在输出的时候，都带上""，例如{"name": "温少"}, 其中name是的双引号是不必要的，在输出时应该判断，不需要的就是就不加上""，减少网络流量。
4、JSON的解释器中，应该支持简单的表达式，例如new Date()、new Date(2939234723)之类的，这使得JSON的表达能力会更强一些。
5、JSON应该分两种，一种只支持简单格式，类似开源的JSON-LIB，一种是通过JavaScript解释器来实现的。后者在程序中传输数据时，能够得到更强大的表达能力，但是也会导致安全问题，需要慎重使用。
1、
XP中的结对编程。XP编程中，有一些思想总结的很好，例如测试驱动，但又有极度的荒唐的就是结对编程。结对编程是我看到过的最荒唐最可笑的软件工程方
法，两倍的投入，一半的产出，可谓事倍功半。以前看结对编程只是觉得荒唐可笑，后来看了李安的电影《断背山》，觉得以“断背”来形容结对编程最适合了，结
对编程简直就是专门为“男同志”们度身定做的软件工程方法，你想一对“男同志”，每天手牵手背靠背进行“结对编程”，是多么“浪漫有趣”的事情。不过这只
对“男同志”们的浪漫有趣，对工作本身一点也不有趣！
--------------
2、JDO投票闹剧（2004-2005）。
一个通过黑客式静态AOP方式旁门左道实现的持久化技术JDO，竟然会被一些人追捧，这本身就是一个很荒唐的事情了。在JCP的投票中，JDO被否决了，
这一点也不奇怪，奇怪的是投票结果出来之后的闹剧。一些人以“政治阴谋论”来说事，说JDO不被通过，是因为政治原因，而非技术原因，这个荒唐的理由竟然
被社区的很多人相信了，一片声讨，JCP迫于压力，重新投票，通过了JDO相关的JSR。但是JDO并没有因此有一点点起色，一直沉沦至今。JDO通过静
态AOP（enhance）的方式使得代码无法调试，就单这一点，就足以使JDO永远无法流行。
这件事情很明确表明两点：1)、不要相信一些技术作家的判断力；2)、普通的大众没有判断能力，会人云亦云。
当年荒唐的文章选录：
《程序员》2005年第2期 http://blog.csdn.net/gigix/archive/2005/01/21/262163.aspx
---------------
竟
然64个annotation，没有分类，放在同一个package下，同一个package（javax.persistance）还有其他java文
件，共有88个java文件。不看内容本身，单从表面，都觉得这是混乱不堪的事情。这是那个猪头的杰作？glassfish上下载的源码中，这些java
文件似乎都没有author，估计也不好意思把名字放出来见人吧！
------
觉得对象关系存储方面一直没有突破，也没有好的产品出来，其中一个原因，就是从没有过优秀的工程师投身过这个领域。关系数据库为什么能够一直坚守领地，成为绝大多数商业应用的基石，其中一个原因就是有过大量的精英投身于此，包括两个图灵奖获得者。
关
系数据库，为了描述关系，创造一门SQL语言，将关系一些操作，例如投影（select）、选择（where）、分组(group
by)等等，抽象得形象易懂，功能强大。对于数据的操作，SQL语言是最强大，也是最方便的，也是最易于使用的。一些非程序员的IT从业人员，非计算机专
业的人员都能够熟练掌握SQL。
OO和Relational都是伟大的技术，从计算机最高荣誉奖可以看出这两个技术的伟大。OO的图灵奖获得者是三个，Relational的图灵奖获得者是两个。
面向对象技术自1967年simula引进以来，所想披靡，93年-98年从C++开始流行，然后到Java，成为主流编程技术。Relational没有OO那么辉煌，但是在数据存储方面的地位固如磐石，长期占据绝对的地位。
曾
经OO技术涉足于数据存储领域，但终究没有成功。面向对象数据库的变现总是差强人意，面向对象的方式操作数据，总是不如使用关系那么方便，那么灵活，那么
易于使用，那么好的性能。于是人们在数据存储和处理方面，不在青睐面向对象技术，而是仍然使用关系方式，使用SQL语言，使用关系运算操作数据。面向对象
数据库成了昙花一现的东西，并且可能永远都不会再流行了。
OO成了主流编程技术，Relational占据了绝对的数据存储地位，这两大技术需要交互，需要桥接，这需要OR-Mapping。Relational虽然好，但我们也要与时俱进，所以也需要OR-Mapping。
但
是，做OR-Mapping时，不积极吸取relational方式对数据处理的灵活性、方便性、简单性，而只强调Relational和对象之间的的
Mapping，试图以面向对象的方式操作数据，这是错误的方向。以前的EJB、现在Hibernate、JPA都犯了同样的错误，试图以更面向对象的方
式操作数据，从而导致复杂混乱的模型，这也是JPA的现状吧。例如user.getGroup()，目前的ORM试图以纯OO的方式操作数据，所引起的
LazyLoad、n+1等问题，使得事情变得复杂而且混乱不堪。
一些开发人员，去学习Hibernate，不学习SQL，有人提倡，只需要了解面向对象编程技术，不需要了解关系技术，亦属于本末倒置。需求人员都会用的SQL语言，对数据操作最方便最简单最强大的SQL语言，竟然成了令人生畏的纸老虎，可笑啊。
-------------
以下是过去的一些业界浮躁不理智：
1、面向对象数据库。曾被热衷而吹捧，面向对象数据库的变现总是差强人意，面向对象的方式操作数据，总是不如使用关系那么方便，那么灵活，那么易于使用，那么好的性能。于是人们在数据存储和处
理方面，不在青睐面向对象技术，而是仍然使用关系方式，使用SQL语言，使用关系运算操作数据。面向对象数据库成了昙花一现的东西，并且可能永远都不会再
流行了。
2、
JDO投票闹剧。2004-2005年，JDO的JSR在JCP投票被否决的，无聊者在Java社区以及媒体发起闹事，阴谋论其为政治谋杀，几大公司是的
迫于形象，重新投票使得JDO被通过，但JDO这种静态AOP叫雕虫小计式技术，不单开发过程不方便，而且会使得"enhance"之后的代码不可调试。
这完全是对开发者不友好的技术，没有前途的技术，竟然会有人为它在JCP投票不通过鸣不平。这件事情使得我更坚信一点，不要相信那些技术编辑的判断力。
3、
AOP。也是最近这几年流行的一个名词了。起了一个和OOP相似的名字，但是和伟大的OOP相比，它完全不算是什么。AOP只是一种很小很小的技巧而已，
静态的AOP是黑客式的插入代码，会导致代码不可调试，动态的AOP能力有限，AOP最常被引用例子“日志AOP”是不合适，有用的日志通常是精心设计
的，AOP方式的日志在生产环境中基本上是不可用。OO这么多年，这么为伟大，人们总是希望自己能做点什么和伟大的OO相比，于是命名为AOP，这是一个
可笑的名字，前些年还有人谈论面向对象的未来是面向事实，也是同样的可笑。AOP有价值，但它是一种小技巧，和名字不般配。
--------------
目前在流行，但是可能是不理智的技术：
1、hibernate之类的ORM，试图以面向对象方式操作数据，和面向对象数据库一样，重蹈覆辙。
2、Ruby，一个小脚本语言，只是因为动态类型、mixin之类的功能，还没有被证明有生产力，有效益可用的脚本语言，就被媒体吹到天上去。Ruby有价值，但是最终结果会离大家的期待相差甚远。
摘要: 本文介绍流行的非阻塞算法关键思想Compare And Set在数据库开发中的应用
阅读全文
由于在实际工作中使用到了mina，所以一直关注其mail-list。
最近mina的mail-list讨论的一个问题，就是提供的manual close connector，这个问题可害惨我了。
原来的Connector，无论是SocketConnector或者VmPipeConnector，都是没有提供close方法的，而且不会自动释放。
原来做得一个网络程序客户端，每次重新创建的时候，都会new SocketConnector，可是，SocketConnector不会被GC回收的，所使用的线程和内存都不会自动释放，这个程序在服务器断开时会重连，于是，当服务器重启或者网络中断时，内存泄漏就产生了，程序慢慢的占用更多的内存，直至崩溃！
解决此问题的办法就是，要么使用Singleton，要么使用即将发布的1.1.3!
