Добрый день.
Думаю, многие из вас знают о выходе Java 8, и о том, какие нововведения она несет. К сожалению, последняя версия GWT(2.6.0) на данный момент до сих пор не поддерживает лямбды и default-методы в интерфейсах. Поскольку фреймворк GWT довольно востребован, многим приходится часто сталкиваться с разработкой именно на нем, мне не терпелось попробовать писать на GWT с использованием вновь добавленных в язык фич.

Внесу и свой вклад в тренд темного программирования.
Многим из вас знакома дилемма: использовать ли DI в своем проекте или нет.
Поводы перехода на DI:

• создание развитой системы авто-тестов
• повторное использование кода в различном окружении, в том числе в различных проектах
• использование 3rd-party библиотек, построенных на DI
• изучение DI

Доводы не использовать DI:

• усложнение понимания кода (поначалу)
• необходимость конфигурирования контекста
• изучение DI

Допустим, у нас есть большой рабочий проект, принято решение: переводить на DI. Разработчики чувствуют свой потенциал, уровень мидихлориан в крови зашкаливает.

Путь тебя ждет тернистый и долгий, мой юный падаван.

Если проект большой и в нем много разработчиков, одним коммитом вряд ли удастся сделать такой рефакторинг. Поэтому мы используем несколько плохих практик, упростив переход, а затем от них избавимся.

Приветствую, хабражители!

Сегодня я хочу рассказать вам про сервис, который обнаружил буквально недавно — Dripstat. Он позволяет установить на локальную JVM специальный java-агент, который собирает статистику работы сервера приложений и отправляет на сайт, где с ней можно детальнее ознакомиться.

— Ну какие сервисы мониторинга? Сегодня суббота! — скажете вы, и будете правы. Более того, я даже поддержу эту мысль и в данной заметке расскажу как раз об обратной, развлекательной, стороне медали, и чуть-чуть о программировании на JS.



Итак, приглашаю дочитать тех кто заинтересовался.

Пирамидальная сортировка (она же сортировка кучей) – классический алгоритм который, пожалуй, должен знать любой программист. Старая добрая «пирамидка» примечательна тем, что в независимости от набора данных у неё одна и та же сложность по времени (причём, очень пристойная) – O(n log n). Лучших и вырожденных случаев для неё нет.

С момента изобретения метода (а в этом году алгоритм празднует свой полувековой юбилей) было немало охочих кардинально оптимизировать процесс накладывания сортирующих куч. Тернарная пирамидальная сортировка, плавная сортировка, сортировка декартовым деревом – вот неполный список инноваций. Перечисленные алгоритмы хотя при тестировании и опережают оригинал по абсолютной скорости кто на 12, а кто и на 25%, в оценке временной сложности всё равно крутятся вокруг O(n log n). При этом данные методы весьма изощрённо реализованы.

Своё видение пирамидальной сортировки предложил и скромный труженик Университета Манитобы Джейсон Моррисон. При этом способ в некоторых случаях по скорости приближается к O(n).

Эта тема была поднята в ходе нескольких (3+) собеседований который я прошёл за последние полтора месяца — в разных вариациях но примерно об одном. Казалось бы, известные вещи — но собрав все ответы и объяснения какие я давал (и кое-что что нашёл позже в гугле), решил сохранить их не у себя в гугл-драйве, а написать краткий обзор.

Речь шла о небольших и типовых приложениях Enterprise / Web на Java, каких пишется множество (ну такие, на 10-100 тысяч клиентов, миллион посещений и т.п.). Пусть это будет обобщённый диалог в виде вопросов и ответов.

 

В: Допустим, у вас есть приложение (самое обычное — JSP, Spring, Hibernate например) развернутое на томкате (Apache Tomcat) и вы однажды замечаете что сервер с томкатом загружен на 80% в среднем. Что делать?

