精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2007-07-30
本文已经发表于InfoQ
JavaEye上活跃的开发者Complystill(歆渊)最近发布了自己的开源SecureJSH项目,提供了一个通过SSH交互进行Java应用开发或者管理的工具。 在项目的介绍中可以得知,SecureJSH与Ptyhon里面的ipython或者Ruby里面的irb非常相似。它们都允许交互式运行语言的代 码,以方便跟踪或者调试应用。但是,Java与Ruby、Python不同,后者是动态脚本语言,它们天生具有解释执行的特点(注意:当然Python支 持预编译,Ruby也将在YARV中开始支持,这里指它们的解释执行状态)。我们常见的Python和Ruby发行版本基本上都包括自己的解释器(这也是 它们的核心组件),但是Java是一种需要中间编译过程的语言,默认情况下它无法直接解释运行,也没有相应的解释器。 那么SecureJSH是如何实现的呢?读者首先会想到JSR-223,这个API可以自己扩展脚本语言支持,比如rhino是 Javascript解释引擎。但是使用它难以实现交互操作,因为它必须输入一个相对完整的脚本才可以运行,这样会丧失一部分交互性。SecureJSH 实际上是使用了JDK 6.0的新特性Java Compiler API(JSR-199),它提供了一组API来让程序可以动态地访问Java编译器的接口,这样就可以使用Java编译器动态检查代码语法或者动态根据 Java源码生成可以执行的字节码。这种方式与ASM的编程直接生成字节码不同,它能直接将Java源码转换为字节码,XRuby的主力开发者郑晔(网名 dreamhead)在他的Blog中这样对比了两种方案: 之前,刚刚在Blog中提到ASM, 里面的代码生成工作是通过直接写 字节码完成的。现在有了Compiler API,可以考虑生成代码以Java源码的形式完成,然后,通过调用Compiler API对源码进行动态编译,这样,可以达到同直接写字节码类似的作用。使用Compiler API,肯定不如直接生成字节码来得高效,但对于不了解JVM指令的人来说这也许是一种解决方案。 可见JSR-199不是最高效的字节码生成方案,但是更方便使用。Java Compiler API不是为了取代ASM这样的方案的,它的本意是以编程的方式实现实时编译及信息反馈。Java目前的主要架构师之一Peter von der Ahé曾经在他的Blog对谁需要使用Java Compiler API这个问题做了如下解释: 99%的Java开发者都不需要了解Java Compiler API。只有少数的开发者会直接应用这个API。但是IDE、Java EE应用程序服务器、Maven或者Ant还有测试框架的开发者却不一样,他们有一个共同点,就死需要调用编译器将Java源码转换为类文件(他们是这个 API的潜在用户)。 可见JSR-199的产生主要是面向热部署或者增量编译这样的场合,但是SecureJSH的产生扩展了Java Compiler API的应用场景,同时也增强了Java和JVM的交互性。Complystill这样介绍了SecureJSH的应用场景和需求: SecureJSH允许Java编写的服务器端应用程序为管理员、客户、开发者和客户端服务提供一个安全shell,这里可以交互性地让Java语言逐句运行。SecureJSH需要JDK 6.0或者JRE 6.0加JAVAC(在classpath中)来运行。SecureJSH的官方首页这样描述了它的主要特性:
作为一个开源项目,SecureJSH使用了ganymed的纯Java实现的SSH 2.0库,并使用Java NIO编写了网络服务,代码质量很高。据Comply Still介绍,SecureJSH最初是为内存数据库TOB设计的,为这个面向对象数据库提供交互访问的接口,但是后来作者发现它可以被应用在很多场 合,所以单独开源发布。作为Java开发者,您可以从这里下载源码从中学习SSH 2.0、NIO网络服务、Java Compiler API的使用方法,相信一定会有所收获。 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2007-07-30
这个工具是不是
类似eclipse debug里的display, 编写一部分代码, 在远程服务器里动态执行? |
|
返回顶楼 | |
浏览 3483 次