Java *

Очередная встреча московского сообщества Java-разработчиков jug.msk.ru прошла 7 июня 2018 года. На ней выступили Руслан Черёмин и Максим Грамин. Доклады были посвящены тестированию конфигурации и управлению кодом для баз данных.

Вопросов о работе сервисов на этапах разработки, тестирования и поддержки очень много и все они на первый взгляд непохожи: «Что произошло?», «Был ли запрос?», «Какой формат даты?», «Почему сервис не отвечает?» и т.д.

Корректно составленный лог сможет подробно ответить на эти и многие другие вопросы абсолютно автономно без участия разработчиков. В стремлении к такой заманчивой цели родилась библиотека логирования Eclair, призванная вести диалог со всеми участниками процесса, не перетягивая на себя слишком много одеяла.

Об одеяле и особенностях решения — далее.

Каждый из нас делает рутинную работу. Каждый пишет boilerplate код. Зачем? Не лучше ли автоматизировать данный процесс и работать только над интересными задачами? Читай эту статью, если хочешь, чтобы такую работу за тебя делал комп.



Данная статья написана на основе расшифровки доклада Зака Свирса (Zack Sweers), разработчика мобильных приложений Uber, с которым он выступил на конференции MBLT DEV в 2017 году.

Я участвую в развитии open source проекта Apache Ignite, работая над проектом мне стало интересно оценить тестовое покрытие и вот что из этого получилось.

Компания Netflix одержима вопросом доступности сервисов. Мы уже не раз рассматривали его в нашем блоге и рассказывали, как нам удаётся достичь своих целей. Мы используем circuit breakers, лимиты параллельных подключений, тестирование с помощью намеренного внедрения ошибок (chaos testing) и многое другое. Сегодня мы представляем вам ещё один инновационный подход, который существенно повышает стабильность приложения при экстремальных нагрузках и позволяет избежать каскадных сбоев в работе сервисов — адаптивные лимиты параллельных подключений. Больше не нужно тратить силы, чтобы определить лимиты параллельных подключений, позволяющие системе поддерживать небольшое время отклика. В рамках этого анонса мы также выкладываем в открытый доступ простую Java-библиотеку с возможностями интеграции для сервлетов, управляющих программ и gRPC.

Привет, Хабр!

Работаю на большом интеграционном проекте (IBM WAS, WebSphere MQ, Oracle) и оплетаю наш кровавый энтерпрайз паутиной функциональных тестов в JMeter, который крутится на тестовом стенде и пробуждается по зову Jenkins после деплоя нового билда. По мере увеличения количества тестов столкнулся с проблемой поддержания тестовой документации в актуальном виде.

Здравствуйте, уважаемые Хабровчане.

Изложенный в статье материал предназначен для новичков и, возможно, как и мне сэкономит несколько часов поисков на StackOverFlow и других сайтах с целью получить удобную систему логирования, которая сама поймет куда логировать — в консоль, файл или logstash.

Автор: Игорь Мастерной, Senior Developer, лидер Java-сообщества DataArt

18–19 мая в Киеве прошла JEEСonf — одно из самых ожидаемых событий для всего Java-сообщества Восточной Европы. DataArt выступил партнером конференции. На четырех сценах выступали докладчики со всего мира: Фолькер Симонис — представитель SAP в JCP и контрибьютор OpenJDK, Юрген Хёллер — главный инженер Pivotal, отец всеми любимого Spring Framework, Клаус Ибсен создатель Apache Camel, и Хью МакКи — евангелист в Lightbend.

График был очень насыщенным: за два дня более 50 выступлений, по 45 минут на каждое. 10 минут перерыва — и бежим на новый доклад. На то, чтобы посмотреть все видео, когда они появятся в сети, потребуется много времени. Поэтому кратко опишу доклады, которые я счел наиболее интересным и на которых побывал лично.

Видео версия туториала

