JDK 7发布后, xruby 何去何从?

Sun JDK 7将会包括很多scripting language, 并提供动态bytecode compilation.
很想知道xruby的未来是如何?

评论

13 楼 sp42 2007-08-21  

indexchen 写道

仅有动态语言是不够的，关键是要有一个易用框架来提高开发效率。 如果没有rails，ruby很难有现在的知名度和使用者。在java中缺少的就是类似rails这样提供从显示层到数据库层解决方案的统一框架。每层都有不同的框架，最终要花力气去整合不同的框架，效率高不起来

JavaScript的也有～嘻嘻
Rhino on Rails：将 Rails 移植到 Javascript/Rhino
http://jstang.5d6d.com/thread-432-1-1.html

12 楼 gigix 2007-08-20  

indexchen 写道

仅有动态语言是不够的，关键是要有一个易用框架来提高开发效率。 如果没有rails，ruby很难有现在的知名度和使用者。在java中缺少的就是类似rails这样提供从显示层到数据库层解决方案的统一框架。每层都有不同的框架，最终要花力气去整合不同的框架，效率高不起来

这个……
有了Ruby，Rails还会远吗？
http://gigix.thoughtworkers.org/articles/2007/08/17/jrubyworks-j2ee-on-rails

11 楼 indexchen 2007-08-20  

仅有动态语言是不够的，关键是要有一个易用框架来提高开发效率。 如果没有rails，ruby很难有现在的知名度和使用者。在java中缺少的就是类似rails这样提供从显示层到数据库层解决方案的统一框架。每层都有不同的框架，最终要花力气去整合不同的框架，效率高不起来

10 楼 dreamhead 2007-08-17  

从目前的情况来看，JRuby不一定会走上完全编译的道路。某些情况在他们看来，并不值得去编译，比如eval。因为eval对于编译的处理是，编译之后，加载这个类（在JVM的层次上），然后运行得到结果。而这个过程中生成的这个类在运行结束之后，就失去了作用，所以，从某种角度上来说，他们认为这是一种浪费，倒不如直接解释了。

在我看来，JRuby和XRuby最主要的差别是：JRuby已经走上了正轨，而XRuby则很年轻。走上正轨意味着，JRuby考虑问题要谨慎得多，仅仅一个向Java 5移植的工作就讨论了好久，而在XRuby中，我们可以很快的将用Annotation绑定Ruby方法的这个想法付诸实现。JRuby现在选择的向编译器移植的路，是一条稳妥的路，在保证不破坏他们现有成果的基础上，一点点稳步前进。

其实，无论是JRuby还是XRuby，在编译这条路上都是刚刚起步，还有很长的路要走。有些问题只有有了一些应用之后，才会逐渐的暴露出来。比如Jon Tirsen给JRuby Team提出了一个问题，因为Rails本身的单线程模型，所以，需要可能需要起多个JRuby实例保证多线程处理，结果就是会在内存中存在大量相同的AST，造成浪费。我想了一下，如果走编译的道路，这个问题可以在部分上得到解决。当然，现在XRuby中的解决方案也不是特别理想。

从我的个人经验上来看，一个项目在它还比较新的阶段加入付出的远要比在它成熟之后加入要小得多。因为一个项目在最开始的时候，内容很少，很容易理解，然后，你会看到这个项目是如何一点点发生的变化，那些变化在参与者看来是理所当然的。

所以，我愿意鼓励有兴趣的人加入到XRuby中来，虽然它发展了有一段时间，但整体上来说，它还是一个非常年轻的项目。只要花不算特别多的时间去了解这个项目，就可以很快上手加入到开发之中。每次发布新版本时，想想自己在这个过程中的付出，总是一件很有乐趣的事情。

9 楼 yawl 2007-08-17  

我在最新的JDK 7里面没看到什么和script language直接相关的feature。原来倒是见到不少相关的设想，但好像很多feature由于时间关系都没加到JDK 7了。

