jruby编写java
JRuby 1.5已经发布 ，InfoQ借此机会赶上了JRuby的Charles Nutter ，讨论了发行版中的重大变化，当前和未来JVM上JRuby的未来等等。
InfoQ JRuby 1.5中AOT的状态是什么？
我们一直都有一个提前编译器，可以在.class文件中生成预编译的Ruby代码。 但是缺少一些东西：
*这些预编译的文件将继续生成“调用程序”，并生成代码存根以绑定文件中的所有方法和块。 这造成了额外的类加载冲击，同时阻止了预编译脚本在禁止生成字节码的环境（如applet或Android）中运行。
*没有办法产生“真实的” Java类。 生成的.class文件与.rb文件是1：1，以提供一种不错的机制来预编译脚本而不会生成大量的输出。 但是在实践中，这还远远不够，人们真正需要的是一种从Ruby代码生成真实外观的Java类的方法。
这两个都已在1.5中进行了修复，并增加了一些标志：
--java和--javac允许您从给定文件中的Ruby类生成“实际” Java类。 您可以针对它们编译Java代码，向它们添加注释，实现接口，反映它们的方法，并像普通Java类一样构造它们。
--handles在编译时生成所有在运行时生成的“调用程序”句柄。 这意味着可以“完全”预编译Ruby脚本，因此根本不需要进行任何运行时代码生成。
我们还添加了--sha1标志，该标志生成基于实际Ruby源代码的SHA1哈希命名的.class文件。 通过使用这种更标准的命名，您可以将.rb文件以任何目录布局发送，而.class文件位于类路径中的某个位置，并且可以维护.rb和.class之间的关联。
InfoQ版本说明中提到了一个设置'jruby.jit.codeCache'。 这些类文件是仅在运行之间缓存的还是与AOT功能相关？
两者都是。 如果将codeCache = <dir>与-X + C一起使用来强制所有文件在加载时进行编译，您会看到它可以保存运行过程中“实际上”已加载的所有文件。 然后，理想情况下，您可以只发送那些类，而不是预编译每个库中的每个文件（假设您的运行触及应用在生产环境中运行时实际需要的所有文件。如果您将codeCache与正常执行一起使用，则只会保存编译后的方法主体如果您只想预编译很多，则可以将--sha1和--handles标志与jrubyc结合使用，将它们与罐中的类文件或codeCache组合起来以进行预编译。
我们将为所有这些整理一些文档和方法，但是我已经在博客上写了一些关于--sha1和--handles的信息，这些信息用于预编译Android的Ruby应用程序。
InfoQ AOT的局限性是什么？ 是否可以使用eval（），元编程等？
只要我们提供用于Ruby代码的解析器和解释器，就可以进行eval评估。 唯一的限制是该代码是否能够在运行时JIT，这在某些环境中是不可能的（例如Ruboto--Android上的JRuby）。 我们也正在考虑构建一个精简的JRuby运行时，其中仅包含运行预编译代码所需的部分。 在那种情况下，不可能实现eval ...但是这可能值得，因为这意味着我们不必交付解析器，解释器，AST类，编译器，ASM（用于生成字节码），并且可能更多。
如果您的元编程需要评估，则必须遵循相同的要求。 但是只要不需要评估，它就始终有效。 方法和块体可以“完全”编译，因此即使eval不可用，也可以使用define_method和friends。
InfoQ FFI和其他访问本地库的方法的状态如何？
在JRuby 1.5中，我们从JNA（Java本机访问）切换到JFFI（Java外部功能接口）。 我们的本地绑定专家Wayne Meissner在JNA上进行了广泛的研究，他将这些知识传递给JFFI，以使其变得更快，更有效。 我们所有的本机库逻辑，包括我们在JVM上通常不可用的POSIX函数的绑定（JRuby可以与符号链接，打开的UNIX套接字等一起使用），现在都通过JFFI，并且我们为所有流行的平台附带了JFFI的本机位和几个怪异的（PPC-AIX！zLinux！）。
InfoQ Wayne Meissner对JRuby Native Extension的支持情况如何？
韦恩（Wayne）为JRuby模拟了“ Ruby C API”的早期原型，希望社区成员能够帮助我们填写它，以便我们至少可以运行人们编写的许多本机扩展。 但是在这样一个层上工作并不适合每个人，而且面对其他我们认为更重要的错误和功能，并没有取得进展。
但是，有一个好消息：作为Ruby Summer of Code的一部分，JRuby将于今年夏天有一个专门的学生来帮助我们进行C扩展支持。 我不确定我们是否能够为*大多数*扩展做足够的工作，但是我认为我们将能够提供一个使*某些*扩展正常工作的安全子集。 我还希望通过划清界限，仅实现我们认为可以“安全”实现的API调用，我们将为C Ruby的发展提供一些指导。
InfoQ 1.9支持的状态如何？
在此发行版中，我们对Ruby 1.9的支持做了很多工作，并且有用户在1.9模式下运行JRuby ...但是我们并未集中精力。 这是有充分理由的。 去年下半年，Ruby 1.9.2的管理者Yuki Sonoda（yugui）打破了“圣诞节发布”的传统，他说1.9.2需要更多的工作，并且它的发布将推迟到2010年。他们现在接近1.9的完成。 2，这意味着我们很快就会有一个1.9的“稳定”版本，我们可以开始认真追逐。 我想说的是，JRuby 1.6发行版需要更多“完整”的1.9支持。
InfoQ MLVM的状态如何，Java 7的工作例如。 与invoke_dynamic等？
自从去年秋天以来，MLVM最有趣且更成熟的组件invokedynamic发生了横向变化。 例如，对API进行了改进，并且Hotspot中的基础实现已大大提高。 我们一直在跟踪这些更改，并使JRuby的invokedynamic支持保持同步。 我们还开始看到JRuby + invokedynamic在Java 6上的运行速度比JRuby快。 这是非常有前途的。
另一个有趣的发展是协程对MLVM（也许最终对JVM的支持）的支持。 卢卡斯·斯塔德勒（Lukas Stadler）最近在博客上发表了一篇文章，其中他重新设计了JRuby的Ruby 1.9“纤维”支持（您可能将它们称为协程或小线程或合作调度的微线程），以使用他为Hotspot所使用的协程支持。 结果非常令人印象深刻。 JRuby纤维加上Lukas的延续性比Ruby 1.9中的绿色线程实现更好，这是我们认为不可能实现的壮举。 更好的是，它消除了对本机线程的使用，这是标准JVM上的JRuby现在模拟协程的方式。 我不知道是否有可能进入真正的JVM版本，但是任何需要协程或小线程的语言都将不胜感激。
Lukas Stadler在为 JVM 提供协程支持方面的工作 。
InfoQ对于1.6有什么大计划吗？
我们有几点想法：
通过添加对Rake的Maven支持，对jrubyc --java的扩展支持，以及使用基于类的框架与JRuby一起使用的以前很难或不可能使用的更多演练，继续集成Java平台的其余部分。
* Ruby 1.9.2支持。 我们已经完成了很多工作，但是还有很多事情要做。 我们绝对可以在这里使用一些社区帮助。
*重新审视JRuby的性能。 与标准Ruby实现相比，我们的性能一直很好，但是在特定领域中，MacRuby和Rubinius等较新的实现很容易超越我们。 其中一些是由于在JVM上运行所固有的局限性，例如需要100％装箱的数字（这严重限制了我们使用数字算法的能力）。 但这很多是因为自从2008年中以来我们就没有在JRuby方面进行重大的推动。我们知道很多事情可以改进，但是有些棘手。
InfoQ JRuby团队写了一本关于JRuby的书 -目标读者是什么？
我们试图使这本书对那些对使用JVM或Java库感兴趣的Ruby开发人员，以及希望将其部分代码移至Ruby（或将其某些Web应用程序移至Rails）的Java开发人员都适用。 有很多演练，有许多从初学者到中级的内容，并且我们在这方面有更多的章节。
Charles最近在博客中谈到了未来版本中JRuby性能改进的计划 。
InfoQ EngineYard现在提供商业JRuby支持 -关于此的任何新闻？
是! Engine Yard现在正在为担心在其组织中安全地投资JRuby的JRuby用户提供支持和服务包。 您可以获得远程客户支持，专用的错误修复时间，甚至还有现场时间。 我们希望这将使大型客户更容易自信地朝着JRuby迈进，并将其视为对我们所有用户都可获得的一流OSS风格支持的完美补充（当然，在时间允许的情况下）。
jruby编写java
1264
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