Оптическое распознавание символов (англ. Optical Character Recognition, сокр. OCR) дает компьютеру возможность читать текст на изображении, позволяя приложениям понимать знаки, статьи, листовки, страницы текста, меню или что угодно в виде текста. Mobile Vision Text API предоставляет разработчикам Android мощную и надежную возможность OCR, которая поддерживает большинство устройств Android и не увеличивает размер вашего приложения.

В этом туториале вы создадите приложение, в котором в процессе видеосъёмки будет распознаваться и воспроизводиться весь текст, попадающий в кадр.

Статья отражает личный опыт автора – заядлого программиста микроконтроллеров, которому после многолетнего опыта микроконтроллерной разработки на языке С (и немного на С++) довелось участвовать в крупном Java-проекте по разработке ПО для ТВ-приставок под управлением Android. В ходе этого проекта удалось собрать заметки об интересных различиях языков Java и C/C++, оценить разные подходы к написанию программ. Статья не претендует на роль справочника, в ней не рассматривается эффективность и производительность Java-программ. Это скорее сборник личных наблюдений. Если не указано иное, то речь идет о версии Java SE 7.

Во вторник, 5 июня, в петербургском офисе компании Oracle состоится встреча JUG.ru с Артуром Пилипенко, инженером компиляторной команды компании Azul Systems. Тема встречи — Falcon.

Falcon — JIT-компилятор, построенный на базе инфраструктуры LLVM, уже год как является компилятором по умолчанию в виртуальной машине Zing. Новый компилятор во всю используется в продакшне и показывает существенный прирост производительности по сравнению со старым компилятором C2.

Привет! Удивительно, но первая часть статьи даже кому-то понравилась.
Отдельное спасибо за ваши отзывы и комментарии. У меня для вас плохая хорошая новость: нам ещё есть о чём поговорить! А если точнее, то о некоторых деталях работы Reactor.

Прошлые статьи с цифрами нашли положительный отклик среди читателей, поэтому — на этот раз нечто совершенно иное — ещё один статистический сборник: рынок труда в Java, цифры из вакансий, резюме и заработные платы. Сам наш hh.ru в большей части написан на ней — уже ~15 лет мы следим за всей экосистемой Java и за динамикой джавистов на рынке.

Под катом — сравнение Java с совокупным рынком, реальные/предлагаемые/ожидаемые зарплаты, конкуренция и общие тренды. 21 график, время чтения — примерно 7 минут.

19 апреля мы впервые провели Open Day в Москве.


Наташа Числер, HR директор JetBrains и главный организатор мероприятия:

В рамках проекта интеграции GridGain и хранилища на базе Hadoop (HDFS + HBASE) мы столкнулись с задачей получения и обработки существенного объема данных, примерно до 80 Тб в день. Это необходимо для построения витрин и для восстановления удаленных в GridGain данных после их выгрузки в наше долговременное хранилище. В общем виде, можно сказать, что мы передаём данные между двумя распределёнными системами обработки данных при помощи распределённой системы передачи данных. Соответственно, мы хотим рассказать о тех проблемах, с которыми столкнулась наша команда при реализации данной задачи и как они были решены.

Так как инструментом интеграции является кафка (весьма подробно о ней описано в статье Михаила Голованова), естественным и легким решением тут выглядит использование SparkStreaming. Легким, потому что не нужно особо беспокоиться о падениях, переподключениях, коммитах и т.д. Spark известен, как быстрая альтернатива классическому MapReduce, благодаря многочисленным оптимизациям. Нужно лишь настроиться на топик, обработать батч и сохранить в файл, что и было реализовано. Однако в ходе разработки и тестирования была замечена нестабильность работы модуля приема данных. Для того чтобы исключить влияние потенциальных ошибок в коде, был произведен следующий эксперимент. Был выпилен весь функционал обработки сообщений и оставлено только прямое сохранение сразу в avro:

Буквально недавно, в конце марта, вышел Java 10. Но в связи с тем, что компания Oracle внесла изменения в релизный цикл (новый релиз каждые полгода), к выходу готовится 11-я версия.

Запуск намечен на сентябрь 2018-го. Мы предлагаем взглянуть на некоторые из грядущих обновлений, о которых известно на сегодняшний день.

