ラベル JRuby の投稿を表示しています。 すべての投稿を表示
ラベル JRuby の投稿を表示しています。 すべての投稿を表示

2011年3月15日火曜日

JRuby 1.6.0 がリリースされました。

原文

The JRuby community is pleased to announce the release of JRuby 1.6.0.

JRuby 1.6.0 が正規にリリースされました。


JRuby 1.6.0 は過去最大のJRubyリリースです。
このリリースは、ユーザから報告のあった数百の不具合を直し、またRuby 1.9.2との高い互換性を実現しています。
またウィンドウズ上で継続的インテグレーションを行い、これをサポートするプラットフォームに加えました。
ウィンドウズでRubyを体験するのにJRuby 1.6は最適の方法と言えるでしょう。
このリリースではRubyのAPIに基づいたC拡張への対応を試験的に取り入れています。
更に、今までの主なリリースと同様、ユーザの声に耳を傾け、安定性とパフォーマンスの向上を実現しています。


今後一二ヶ月の間は1.6.0へのフィードバックを受けて1.6.1, 1.6.2等、細かくリリースを行う予定です。
1.6.0を是非使ってみて、報告をして下さい。

主な特長

  • Ruby 1.9.2言語とAPI互換性の実現

    • Encoding::Converterとripperは未対応
  • Rubyメソッド呼び出しのパフォーマンス向上

  • 組み込みのプロファイラ(–profile, –profile.graph)

  • RSpecを配布ファイルから外しました

  • C拡張のサポート(試験的)

  • MavenアーティファクトをRuby gemとして扱える(プレビュー)

  • Windowsプラットフォームへの対応

  • 1.9標準ライブラリをjruby-complete.jarに追加

  • 組み込みAPIの更なる改善

  • 2000のコミットと270を超える不具合の解消


2010年12月30日木曜日

JRubyの一年を振り返って

原文: チャールズ=オリバー=ナター

皆さん、こんにちは。

2010年ももうすぐ終わり。この一年を振り返ってJRubyにとって重要な出来事や人々を見て行きましょう。
2010年は、JRubyにとって素晴らしい年でした。様々なプロジェクトに採用され、また、第一級のRuby言語実装としても第一級のJVM言語としても人々に認知され、更にはJRuby自体も多いに進化した一年でした。早速みていきましょう。

2010年7月25日日曜日

Eclipse Memory AnalyzerでRubyアプリケーションのメモリリークを検知する

原文: チャールズ=オリバー=ナター


前回の記事「JRubyでメモリを観察するには」の後、何人かの人からEclipse MATのJRubyでの使い方について書いてみたらどうかとの意見を貰いました。これを早速取り上げる事にします。

2010年7月24日土曜日

JRubyのメモリを観察するには

原文: チャールズ=オリバー=ナター


Ruby言語の各実装において、どんなメモリ消費を解析するツールがあるのかが近頃ちょっとした話題になっています。 それもその筈、Rubyで書かれたアプリケーションの(不具合の調査は言うに及ばず)メモリ消費の具合を詳しく調べるのは容易い事ではありません。 JRubyを使わないのなら、そうです。


JRubyはJVM上で走るので、JVM向けに作られた何十ものツールの恩恵に授かる事が出来ます。 中にはJDKに同梱されているものを含め、メモリの調査、解析、レポートをするものもあります。 ヒープダンプが欲しければ、Hotspot系のJVM(SunまたはOpenJDK)に含まれるjmapやjhatが使えます。 もっと高度なツールが欲しければ、Eclipseを基にしたMemory Analysis Tool、 メモリ及びCPU性能解析ツールであるYourKit、 今ではHotspotに含まれているJavaVMを始め、 数多くの選択肢があります。 こうした数多くのツールのお陰でメモリの調査には事欠きません。


本稿では実際にこのうちの二つのツールをどの様に使いこなすか見ていく事にします。 取り上げたツールは起動中のJVMを観察するグラフィカルなツールであるVisualVMと、 ヒープをダンプして事後解析を可能にするjmapとjhatのタッグチームです。

2010年6月17日木曜日

今のJVMに欠けている物

原文: チャールズ=オリバー=ナター

今日ツイッターで、「JVM及びJDKが、あらゆるプログラミングにおいて真にイケてるプラットフォームになる為には未だ幾つかの欠陥が有る」と呟きました。沢山の人から「もっと詳しく」とせっつかれたので、ここに短く書き起こしておきます。勿論、これで全部という訳ではないのでしょうが、今日思いついたのはこれだけです。