Доводилось ли вам когда-либо исследовать шаг за шагом выполние некого Java кода, который не удосужились снабдить средствами логирования или прочими механизмами наблюдения?
Усложним задачу тем, что не будем перекомпилировать исследуемый код, да и вообще перезапускать существующий процесс (тот случай, когда непонятное поведение было да и при перестарте сплыло). Java машина, конечно же, запущена с самыми обыкновенными опциями (без параметров для аттача дебагера или ещё каких наворотов).
А так хочется понять, что же происходит.

Именно этим мы и займёмся.

Данная статья будет интересна тем, кто вдруг осознал, что ему хочется
попробовать создать что-то без навязанного обществом JEE и Spring.

Вы, о дорогой Java Смельчак, не хотите быть винтиком в огромном механизме вашего Фреймворка?
Вам надоело чувствовать себя «машинисткой» по написанию конфигов и настроек?
Вы хотите решать задачи так, как хочется вам, а не так, как это видится автору унифицированной на нужды
миллионов библиотеки?

Тогда добро пожаловать под кат, где я поделюсь с вами полезными находками Мира без Фреймворка.

Скажу сразу, что стандартная реализация такого взаимодействия — существует.

Однако, поскольку эта статья — продолжение темы «Простой вызов удалённых сервисных методов в одностраничных приложениях», здесь будет приведена альтернативная схема взаимодействия, необходимая для замены ajax на вебсокеты, в контексте подхода (jrspc), описанного в вышеупомянутой теме.

В первой статье — был описан механизм вызова сервисных методов, с использованием ajax.

В этой статье — описано, как можно реализовать данный механизм, с заменой ajax на вебсокеты, не меняя код бизнес-логики приложения.

Такая замена даёт более быстрое соединение(тесты в конце), экономию серверной памяти, и добавляет возможность вызывать методы клиента с сервера.

Для демонстрации, написано небольшое чат-приложение, с исходным кодом на гитхабе.
на примере разбора которого, я попытаюсь объяснить, как реализованы клиентская и серверная части такого взаимодействия.
Приложение работает на сервере tomcat 7.042.
Поддерживает https и wss (сертификат неподтверждённый), и не ведёт логов на сервере.

Всем привет. Последние события в Украине как-то отбросили меня от хабра, но вот, все, более менее, наладилось и я, вернувшись к привычному ритму работы, вспомнил о парочке своих постов в черновиках. В связи с выходом 8-й версии явы, пост, возможно, уже несколько устарел, но не пропадать же добру.
Итак, как-то вечером, оптимизируя очередной кусочек кода — случайно заглянул в String и обнаружил, что класс строки уже не тот. Так как строка, пожалуй, один из самых распространенных типов, думаю многим будет интересно узнать об изменениях.

Оптимизирован метод String.split()

Метод split строки стал быстрее работать для односимвольного параметра. Теперь в методе вообще не будет использоваться регексп и будет применен indexOf в цикле.
Было:

public String[] split(String regex, int limit) {
        return Pattern.compile(regex).split(this, limit);
}

Стало:

public String[] split(String regex, int limit) {
    if (((regex.value.length == 1 && 
           ".$|()[{^?*+\\".indexOf(ch = regex.charAt(0)) == -1) || ...)) {
            ...
            while ((next = indexOf(ch, off)) != -1) {
                ...
            }
            ...
            return result;
    }
    return Pattern.compile(regex).split(this, limit);
}

2 поля удалены

Начиная с 6-го апдейта 7-й явы из класса строки были удалены 2 поля:

private int offset;
private int count;

Как вы, наверное, помните эти поля использовались при вызове метода substring. Назначение полей — уменьшение сложности метода и попытка избежать создания нового массива символов строки используя ссылку на уже существующий массив. Что, в свою очередь, в некоторых ситуациях могло порождать известную утечку памяти. Теперь же размер строки на 8 байт меньше и проблема утечки навсегда решена.

Если вам приходилось создавать интеграционные решения на Java, наверняка, вам знаком замечательный Java framework под названием Apache Camel. Он с лёгкостью осуществит связку между несколькими сервисами, импортирует данные из файлов, баз данных и прочих источников, оповестит вас о различных событиях в Jabber-клиент или по E-mail, станет основой для композитного приложения на базе большого числа других приложений.

