LINUX.ORG.RU

Поддержка динамических языков в Java 7

 , ,


0

0

В JSR 292 предлагают реализовать динамический вызов метода без указания типов аргументов (invokedynamic) и инъекцию интерфейсов, которая позволит «на лету» добавлять в класс новые методы. Хотя «родная» реализация eval все еще под вопросом (в основном, из-за проблем с безопасностью), предложенные изменения повысят скорость исполнения программ на JavaScript в несколько тысяч раз и практически сравняют ее со скоростью исполнения программ на Java.

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

★★★

Проверено: maxcom ()
Последнее исправление: eugine_kosenko (всего исправлений: 2)

Ответ на: комментарий от faustus

> Компания пишет продукты, которые позволяют запускать .NET под JVM (возможно, и наоборот - не помню), без разницы в производительности. Такие дела.

Ни хера они не пишут. JVM в .NET можно транслировать без потерь (см IKVM.NET), а вот .NET в JVM транслировать невозможно, потому как:

a) Нет поддержки хвостовых вызовов b) Есть ограничения на размер классов и методов

c) Отсутствуют value types

d) Отсутствует арифметика указателей

Так что транслировать можно только некое жалкое подмножество C#. То, которое с Java более-менее совпадает. Произвольный .NET код транслировать невозможно в принципе.

Java - отличный язык. Его недостатки с лихвой компенсируются легким рефакторингом.

Ты так говоришь, потому что ты не знаешь никаких других языков. Учись, студент, подрастешь - поймешь, что Жаба примитивный, ограниченный, убогий язык.

Что, CLR даже multiple-inheritance поддерживает?

А кто тебя заставляет реализовывать ООП на уровне классов CLR? В .NET хотя бы есть выбор.

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

Всяк кулик свое болото хвалит... Ясно одно, что в ближайшем будущем программист Java будет более ценен чем программист .NET из за богатства поддерживаемых платформ...

А пока Вы тут спорите о всякой фигне, индусы тихим сапом завоевывают рынок, лабая проекты на джава и пользуясь огромной популярностью у столпов IT индустрии...

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

> Не нужно.

А я не про это спрашивал. Ты (или другой анонимус) сказал, что .NET годится для любых языков. А я вот что-то не помню, чтобы C++ (под который куева туча строк кода) можно было скомпилировать в .NET. Выходит, CLR - всего лишь ограниченный закос под JVM?

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

> Ясно одно, что в ближайшем будущем программист Java будет более ценен чем программист .NET из за богатства поддерживаемых платформ...

Онолитеги на лоре - такие онолитеги. Смешно.

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

> А я вот что-то не помню, чтобы C++ (под который куева туча строк кода) можно было скомпилировать в .NET

Managed C++ видел?

Выходит, CLR - всего лишь ограниченный закос под JVM?

CLR - это намного больше, чем JVM. Потому и годится для гораздо более широкого диапазона языков.

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

> А пока Вы тут спорите о всякой фигне, индусы тихим сапом завоевывают рынок,

О, он собрался с индусами за миску риса конкурировать. Ну, если ты сам так свой уровень оцениваешь - вперед, с песнями, лабай на Жабе.

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

> Онолитеги на лоре - такие онолитеги. Смешно.

Смешно, не смешно, а .Net держится только в вин среде и более он нах никому не нужен. Студентам еще, преподу показать как они круто могут на C# ЧМ считать.

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

> Смешно, не смешно, а .Net держится только в вин среде и более он нах никому не нужен

Дурак, такой дурак. Неграмотный, неумный, малолетний - но зато с понтами. Презираю таких.

Про MonoTouch слышал? Гигантских размеров рынок. ASP.NET сейчас очень много где на unix/mono хостится. Ещё более гигантский рынок.

Ну и я не говорю уж о твоих убогих познаниях в ценообразовании. Стоимость труда ну никак не зависит от числа платформ, представь себе, красноглазик малолетний.

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

> Гигантских размеров рынок. ASP.NET

Повторяй это 3 раза в день перед едой. Смешной пример, ага.

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

> 1. НЕНАВИЖУ динамическую типизацию, ибо, кладес ошибок.

прикол в том, что для тупой JVM вполне статическая типизация продвинутого языка (типа скалы) может транслироваться в код, требующий «динамических» инструкций

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

Да они даже такой весь статический по природе Hibernate умудряются делать на рефлексии. У жабистов вообще мозги очень странно работают.

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

Ясно одно, что в ближайшем будущем программист BASIC будет более ценен чем программист .NET из за богатства поддерживаемых платформ...

Fixed во имя банка Империал и всемирной истории.

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

>Да они даже такой весь статический по природе Hibernate умудряются делать на рефлексии.

В каком месте он статический?

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

> В каком месте он статический?

Схема БД известна во время компиляции. Типы объектов, которые в неё мапятся, тоже известны. Можно генерить статический код. Но вместо этого дрючат тормозную рефлексию. Глупо.

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

> Это не лишняя сущность, это контроль. В JVM escape analysis ни хера не работает, кроме как в самых тривиальных случаях.

А какие случаи могут быть «нетривиальные»? Хм-хм... И есть какие-то бенчмарки по этому поводу?

В .NET же можно сколь угодно сложные ситуации разруливать через стек. Совершенно рациональное решение.

«Сложные ситуации», которые bottleneck и которые один раз на тысячу, было бы разумнее, имхо, выражать через хинты виртуальной машине, т.е. через обычные атрибуты к определению класса.

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

