Ext 2.0 for JSVM

1. 严格按照一个“类/对象”对应一个相同名称的文件的方式保存。

wch3116 , 取“别名”的一部份原因是向后兼容。

基本上所有的库都用这种方式来管理源代码

这一点我注意到了，但实际上 Ext 并没有做到很好的向下兼容。

“因为classloader发现已存在A”这种说法，已经带有一定的破除回环算法在里面，不过AB两个类相对来说简单，多几个类九不能简单地说“发现”了。在B尚未被import完毕，A可能是不能被表示为已经存在的。

解析Ext模块之间依赖关系的工具非常简陋，几乎没有共享出来的价值，呵呵。
大概原理是：通过正则表达式匹配出当前模块的代码中引用了哪些其它 Ext 模块的名称，然后在文件头部生成 $import 语句。
但是存在一些地方是需要手工调整。因为模块之间文件头部“静态”import 不能形成回环，循环import会造成 jsvm engine 的“死锁”。所以必须将一些造成回环的依赖链打断，调整为运行时动态的import。
启用过smartloader的页面，不会存在多次xhr交互的情况。当然这并不否定import支持多个动态参数是一个好的办法。

再谈 js 代码的加载问题

我们在开发一个 rich javascript 应用时，一般会遇到两件事情：
1. 代码应该按功能、模块或其它合理粒度方式切分到多个文件单元中，以便于管理维护和重用。
2. 系统运行时，应该按需加载所要执行的模块代码。因为将程序所有可能要用到的模块都事先全部加载进来听起来并不是一个好主意。

由于 js 代码因为设计上的需要被切分成多个文件，XMLHttpRequest 同步操作造成浏览器阻塞，如果网络不畅，这个过程时间长的话，浏览器的现象是假死（没有响应了）
传统的 <script> 标签方式加载多个 js 文件显然没有出现上面的问题，于是异步加载方案又被重新考虑进来。

其实在比较早（大概是2004年）的一次讨论中，有位网友提到了类似的问题，他提出了一个“异步加载”的方案。我们对此也做了不短时间的讨论。
但我一直坚持以为解决问题的方向不应该是“同步”和“异步”之间的选择问题。

“异步” 不仅打乱了开发人员的一般习惯思维方式，同时也改变了程序顺序加载执行最朴素的规律。
对于模块之间的静态依赖，或者程序对模块的静态需求，采用预加载的方式，然后通过事件侦听或者回调程序入口来继续加载后的的程序执行尚且可以。
但这些依赖或者需求是程序运行时动态决定的，而采用异步的方式肯定造成程序分支增多，增加了系统的复杂性。

而这一切就是为了解决浏览器同步加载多个文件时而造成的“假死”？
浏览器假死不是“同步”这个模式（概念）本身的错误。而是现有的环境（条件）造成的。
试想，如果仍然是同步阻塞，但没有造成浏览器假死是不是也能接受？
所以，我觉得可以通过其它方式来解决这个问题。

本地浏览模式或者网络相当顺畅的情况下，我们几乎不用太担心浏览器因为这种原因而造成的假死。
如果能为页面为单位，记录每个页面所需要的模块（代码），当下一次程序被运行时能提前将这些代码通过非阻塞的方式预加载到缓存（内存）中，
之后的代码加载都在内存中进行，虽然还是同步方式，但没有网络IO的操作，问题是不是解决了？

jsvm 2.06 之后的 smartloader 模块（扩展）就是基于这个原理工作的。
开发人员依然只需考虑设计层面的问题，而不必去关心过多加载次数造成的麻烦。

没错！如今js framework很多，还有很多人都在设计自己的framework，如果这些framework之间能达成协议，采用相同规范的接口，那么基于这个规范，一样可以实现跨framework/container的js开发。

我个人推荐尽量减少编译时的依赖，尽量使用运行时的动态依赖。

jsvm 在处理 $import 造成的回环，面临两个选择。
发现回环，抛出异常中断加载，或者忽略继续运行（因为头部的$import进来的模块不一定是编译时就需要的，也许是运行时才用到的）
最后jsvm暂时选择了前者。这个矛盾现在依然存在，是一个如何取舍问题，没有绝对的对与错。

$import(com.javaeye.webeditor.WYSIWYG);
$import(com.javaeye.webeditor.BBQ);
...
function pageLoaded() {
   if (...) {
     myEditor = new WYSIWYG();
   } else {
     myEditor = new BBQ();
   }
}

function pageLoaded() {
   if (...) {
     Editor = $import(com.javaeye.webeditor.WYSIWYG);
   } else {
     Editor = $import(com.javaeye.webeditor.BBQ);
   }
   myEditor = new Editor();
}

function pageLoaded() {
   if (...) {
     editorPlugin = loadPlugin("WebEditor.WYSIWYG");
   } else {
     editorPlugin = loadPlugin("WebEditor.BBQ");
   }
   editorPlugin.init();
}

无论预加载还是异步按需加载，如果控制粒度都是一个个问题。粒度的控制不应该是开发阶段作考虑，应该是在部署阶段进行配置的（当然ClassLoader需要提供控制粒度的配置），有专业人士进行分包打包并作优化。

异步按需加载并没有想象中的那么复杂，如果你已经完成一个ClassLoader，那么给ClassLoader一个改造，提供加载完毕的callback，那么可以用类似如下代码完成异步调用：
ClassLoader.loadClass ("org.blahblah.HelloWorld", function () {
org.blahblah.HelloWorld.sayHi();
));
或者
ClassLoader.loadClass (["org.blahblah.HelloWorld","org.blahblah.utils.StringUtils"], function () {
var s = org.blahblah.HelloWorld.sayHi();
var k = org.blahblah.utils.StringUtils (s);
));

在Java2Script的支持下，可以使用Java的匿名类作为相关callback类，还可以跨closure传递相关的变量对象，这样的话，对开发者不会有太大的异步恐惧的。

BTW：个人认为，需要专门的服务器端*.jsp或者servlet协助ClassLoader完成相关功能，是一个非常糟糕的设计。

“异步” 不仅打乱了开发人员的一般习惯思维方式，同时也改变了程序顺序加载执行最朴素的规律。
对于模块之间的静态依赖，或者程序对模块的静态需求，采用预加载的方式，然后通过事件侦听或者回调程序入口来继续加载后的的程序执行尚且可以。
但这些依赖或者需求是程序运行时动态决定的，而采用异步的方式肯定造成程序分支增多，增加了系统的复杂性。