2010年6月15日火曜日

JRubyのパフォーマンスの更なる向上を目指して

原文: チャールズ=オリバー=ナター

JVM上でJRubyが動く事の利点は折りに触れて述べてきました。JRubyのパフォーマンス数値はそこそこの結果を出しているのですが、多くの人々の期待に反して「抜群に素晴らしい」というものではありませんでした。詰まる所、他のRuby言語の実装に較べて良い結果を出したとしても、静的な型システムを用いる他のJVM言語には敵わないのでした。

しかし、それは今までの話し。

2010年5月12日水曜日

JRuby 1.5.0 リリースのお知らせ

原文:トム=エネボ

JRuby バージョン1.5.0


JRubyのバージョン1.5.0 のリリースを発表いたします。

ホームページ: http://www.jruby.org/
ダウンロード: http://www.jruby.org/download

今まで最長のリリース期間(凡そ五ヶ月)を経た今回のリリースは不具合の修正の数も最多になりました。加えて、以下に示す通り、多くの新しい機能も含んでいます。不具合の内訳としてはRubyのメソッドの細かい仕様の修正が殆どです。その点から申しますと、JRuby 1.4.0から1.5.0へのアップグレードは容易でしょう。また、「JRubyから暫く遠ざかっていた」と仰るあなたも、この機会に是非JRubyを今一度試してみて下さい。

2010年4月15日木曜日

JRubyのバージョン1.5.0.RC1がリリースされました

原文:トム=エネボ

JRuby バージョン1.5.0.RC1


JRubyのバージョン1.5.0.RC1を発表いたします。

ホームページ: http://www.jruby.org/
ダウンロード: http://www.jruby.org/download

今まで最長のリリース期間(凡そ五ヶ月)を経た今回のリリースは不具合の修正の数も最多になりました。加えて、以下に示す通り、多くの新しい機能も含んでいます。不具合の内訳としてはRubyのメソッドの細かい仕様の修正が殆どです。その点から申しますと、JRuby 1.4.0から1.5.0.RC1へのアップグレードは容易でしょう。また、「JRubyから暫く遠ざかっていた」と仰るあなたも、この機会に是非JRubyを今一度試してみて下さい。以前あった不具合が解消されている可能性大です。1.5.0の正規リリースをより良い物にする為にどうぞご協力下さい。

2010年3月3日水曜日

JRubyの起動時間についてのヒント

原文: チャールズ=オリバー=ナター

JRubyはRuby言語の実装の中では一際起動が遅い事で悪名高くなってしまいました。一部は、JITの生成品がなくてブートストラップして動き出すまでに時間がかかってしまうJVMを使っているせいです。起動の際のボトルネックが報告されて原因が解明されればそれを除く努力を我々はしていますが、JRuby自体にも問題があります。起動の問題は、実は簡単な設定問題である事もしばしばです。JRubyの起動を早くするコツを幾つか見ていきましょう。

注意。JRuby自体の起動は、他のJVM言語に較べると結構いい線いっていますが、MatzのRuby(一般的には最も速い実装とは言えない)の起動は素晴らしく早いです。

クライアント用のJVMを使う


これが何と言っても一番手っ取り早い方法です。OpenJDKとSunのJDKを動かしているJVMであるHotSpotには、「クライアント用」と「サーバ用」の二種類のバックエンドがあります。「クライアント用」はバイトコードをコンパイルする時、最適化は最小限に、始めのうちにササッとやってしまうだけです。一方、「サーバ用」は大規模にしかも全体的に最適化をする訳ですが、これが出来るようになる時点に到着するには長い時間が掛かりますし、最適化の為には多くのリソースが必要です。

2010年2月24日水曜日

JRubyとRails 3を仲良くさせる方法

原文 ニック=シーガー

概要



jruby -S rails newapp -m http://jruby.org/rails3.rb



