Mała poprawka: Marcin Mielżyński. Znany jako lopex (często można spotkać jego komentarze na blogach), można z nim pogadać na IRCu (kanały jruby, rubyonrails.pl i inne ;)). Chłopak ma niesamowitą wiedzę i zapał do pracy - tylko podziwiać. Przez ostatnie dni implementował właśnie wspomnainy port Oniguramy do Javy - JOni. Wszystko z naciskiem na regexpy. Wiem to, bo czasem zaglądałem na kanał #jruby i widziałem dyskusje chłopaków (najbardziej udziela się olabini, lopex i headius ;)).
Co do JRubiego. To bardzo, bardzo ważny projekt. Zarówno dla nas, rdzennych Rubbistów (:D) jak i Javowców (oni jeszcze o tym nie wiedzą, ale jestem prawie pewien, że już niedługo docenią (J)Rubiego). Wydawać by się mogło, że w najprostszym ujęciu JRuby umożliwia używanie całego Java API w kodzie Rubiego. Czyli łączymy piękno i prostotę pisania w Rubym z tym co Java ma najlepsze - cały ‘code base’ (API + bilbioteki, a nawet i całe frameworki). Odrzucamy oczywiście to czego w javie nie lubimy - toporność. Nawet jeśli użycie samego API wiąże się z niewygodą to można to zmienić, dzięki elastyczności Rubiego. Już powstają takie projekty, które bazując na powiedzmy Swingu budują na nim ładniejszy i wygodniejszy w użyciu kod (np. zamiast implementacji przez klasę interfejsu listenera i dodawaniu go do listy słuchaczy robimy coś takiego: button.on_click { puts “clicked” }).
Jest to obustronna (java vs ruby) korzyść. My powiemy: fajnie, mogę użyć biblioteki Javy w moim kodzie (bo np jakiegoś liba brakuje w czystym Rubym). Programista Javy powie: hm, może jednak skuszę się na Rubiego, skoro nie muszę rezygnować z całego API Javy, którego uczyłem się po nocach ;).
Kolejna sprawa - wydajność. Bodajże Ruby 1.6 był tragicznie wolny i pomimo sporego skoku wydajności w wersji 1.8, nadal ciąży na nim ta kwestia ;). Najbardziej na wydajność narzekają Ci… którzy Rubiego nie używają (i nie rozumieją 2 kwestii: mózg ludzki jest cenniejszy niż bezduszna maszyna, jeśli wydajność jest kwestią kluczową to Ruby nie jest właściwym wyborem). My oczywiście nie obrazilibyśmy się gdyby dało się trochę naszego Rubiego pszyspieszyć. Na horyzoncie widać już Ruby 1.9, który na pewno będzie szybszy od poprzedniej wersji. Jednak JRuby już pokazuje, że aspiruje do bycia najszybszym. A to wszystko dzięki technologii JIT, która w trakcie działania programu potrafi go optymalizować, np poprzez kompilację bezpośrednio do kodu maszynowego “gorących” miejsc. Co ciekawe operacje na liczbach już teraz potrafią być szybsze w JRuby, a będą prawdopodobnie jeszcze szybsze! W obecnej chwili każda liczba jest pełnoprawnym obiektem Javy. W przyszłości JRuby będzie prawdopodobnie potrafił reprezentować liczby jako prymitywy (tak gdzie może na to sobie pozwolić) dzięki czemu operacje na liczbach mogą drastycznie przyspieszyć.
W tym miejscu chciałbym jeszcze zwrócić uwagę na inne implementacje Rubiego. Są to m.in. http://rubini.us/, http://cardinal2.rubyforge.org/, http://www.ironruby.net/, http://rubydotnet.googlegroups.com/web/Home.htm, http://xruby.com/default.aspx. Z jednej strony strony programiści tych implementacji rywalizują ze sobą (raczej po cichu), z drugiej wymieniają doświadczenie ze sobą itp. Przykładowo w Rubinius i JRuby duży nacisk położono na testy (zgodność z MRI), dzięki czemu już powstała inicjatywa zebrania tych testów w jednym miejscu a także wyszła prośba do Matza by taką specyfikację przygotował 
(do tej pory taką specyfikacją był kod C MRI;)) To może wyjść tylko na dobre Rubiemu. Jeśli oficjalnie JRuby będzie uznawany za najszybszą implementację to myślę, że japończycy zrobią wszystko by wersja w C dogoniła go i być może zaimplementują jakiś mechanizm JIT (do tej pory nic o tym nie słychać). Jest współpraca, jest rywalizacja (bardzo zdrowa) - jest fajnie :).
To co napisał @piachoo jest bardzo ważne. Po pierwsze Java to prestiż (chociaż nie przepadam za facetami w gajerkach…). Ale to jeszcze nic. Za JRubym w zasadzie stoi Sun (Charles Nutter i zdaje się jeszcze jeden z programistów został zatrudniony przez Sun). Z kolei IronRuby tworzy programista Microsoftu (jeśli nic nie pomyliłem to twórca IronPythona). To już jest dowód na zainteresowanie sektora enterprise Rubym.
Coś jeszcze? Choćby i prostota pisania rozszerzeń - piszemy przecież w Javie, a chyba każdy się zgodzi, że pisze się w niej o wiele przyjemniej niż w C ;). “Naprawiony” model wielowątkowy (zamiast green threads mamy pełnoprawne wątki).
A jakie widzicie ewentualne minusy/zagrożenia ?
Na pewno kwestia rozszerzeń. Te pisane w C w JRubym są bezużyteczne - nie ma możliwości ich użcyia (raczej logiczne). Zastanawia mnie także, czy jeśli (J)Ruby przebije tą “enterprisową” ścianę, Ruby pod naciskiem społeczności, firm nie zacznie zbaczać z dotychczasowej ścieżki. Ale nie ma co się martwić na zapas. Zawsze można przecież skopiować własną wersję źródeł Rubiego. Tak na wszelki wypadek ;).
dokonał portu biblioteki wyrażeń regularnych Onigurama na Jave - Joni. Z postu Ch. Nuttera wynika, że wydajność nowej biblioteki jest nawet 30 krotnie lepsza niż poprzedniej! (testy dla biblioteki REXML).