LINUX.ORG.RU

Вышел JRuby 1.7.0

 ,


0

3

После полуторалетнего перерыва вышел JRuby 1.7.0 .
Важные изменения и багфиксы:

  • 1.9.3 по умолчанию;
  • стандартная библиотека обновлена до последней 1.9.3p286 версии;
  • поддержка invokedynamic (кто-то называет это самым важным введением);
  • java 6+ по умолчанию, java 5 больше не поддерживается;
  • все известные проблемы с кодировками пофикшены;
  • rake обновлён до 0.9.2.2, rubygems до 1.8.24;
  • улучшена произодительность и ещё тысячи багов пофикшены.

>>> Подробности

anonymous

Проверено: Shaman007 ()

Зачем это нужно?
На этом есть что-то существенное, на что можно посмотреть?

Spirit_of_Stallman ★★★ ()
Ответ на: комментарий от Spirit_of_Stallman

На этом есть что-то существенное, на что можно посмотреть?

Rails.

resurtm ★★★ ()
Ответ на: комментарий от Spirit_of_Stallman

Приятные обвязки к джаве, код становится приятнее писать. тот же глимер довольно-таки приятен в сравнении с писаниной на чистой джаве.

anonymous ()
Ответ на: комментарий от resurtm

Rails.

Я о законченных проектах, с использованием этого.
Ссылки, если таковые есть, я об этом.

Spirit_of_Stallman ★★★ ()
Ответ на: комментарий от Spirit_of_Stallman

JRuby – самая быстрая реализация рубей, плюс может в мультитрединг.

tensai_cirno ★★★★★ ()

В это, кстати, активно вкладываются редхатовцы. Сдается мне, что это будет новым энтерпрайзом.

plm ★★★★★ ()
Ответ на: комментарий от Spirit_of_Stallman

Вы откуда свалились? Там глобальный лок на тред с руби-контекстом стоит.

tensai_cirno ★★★★★ ()
Ответ на: комментарий от tensai_cirno

жэсточайшэ спорное утверждение. но jruby нужен

punya ★★ ()
Ответ на: комментарий от resurtm

а на рельсовых апликейшен серваках можно JRuby код гонять? я полагал что все это сделано чтобы с J2E окружением взаимодействовать и например на weblogic-е запускать.

BillDver ★★★ ()
Ответ на: комментарий от anonymous

я вижу что 5 тестов он выиграл - 5 проиграл зажрав в среднем в 8 раз больше памяти

punya ★★ ()
Ответ на: комментарий от punya

джит, что поделать? для увеличения скорости возрастает потребление памяти.

anonymous ()

нужно! на досуге буду тыкать палочкой.

ymn ★★★★★ ()
Ответ на: комментарий от anonymous

но все равно я не вижу преимущества у джруби. по тестам они равны. но джруби заедает больше оперативы

джруби прекрасен для интеграции с жаба приложениями

punya ★★ ()

Недавно прикрутил как скриптовый язык для КИС, очень удобно.

drakmail ★★★★ ()
Ответ на: комментарий от punya

по тестам они равны

Нет же. Обратите внимание на время выпонения тестов: чем дольше выполняется тест, тем очевиднее преимущество jRuby. Man jit-компиляция. Если коротко и просто, чем дольше работает ваше приложение, тем оно быстрее.

RedPossum ★★★★★ ()

поддержка invokedynamic

Кратко, что это? Загрузка классов на лету? Если так — то годно!

buddhist ★★★★★ ()
Ответ на: комментарий от buddhist

а в новости открыть ссылку и посмотреть что не позволяет?

anonymous ()

Лучше бы на PHP реализовали Ruby, думаю, многим бы пригодилось.

firestarter ★★★☆ ()
Ответ на: комментарий от anonymous

Лень парсить большое количество плохоструктурированного текста.

buddhist ★★★★★ ()
Ответ на: комментарий от Spirit_of_Stallman

А оригинальный раби не может?

Вам крайне показан логопедический массаж гландов.

Apple-ch ★★ ()
Ответ на: комментарий от firestarter

Лучше бы на PHP реализовали Ruby, думаю, многим бы пригодилось.

эт точно... :-) +1 !

посидел на ЛОРе.. почитал новости о новых версиях реализаций Ruby....

...а теперь иду назад копаться в говн^W PHP-файлах :-( .

user_id_68054 ★★★★★ ()

Как минимум 4 годных реализации языка(mri,rubinius,maglev,jruby), разве это не прекрасно! Правда я не знаю в чем фишка rubinius.. Но у jruby фишка довольно четкая (java - быстрая кроссплатформенная виртуальная машина).

special-k ★★★ ()
Ответ на: комментарий от special-k

Правда я не знаю в чем фишка rubinius

в том, что он сам написан на руби )

kelyar ★★★★★ ()
Ответ на: комментарий от Spirit_of_Stallman

А еще на JRuby написан Torquebox и частично Openshift. В общем --Redhat всячески способствует развитию.

Anatolik ★★ ()

А зачем это нужно, если есть просто Джава?

В чём преимущество?

Bioreactor ★★★★★ ()
Ответ на: комментарий от Bioreactor

А вообще, преимущества известны: скорость написания программ.

special-k ★★★ ()
Ответ на: комментарий от special-k

Очевидно программисты не хотят писать на джаве?

Очевидно программисты не хотят писать на джаве.

