年底Sun 公司发布了 Java Standard Edition （Java SE ）的最终正式版代号 Mustang（野马）跟 Tiger（Java SE ）相比Mustang 在性能方面有了不错的提升与 Tiger 在 API 库方面的大幅度加强相比虽然 Mustang 在 API 库方面的新特性显得不太多但是也提供了许多实用和方便的功能在脚本Web serviceXML编译器 API数据库JMX网络和 Instrumentation 方面都有不错的新特性和功能加强
本系列文章主要介绍 Java SE 在 API 库方面的部分新特性通过讲解一些例子帮助开发者在编程实践当中更好的运用 Java SE 提高开发效率
Instrumentation 简介
利用 Java 代码即 javalanginstrument 做动态 Instrumentation 是 Java SE 的新特性它把 Java 的 instrument 功能从本地代码中解放出来使之可以用 Java 代码的方式解决问题使用 Instrumentation开发者可以构建一个独立于应用程序的代理程序（Agent）用来监测和协助运行在 JVM 上的程序甚至能够替换和修改某些类的定义有了这样的功能开发者就可以实现更为灵活的运行时虚拟机监控和 Java 类操作了这样的特性实际上提供了一种虚拟机级别支持的 AOP 实现方式使得开发者无需对 JDK 做任何升级和改动就可以实现某些 AOP 的功能了
在 Java SE 里面instrumentation 包被赋予了更强大的功能启动后的 instrument本地代码（native code）instrument以及动态改变 classpath 等等这些改变意味着 Java 具有了更强的动态控制解释能力它使得 Java 语言变得更加灵活多变
在 Java SE 里面最大的改变使运行时的 Instrumentation 成为可能在 Java SE 中Instrument 要求在运行前利用命令行参数或者系统参数来设置代理类在实际的运行之中虚拟机在初始化之时（在绝大多数的 Java 类库被载入之前）instrumentation 的设置已经启动并在虚拟机中设置了回调函数检测特定类的加载情况并完成实际工作但是在实际的很多的情况下我们没有办法在虚拟机启动之时就为其设定代理这样实际上限制了 instrument 的应用而 Java SE 的新特性改变了这种情况通过 Java Tool API 中的 attach 方式我们可以很方便地在运行过程中动态地设置加载代理类以达到 instrumentation 的目的
另外对 native 的 Instrumentation 也是 Java SE 的一个崭新的功能这使以前无法完成的功能 —— 对 native 接口的 instrumentation 可以在 Java SE 中通过一个或者一系列的 prefix 添加而得以完成
最后Java SE 里的 Instrumentation 也增加了动态添加 class path 的功能所有这些新的功能都使得 instrument 包的功能更加丰富从而使 Java 语言本身更加强大
Instrumentation 的基本功能和用法
javalanginstrument包的具体实现依赖于 JVMTIJVMTI（Java Virtual Machine Tool Interface）是一套由 Java 虚拟机提供的为 JVM 相关的工具提供的本地编程接口集合JVMTI 是从 Java SE 开始引入整合和取代了以前使用的 Java Virtual Machine Profiler Interface (JVMPI) 和 the Java Virtual Machine Debug Interface (JVMDI)而在 Java SE 中JVMPI 和 JVMDI 已经消失了JVMTI 提供了一套代理程序机制可以支持第三方工具程序以代理的方式连接和访问 JVM并利用 JVMTI 提供的丰富的编程接口完成很多跟 JVM 相关的功能事实上javalanginstrument 包的实现也就是基于这种机制的在 Instrumentation 的实现当中存在一个 JVMTI 的代理程序通过调用 JVMTI 当中 Java 类相关的函数来完成 Java 类的动态操作除开 Instrumentation 功能外JVMTI 还在虚拟机内存管理线程控制方法和变量操作等等方面提供了大量有价值的函数关于 JVMTI 的详细信息请参考 Java SE 文档当中的介绍
Instrumentation 的最大作用就是类定义动态改变和操作在 Java SE 及其后续版本当中开发者可以在一个普通 Java 程序（带有 main 函数的 Java 类）运行时通过 –javaagent 参数指定一个特定的 jar 文件（包含 Instrumentation 代理）来启动 Instrumentation 的代理程序
在 Java SE 当中开发者可以让 Instrumentation 代理在 main 函数运行前执行简要说来就是如下几个步骤
编写 premain 函数
编写一个 Java 类包含如下两个方法当中的任何一个
public static void premain(String agentArgs Instrumentation inst);[]
public static void premain(String agentArgs);[]
其中[] 的优先级比 [] 高将会被优先执行（[] 和 [] 同时存在时[] 被忽略）
在这个 premain 函数中开发者可以进行对类的各种操作
agentArgs 是 premain 函数得到的程序参数随同 –javaagent一起传入与 main 函数不同的是这个参数是一个字符串而不是一个字符串数组如果程序参数有多个程序将自行解析这个字符串
Inst 是一个 javalanginstrumentInstrumentation 的实例由 JVM 自动传入javalanginstrumentInstrumentation 是 instrument 包中定义的一个接口也是这个包的核心部分集中了其中几乎所有的功能方法例如类定义的转换和操作等等
jar 文件打包
将这个 Java 类打包成一个 jar 文件并在其中的 manifest 属性当中加入 PremainClass来指定步骤 当中编写的那个带有 premain 的 Java类（可能还需要指定其他属性以开启更多功能）
运行
用如下方式运行带有 Instrumentation 的 Java 程序
java javaagent:jar文件的位置[=传入premain的参数]
对 Java 类文件的操作可以理解为对一个 byte 数组的操作（将类文件的二进制字节流读入一个 byte 数组）开发者可以在ClassFileTransformer的 transform 方法当中得到操作并最终返回一个类的定义（一个 byte 数组）这方面Apache 的 BCEL 开源项目提供了强有力的支持读者可以在参考文章Java SE 特性 Instrumentation 实践中看到一个 BCEL 和 Instrumentation 结合的例子具体的字节码操作并非本文的重点所以本文中所举的例子只是采用简单的类文件替换的方式来演示 Instrumentation 的使用
下面我们通过简单的举例来说明 Instrumentation 的基本使用方法
首先我们有一个简单的类TransClass 可以通过一个静态方法返回一个整数
public class TransClass {
public int getNumber() {
return ;
}
}
我们运行如下类可以得到输出
public class TestMainInJar {
public static void main(String[] args) {
Systemoutprintln(new TransClass()getNumber());
}
}
然后我们将 TransClass 的 getNumber 方法改成如下:
public int getNumber() {
return ;
}
再将这个返回 的 Java 文件编译成类文件为了区别开原有的返回 的类我们将返回 的这个类文件命名为 TransClassclass
接下来我们建立一个 Transformer 类
import javaioFile;
import javaioFileInputStream;
import javaioIOException;
import javaioInputStream;
import javalanginstrumentClassFileTransformer;
import javalanginstrumentIllegalClassFormatException;
import javasecurityProtectionDomain;
class Transformer implements ClassFileTransformer {
public static final String classNumberReturns = TransClassclass;
public static byte[] getBytesFromFile(String fileName) {
try {
// precondition
File file = new File(fileName);
InputStream is = new FileInputStream(file);
long length = filelength();
byte[] bytes = new byte[(int) length];
// Read in the bytes
int offset = ;
int numRead = ;
while (offset <byteslength
&& (numRead = isread(bytes offset byteslength offset)) >= ) {
offset += numRead;
}
if (offset < byteslength) {
throw new IOException(Could not completely read file
+ filegetName());
}
isclose();
return bytes;
} catch (Exception e) {
Systemoutprintln(error occurs in _ClassTransformer!
+ egetClass()getName());
return null;
}
}
public byte[] transform(ClassLoader l String className Class<?> c
ProtectionDomain pd byte[] b) throws IllegalClassFormatException {
if (!classNameequals(TransClass)) {
return null;
}
return getBytesFromFile(classNumberReturns);
}
}
这个类实现了 ClassFileTransformer 接口其中getBytesFromFile 方法根据文件名读入二进制字符流而 ClassFileTransformer 当中规定的 transform 方法则完成了类定义的替换转换
最后我们建立一个 Premain 类写入 Instrumentation 的代理方法 premain
public class Premain {
public static void premain(String agentArgs Instrumentation inst)
throws ClassNotFoundException UnmodifiableClassException {
instaddTransformer(new Transformer());
}
}
可以看出addTransformer 方法并没有指明要转换哪个类转换发生在 premain 函数执行之后main 函数执行之前这时每装载一个类transform 方法就会执行一次看看是否需要转换所以在 transform（Transformer 类中）方法中程序用 classNameequals(TransClass) 来判断当前的类是否需要转换
代码完成后我们将他们打包为 TestInstrumentjar返回 的那个 TransClass 的类文件保留在 jar 包中而返回 的那个 TransClassclass 则放到 jar 的外面在 manifest 里面加入如下属性来指定 premain 所在的类
ManifestVersion:
PremainClass: Premain
在运行这个程序的时候如果我们用普通方式运行这个 jar 中的 main 函数可以得到输出如果用下列方式运行:
java –javaagent:TestInstrumentjar –cp TestInstrumentjar TestMainInJar
则会得到输出
当然程序运行的 main 函数不一定要放在 premain 所在的这个 jar 文件里面这里只是为了例子程序打包的方便而放在一起的
除开用 addTransformer 的方式Instrumentation 当中还有另外一个方法redefineClasses来实现 premain 当中指定的转换用法类似如下
public class Premain {
public static void premain(String agentArgs Instrumentation inst)
throws ClassNotFoundException UnmodifiableClassException {
ClassDefinition def = new ClassDefinition(TransClassclass Transformer
getBytesFromFile(TransformerclassNumberReturns));
instredefineClasses(new ClassDefinition[] { def });
Systemoutprintln(success);
}
}
redefineClasses 的功能比较强大可以批量转换很多类
Java SE 的新特性虚拟机启动后的动态 instrument
在 Java SE 当中开发者只能在 premain 当中施展想象力所作的 Instrumentation 也仅限与 main 函数执行前这样的方式存在一定的局限性
在 Java SE 的基础上Java SE 针对这种状况做出了改进开发者可以在 main 函数开始执行以后再启动自己的 Instrumentation 程序
在 Java SE 的 Instrumentation 当中有一个跟 premain并驾齐驱的agentmain方法可以在 main 函数开始运行之后再运行
跟 premain 函数一样 开发者可以编写一个含有agentmain函数的 Java 类
public static void agentmain (String agentArgs Instrumentation inst);[]
public static void agentmain (String agentArgs);[]
同样[] 的优先级比 [] 高将会被优先执行
跟 premain 函数一样开发者可以在 agentmain 中进行对类的各种操作其中的 agentArgs 和 Inst 的用法跟 premain 相同
与PremainClass类似开发者必须在 manifest 文件里面设置AgentClass来指定包含 agentmain 函数的类
可是跟 premain 不同的是agentmain 需要在 main 函数开始运行后才启动这样的时机应该如何确定呢这样的功能又如何实现呢？
在 Java SE 文档当中开发者也许无法在 javalanginstrument 包相关的文档部分看到明确的介绍更加无法看到具体的应用 agnetmain 的例子不过在 Java SE 的新特性里面有一个不太起眼的地方揭示了 agentmain 的用法这就是 Java SE 当中提供的 Attach API
Attach API 不是 Java 的标准 API而是 Sun 公司提供的一套扩展 API用来向目标 JVM 附着（Attach）代理工具程序的有了它开发者可以方便的监控一个 JVM运行一个外加的代理程序
Attach API 很简单只有 个主要的类都在 comsuntoolsattach 包里面 VirtualMachine 代表一个 Java 虚拟机也就是程序需要监控的目标虚拟机提供了 JVM 枚举Attach 动作和 Detach 动作（Attach 动作的相反行为从 JVM 上面解除一个代理）等等 VirtualMachineDescriptor 则是一个描述虚拟机的容器类配合 VirtualMachine 类完成各种功能
为了简单起见我们举例简化如下依然用类文件替换的方式将一个返回 的函数替换成返回 的函数Attach API 写在一个线程里面用睡眠等待的方式每隔半秒时间检查一次所有的 Java 虚拟机当发现有新的虚拟机出现的时候就调用 attach 函数随后再按照 Attach API 文档里面所说的方式装载 Jar 文件等到 秒钟的时候attach 程序自动结束而在 main 函数里面程序每隔半秒钟输出一次返回值（显示出返回值从 变成 ）
TransClass 类和 Transformer 类的代码不变参看上一节介绍 含有 main 函数的 TestMainInJar 代码为
public class TestMainInJar {
public static void main(String[] args) throws InterruptedException {
Systemoutprintln(new TransClass()getNumber());
int count = ;
while (true) {
Threadsleep();
count++;
int number = new TransClass()getNumber();
Systemoutprintln(number);
if ( == number || count >= ) {
break;
}
}
}
}
含有 agentmain 的 AgentMain 类的代码为
import javalanginstrumentClassDefinition;
import javalanginstrumentInstrumentation;
import javalanginstrumentUnmodifiableClassException;
public class AgentMain {
public static void agentmain(String agentArgs Instrumentation inst)
throws ClassNotFoundException UnmodifiableClassException
InterruptedException {
instaddTransformer(new Transformer () true);
instretransformClasses(TransClassclass);
Systemoutprintln(Agent Main Done);
}
}
其中retransformClasses 是 Java SE 里面的新方法它跟 redefineClasses 一样可以批量转换类定义多用于 agentmain 场合
Jar 文件跟 Premain 那个例子里面的 Jar 文件差不多也是把 main 和 agentmain 的类TransClassTransformer 等类放在一起打包为TestInstrumentjar而 Jar 文件当中的 Manifest 文件为:
ManifestVersion:
AgentClass: AgentMain
另外为了运行 Attach API我们可以再写一个控制程序来模拟监控过程（代码片段）
import comsuntoolsattachVirtualMachine;
import comsuntoolsattachVirtualMachineDescriptor;
……
// 一个运行 Attach API 的线程子类
static class AttachThread extends Thread {
private final List<VirtualMachineDescriptor> listBefore;
private final String jar;
AttachThread(String attachJar List<VirtualMachineDescriptor> vms) {
listBefore = vms; // 记录程序启动时的 VM 集合
jar = attachJar;
}
public void run() {
VirtualMachine vm = null;
List<VirtualMachineDescriptor> listAfter = null;
try {
int count = ;
while (true) {
listAfter = VirtualMachinelist();
for (VirtualMachineDescriptor vmd : listAfter) {
if (!ntains(vmd)) {
// 如果 VM 有增加我们就认为是被监控的 VM 启动了
// 这时我们开始监控这个 VM
vm = VirtualMachineattach(vmd);
break;
}
}
Threadsleep();
count++;
if (null != vm || count >= ) {
break;
}
}
vmloadAgent(jar);
vmdetach();
} catch (Exception e) {
ignore
}
}
}
……
public static void main(String[] args) throws InterruptedException {
new AttachThread(TestInstrumentjar VirtualMachinelist())start();
}
运行时可以首先运行上面这个启动新线程的 main 函数然后在 秒钟内（仅仅简单模拟 JVM 的监控过程）运行如下命令启动测试 Jar 文件:
java –javaagent:TestInstrumentjar –cp TestInstrumentjar TestMainInJar
如果时间掌握得不太差的话程序首先会在屏幕上打出 这是改动前的类的输出然后会打出一些 这个表示 agentmain 已经被 Attach API 成功附着到 JVM 上代理程序生效了当然还可以看到Agent Main Done字样的输出
以上例子仅仅只是简单示例简单说明这个特性而已真实的例子往往比较复杂而且可能运行在分布式环境的多个 JVM 之中
Java SE 新特性本地方法的 Instrumentation
在 版本的 instumentation 里并没有对 Java 本地方法（Native Method）的处理方式而且在 Java 标准的 JVMTI 之下并没有办法改变 method signature 这就使替换本地方法非常地困难一个比较直接而简单的想法是在启动时替换本地代码所在的动态链接库 —— 但是这样本质上是一种静态的替换而不是动态的 Instrumentation而且这样可能需要编译较大数量的动态链接库 —— 比如我们有三个本地函数假设每一个都需要一个替换而在不同的应用之下可能需要不同的组合那么如果我们把三个函数都编译在同一个动态链接库之中最多我们需要 个不同的动态链接库来满足需要当然我们也可以独立地编译之那样也需要 个动态链接库——无论如何这种繁琐的方式是不可接受的
在 Java SE 中新的 Native Instrumentation 提出了一个新的 native code 的解析方式作为原有的 native method 的解析方式的一个补充来很好地解决了一些问题这就是在新版本的 javalanginstrument 包里我们拥有了对 native 代码的 instrument 方式 —— 设置 prefix
假设我们有了一个 native 函数名字叫 nativeMethod在运行中过程中我们需要将它指向另外一个函数（需要注意的是在当前标准的 JVMTI 之下除了 native 函数名其他的 signature 需要一致）比如我们的 Java 代码是
package nativeTester;
class nativePrefixTester{
…
native int nativeMethod(int input);
…
}
那么我们已经实现的本地代码是:
jint Java_nativeTester_nativeMethod(jclass thiz jobject thisObj jint input);
现在我们需要在调用这个函数时使之指向另外一个函数那么按照 JSE 的做法我们可以按他的命名方式加上一个 prefix 作为新的函数名比如我们以 another_ 作为 prefix那么我们新的函数是:
jint Java_nativeTester_another_nativePrefixTester(jclass thiz jobject thisObj
jint input);
然后将之编入动态链接库之中
现在我们已经有了新的本地函数接下来就是做 instrument 的设置正如以上所说的我们可以使用 premain 方式在虚拟机启动之时就载入 premain 完成 instrument 代理设置也可以使用 agentmain 方式去 attach 虚拟机来启动代理而设置 native 函数的也是相当简单的:
premain(){ // 或者也可以在 agentmain 里
…
if (!isNativeMethodPrefixSupported()){
return; // 如果无法设置则返回
}
setNativeMethodPrefix(transformeranother_); // 设置 native 函数的 prefix注意这个下划线必须由用户自己规定
…
}
在这里要注意两个问题一是不是在任何的情况下都是可以设置 native 函数的 prefix 的首先我们要注意到 agent 包之中的 Manifest 所设定的特性:
CanSetNativeMethodPrefix
要注意这一个参数都可以影响是否可以设置 native prefix而且在默认的设置之中这个参数是 false 的我们需要将之设置成 true（顺便说一句对 Manifest 之中的属性来说都是大小写无关的当然如果给一个不是true的值就会被当作 false 值处理）
当然我们还需要确认虚拟机本身是否支持 setNativePrefix在 Java API 里Instrumentation 类提供了一个函数 isNativePrefix通过这个函数我们可以知道该功能是否可以实行
二是我们可以为每一个 ClassTransformer 加上它自己的 nativeprefix同时每一个 ClassTransformer 都可以为同一个 class 做 transform因此对于一个 Class 来说一个 native 函数可能有不同的 prefix因此对这个函数来说它可能也有好几种解析方式
在 Java SE 当中Native prefix 的解释方式如下对于某一个 package 内的一个 class 当中的一个 native method 来说首先假设我们对这个函数的 transformer 设置了 native 的 prefixanother它将这个函数接口解释成
由 Java 的函数接口
native void method()
和上述 prefixanother去寻找本地代码中的函数
void Java_package_class_another_method(jclass theClass jobject thiz);
// 请注意 prefix 在函数名中出现的位置！
一旦可以找到那么调用这个函数整个解析过程就结束了如果没有找到那么虚拟机将会做进一步的解析工作我们将利用 Java native 接口最基本的解析方式去找本地代码中的函数:
void Java_package_class_method(jclass theClass jobject thiz);
如果找到则执行之否则因为没有任何一个合适的解析方式于是宣告这个过程失败
那么如果有多个 transformer同时每一个都有自己的 prefix又该如何解析呢？事实上虚拟机是按 transformer 被加入到的 Instrumentation 之中的次序去解析的（还记得我们最基本的 addTransformer 方法吗？）
假设我们有三个 transformer 要被加入进来他们的次序和相对应的 prefix 分别为transformer 和prefix_transformer 和 prefix_transformer 和 prefix_那么虚拟机会首先做的就是将接口解析为:
native void prefix_prefix_prefix_native_method()
然后去找它相对应的 native 代码
但是如果第二个 transformer（transformer）没有设定 prefix那么很简单我们得到的解析是
native void prefix_prefix_native_method()
这个方式简单而自然
当然对于多个 prefix 的情况我们还要注意一些复杂的情况比如假设我们有一个 native 函数接口是
native void native_method()
然后我们为它设置了两个 prefix比如 wrapped_ 和 wrapped_那么我们得到的是什么呢？是
void Java_package_class_wrapped_wrapped_method(jclass theClass jobject thiz);
// 这个函数名正确吗？
吗？答案是否定的
因为事实上
对 Java 中 native 函数的接口到 native 中的映射
有一系列的规定
因此可能有一些特殊的字符要被代入
而实际中
这个函数的正确的函数名是
void Java_package_class_wrapped_wrapped_method（jclass theClass jobject thiz） // 只有这个函数名会被找到
很有趣不是吗？因此如果我们要做类似的工作一个很好的建议是首先在 Java 中写一个带 prefix 的 native 接口用 javah 工具生成一个 c 的 headerfile看看它实际解析得到的函数名是什么这样我们就可以避免一些不必要的麻烦
另外一个事实是与我们的想像不同对于两个或者两个以上的 prefix虚拟机并不做更多的解析它不会试图去掉某一个 prefix再来组装函数接口它做且仅作两次解析
总之新的 native 的 prefixinstrumentation 的方式改变了以前 Java 中 native 代码无法动态改变的缺点在当前利用 JNI 来写 native 代码也是 Java 应用中非常重要的一个环节因此它的动态化意味着整个 Java 都可以动态改变了 —— 现在我们的代码可以利用加上 prefix 来动态改变 native 函数的指向正如上面所说的如果找不到虚拟机还会去尝试做标准的解析这让我们拥有了动态地替换 native 代码的方式我们可以将许多带不同 prefix 的函数编译在一个动态链接库之中而通过 instrument 包的功能让 native 函数和 Java 函数一样动态改变动态替换
当然现在的 native 的 instrumentation 还有一些限制条件比如不同的 transformer 会有自己的 native prefix就是说每一个 transformer 会负责他所替换的所有类而不是特定类的 prefix —— 因此这个粒度可能不够精确
Java SE 新特性BootClassPath / SystemClassPath 的动态增补
我们知道通过设置系统参数或者通过虚拟机启动参数我们可以设置一个虚拟机运行时的 boot class 加载路径（Xbootclasspath）和 system class（cp）加载路径当然我们在运行之后无法替换它然而我们也许有时候要需要把某些 jar 加载到 bootclasspath 之中而我们无法应用上述两个方法或者我们需要在虚拟机启动之后来加载某些 jar 进入 bootclasspath在 Java SE 之中我们可以做到这一点了
实现这几点很简单首先我们依然需要确认虚拟机已经支持这个功能然后在 premain/agantmain 之中加上需要的 classpath我们可以在我们的 Transformer 里使用 appendToBootstrapClassLoaderSearch/appendToSystemClassLoaderSearch 来完成这个任务
同时我们可以注意到在 agent 的 manifest 里加入 BootClassPath 其实一样可以在动态地载入 agent 的同时加入自己的 boot class 路径当然在 Java code 中它可以更加动态方便和智能地完成 —— 我们可以很方便地加入判断和选择成分
在这里我们也需要注意几点首先我们加入到 classpath 的 jar 文件中不应当带有任何和系统的 instrumentation 有关的系统同名类不然一切都陷入不可预料之中 —— 这不是一个工程师想要得到的结果不是吗？
其次我们要注意到虚拟机的 ClassLoader 的工作方式它会记载解析结果比如我们曾经要求读入某个类 someclass但是失败了ClassLoader 会记得这一点即使我们在后面动态地加入了某一个 jar含有这个类ClassLoader 依然会认为我们无法解析这个类与上次出错的相同的错误会被报告
再次我们知道在 Java 语言中有一个系统参数javaclasspath这个 property 里面记录了我们当前的 classpath但是我们使用这两个函数虽然真正地改变了实际的 classpath却不会对这个 property 本身产生任何影响
在公开的 JavaDoc 中我们可以发现一个很有意思的事情Sun 的设计师们告诉我们这个功能事实上依赖于 ClassLoader 的 appendtoClassPathForInstrumentation 方法 —— 这是一个非公开的函数因此我们不建议直接（使用反射等方式）使用它事实上instrument 包里的这两个函数已经可以很好的解决我们的问题了
结语
从以上的介绍我们可以得出结论在 Java SE 里面instrumentation 包新增的功能 —— 虚拟机启动后的动态 instrument本地代码（native code）instrumentation以及动态添加 classpath 等等使得 Java 具有了更强的动态控制解释能力从而让 Java 语言变得更加灵活多变
这些能力从某种意义上开始改变 Java 语言本身在过去很长的一段时间内动态 脚本语言的大量涌现和快速发展对整个软件业和网络业提高生产率起到了非常重要的作用在这种背景之下Java 也正在慢慢地作出改变而 Instrument 的新功能和 Script 平台（本系列的后面一篇中将介绍到这一点）的出现则大大强化了语言的动态化和与动态语言融合它是 Java 的发展的值得考量的新趋势