Rails 3のアプリを生成する際にはJRuby専用のテンプレート(-m http://jruby.org/rails3.rb)を使用して下さい。



2010年2月23日火曜日

RakeとAntを一緒に

原文: トム=エネボ

JRuby 1.5リリースに含まれる新しいライブラリをレポジトリーに先日コミットしました。これについて述べる前にこの下にでている写真を見て色々と思いを巡らして下さい。そう!私たち皆の模範となるミスター・ポテトヘッドです。ミスター・ポテトヘッドは私たちを数時間に渡って楽しませる(少なくともおそらく楽しませてくれていたであろう)、柔軟なただのオモチャではなくて、澱粉質を多く含む食べ物でもあるのです。

ミスター・ポテトヘッド

(MyMollyPopさんの写真)



ちょっとトンチンカンな事を言っているな、と思う前にちょっと考えてみて下さい。実際のところ、私たちがプログラマとして日常やっているのは、ミスター・ポテトヘッドを造り上げているようなものではないですか。ソフトウェアを造り上げるという問題に私たちが直面した時、求められているのは、さまざまな部品をくっつけるだけではなく、部品を最も綺麗に組み合わせる事です。ソフトウェアデザインとは正しくジャガイモを飾り付けるようなものです。この記事の「ジャガイモ」はソフトウェアです。

2010年1月10日日曜日

大忙しの一週間。アンドロイド、Maven、Rake、C拡張、そして…

原文: チャールズ=オリバー=ナター

(最後のブログ記事からどれ位経ったでしょうか?正解は「長い間」。カンファレンス続きで大忙しだった秋が終ったので、もっとブログを書くつもりです。これからは、一月に三つも会議に出かけないように忠告して下さい。)

やあ!この一週間はとても忙しかったです。でも、僕らは元気でせっせとコード書いてるって解るように、JRubyで何が起こってるかを見ていきましょう。

アンドロイド


今週の頭にJan Berkelの手伝いをやってRuboto IRBを最新のアンドロイド携帯環境で走らせる事に成功しました。細かい手直しが二つ三つ必要だったのと、Janが手伝うのに興味があるというので、この変更を追加して彼をRubotoのコミッタに追加しました。

Ruboto IRBのレポジトリはこちら→http://github.com/headius/ruboto-irb

最近、アンドロイド上で動くJRubyに対する私の興味が増してきました。極最近の事ですが、JRubyはJVMで動くメジャーな言語の内ではアンドロイド携帯で動いている間に新規のコードを作って動かす事が出来る凡そ唯一の言語なのだと思い至ったんです。GroovyやScalaやClojureでは双方向型のシェルを造るのは不可能。というのも、これらの言語はソースコードを一旦JVMのバイトコードにコンパイルする必要があって、JVMのバイトコードはDalvikのVMでは直接には動かないからです。

2009年12月1日火曜日

JRubyのJはJVMのJ

原文:トム=エネボ

現在JRubyの開発に携わっている面々は皆Ruby、Java、そして勿論JRubyを熟知している情熱的なハッカーばかりです。とは言うものの、このプロジェクトの創成に関わった者は一人も居ません。JRubyの先駆者たちはそれがいいアイディアだったと考えたに違いありません—私もJRubyのことを初めて耳にした時そう思いました。ところが多くの人にとってはこれはそう自明の事では無いのかも知れません。そういう人たちは「JVMの上でJRuby書いていい事なんかあるのですか」と訊きます。僕らJRubyチームはちょっとネジが外れてるか、狂気の天才なのか、それともJVMを使うのは至極実利的な決断なのでしょうか。

Javaは登場した当時、存在していたプログラム言語をちょっと良くしたような物でした。Javaはそこそこ簡単であり、かつ既によく使われていたCやC++を進化させたような物であるにも拘わらず、ハードウェアに中立なバイトコードを走らせる事の出来る仮想マシンでした。ガーベージコレクションがJavaには実装されていたので、メモリ管理やコアダンプに大して気を捕らわれなくなりましたし、加えて中々総括的なライブラリを持っていました。特に目新しい物は無かったのですが、既にあったアイディアを上手い具合に組合わせて使える物になっていたと言えるでしょう。

これは私見ですが、このように二つの異なる物をJavaと言う一つのブランドで売ろうとしたSunのマーケット戦略は長い目で見ると失敗でした。この戦略では、プログラム言語とランタイムが全く同一の物であるかのように同じ名前で呼ばれる事になっていたのです。この戦略は、ランタイム(それ自体で充分に利点の有ったJava仮想マシン)にとって非常に不公平な物でした。更に、JythonやJRubyの様にJVMを基にしたプログラム言語が、プログラム言語としてのJavaとの混乱を招く事無しにJVMの良さを説明する事が出来なくなるという結果にもなりました。

本稿ではJVMの良い点と悪い点について触れることにして、JVMの姿を読者が垣間見る事が出来ると良いと考えます。

本題に移る前にもう一言。本稿で扱うのはSunのJVMについて私の知っている事に限っています。Sun以外からもJVMはリリースされていますし、それぞれに良さが有ります。私が以下に挙げる点の多くはそうしたJVMにも当て嵌ると思われますが、私がそうしたJVMの詳細に暗い事は断っておきます。