В этой статье я расскажу как создать библиотеку, которая использует другие библиотеки и при этом уместить всё в одном jar.

Допустим мы пишем библиотеку, она использует другие библиотеки и, в частности, для примера, support library. Если бы мы использовали maven, то в pom файле просто прописали зависимости и не парились. Но что если нашу библиотеку будут использовать люди, которые не пользуются системами сборок или пользуются ant' ом?

Мы можем положить зависимости рядом с нашим jar. Но тогда неизбежны конфликты библиотек разных версий, например, если мы используем одну версию support library, а в самом приложении другая. Тогда придется руками одну из них удалять.

Можно пойти другим путем, вспомним что jar это обычный zip файл. Мы распакуем все зависимости, получим байт-код в виде .class файлов, далее компилируем код нашей библиотеки, кладем все .class файлы в одно место и собираем из них jar. Но если в приложении используются те же библиотеки что и у нас, то получим ошибку что в проекте два одинаковых класса.

Несколько дней назад мне на глаза попался занимательный такой вопрос, касающийся того, каков будет результат выполнения данного кода:

double a = 2.0 - 1.1;

или такого:

double f = 0.0;
for (int i=1; i <= 10; i++) {
	f += 0.1;
}

Вопреки всем моим ожиданиям, ответ: 0.89999999999999991 в первом случае и 0.99999999999999989 во втором.
Для тех, кто хочет узнать почему, а так же еще несколько занимательных фактов про этот тип данных, милости просим.

При написании собственных веб-приложений часто возникают такие ситуации, в которых приходится делать выбор между синхронным и асинхронным выполнением запросов. С одной стороны, идея синхронной работы выглядит вполне логичной: мы запускаем некоторый процесс, дожидаемся его завершения и после этого продолжаем работу. Но на деле такой подход хорош только в случае простых вычислений. Представьте, что в процессе выполнения вам нужно, к примеру, сделать сложный запрос к базе данных — а то и, еще лучше, отправить запрос к другому серверу и дождаться от него результатов. В этом случае дальнейшая работа потока будет остановлена на довольно продолжительное время — а это, понятное дело, далеко не всегда является приемлемым. Именно в таких случаях на помощь приходят асинхронные запросы. Давайте посмотрим, как работа с ними реализована в Play framework.

Уже много лет работая со спрингом, я заметил забавную закономерность: в каждой новой версии добавляется новый способ конфигурирования контекста. Давайте вспомним, как это было:

• В первом спринге конфигурацию можно было писать исключительно на xml-e. (ClassPathXmlApplicationContext(“context.xml”))
• Во втором (точнее с 2.5) появилось возможность создавать контекст через аннотации. (AnnotationConfigApplicationContext(“package.name”))
• Третий спринг добавил конфигурацию на джаве. (AnnotationConfigApplicationContext(JavaConfig.class))
• Четвёртый тоже сохранил традицию и уже с декабря 2013 года можно конфигурировать при помощи груви скриптов (GenericGroovyApplicationContext(“context.groovy”))

Консультируя и проводя тренинги в различных компаниях, я видел самое разное отношение к этим способам конфигурирования. Крупные компании, зачастую живущие по принципу «работает – не трогай», до сих пор лелеют старые xml -конфигурации, продолжая их множить и кормить новыми бинами. «Зато у нас все централизовано!» — кричат их архитекторы, добавляя 100500-тысячную строчку в xml-Бога.
Компании поменьше, пытающееся угнаться за новшеством технологий, беспощадно сжигают старые XML-ы, переписывая всё что могут, на аннотации, а что не могут на Java-конфиг. И уже потирают руки, пытаясь придумать, а куда бы им теперь приткнуть конфигурацию на грувях.



Видел я и совсем забавные ситуации, когда не очень разбирающийся во всей этой каше конфигураций джуниор, дублировал декларацию бинов, прописывая их и в xml-e и через аннотации (ну так чтобы наверняка).

