jnotify，文件，目录，及其他
前天混迹于freenode ##java的时候听到omry提及jnotify ，一个使用JNI通过本地库来监视文件系统变化的实用库，支持win32系统和Linux（需要INotify），而这位omry也正是jnotify 项目的admin。我觉得这样一个库很有用，因为平时能做的就是创建线程来监视，而通过JNI借由操作系统的支持，就方便的多，而且性能也稍微好一些。
继续阅读从太阳到木卫四
别急着骂我冒充天文爱好者，我说的是Eclipse和其基金会旗下的Callisto项目 ，或者说是"Callisto并行发布"。 前几天开始，Eclipse 3.2和Callisto这些字眼渐渐变得多起来，本人本着没事儿也要瞎忙的精神装作日理万机的样子无视这些逐渐升温的单词。刚看新闻才知道eclipse 3.2 RC3昨天发布了–呃，应该算是前天了，就去eclipse.org一通考古，才发现了这个Callisto项目，仔细看看，原来是个插件集，而且都只是eclipse.org提供的插件。 按照Callisto主页 上的说法，Callisto并行发布并不是提供新插件，而是将10个主要的Eclipse项目同时捆绑发布，以使得一些Eclipse生态系统中的成员更容易将Eclipse集成进各自的产品中。这10个项目是BIRT ，CDT ，DTP ，EMF ，GEF ，GMF ，Eclipse ，TPTP ，WTP ，VE ，几乎覆盖了一般的开发需求。
继续阅读Spring::NamespaceHandler
Spring 2.0带来的一个比较便利的好处就是更加灵活的XML配置方案。由于Annotation在设计方面的特殊地位，决定了它不会完全取代XML配置文件，所以我认为很长一段时间内，Java的server端框架不会把宝都押在Annotation上。Spring 2.0也是这样，解析XML配置文件这一工作不仅没有随着Annotation的加入而停滞，反而添加了更加灵活的配置方案–自定义namespace。
当然，自定义namespace远非说起来那么简单，又得有合适的XML Schema，还要自己实现Spring中的比较核心的接口和抽象类。下午才和Leon抱怨过，因为我无法像使用python的tuple和字典类型一样方便的访问java.util.List和java.util.Map的对象里面的数据，比如aList[12]或者aMap['name']，这些东西虽然通过其他方法也能解决，但毕竟不太舒服。这个问题的起因比较简单：我把一些JDBC相关的配置写在了一个db.properties文件里面，用Spring 1.2.x的时候，我习惯的做法是用一个org.springframework.beans.factory.config.PropertyPlaceholderConfigurer来把几个.properties文件解析，然后使用${name}的方法来访问某个属性所对应的值，当然这还是不够方便，我这破记性让我经常取了一些重复的属性名，非debug而不能得也。今天翻Spring 2.0 M4得文档，发现了<util:properties/>这么个好东西，可以从location指定的资源读取符合属性文件格式的配置信息，以一个PropertiesFactoryBean使框架在引用这个bean的时候可以访问到解析了的Properties对象。这个让我比较高兴，因为可以不用像以前那样把一些没什么关系的.properties文件用同一个PropertyPlaceholderConfigurer装载了，.properties文件的关系得以区分，我也不怕再取一些重复的名字了。问题又来了，就是那个比较无聊的问题：如果我想访问一个.properties文件中某个键名对应的属性值该怎么办？再联想开来，很多动态语言都提供的用键名做下标引用键值的方法，以及类似tuple这样的类型，Spring好像并没有为这种引用方法提供方便，放在Spring 1.x的时候，恐怕也得自己实现一些FactoryBean，然后在配置文件中设置一些property才能完成，很冗长。 所以我就想能不能通过自己解析一个namespace提供的配置，完成这个事情，最终效果就像这样：
推荐OpenOffice.org 2
不知道有多少人还在孜孜不倦地用着盗版的Microsoft Office，我曾经也是里面的一员，对此我感到十分赧颜，身为一位靠知识吃饭的开发人员，尽管水平不怎么样，也同样希望别人可以尊重自己的知识自己的劳动，而却一直以来使用了太多的盗版软件，肆意践踏自己一直奢望得到的尊重。
继续阅读