> А какие случаи могут быть «нетривиальные»?

Первый же виртуальный вызов всё обломает.

Хм-хм... И есть какие-то бенчмарки по этому поводу?

По поводу сравнения скорости выделения на стеке и на куче? Полно.

«Сложные ситуации», которые bottleneck и которые один раз на тысячу, было бы разумнее, имхо, выражать через хинты виртуальной машине, т.е. через обычные атрибуты к определению класса.

Нелепо. VM не должна быть настолько сложной (и, соответственно, тормозной).

Вообще не понимаю причины претензий к структурам в .NET. Удобно же!

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

> > Хм-хм... И есть какие-то бенчмарки по этому поводу?

По поводу сравнения скорости выделения на стеке и на куче? Полно.

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

Вообще не понимаю причины претензий к структурам в .NET. Удобно же!

Ну по сути к структурам как к части CLR претензий нет — мало ли какие языки придётся молоть. Скорее у меня претензии к сишарпу, потому как противоречит замыслу — управление памяти, дескать, берёт на себя язычок/платформа, и в то же время мы явно указываем — в стеке или в куче работать. Если так идти, то можно было бы и разрешить явно указывать когда мы хотим освободить память (т.е. опционально вырубать GC) и прочие плюшки.

А какие случаи могут быть «нетривиальные»?

Первый же виртуальный вызов всё обломает.

Не могу понять сходу, что не так с ними?

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

> Не, по поводу того, искейп-анализит ли ява конкретный данный случай, или нет.

Ну, как бы, совершенно очевидно, что не анализит.

противоречит замыслу

Не очень. C# позиционируется не как Java, все же.

Не могу понять сходу, что не так с ними?

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

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

> То, что мы не знаем, что именно может быть вызвано, и, соответственно, не знаем, искейпится ли указатель из текущего контекста, или он подохнет по первому же return-у.

гы. прикольно.

а я воспринимал структуры только с точки зрения программиста — семантика value types как-то более привычна например в математике.

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

> То, что мы не знаем, что именно может быть вызвано, и, соответственно, не знаем, искейпится ли указатель из текущего контекста, или он подохнет по первому же return-у.

А где бы вообще почитать такие краткие и емкие сравнения языков/вирт. машин? В википедии java vs. этого нет (хотя много другого интересного). А то у меня терпения и времени не хватает спецификации читать.

Да и вообще сжатую инфу по c#, в таком вот стиле.

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

>Схема БД известна во время компиляции. Типы объектов, которые в неё мапятся, тоже известны. Можно генерить статический код. Но вместо этого дрючат тормозную рефлексию. Глупо.

Дык - в этом смысле и XML парсить универсальными парсерами глупо.

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

Но вместо этого дрючат тормозную рефлексию. Глупо.


Посмотрите исходники. В Hibernate дофигища мест где генерируется нативный байт-код.
Да и рефлексия используется исключительно с кэшированием.

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

Компания пишет продукты, которые позволяют запускать .NET под JVM (возможно, и наоборот - не помню), без разницы в производительности. Такие дела. Так что (ну ты понял)


linux.org.ru/news/java/1988216

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

> А какими надо?

То же самое соображение - если схема паршеного документа известна во время компиляции можно сгенерировать эффективный парсер.

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

У кого-нибудь IDEA завелась на Java7?


Чтобы завелась, надо в idea.properties добавить idea.no.jdk.check=true

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

Но то, что тот же F# под .NET генерит гораздо более шустрый код, чем Scala под JVM - это показательно


Какие ваши доказательства?

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

>чего греха таить, ява говно по сравнению с шарпом.

Блин, давно мечтаю эту фразу услышать не от анонимуса. Но пока смелости тока анонимусам и хватает.

По сабжу: инъекции интерфейсов свойственны динамическим языкам (например питону, в котором это есть). Но у динамических языков есть общий недостаток - они медленные. Срвсем недавно на ЛОРе, кажется при обсуждении луа, срач стоял на эту тему.

А теперь правильный вопрос: че жаба реализнув такие инъекции будет более тормознутая чем раньше?!

k0valenk0_igor ★★★
()

> реализовать динамический вызов метода без указания типов аргументов

и инъекцию интерфейсов, которая позволит «на лету» добавлять в класс новые методы

Жаждут успеха Питона, который это умеет уже лет 10?

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

>Жаждут успеха Питона, который это умеет уже лет 10?

Это как раз и нужно для успешной реализации питона и тому подобного.

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

>Жаждут успеха Питона, который это умеет уже лет 10?
Грешно смеяться над умирающим питоном.

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

>А теперь правильный вопрос: че жаба реализнув такие инъекции будет более тормознутая чем раньше?!

А это собираются именно в жабку тащить, а не в JVM? В 7-ке и сейчас нет поддержки invokedynamic, хотя в JVM уже пол года присутствует, если не более.

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

>> CLR - это намного больше, чем JVM

О, да. Намного больше. dotNetFx 3.5 SP1 230Мб весит. Против 40Мб jre7ea

Картинки и видео там же не может быть. Стало быть, там один код. Вот это действительно дотнет намного больше чем ЖВМ :\ Дотнет действительно как большая такая часть десктопного ОС, в то время как ЖВМ - небольшой костыль для запуска пары серверных приложений гыгы.

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

>Не, это не он. Стиль речи другой.

Судя по тому, что он писал лисп для JVM, а сейчас кучу времени инвестировал в .NET - может и он.

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