А где же находится правда? Неужели как всегда посередине?
Давайте попробуем разобраться…

Для начала давайте сравним стратегии декларации бинов.

Начнём с классического XML-a:

Кратко рассматривается API библиотеки GPars и решение многопоточной задачи средней сложности, результаты которой могут быть полезны в «народном хозяйстве».

Данная статья написана в ходе исследования различных библиотек акторов, доступных Java-программисту, в процессе подготовки к чтению курса «Multicore programming in Java».

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

Это первая статья из цикла статей цель которых сравнить API, быстродействие и реализацию акторов Akka с реализациями в других библиотеках на некоторой модельной задаче. Данная статья предлагает такую задачу и решение на GPars.

GPars — библиотека написанная для Clojure с широкой поддержкой различных подходов к параллельным вычислениям.
Плюсы GPars

• Исходный код написан на Java (в отличии от Akka, написанной на Scala). Всегда интересно посмотреть «что под капотом» на «родном» языке программирования
• GPars представляет собой целый «зоопарк» подходов (Actor, Agent, STM, CSP, Dataflow)
• GPars использует классы из runtime-библиотеки Clojure, написанной на Java. Интересно покопаться

Это первая часть статьи, посвященной такому языковому механизму Java 5+ как аннотации. Она имеет вводный характер и рассчитана на Junior разработчиков или тех, кто только приступает к изучению языка.

Я занимаюсь онлайн обучением Java и опубликую часть учебных материалов в рамках переработки курса Java Core.

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

Мой метод обучения состоит в том, что я

1. строю усложняющуюся последовательность примеров
2. объясняю возможные варианты применения
3. объясняю логику двигавшую авторами (по мере возможности)
4. даю большое количество тестов (50-100) всесторонне проверяющее понимание и демонстрирующих различные комбинации
5. даю лабораторные для самостоятельной работы

Данная статье следует пунктам #1 (последовательность примеров) и #2(варианты применения).

В свете недавних изменений (начиная с релиза 0.7.3 от 27 декабря 2013) новая система сборки под Android становится очень интересной в том числе и для тех, кто использует NDK. Теперь стало действительно просто интегрировать нативные библиотеки в вашу сборку и генерировать APK для различных архитектур, корректно обращаясь с кодами версий.

Реклама в приложении — это очень важный момент, а иногда и единственный заработок.

Думаю, многие задавались вопросом о том, какая реклама лучше и где ее лучше размещать. Каждое приложение индивидуально, поэтому нужно экспериментировать.

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

Но все ли так просто?

Вот и состоялся релиз Java 8. Кто-то по-настоящему ждал её и тестировал предрелизную версию, считая недели до марта, для кого-то смена цифры в версии JDK была лишь поводом пару раз поиграть с обновленным языком в домашней IDE без отрыва от работы (ввод языка в production всегда занимает некоторое время), кто-то просто не нуждается в новых фичах, им и возможностей «семерки» хватает с лихвой. Тем не менее, восьмую Java ждать стоило — и не просто ждать, но и внимательно присмотреться к некоторым ее нововведениям, ведь в этой версии их действительно немало, и если ознакомиться с ними поближе, то не исключено, что хорошо знакомый язык предстанет перед вами в совершенно новом свете, порадовав возможностью писать еще более красивый и лаконичный код. И если уж говорить про новые возможности Java 8, было бы странно не начать с лямбда-выражений.

Java еще не умерла — и люди начинают это понимать.

Добро пожаловать в ведение по Java 8. Этот материал шаг за шагом познакомит вас со всеми новыми фичами языка. Вы научитесь использовать методы интерфейсов по умолчанию (default interface methods), лямбда-выражения (lambda expressions), ссылки на методы (method references) и повторяемые аннотации (repeatable annotations). Все это будет сопровождаться короткими и простыми примерами кода. В конце статьи вы познакомитесь с наиболее свежими изменениями в API, касающихся потоков, функциональных интерфейсов, расширений для ассоциативных массивов, а также с изменениями в API работы с датами.