Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 39
Новые API годные (особенно встроенный JSON), но в целом релиз, судя по всему, будет довольно унылым. Одну из самых ожидаемых фич — Jigsaw — в девятку не только не включили, но и вообще, собственно модульность для конечных пользователей JDK отложена на неопределённый срок. Печально :(
Почему печально? Вы действительно чувствуете острую необходимость в ней?
Там, где я сейчас работаю — уже нет, в связи со спецификой архитектуры и технологий. А вот там, где я был раньше, модульности очень сильно не хватало. Понятно, что одним лишь изменением в языке всё не исчерпывается, здесь нужна инфраструктура — библиотеки, сервера приложений и т. д., но даже изменение в языке было бы очень приятным.
А где же Value Types, Continuations, отказ от Erasure, поддержка примитивных типов в дженериках, легковесные потоки? Печально… Кажется что-то не так в консерватории…
Value Types — в данный момент идет обсуждение
openjdk.java.net/jeps/169
отказ от Erasure — и отвалится scala, только за счет Erasure она и работает на jvm, но толком не работала на .net, не сталкивался когда он так уж сильно мешал, если чего и хотелось бы, так это Value Types для большей локальности данных.
поддержка примитивных типов в дженериках — в контексте Value Types возможно частично будет сделано, так как обсуждение идет, отдельно еще тестируют в www.infoq.com/news/2014/07/Project-Valhalla
Continuations/легковесные потоки — для первого придется заниматься перебрасыванием стека (что сразу усложняет ещё и jit), для второго тянуть еще и свой шедулер в jvm
Почему по первым JEP которые войдут в 9ку делается вывод о том, что там будет, а чего не будет?
Никто же не пытается по первым строкам кода говорить «какой говняный релиз вы делаете, ни нормальной админки, ни ui, а уж производительность вообще печальна»
openjdk.java.net/jeps/169
отказ от Erasure — и отвалится scala, только за счет Erasure она и работает на jvm, но толком не работала на .net, не сталкивался когда он так уж сильно мешал, если чего и хотелось бы, так это Value Types для большей локальности данных.
поддержка примитивных типов в дженериках — в контексте Value Types возможно частично будет сделано, так как обсуждение идет, отдельно еще тестируют в www.infoq.com/news/2014/07/Project-Valhalla
Continuations/легковесные потоки — для первого придется заниматься перебрасыванием стека (что сразу усложняет ещё и jit), для второго тянуть еще и свой шедулер в jvm
Почему по первым JEP которые войдут в 9ку делается вывод о том, что там будет, а чего не будет?
Никто же не пытается по первым строкам кода говорить «какой говняный релиз вы делаете, ни нормальной админки, ни ui, а уж производительность вообще печальна»
да, чуть не забыл, еще не анонсированны какие-либо наработки из graal, из наиболее интересных это работа с gpu (генерация как opencl кода, так и ptx, ну и единый jit для пачки архитектур, причем написанный на java) и Truffle
wiki.openjdk.java.net/display/Graal/Main
www.oracle.com/technetwork/java/jvmls2013wimmer-2014084.pdf
aosd.net/2014/sites/default/files/2014-04-24Graal_Modularity.pdf
wiki.openjdk.java.net/display/Graal/Main
www.oracle.com/technetwork/java/jvmls2013wimmer-2014084.pdf
aosd.net/2014/sites/default/files/2014-04-24Graal_Modularity.pdf
> отказ от Erasure — и отвалится scala, только за счет Erasure она и работает на jvm, но толком не работала на .net, не сталкивался когда он так уж сильно мешал, если чего и хотелось бы, так это Value Types для большей локальности данных.
Что за бред? Они (Scala) сами постоянно жалуются на то, что из-за грёбаного Erasure они не могут делать pattern-matching на обобщённых типах данных. Для обхода Erasure в Scala пришлось «изобретать» Manifest[T] и т.п.: docs.scala-lang.org/overviews/reflection/typetags-manifests.html
Что за бред? Они (Scala) сами постоянно жалуются на то, что из-за грёбаного Erasure они не могут делать pattern-matching на обобщённых типах данных. Для обхода Erasure в Scala пришлось «изобретать» Manifest[T] и т.п.: docs.scala-lang.org/overviews/reflection/typetags-manifests.html
www.scala-lang.org/old/node/10299
The key limitation for the moment is that Scala programs cannot use libraries in .Net that are compiled using CLR generics, such as the .Net collections. However, for this particular example that's a minor limitation as the much better Scala collections library would be the natural developer choice anyway. Just to be clear: it's only CLR generics that are not implemented in the Scala.Net compiler, all the Scala features (including Scala generics) are available to the programmer. The .Net generics will be supported in the fall.
stackoverflow.com/questions/11607170/reified-generics-in-scala-on-net-clr
The net-net is that if the JVM had reified generics (no type erasure), it would not be possible to implement Scala's type system… Scala's type system is more complex than Java's and if the JVM had generics based on Java generics, we'd still have problems in Scala. On the other hand, type erasure allows the compiler to implement a complex type system, even if all the type information is not available at runtime. (David Pollak, ему то хоть немного можно верить)
в пределах jvm за счет erasure нет разницы в каком из jvm языков использовать скала коллекции, так же верна и обратная вещь.
erasure дает как плюсы, так и минусы, но без него работа с типами требует больше накладных расходов, особенно когда вы не замыкаетесь только на своем языке.
По поводу Manifest я знаю.
The key limitation for the moment is that Scala programs cannot use libraries in .Net that are compiled using CLR generics, such as the .Net collections. However, for this particular example that's a minor limitation as the much better Scala collections library would be the natural developer choice anyway. Just to be clear: it's only CLR generics that are not implemented in the Scala.Net compiler, all the Scala features (including Scala generics) are available to the programmer. The .Net generics will be supported in the fall.
stackoverflow.com/questions/11607170/reified-generics-in-scala-on-net-clr
The net-net is that if the JVM had reified generics (no type erasure), it would not be possible to implement Scala's type system… Scala's type system is more complex than Java's and if the JVM had generics based on Java generics, we'd still have problems in Scala. On the other hand, type erasure allows the compiler to implement a complex type system, even if all the type information is not available at runtime. (David Pollak, ему то хоть немного можно верить)
в пределах jvm за счет erasure нет разницы в каком из jvm языков использовать скала коллекции, так же верна и обратная вещь.
erasure дает как плюсы, так и минусы, но без него работа с типами требует больше накладных расходов, особенно когда вы не замыкаетесь только на своем языке.
По поводу Manifest я знаю.
1) Поддержку .NET платформы выпилили в Scala 2.11: docs.scala-lang.org/scala/2.11/
2) Накладные расходы возникают как раз тогда, когда пытаясь заткнуть «баг» языка, начинают придумывать всякие Manifest[T] в коде прикладного уровня… А вот, например, на этапе выполнения JIT, зная тип, которым нужно параметризовать generic, может скомпилировать нужную версию generic'а и никаких проблем с производительностью не будет. Это как один из вариантов, можно и другие предложить.
2) Накладные расходы возникают как раз тогда, когда пытаясь заткнуть «баг» языка, начинают придумывать всякие Manifest[T] в коде прикладного уровня… А вот, например, на этапе выполнения JIT, зная тип, которым нужно параметризовать generic, может скомпилировать нужную версию generic'а и никаких проблем с производительностью не будет. Это как один из вариантов, можно и другие предложить.
1) правильно, помучались немного и решили, что овчинка не стоит выделки.
2) вот это в данный момент и обсуждается, причем нужно сделать так, чтобы не поломать совместимость со всем существующим кодом (это вам не c# где можно все взять и поломать, пользователи спокойно проглотят, для stream api в 8ке даже придумали default methods).
Из последнего:
cr.openjdk.java.net/~jrose/pres/201407-JVMEvolution.pdf
там половина ответов на ваши вопросы.
хочется быстрее? так никто не мешает принять участие в дискуссии КАК это должно быть сделано или помочь РЕАЛИЗОВАТЬ.
p.s. может я и ошибаюсь, но считаю что любой кто следит за разработкой именно платформы, видит куда все движется и что движение последнее время активизировалось. indy из 7й jvm более ограничен чем он же в 8й, так как в 7й его активно уже начал использовать ruby и дал хороший feedback, что нужно чтобы работало быстро. Похожий подход пытается применяться везде, так как после того как уйдет в люди, что-то менять будет уже очень сложно, а местами и невозможно.
2) вот это в данный момент и обсуждается, причем нужно сделать так, чтобы не поломать совместимость со всем существующим кодом (это вам не c# где можно все взять и поломать, пользователи спокойно проглотят, для stream api в 8ке даже придумали default methods).
Из последнего:
cr.openjdk.java.net/~jrose/pres/201407-JVMEvolution.pdf
там половина ответов на ваши вопросы.
хочется быстрее? так никто не мешает принять участие в дискуссии КАК это должно быть сделано или помочь РЕАЛИЗОВАТЬ.
p.s. может я и ошибаюсь, но считаю что любой кто следит за разработкой именно платформы, видит куда все движется и что движение последнее время активизировалось. indy из 7й jvm более ограничен чем он же в 8й, так как в 7й его активно уже начал использовать ruby и дал хороший feedback, что нужно чтобы работало быстро. Похожий подход пытается применяться везде, так как после того как уйдет в люди, что-то менять будет уже очень сложно, а местами и невозможно.
[промахнулся]
Сдаётся мне, что Value Types и отказ от Erasure не могут быть сделаны без поломки обратной совместимости. Плюс будут ли существующие классы JDK поддерживать нововведения? Помнится, во времена второго дотнета возник целый неймспейс — System.Collections.Generic, и так до сих пор в .NET два неймспейса с коллекциями. А в Java намеренно сделали дженерики просто в виде опциональной метаинформации для компилятора и удалось их запихнуть в существующие классы.
А зачем встраивать continuations в JDK? Это реализуемо на уровне библиотек. Лично мне известен apache javaflow, может ещё какие реализации есть.
А зачем встраивать continuations в JDK? Это реализуемо на уровне библиотек. Лично мне известен apache javaflow, может ещё какие реализации есть.
Если на пальцах. Вот выполняется функция, у неё есть локальный стек, вы делаете yield, куда и как сохранить стек, причём так, чтобы без фатального ущерба для производительности? Библиотекой такую задачу не решить без поддержки на уровне виртуальной машины… Никак…
Я думаю, что сохранить стек даже с поддержкой виртуальной машины быстро не получится. Наверное, нужно просто не так часто заниматься этой операцией. Вон, даже на уровне процессора переключение контекста не очень быстро выходит, поэтому шедулер ОС на самом деле переключается между параллельными задачами сравнительно редко по меркам процессора. javaflow для сохранения стека после каждого INVOKE* вставляет байт-код, сохраняющий стек и локальные переменные. Работает это достаточно быстро, чтобы быть приемлемым в реальных задачах, единственная проблема — серьёзное разбухание байткода. Но на самом деле, если не вставлять эти continuations вообще везде, будет не так уж и страшно. А если они нужны вообще везде… а вы уверены, что на Java напишете лучший шедулер для fibers, чем есть в ОС для потоков?
Работаем: openjdk.java.net/projects/valhalla/
Пишу на C# и Java.
Очень не хватает в Java свойств (property) как в C#. Со свойствами читабельность и компактность кода сильно повышаются.
Сравните:
C#:
User.Profile.Money += 10;
Java:
user.getProfile().setMoney(user.getProfile().getMoney() + 10);
Очень не хватает в Java свойств (property) как в C#. Со свойствами читабельность и компактность кода сильно повышаются.
Сравните:
C#:
User.Profile.Money += 10;
Java:
user.getProfile().setMoney(user.getProfile().getMoney() + 10);
Переходите на Groovy, хе-хе.
Посмотрите на Scala — это язык способен помочь вам не писать много кода, он типизированнный и вы сможете использовать Java библиотеки.
Также можно обратить внимание и на Kotlin.
О, да, согласен с вами…
У нас разрастается до: user.getProfile().setMoney(user.getProfile().getMoney().add(new BigDecimal(«10.0»)));
Бяка по сравнению с шарпом…
У нас разрастается до: user.getProfile().setMoney(user.getProfile().getMoney().add(new BigDecimal(«10.0»)));
Бяка по сравнению с шарпом…
Ничего так у вас юзеры, если у них Money в BigDecimal'ах измеряются. Или это вам точности не хватает?
А в чем бы вы измеряли Money?
Я работаю в банке.
Думаю вопросы о точности валютных операций отпадают сами собой ?:)
Думаю вопросы о точности валютных операций отпадают сами собой ?:)
Тут проблема не столько в том, что Decimal, а что валюты нет. Денег не бывает абстрактных.
У Money должен быть конструктор, который не работает без валюты.
У Money должен быть конструктор, который не работает без валюты.
Тут не в яве дело…
https://ru.wikipedia.org/wiki/Закон_Деметры
https://ru.wikipedia.org/wiki/Закон_Деметры
Свойства, скорее всего, не подружатся с соглашениями по оформлению кода Java: имена свойств будут конфликтовать с именами полей. В .NET методы и свойства именуются с заглавной буквы, поэтому имена поля и свойства будут всегда отличаться. И да, в своё время, когда я переходил с .NET на Java, я тоже сильно боялся того, что придётся от свойств отказаться, а сейчас ничего, привык.
Ну такое по-факту в одном месте кода надо написать (геттеры и прочее опущены).
Ну и потом уже в реализации
И вообще, странно искать откровений в синтаксисе языка программирования :)
IAccountOperations {
void processTransaction(Transaction t);
}
Transaction {
Type type;
}
DepositTransaction: Transaction (type=Deposit) {
UserId userId;
BigDecimal depositAmount;
String description;
}
Ну и потом уже в реализации
....
processDeposit(DepositTransaction t) {
ctx.beginTransaction();
User u = dao.lockUser(t.userId);
BigDecimal newBalance = u.profile().getBalance().add(t.depositAmount);
u.profile().setBalance(newBalance);
dao.saveTransaction(t);
dao.saveUser(u);
ctx.commitTransaction();
}
И вообще, странно искать откровений в синтаксисе языка программирования :)
Используйте Jruby :)
user.profile.money += 10.rubles
user.profile.money += 10.rubles
:-D
Люто не люблю скриптовые языки. И пусть меня за это закидают тапками — не люблю.
Отладка любого legacy в них представляет собой АД.
Особенно учитывая всякие mixin'ы.
И за возможность статического анализа кода средствами IDE очень люблю языки со строгой статической типизацией а-ля Java. И еще лучше — с автоматическим выводом типов. :-)
Люто не люблю скриптовые языки. И пусть меня за это закидают тапками — не люблю.
Отладка любого legacy в них представляет собой АД.
Особенно учитывая всякие mixin'ы.
И за возможность статического анализа кода средствами IDE очень люблю языки со строгой статической типизацией а-ля Java. И еще лучше — с автоматическим выводом типов. :-)
Хотелось бы ключевое слово var, как в C# и других JVM-based языках.
Для локальных переменных — соглашусь.
Для параметров и возвращаемого значения методов — категорически против.
Для параметров и возвращаемого значения методов — категорически против.
И вообще — чем больше можно ограничить контекст для чтения кода — тем лучше.
Подчеркиваю — тут идет разговор о возможности.
Должна быть возможность ограничений типов. Так же как и возможность их ограничивать менее строго (через generic'и, например). Одно дело, когда есть инструмент для гибкости а-ля mixin'ы, а другое дело — когда они навязываются, и никак не могут быть устранены.
Я за гибкость, но против навязываний.
Подчеркиваю — тут идет разговор о возможности.
Должна быть возможность ограничений типов. Так же как и возможность их ограничивать менее строго (через generic'и, например). Одно дело, когда есть инструмент для гибкости а-ля mixin'ы, а другое дело — когда они навязываются, и никак не могут быть устранены.
Я за гибкость, но против навязываний.
WebGL опять нет?????????????
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Анонсированы новые функции Java 9