程序运行效率与灵活性之间的矛盾

实际应用中为求得更高的灵活性，往往借助于配制文件，如xml，properties文件等，但由于io操作效率过于低下，所以需要寻找合理的方法来解决这个问题，如静态区，JNDI，注册模式等，在容器一启动的时候就读取配制文件，这样以后就直接读取静态区或是JNDI查找就可以，但是这些往往都需要借助于容器，但是如果简单的Application的话，没有容器，也就不能用JNDI了，而静态区，随着Application运行的结束也就不存在了，所以当再次运行Application的话，还需要再次进行io操作，严重的影响了性能，不知道有没有更好的解决方案？

第一，从没听说过“没有容器就不能用JNDI”这种事。第二，启动一次application才加载一次配置信息，这点性能损耗会很严重吗？

OK! 如果不借助JNDI 的implement如何使用JNDI？我所说的容器，是泛指容器，不仅是EJB Container，还包括JTA Container,JNDI Container，JMS Container...

至于启动一次Application加载一次配制信息的话，是否损耗性能，你也不能一棒打死，同样，如果就是有一些Application需要经常性的重新启动，而如果每次用户都因为加载信息而等上几秒种的话，恐怕不能满足所有用户的口味吧。

这样的话，的确JNDI是不能用的。你说的就好象一个desktop application的环境，唯一能够利用的持久化信息来源也就只剩文件了。不过事情明摆在面前：你有那么些信息需要持久化，那么你就得花那么些时间来做IO。你不可能既要马儿跑又要马儿不吃草吧？要是用户不能满足，好办，换C++来做就是。

可以把配置集中写死在一个程序里面。
^_^ 别砸我，我怕怕！

其实也是可以的，如果配置不需要运行时写回的话。如果还要运行时改变再写回，你岂不是还要在程序里调用javac？

gigix

你的观点似乎一直很“执着”的热爱配置文件。
至于你说的观点，不用配置文件就不能动态改变了吗？这显然是错误的观点。
subclass可以代替配置的不同形式。虽然带来很多值得狠狠争论的话题，但是很多情况下，subclass要比配置文件好得多！
其实这个问题很值得深入讨论下去。
为什么呢？
因为现在所这Spring，Webwork等等具有容器概念的可配置文件形式已经越来越深入 “人心”，然而，有“滥用”的趋势。
本来可以用一个Subclass扩展的，很多人却选择了用配置文件的格式。
考虑如下两种情况：
1）一个class读取配置文件进行初始化，随着配置文件内容的不同，那个class有不同的行为。

2）superclass----〉subclass  ，将相应的不同配置形式的内容编码在不同的子类里。

很多人可能会选择第1）种，而且是带着一股欣欣然的心情去选择第一种方式，其实这种“随便”选择配置文件的方式是非常可怕的。
配置文件带来很多不得不考虑的问题：
1）配置验证
2）弱类型，往往用集合来保留实例对象。
3）失去了显式调用的意义，这在OOP中，是很被反对的
4）配置文件的管理，读取也需要引入多个jar，形成一个模块

但是这些配置信息是要持久化的。没有JNDI，当然更没有数据库，持久化到哪里？说来说去，还是文件。

就来考虑配置信息的持久化，没有JNDI，没有数据库，怎样来持久化，我能想到的只有是JVM中的静态区了，所以只要保证JVM一直处于打开状态，静态区就不会消失，可以写个后台线程，让它保证JVM不会关闭，不过这样是不是有点得不偿失？

呵呵，要是断电了怎么办？为了节约几秒钟加载时间，一次断电之后没准就得花几个小时来恢复以前的状态。