Расширенный материал по Java 8

    Не секрет, что многие Java-программисты, начиная свой путь в индустрии, уделяют большое внимание «тяжелым» технологиям — OpenJPA, Spring, JAX-RS, EJB, WS-*,… Это дает возможность как скорее влиться в современные корпоративные проекты, так и максимизировать скорость роста зарплаты.

    Многие из них в конце концов «спускаются» до технологий лежащих в основе указанных фреймворков — JDBC, Servlet API, NIO/NIO.2. Однако прискорбно, что зачастую не остается время на детальное изучение самого языка и возможностей платформы.

    Речь идет не о тонкостях или экзотике, а о том, что составляет существенную часть работы фреймворка: Servlet-контейнер использует множественные ClassLoader-ы, JPA2-провайдер использует манипулирование байткодом, абсолютное большинство библиотек используют Reflection API, всеобщее использование Generics только «усугубилось» с появлением функциональных интерфейсов (java.lang.function.*) и лямбд.

    На недопонимание изначальной платформы (ClassLoader, Reflection API) накладываются «новвоведения» Java 5 (Generics), а теперь еще и Java 8 (методы в интерфейсах, ссылки на методы, лямбды, Stream API, JSR 308: Pluggable Type Systems). Надо обратить внимание на то, что Generics + Java 8 — это не просто языковые фичи, это частично переход к функциональному стилю программирования.

    Также я веду курс «Scala for Java Developers» на платформе для онлайн-образования udemy.com (аналог Coursera/EdX).

    Я собрал определенное количество полезных (на мой взгляд) ссылок по следующим темам
    1. Методы в интерфейсах, ссылки на методы, множественное наследование
    2. Лямбды (Project Lambda)
    3. Stream API
    4. Функциональные алгоритмы
    5. Аннотации
    6. Генерики
    7. Reflection API
    8. Загрузка классов

    Надеюсь кто-то сочтет их полезными.

    Детальная информация


    1. Методы в интерфейсах, ссылки на методы, множественное наследование
      • Статические методы в интерфейсах
      • Методы по умолчанию (default methods) в интерфейсах
      • Как жить с множественным наследованием: возможности, разрешение конфликтов
      • Ссылки на методы


    2. Лямбды (Project Lambda)
      • Предыстория, синтаксис лямбд
      • Детали: lexical scope, effectivelly final, closures, type inference, target typing, сериализация лямбд


    3. Stream API
      • Внешняя и внутренняя итерация: map, filter, forEach
      • Более сложные операции: flatMap, reduce, collect
      • Свойства потоков и свойства операций: immediate/terminal, lazy/eager, stateless/stateful, short-circuiting, serial/parallel, ordered/unordered, associative
      • Параллельные Stream-ы и неявная интеграция с Fork/Join


    4. Функциональные алгоритмы
      • Параллельная редукция работает на моноидах (ассоциативностью, нейтральный элемент). Что это значит?
      • Optional, CompletableFuture,… и другие монады. Что это значит?
      • Карринг, функции высшего порядка. Что это значит?
      • Комбинаторные алгоритмы на Java 8


    5. Аннотации
      • Определяем свои аннотации
      • Мета-аннотации: @ Target, @ Retention, @ Inherited, @ Repeatable, ...
      • Аннотации для компилятора: @ Override, @ SafeVarargs,@ SuppressWarnings, @ FunctionalInterface, ...
      • Вычитываем аннотации при помощи Reflection API
      • JSR 308: Type Annotations and Pluggable Type Systems
      • Расширяем проверку типов с помощью Checker Framework: @ NotNull, @ GuardedBy, ...


    6. Генерики
      • Bounded type parameters
      • Self-bounding generics
      • Wildcards
      • Как реализованы в Java, ограничения (type erasure, bridge methods, non-reifiable types)


    7. Reflection API
      • java.lang.reflect
      • Как framework-и используют Reflection API (JUnit, Mockito, Servlet API 3)


    8. Загрузка классов
      • Формат class-файла и процедура загрузки классов (load, link (verify, prepare, resolve), init)
      • ClassLoader: определяем свой загрузчик, строим иерархию загрузчиков
      • Динамическая кодогенерация, компилируем “на лету”: Compiler API, javaassist
      • Динамическая кодогенерация, собираем из байткода: BCEL, cglib
      • Динамическая кодогенерация, трансформация существующего байткода в процессе загрузки классов




    Вебинары


    5 августа стартует серия из 8-ми вебинаров по темам, указанным выше. Вебинары длятся 2.5-3 часа, в течении которых удается глубоко погрузится в проблематику и детали. Занятия проходят 2 раза в неделю в течении 4-х недель во вторник и пятницу в 18.00-21.00 по московскому времени.
    Стоимость
    При оплате до 12 июля: 225$.
    При оплате до 19 июля: 250$.
    При оплате до 26 июля: 275$.
    При оплате после 26 июля: 300$.

    Контакты


    email: GolovachCourses
    skype: GolovachCourses
    GolovachCourses
    Company
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 35

      +5
      Честно, лучшей рекламой ваших курсов было бы написание хороших технических статей. Сразу видно будет что вы преподаете и как.
        0
        Очень хорошо.
        За несколько видео охватывается очень много материала, о котором начинающие даже могут не подозревать
        После его видео начал писать на Java, его видео решили примерно 75% проблем, связанных с самой идеологией Java и ее библиотекой.
          +2
          Отлично пишете, продолжайте.
          +1
          Полезнее было бы увидеть, не что появилось, а как было — как стало.
          В формате best practice на основе реальных проектов или open source библиотек.
            0
            На практике лямбды и прочее из «восьмерки» вы увидите совсем не скоро. Сейчас увы в продакшине популярна версия 1.7,
              +2
              Не надо свой древний продакшен сравнивать со всеми)
              У нас вполне себе используется.
                0
                Что за проект?
                +1
                При чем здесь production?
                Это курсы по обучению, очевидно что нужно для эффективного обучения использовать реальный код, а не абстрактные примеры.
                У нас есть в планах переход на Java 8, поэтому надо постепенно сдвигать сознание в правильном направлении.
                  0
                  В формате best practice на основе реальных проектов или open source библиотек.


                  Продакшен = реальный проект или библиотека.
                    0
                    Так предложение не ментейнерам проектов, а ведущему курсов.
                    Выбрать любой серьезный проект и на его основе показывать примеры, можно вообще форкнуть и переводить на Java 8.
                      0
                      Не уверен, что это хорошая рекомендация.
                      В реальном проекте конкретные языковые фичи будут использоваться в 1%-3% строках кода. Т.е. либо обучающийся не будет читать оcтальные 97%-99% (тогда непонятно зачем их писать), либо будет читать (тогда из каждого часа обучающийся посвятит фичам 1-2 минуты).
                      Пример: для изучения написания своего загрузчика классов читать сорцы RMI (remote class loading) + сорцы Tomcat (множественные загрузчики классов).
                        0
                        Первоначальное предложение было «на основе», а не «целиком». Просто «целиком» — это скорее поддержки open source.
                        Видимо без примера не обойтись:
                        1. Заходим на GitHub
                        github.com/search?q=stars%3A%3E1000&type=Repositories&ref=advsearch&l=Java
                        2. Открываем первый попавшийся файл
                        github.com/nathanmarz/storm/blob/moved-to-apache/storm-core/src/jvm/storm/trident/fluent/ChainedAggregatorDeclarer.java#L72-L114
                        3. Переписываем с применением lambda, stream, map|reduce и т.д.
                        4. Показываем «как было» (красным) и «как стало» (зеленым), объясняем почему так лучше
                        5. Profit ???
                          +1
                          Можно и так. Однако, оцените количество импортов именно в этом файле
                          import backtype.storm.tuple.Fields;
                          import java.util.ArrayList;
                          import java.util.HashSet;
                          import java.util.List;
                          import java.util.Set;
                          import storm.trident.Stream;
                          import storm.trident.operation.Aggregator;
                          import storm.trident.operation.CombinerAggregator;
                          import storm.trident.operation.ReducerAggregator;
                          import storm.trident.operation.impl.ChainedAggregatorImpl;
                          import storm.trident.operation.impl.CombinerAggregatorCombineImpl;
                          import storm.trident.operation.impl.CombinerAggregatorInitImpl;
                          import storm.trident.operation.impl.ReducerAggregatorImpl;
                          import storm.trident.operation.impl.SingleEmitAggregator;
                          import storm.trident.operation.impl.SingleEmitAggregator.BatchToPartition;
                          import storm.trident.tuple.ComboList;
                          И добавьте сюда неимпортированные, но используемые классы из этого же пакета.
                          Вот с таким количеством сущностей придется столкнуться человеку, читающему сорцы этого класса. Сущностей явно больше 7+-2, которые реально удерживать в голове.
                            +1
                            Также при переходе с Collection API на Stream API зачастую происходит жесткий рефакторинг (связанный хотя бы с ленивостью и распараллеливанием стримов), который охватывает не границы классов, а границы целых пакетов.
                            В итоге найти отдельный содержательный класс с фиксированной функциональностью, который перешел с Java 7 на Java 8 — это отдельная проблема.
                            0
                            Абсолютно с вами согласен. Увы, но java 8 сейчас для проектов типа «пофанится» не более. Никто в серьезное приложение ее сувать не будет.
                              0
                              Никто в серьезное приложение ее сувать не будет.

                              А серьезный проект для вас это Java не выше 1.4 + WebSphere не выше 6?
                              Там же все годами проверено, и уж точно никогда не заглючит.
                              Ведь новая Java то постоянно падает, глючит и вообще непонятно как ее в релиз-то в таком состоянии выпустили.

                              P.S. А вообще я заметил такую тенденцию. Если контора бодишоп аутсорсерская, то они до последнего держатся и не будут внедрять новые технологии. Ибо «заказчик не хочет рисковать, а за покупку IBM еще никого не увольняли».
                              А вот если контора продуктовая, то они больше думают о собственной эффективности и там гораздо чаще можно увидеть какую нибудь Java8 или Scala. Хотя конечно это лишь мое окружение, в котором не так много контор. Было бы интересно узнать статистику по обширнее.
                                0
                                Ваша ирония мне понятно, но
                                1. Сейчас я считаю, что stable = java 7.
                                2. WAS 6 нифига не стабильная, потому что пишут индусы.
                                3. Java 8 вы можете увидеть только в проектах молодых и которые будут не скоро работать.
                                4. Scala и собственная эффективность два несопоставимых слова. Компилится она ужасно долго.

                                P.s. сам юзаю в своих проектах java 8 + spring 4, но на работе Java 7 + spring 3. Не хочу чтобы, кто-то терял деньги из-за сырого продукта.
                                  0
                                  Ну да, в принципе на Java8 проекты сейчас в разработке.
                                  Но многие в прод пойдут до конца года. Что в общем-то довольно скоро по меркам проектов.

                                  Фишка использования Scala в том, что скорость разработки с лихвой компенсирует скорость компиляции. Которая кстати постоянно улучшается.
                                    0
                                    Ну не знаю. Scala по сравнению с той же Java не дает в скорости разработки ровным счетом ничего.)
                                      0
                                      Пока не начал на ней писать — конечно)
                                      Говорить на эту тему можно долго, но я пока не сделал на ней пару проектов тоже особо не понимал плюшек.
                                0
                                Тут есть проблема, что в апреле прикрыли публичные обновления Java 7. Поэтому если хочется исправлений безопасности, то надо платить деньги или идти на Java 8.
                        0
                        Где GWT и GXT — там все еще 1.6 проживает :-)
                      0
                      Сам пока только посматриваю в сторону Java. С одной стороны радует, что платформа и язык развиваются. С другой стороны — ощущение, что развитие идет очень медленно и тот же .Net развивается куда шустрее. Можете прояснить, что происходит и куда движется платформа в целом? И если кто переезжал с .Net на Java — стоит ли при текущем положении дел это делать.
                        0
                        Можете прояснить, что происходит и куда движется платформа в целом?

                        Ну не берусь говорить о планах Oracle, но я бы отметил следующий моменты:
                        1. Языковые фичи — это не платформа. И, по моему мнению, они не играют такой значительной роли, какую им приписывают. Скажем лично я перешел с C++ на Java потому, что в моей конторе больше платили за Java (отсутствие перегрузки операторов меня вообще не волновало). Я выбрал Java, а не C# (в то время) потому, что мне казалось, что на Java более открытая экосистема, точнее открыты сорцы всей JDK и я могу не читать MSDN, а просто подключить сорцы к IDE и читать сорцы.
                        2. Из платформы — введение в Java 7 байткода invokedynamic (java.lang.invoke.*), что открывает возможность написания эффективных языков с динамической типизацией для JVM. Однако, полагаю, что массовым polyglot programming не станет (т.е. смесь из Java/Scala/Groovy/Clojure) из-за сложности ведения такого проекта.
                          0
                          Спасибо, просто после LINQ, лямбд и остальных фич, не очень уютно было пробовать Java(смотрел Spring MVC3 как вариант портирования наработок с Asp.Net MVC).
                          Ну и немного смущало как раз polyglot programming — для больших проектов(продукты с постоянной поддержкой и постепенными развитием) не очень хотелось такого «счастья».
                            0
                            LINQ — это вещь. У нас такое даже не рассматривается.
                            В Scala вводят какую-то сильную концепцию макросов, будет доступ к AST в момент компиляции, можно делать проверки типов, автогенерацию и прочее.
                          0
                          Наблюдаю перетекание части программистов с Java на Scala — она реально крута. Однако останавливает
                          1) на Scala мало работы, а это не очень хорошо.
                          2) на Scala мало фреймворков. Либо используешь Java-стек со стилем Java (Hibernate, JSF, ...) либо сыроватые фреймворки Scala. Т.е. можно из-за одной Akka пописать на Scala, однако современный проект — это десяток фреймворков, а не один.

                          P.S. Чистое IMHO, наблюдаю друзей, перешедших на Scala, со стороны.
                            0
                            На сколько я понимаю Akka так же юзабельна и из Java?
                              0
                              Это просто мода. Не более.
                                0
                                По поводу работы есть разные мнения. С одной стороны разработчики не могут найти работу, а с другой работодатели буквально плачут в поисках Scala разработчиков и готовы брать просто джавистов с переобучением.

                                А по поводу фреймворков… Вот меня лично всегда удивляли люди, которые пробуя скалу пытаются все делать «Scala-way», переходя все границы. Люди, очнитесь, если вы пишете на Scala, это совсем не означает что везде надо использовать имплисеты или макросы с квазицитатами. Ну на Java вы же не делаете все на дженериках, только потому что они там есть? А если вдруг где-то нет дженериков то не называете это «не Java-way».
                                На Scala отлично пишется простой ООП, с использованием того же хибернейта. Те же Entity пишутся как обычно принято в Scala, безо всякого мифического Java стиля. Scala мультипарадигменный язык и то что на ней можно делать удобный ООП, не превращает ее автоматом в Java.
                                А то что сами библиотеки написана на Java, что из того? В этом есть огромное преимущество Scala. Не надо изобретать все велосипеды по новой.
                                  0
                                  То есть как с F# — где надо — можно и на нем, а где пофиг можно и на Java? Оба в байткод компилятся для JVM?
                                    0
                                    1. Да, и Scala и Java компилятся в один байткод для JVM.
                                    2. Нет, не так. Везде можно писать на Scala. Просто используем различные возможности Scala в разных местах.
                                    А на чем написана библиотека вообще пофиг.
                                      0
                                      Спасибо.
                              0
                              Также я веду курс «Scala for Java Developers» на платформе для онлайн-образования udemy.com (аналог Coursera/EdX).

                              Only users with full accounts can post comments. Log in, please.