Добрый вечер, коллеги.

Перевод статьи, который мы вам предложим сегодня, призван помочь ответить на вопрос: а назрела ли необходимость целой книги по оптимизации кода на Java? Надеемся, что материал не только покажется вам интересным, но и пригодится на практике. Пожалуйста, не забудьте проголосовать.

Привет, Хабр! Представляю вашему вниманию перевод статьи «The Java Language Specification (Chapter 17. Threads and Locks)» Оригинал.

Глава 17. Треды и блокировки (Chapter 17. Threads and Locks)

В то время как большая часть дискуссий в предыдущих главах касалась только поведения кода, исполняемого одновременно и как единое утверждение или выражение одновременно, т.е. в одном треде, JVM (Java virtual machine) может поддерживать одновременно несколько тредов исполнения. Эти треды независимо друг от друга используют код, который действует на значения и объекты, находящиеся в общей памяти (shared main memory). Треды могут поддерживаться за счет использования множества аппаратных процессоров, временным разделением одного аппаратного процессора или временным разделением нескольких аппаратных процессоров.

Треды представлены классом Thread. Единственный способ, каким пользователь может создать тред — это создать объект этого класса; каждый тред ассоциируется с каким-то объектом. Тред начнет свое исполнение, когда будет вызван метод start() на соответствующем Thread-объекте.
Поведение тредов, особенно когда синхронизация выполнена некорректно, может быть непонятно и не соответствовать ожиданиям. Эта глава описывает семантику многопоточного программирования; она содержит правила, согласно которым значения можно увидеть для чтения в общей памяти, которая обновляется множеством тредов. Так как спецификация аналогична Memory Models для различных архитектур, эта семантика известна как Memory Model языка программирования Java. Когда не будет возникать путаницы, мы просто будем называть эти правила "Memory Model".

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

17.1 Синхронизация (17.1. Synchronization)

Не знаю, как на вас, а на меня в последнее время производят сильное впечатление статьи про новые Java-технологии — Graal, Truffle и все-все-все. Выглядит так, как будто раньше ты придумал язык, написал интерпретатор, порадовался какой язык хороший и погрустил, какой медленный, написал к нему нативный компилятор и/или JIT, а ведь нужен ещё отладчик… LLVM есть, и на том спасибо. После прочтения этой статьи сложилось (несколько гротескное) впечатление, что после написания интерпретатора специального вида работу можно, в принципе, и завершать. Ощущение, что теперь кнопка "Сделать зашибись" стала доступна и программистам-компиляторщикам. Нет, конечно, JIT-языки медленно стартуют, им нужно время на прогрев. Но, в конце концов, время и квалификация программиста тоже не бесплатные — в каком бы мире информационных технологий мы бы жили, если бы до сих пор писали всё на ассемблере? Нет, может, всё бы, конечно, и летало (это если программист грамотно инструкции разложил), но вот насчёт суммарной сложности активно используемых программ у меня есть некоторые сомнения...

В общем, я прекрасно понимаю, что в дилемме «затраченное программистом время vs идеальность полученного продукта ("ручная работа")» границу можно двигать до скончания веков, поэтому давайте сегодня просто попробуем воспользоваться традиционной библиотекой SQLite без подгрузки нативного кода в чистом виде. Будем использовать уже готовую truffle-реализацию языка для LLVM IR, зовущуюся Sulong.

Агентно-ориентированное программирование

Тема дипломной работы в университете была «Многоагентные системы для обработки баз знаний». Подключение многоагентной системы Jade к базе знаний Protege не составило труда и диплом готов. Теперь можно моделировать абстрактные учебные задачи, рои агентов, и так далее и тому подобное. Но возник вопрос, а как применить на деле полученные знания? Случай завершить НИОКР подвернулся при работе над системой «умный дом». Потребовалось небольшое многопоточное приложение для передачи данных от «умного дома» стороннему разработчику веб-интерфейсов. Вот прекрасная возможность применить Агентно-ориентированное программирование. В результате была успешно создана многоагентная система для параллельного программирования.