История изменений

Что за зверь и для чего?

Легковесные потоки, как в erlang/golang, чтобы можно было писать блокирующий код, и при этом держать миллион соединений без миллиона ОС-потоков.

Народ ещё с рекордами не обжился, а тут это.

По сути это будет оптимизация. К примеру Optional будет не отдельным объектом в куче, то же к Integer и тд. Если я правильно понял, там особо ничего и делать не надо, оно само заработает. Ну для своих классов надо будет включить, если у тебя есть классы-обёртки, но и без этого профит ожидается.

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

Чтобы получить app.exe без JVM, который будет моментально стартовать и жрать меньше памяти.

Ведь одно из преимуществ первого в том, что там динамическая оптимизация, которая может оптимизировать лучше статической в каком нибудь C++.

Это опциональный режим. Определённая популярность GraalVM говорит о том, что народу это интересно.

Какое-то оно малоинтересное получается, в итоге. Лучше бы довели до ума модули и дженерики. Например коллизии в версиях транзитивных зависимостей до сих пор не имеют нормального решения, а лишь те или иные костыли, о которых постоянно плачится Барух на Jug.ru Нормальные модули могли бы решить эту проблему.

Вряд ли это когда-нибудь изменится. Да и вряд ли это кому-то особо надо. Меня текущие генерики устраивают более чем, к примеру. С версиями - в npm превращать жаву - я против.

Что за зверь и для чего?

Легковесные потоки, как в erlang/golang, чтобы можно было писать блокирующий код, и при этом держать миллион соединений без миллиона ОС-потоков.

Народ ещё с рекордами не обжился, а тут это.

По сути это будет оптимизация. К примеру Optional будет не отдельным объектом в куче, то же к Integer и тд. Если я правильно понял, там особо ничего и делать не надо, оно само заработает. Ну для своих классов надо будет включить, если у тебя есть классы-обёртки, но и без этого профит ожидается.

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

Чтобы получить app.exe без JVM, который будет моментально стартовать и жрать меньше памяти.

Ведь одно из преимуществ первого в том, что там динамическая оптимизация, которая может оптимизировать лучше статической в каком нибудь C++.

Это опциональный режим. Определённая популярность GraalVM говорит о том, что народу это интересно.

Какое-то оно малоинтересное получается, в итоге. Лучше бы довели до ума модули и дженерики. Например коллизии в версиях транзитивных зависимостей до сих пор не имеют нормального решения, а лишь те или иные костыли, о которых постоянно плачится Барух на Jug.ru Нормальные модули могли бы решить эту проблему.

Вряд ли это когда-нибудь изменится. Да и вряд ли это кому-то особо надо. Меня текущие генерики устраивают более чем, к примеру.

Что за зверь и для чего?

Легковесные потоки, как в erlang/golang, чтобы можно было писать блокирующий код, и при этом держать миллион соединений без миллиона ОС-потоков.

Народ ещё с рекордами не обжился, а тут это.

По сути это будет оптимизация. К примеру Optional будет не отдельным объектом в куче, то же к Integer и тд. Если я правильно понял, там особо ничего и делать не надо, оно само заработает. Ну для своих классов надо будет включить, если у тебя есть классы-обёртки, но и без этого профит ожидается.

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

Чтобы получить app.exe без JVM, который будет моментально стартовать и жрать меньше памяти.

Ведь одно из преимуществ первого в том, что там динамическая оптимизация, которая может оптимизировать лучше статической в каком нибудь C++.

Это опциональный режим. Определённая популярность GraalVM говорит о том, что народу это интересно.

Какое-то оно малоинтересное получается, в итоге. Лучше бы довели до ума модули и дженерики. Например коллизии в версиях транзитивных зависимостей до сих пор не имеют нормального решения, а лишь те или иные костыли, о которых постоянно плачится Барух на Jug.ru Нормальные модули могли бы решить эту проблему.

Вряд ли это когда-нибудь изменится.