Очевидно как раз обратное, хотят именно на java
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

так что скорее JRuby нужен тем, кто пишет на Ruby но хочет что бы его программы не работали уж очень медленно.

Так как Ruby по прежнему вчистую сливает по скорости java(даже когда java работает в режиме интерпретации)
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=yarv&am...

Хотя результаты JRuby пока спорные
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=yarv&am...

Yilativs ★★★ ()

Очевидно как раз обратное, хотят именно на java

Там что-то стрелки вниз, нет? А у руби вверх мм?
А тут у нас что.. https://github.com/popular/starred
javascript и ruby, все так и жаждут писать на java, как посмотреть -_-.

Так как Ruby по прежнему вчистую сливает по скорости java

Ну так это ж низкоуровневая вещь, на которой и следует писать интерпретаторы. Можно довольно долго фапать на эту скорость, но что толку, нормального на java написано чуть меньше чем ничего. Я не пользуюсь ниодной прогой на java в повседневности.

Кроме того, быстрость java мнима:

В языке Java поддерживается несколько типов выполнения операций над объектами:

арифметические операции с примитивными типами данных; [например, сложение и вычитание целых чисел;
вызов статического метода;
вызов виртуального метода;
вызов виртуального метода через интерфейс;
вызов посредством рефлексии (reflexion).

Каждый последующий тип вызова выполняется в несколько раз медленнее предыдущего, а последний - даже в десятки-сотни раз медленнее. То есть мы имеем ситуацию, при которой одни типы вызовов предпочтительнее других. Для производительности лучше будет обходиться статическими вызовами и минимальным количеством виртуальных. Но реальные, хорошо спроектированные приложения, как правило, обладают высокой степенью полиморфизма.

Поэтому процент использования виртуальных методов может быть значительным, что существенно снижает производительность. Есть категория приложений, в которых время вызовов посредством рефлексии начинает доминировать. Все это приводит к тому, что время выполнения приложений увеличивается нелинейным образом относительно сложности проекта.

http://www.smalltalk.ru/articles/smalltalk.html

special-k ★★★ ()

А объясните тупому, как сабж с nokogiri подружить. Никак, не пойму, чего он от меня хочет.

anonymous ()
Ответ на: комментарий от anonymous

А объясните тупому, как сабж с nokogiri подружить. Никак, не пойму, чего он от меня хочет.

Контрибьюторы nokogiri уже подружили. Какая версия jruby и nokogiri? Показывайте stderr.

Anatolik ★★ ()
Ответ на: комментарий от Anatolik
warning: [options] bootstrap class path not set in conjunction with -source 1.5
ext/java/nokogiri/XmlReader.java:43: error: cannot find symbol
import nokogiri.internals.NokogiriEntityResolver;
                         ^
  symbol:   class NokogiriEntityResolver
  location: package nokogiri.internals
ext/java/nokogiri/internals/NokogiriHelpers.java:780: warning: [unchecked] unchecked call to getMethod(String,Class<?>...) as a member of the raw type Class
            nkf_method = nkfClass.getMethod(«nkf», ThreadContext.class, IRubyObject.class, IRubyObject.class, IRubyObject.class);
                                           ^
ext/java/nokogiri/XsltStylesheet.java:119: warning: [unchecked] unchecked conversion
        Set<String> keys = hash.keySet();
                                      ^
  required: Set<String>
  found:    Set
ext/java/nokogiri/internals/ParserContext.java:180: error: cannot find symbol
            NokogiriEncodingReaderWrapper reader = new NokogiriEncodingReaderWrapper(context, (RubyObject) data);
            ^
  symbol:   class NokogiriEncodingReaderWrapper
  location: class ParserContext
ext/java/nokogiri/internals/ParserContext.java:180: error: cannot find symbol
            NokogiriEncodingReaderWrapper reader = new NokogiriEncodingReaderWrapper(context, (RubyObject) data);
                                                       ^
  symbol:   class NokogiriEncodingReaderWrapper
  location: class ParserContext
ext/java/nokogiri/XmlReader.java:447: error: cannot find symbol
            reader.setEntityResolver(new NokogiriEntityResolver(ruby, null, options));
                                         ^
  symbol:   class NokogiriEntityResolver
  location: class XmlReader
ext/java/nokogiri/internals/XmlDomParserContext.java:138: error: cannot find symbol
        parser.setEntityResolver(new NokogiriEntityResolver(runtime, errorHandler, options));
                                     ^
  symbol:   class NokogiriEntityResolver
  location: class XmlDomParserContext
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
5 errors
3 warnings
rake aborted!
Command failed with status (1): [javac -extdirs «/usr/local/jdk1.7...]

Я так понимаю, здесь должен был джава-модуль парсера скомпилится, аналог nokogiri.so для mri.

anonymous ()

Забавно, c/c++ имплементации языка уступают по скорости java и smalltalk. Поводов изучать первые два все меньше..

special-k ★★★ ()
Ответ на: комментарий от anonymous

warning: [options] bootstrap class path not set in conjunction with -source 1.5

Похоже, проблема в том, что используется старая версия jruby, в которой не поддерживается jdk 1.7. Или, может быть, nokogiri старая.

Anatolik ★★ ()
Ответ на: комментарий от Spirit_of_Stallman

Нет. Это из серии...

... «чего только люди не придумают, чтобы на С не писать».

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.