Pull to refresh

Comments 22

Звучит очень-очень заманчиво) Возможность подтянуть разные библиотеки из разных языков очень соблазнительна, правда как представлю проект, написанный 10-ю разными разработчикаи на 10-ти разных языках, который надо поддерживать, начинает глаз дергаться ..)
Ну не обязательно же все свое писать, можно готовые подключать, как в случае графиков на R :-)
Когда я впервые услышал, что в нативном образе нельзя использовать рефлексию я подумал, что он бесполезен. Однако только сейчас до мне дошло, что рефлексия обычно используется в долгоживущих энтерпрайз приложениях. Нативный же образ нужен для быстрых утильных программ, а в них, обычно, рефлексия не используется.
Так это же не нативный образ. Graal умеет собирать «честную» Java без ограничений и тогда дает буст перформанса. А может собрать ее в «нативный образ» тогда получится машинно-зависимый код, без JVM, но зато быстро стартующий. Так вот именно нативная сборка рефлексию не умеет.
Согласен, правильно будет «в нативной сборке использование рефлексии ограничено».
Но лично мое ИМХО — использовать рефлексию настолько неудобно, что можно сказать, что ее использовать нельзя.

Бесполезен. Рефлексия очень глубоко вросла в Java и сильно савязана с Java runtime. Любой фреймворк или практически любая библиотека так или иначе завязана на рефлексию, а без своей экосистемы Java практически бесполезна. Рефлексия не позволяет компилятору вычислить статически все дерево вызовов и слинковать статически только используемый код, как это делает С например. Именно поэтому в Java 9 придумали модули — чтобы хоть как-то обязать пользователя объявлять статически границы, и чтобы финальный бандл можно было порезать с 200-300Мб до 30-40Мб.


Помимо рефлексии фреймворки еще делают такие безобразные вещи как classpath-scan, annotation processing и кодогенерация в рантайме, custom classloaders, etc… Так что много еще что отвалится.

Если мне нужно написать скрипт на 200 строчек и я знаю только java — то рефлексию я зачастую использовать не буду. Часто вы в утильных скриптах используете рантайм кодогенерацию и кастомные класслоадеры?

Возьмите GCJ чтоли и будет вам счастье. GraalVM как бы не для этого.

Получается, что нативный образ — это условный kotlin/native с сохранением большей части либ под jvm? Интересно, почему в него не смогли джетбрейнсы?
Не совсем, KN представляет собой куда более узкоспециализированную и ограниченную штуку. А вообще, «давайте сделаем набор случайных несвязанных ad-hoc возможностей» — modus operandi котлина в целом.
Помню было очень востребовано преобразовать java-code в native: а) чтобы не переписывать кучу кода б) чтобы получить преимущества native.

Все это упирается в то, что Java-код использует большую std-либу, как-то Calendar, Date, Locale, Collator (icu) — сложно представить программу c более 50К LOC, где не вылезет что-то такое. Так вот до GraalVM был многообещающий AvianVM c AOT: куча классных HelloWorld компилировалось, но нужный проект не взлетал, крешился при работе с данными и GС. Avian развивался 4 года, но так и не смог запустить не самую сложную Java программу, а потом похоже пропал интерес и все закончилось.

Хочется верить, что GraalVM не ждет участь неудачников, ведь написание AOT крайне сложная задача, особенно если мы говорим о кроссплатформенной генерации ASM. Прежде всего хотелось бы, чтобы GraalVM позволял компилировать Java-code и делать удобную линковку с C++ кодом туда и обратно. Если это еще можно будет скомпилировать через clang для мобильных платформ. наступит сказка.

Был когда-то больше 10 лет назад вполне рабочий GCJ. Писали на нем и утилиты и серверы. Все летало, особых багов замечено не было. А 20 лет назад был Microsoft JVM, который поддерживал нативную линковку с DLL-ями, win32 API и ActiveX. Еще есть отличный Excelsior…
GraalVM ждет та же участь — мутное целевое использование, сильная завязанность на Java и ее ограничениях, запоздалость. Сейчас грядет WebAssembly, компиляторы в него из разных языков, затем его выпустят как отдельную VM.

Нативный бинарник? Черт, я впервые почувствовал непреодолимое желание написать что-нибудь на Java. Это на столько хорошо, что не верится.

Так берешь Truffle и строишь AST из C# — и будут программы, написанные на C# запускаться :-) Можно ещё попробовать CIL напрямую подсовывать в GraalVM, но это посложнее.
Раз jvm и llvm поддерживаются, значит байткод туда тоже тоже можно засунуть. Просто C# не так интересно, хочется вызывать F# и Nemerle из Scala.

Есть информация по поводу нативных образов из других языков с биндингами?


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

Там как раз написано, что bitcode может выполняться совместно с python. Но совсем нативные образы не получится слинковать, мне кажется. Но, если библиотеки перекомпилировать, то должно все получиться.
Первый проделанный эксперимент с подсчетом слов в лорем ипсуме не дает никакого прироста скорости. Запускаю на ноуте.
TopTen написан не оптимально:
.flatMap(line -> Arrays.stream(line.split("\\b")))
                .map(word -> word.replaceAll("[^a-zA-Z]", ""))

Здесь создается регексп сперва на каждую строчку в файле а потом и на каждое слово. IDEA умеет выносить за скобочки такое.
Collectors.counting
— аллоцирует Long на каждый инкремент (по крайней мере в Java 8). Знаю это довольно позорно, но это так. Тут либо можно написать свой MutableLong и реализовать редьюсер самому, либо взять сторонний Object2LongMap где можно эффективно инкрементить значения.
Ещё связка sort().limit(10) — у меня нет уверенности что там используется какой-то эффективный алгоритм, скорее всего сортируется вся последовательность целиком. Самый быстрый способ на коленки сделать лучше: положить все ентри в PriorityQueue (внутри там бинарная куча на массиве) через конструктор, а потом достать первые 10 элементов. Фокус в том, что можно за линию собрать кучу из массива. Главное не добавлять элементы по одному. Можно реализовать с помощью к-той порядковой статистики алгоритм эффективнее по памяти но это немного муторно.
Only those users with full accounts are able to leave comments. Log in, please.