Pull to refresh

Comments 35

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


Продакшен = реальный проект или библиотека.
Так предложение не ментейнерам проектов, а ведущему курсов.
Выбрать любой серьезный проект и на его основе показывать примеры, можно вообще форкнуть и переводить на Java 8.
Не уверен, что это хорошая рекомендация.
В реальном проекте конкретные языковые фичи будут использоваться в 1%-3% строках кода. Т.е. либо обучающийся не будет читать оcтальные 97%-99% (тогда непонятно зачем их писать), либо будет читать (тогда из каждого часа обучающийся посвятит фичам 1-2 минуты).
Пример: для изучения написания своего загрузчика классов читать сорцы RMI (remote class loading) + сорцы Tomcat (множественные загрузчики классов).
Первоначальное предложение было «на основе», а не «целиком». Просто «целиком» — это скорее поддержки 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 ???
Можно и так. Однако, оцените количество импортов именно в этом файле
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, которые реально удерживать в голове.
Также при переходе с Collection API на Stream API зачастую происходит жесткий рефакторинг (связанный хотя бы с ленивостью и распараллеливанием стримов), который охватывает не границы классов, а границы целых пакетов.
В итоге найти отдельный содержательный класс с фиксированной функциональностью, который перешел с Java 7 на Java 8 — это отдельная проблема.
Абсолютно с вами согласен. Увы, но java 8 сейчас для проектов типа «пофанится» не более. Никто в серьезное приложение ее сувать не будет.
Никто в серьезное приложение ее сувать не будет.

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

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

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

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

Ну не берусь говорить о планах 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) из-за сложности ведения такого проекта.
Спасибо, просто после LINQ, лямбд и остальных фич, не очень уютно было пробовать Java(смотрел Spring MVC3 как вариант портирования наработок с Asp.Net MVC).
Ну и немного смущало как раз polyglot programming — для больших проектов(продукты с постоянной поддержкой и постепенными развитием) не очень хотелось такого «счастья».
LINQ — это вещь. У нас такое даже не рассматривается.
В Scala вводят какую-то сильную концепцию макросов, будет доступ к AST в момент компиляции, можно делать проверки типов, автогенерацию и прочее.
Наблюдаю перетекание части программистов с Java на Scala — она реально крута. Однако останавливает
1) на Scala мало работы, а это не очень хорошо.
2) на Scala мало фреймворков. Либо используешь Java-стек со стилем Java (Hibernate, JSF, ...) либо сыроватые фреймворки Scala. Т.е. можно из-за одной Akka пописать на Scala, однако современный проект — это десяток фреймворков, а не один.

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

А по поводу фреймворков… Вот меня лично всегда удивляли люди, которые пробуя скалу пытаются все делать «Scala-way», переходя все границы. Люди, очнитесь, если вы пишете на Scala, это совсем не означает что везде надо использовать имплисеты или макросы с квазицитатами. Ну на Java вы же не делаете все на дженериках, только потому что они там есть? А если вдруг где-то нет дженериков то не называете это «не Java-way».
На Scala отлично пишется простой ООП, с использованием того же хибернейта. Те же Entity пишутся как обычно принято в Scala, безо всякого мифического Java стиля. Scala мультипарадигменный язык и то что на ней можно делать удобный ООП, не превращает ее автоматом в Java.
А то что сами библиотеки написана на Java, что из того? В этом есть огромное преимущество Scala. Не надо изобретать все велосипеды по новой.
То есть как с F# — где надо — можно и на нем, а где пофиг можно и на Java? Оба в байткод компилятся для JVM?
1. Да, и Scala и Java компилятся в один байткод для JVM.
2. Нет, не так. Везде можно писать на Scala. Просто используем различные возможности Scala в разных местах.
А на чем написана библиотека вообще пофиг.
Sign up to leave a comment.