invokedynamic指令是肯定不会在JDK 7里， 我甚至对是否会在JDK 8都很怀疑，而且即使出现invokedynamic，它自身也无法立即用在ruby compiler上（还需要很多其他东西辅助）。

JRuby现在在编译ruby的路走得不错。因为很明显把cruby解释器用java重新实现一遍不是个好选择，何况cruby解释器的设计本身就不是很好。

JRuby走的路很有趣，很多人可能不太清楚技术细节。现在jruby只是对method body进行编译(不是整个程序)，而且还有相当多的代码无法编译。他们的办法是先'试图'编译，如果不行的话则用解释的办法。这样尽管编译器还不成熟，代码仍可运行。这样可以平稳的渐进式的过渡到compiler上。

xruby则是有自己的问题。尽管在编译上好一些，但在builtin库上则差太多了。就像c程序，光有gcc还不行，没libc库一样跑不了。而这个库是个非常耗时的工作。其实我本人非常喜好这个工作，是熟悉ruby/java的库的非常好的办法，只是工作量太大了些，尤其对于我这样每天只能花1-2小时在业余项目的人。

如果能利用jruby的库当然也是一条路，但同样很大工作量。其实最大的问题还是人手和时间不够的问题。

8 楼 lordhong 2007-08-15  

是的, 我并没有诋毁XRUBY的意思, 我想说的是SUN也有在那个方向发展的计划, 希望XRUBY和SUN可以有某种方式的合作.

7 楼 dreamhead 2007-08-15  

lordhong 写道

dreamhead 写道

脚本语言的支持只是提供了一些接口，具体的工作还要有人来做。
动态bytecode compilation？你说的是invokedynamic那个指令吗？那只是在JVM的层次上增加了对动态语言的支持，让我们可以更好的在JVM上实现动态语言。

不是, SUN JVM组的一个员工说的: bytecode compilation. 也就是说把SCRIPTING/DYNAMIC LANGUAGE 编译到JAVA BYTECODE, 和XRUBY是差不多的.  而且既然他们官方支持JRUBY, 把NATIVE RUBY编译也是很正常的事情.

把动态语言编译为bytecode还是要做很多工作的，不会像说起来这么简单。
JRuby目前在做编译器的工作，而且进展不错，所以，可以预期，JRuby未来在性能上会有一个比较大的提升。

6 楼 lordhong 2007-08-14  

dreamhead 写道

脚本语言的支持只是提供了一些接口，具体的工作还要有人来做。
动态bytecode compilation？你说的是invokedynamic那个指令吗？那只是在JVM的层次上增加了对动态语言的支持，让我们可以更好的在JVM上实现动态语言。

不是, SUN JVM组的一个员工说的: bytecode compilation. 也就是说把SCRIPTING/DYNAMIC LANGUAGE 编译到JAVA BYTECODE, 和XRUBY是差不多的.  而且既然他们官方支持JRUBY, 把NATIVE RUBY编译也是很正常的事情.

5 楼 lordhong 2007-08-14  

manus 写道

sun jdk7  离我们好远

明年第三季度

4 楼 liuyifan.com 2007-08-14  

佛说,未来就是没有未来

3 楼 dreamhead 2007-08-14  

脚本语言的支持只是提供了一些接口，具体的工作还要有人来做。
动态bytecode compilation？你说的是invokedynamic那个指令吗？那只是在JVM的层次上增加了对动态语言的支持，让我们可以更好的在JVM上实现动态语言。

2 楼 gigix 2007-08-14  

最起码，目前全世界在Java平台上做Ruby编译器做得最好的就是XRuby，所以即使JDK7要内建自己的Ruby编译器，也应该向XRuby学习或者引入。所以问题应该是Sun要怎么实现Ruby（如果他们确实打算实现的话），而不是XRuby何去何从。

1 楼 manus 2007-08-14  

sun jdk7  离我们好远