Java *

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

Для примера возьмём приложение Petclinic, исходной код которого можно найти на GitHub. В качестве IDE буду использовать свою любимую IntelliJIDEA.

Что подвигло меня на написание данной библиотеки и чем плохи существующие решения:
К сожалению такие монстры как Hibernate «тяжеловесны» и навязывают свой API для работы с БД. Мне же нужна была простенькая библиотечка, использовать которую можно было бы в перемешку с обычным JDBC-кодом (по сути мне нужно было некоторое подобие Dapper.NET для JDBC).

Основные принципы, используемые при написании библиотеки:

• простота и атомарность — библиотечка представляет собой 1 java-файл, для добавления в проект достаточно просто добавить файлик к своим исходникам.
• ненавязчивость — библиотечка не навязывает свой API, возможно использование «вперемешку» с обычным JDBC-кодом
• независимость — библиотечка не использует ничего кроме Java SE 5
• расширяемость — библиотечка поддерживает добавление расширений, необходимых для конкретного проекта

К сожалению, на данный момент Hibernate не обладает необходимыми механизмами интеграции для работы в OSGi среде, хотя подвижки в этом направлении заметны (начальная OSGi-фикация путём разделения пакетов в 4-ой ветке). Это побуждает разрабатывать собственные механизмы, что требует немалых дополнительных усилий.

Эта статья предназначается для тех разработчиков, кому интересно: как можно использовать Hibernate со связкой Spring+OSGi; что такое паттерн Extender; как реализовать ClassLoader со специфичным поведением; как поддерживается Hibernate в Spring Framework и немного о расширении этого кода. Разумеется, для чтения статьи необходимо разбираться в технологиях Spring, Hibernate, OSGi, а также понимать основные проблемы выполнения кода в многопоточной среде. Те же кто незнаком с использованием Spring Framework в OSGi среде могут обратиться к вводной статье «Использование Spring в OSGi-контейнере».

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

На Хабре несколько раз публиковались статьи, где JRebel либо просто упоминался, либо выкладывалась информация, что вышла новая версия. При этом, не всем читателям было понятно, о чём вообще речь, и как данное ПО работает.

Как непосредственному участнику разработки данного продукта, мне хотелось бы прояснить некоторые моменты, почему JRebel существует и как он может помочь Java-разработчику.

Откуда ноги растут?

Изначальная проблема известна практически любому разработчику, который работает с Java: после каких-либо изменений в проекте, для того, чтобы увидеть результат, тратится довольно много времени на сборку и развёртывание в контейнере. На Хабре уже публиковались отличные статьи о том, как можно ускорить или автоматизировать процесс разработки, не стану повторяться. Но дело в том, что в упомянутых способах есть свои изъяны: далеко не все изменения возможно перегрузить в развёрнутом приложении штатными средствами; очень легко получить утечки памяти, которые приведут к надобности перезапуска контейнера. Технические детали хорошо расписаны в серии статей в нашем сайте — любопытных приглашаю почитать.

Куда уходит время?

Как выглядит цикл разработки web-приложения, в классическом виде:
1. Сделали изменения в коде (или в ресурсах)
2. Собрали JAR/WAR/EAR
3. Развернули полученный архив в контейнере
4. Открыли развёрнутое приложение, и, после некоторых манипуляций увидели результаты своего труда.

В зависимости от размера приложения, используемого контейнера, и некоторых других факторов, этапы 2, 3 и 4 могут занимать от нескольких секунд, до совершенно невменяемых цифр. Наша компания проводила опрос разработчиков относительно используемых технологий и времени которое затрачивается на развёртывание приложения. Как оказалось, в среднем на развёртывание тратится около 3 минут за раз, и около 10 минут в час. В плачевных случаях, где на развёртывание уходит более получаса, нет даже смысла спрашивать у человека, сколько раз в час он может повторить этот процесс. Ответ очевиден.

Когда перезапуск контейнера/приложения занимает считанные секунды, проблема, описанная выше, не ощущается так сильно. Однако, по мере роста и усложнения проекта, неудобства дадут о себе знать. Тут-то и можно задуматься: может быть, JRebel — это то, что вам нужно?

Итак, в своем посте (прим.пер. Да, Вирджиния, Scala сложна!) я согласился с тем, что Scala слишком сложна для большей части Java разработчиков. Тот пост вызвал немало дискуссий, большая часть которых исказила его смысл. Теперь я пишу снова, надеясь пояснить, о чем я, собственно, говорил и зачем мне все это нужно.

Но сначала обо мне. Меня зовут Дэвид Поллак.

Под впечатлениями от habrahabr.ru/blogs/java/134102.

Недавно мне приходилось немного поковыряться внутри JVM. Довольно интересный опыт. Текст в вышеупомянутом топике не совсем сходится с моим опытом, но я не считаю себя обладателем абсолютной истины. Ниже я поделюсь с читателями небольшой частью моих экспериментов, которые касаются непосредственно объектов Java.

Знаете сколько в памяти занимает строка? Каких только я не слышал ответов на этот вопрос, начиная от «не знаю» до «2 байта * количество символов в строке». А сколько тогда занимает пустая строка? А знаете сколько занимает объект класса Integer? А сколько будет занимать Ваш собственный объект класса с тремя Integer полями? Забавно, но ни один мой знакомый Java программист не смог ответить на эти вопросы… Да, большинству из нас это вообще не нужно и никто в реальных java проектах не будет об этом думать. Но это, ведь, как не знать объем двигателя машины на которой Вы ездите. Вы можете быть прекрасным водителем и даже не подозревать о том, что значат цифры 2.4 или 1.6 на вашей машине. Но я уверен, что найдется мало людей, которые не знакомы со значением этих цифр. Так почему же java программисты так мало знают об этой части своего инструмента?

Integer vs int

Все мы знаем, что в java — everything is an object. Кроме, пожалуй, примитивов и ссылок на сами объекты. Давайте рассмотрим две типичных ситуации:

//первый случай
int a = 300;
//второй случай
Integer b = 301;

В этих простых строках разница просто огромна, как для JVM так и для ООП. В первом случае, все что у нас есть — это 4-х байтная переменная, которая содержит значение из стека. Во втором случае у нас есть ссылочная переменная и сам объект, на который эта переменная ссылается. Следовательно, если в первом случае мы определено знаем, что занимаемый размер равен:

sizeOf(int)

то во втором:

sizeOf(reference) + sizeOf(Integer)

Забегая вперед скажу — во втором случае количество потребляемой памяти приблизительно в 5 раз больше и зависит от JVM. А теперь давайте разберемся, почему разница настолько огромна.

Из чего же состоит объект?

Прежде чем определять объем потребляемой памяти, следует разобраться, что же JVM хранит для каждого объекта:

• Заголовок объекта;
• Память для примитивных типов;
• Память для ссылочных типов;
• Смещение/выравнивание — по сути, это несколько неиспользуемых байт, что размещаются после данных самого объекта. Это сделано для того, чтобы адрес в памяти всегда был кратным машинному слову, для ускорения чтения из памяти + уменьшения количества бит для указателя на объект + предположительно для уменьшения фрагментации памяти. Стоит также отметить, что в java размер любого объекта кратен 8 байтам!

На Хабрахабре очень мало статей о SWT, поэтому я постараюсь исправить данное маленькое упущение.

Из данной статьи Вы узнаете:

• Какова мотивация использовать SWT в отличии от основного конкурента — Swing
• Основные трудности с которыми я столкнулся при разработке простенького блокнота на связке Java + SWT и Немного кода
• Каким образом упаковать и распространить свое приложение для нескольких платформ

Если Вас заинтересовало — прошу под кат.

Отзыв лицензии на поставку Oracle Java JDK в составе Linux-дистрибутивов, и с исправление 20 опасных уязвимостей в октябрьском обновлении JDK, привели к исключению реализаций jdk6 и jdk7 от Oracle из основных репозиториев Ubuntu и Debian.

День добрый всем. Решил написать заметку о небольших средствах автоматизации, которые возникли в процессе моей работы со связкой Ant+Tomcat. Работаю java-разработчиком, с недавних пор пришлось окунуться в web-разработку на Java (надо сказать не без удовольствия). Никогда с серьезными проектами для web на java не сталкивался, игрался пару раз с примерами в рамках книжек по java из серии «обо всем по немного», но ничего серьезного. А здесь проект из полноценного портала с backend`ом для отвественных за контент, большими объемами данных в БД. Ну что же столкнулся да и столкнулся. Работа пошла, новая область знаний — интересно, мелочи не достают. Но со временем процесс сборки и развертывания приложения стал очень сильно доставать, так как в самые «жаркие» дни приходилось выполнять эту операцию раз по 40, чтобы посмотреть результат работы и прощелкать его. Вот тут и возник вопрос, нельзя ли это как то автоматизировать.

Наконец-то, после достаточно большого времени бет и релиз-кандидатов вышла новая стабильная версия замечательного Spring Framework. Английский анонс тут, а по-русски — под катом

В статье рассматривается использование платформы Java для разработки совместно с OpenCL, преимущества и недостатки этого подхода. Сочетание этих технологий в разработке ПО в перспективе позволит использовать всю мощь облачных вычислений и OpenCL

Вот уже почти год как усиленно занимаюсь коддингом на Java. Столкнулся с довольно серьезной на мой взгляд проблемой, связанных с многопоточностью, как мне кажется, неразрешимой в рамках текущей реализации JVM от Oracle (сказанное относится к JDK 1.5 и выше). Дело в том, что на данный момент в Java нет возможности гарантированно безопасно остановить выполнение какого-либо потока. Данный пост разъясняет почему это именно так и предлагает начать дискуссию о способах решения этой проблемы.

С выходом седьмой версии JDK нам, счастливым разработчикам на Java, стал доступен из коробки фреймворк Fork/Join, о котором уже писали на хабре тут. Фреймворк в плане API очень похож на уже привычный ExecutorServices, но даёт весьма ощутимый прирост производительности и действительную «легковесность» потоков.

Здесь, я бы хотел рассмотреть на что стоит обратить внимание при переходе на Fork/Join.

Как обычно в конце года, появилось обновление среды разработки на Java — IntelliJ IDEA 11.

Новая версия в первую очередь отличается абсолютно новым, более компактным пользовательским интерфейсом для всех поддерживаемых платформ.

Благодаря переписанной архитектуре редактора можно эффективно работать даже с очень большими файлами. Также ускорена индексация проектов и запуск IDE.

Много внимания уделено специфичной для поддерживаемых платформ функциональности, такой как, например, полноэкранный режим на Mac OS X, или символьные ссылки на Linux.

Естественно, добавлено и улучшено огромное количество других фич

 

Разработкой браузерных GUI под явой я занимаюсь уже около 12 лет, среди прочего имею опыт использования сервлетов, JSP, XML/XSLT, Struts, Tapestry (3,4,5), Wicket, Spring MVC и GWT.

Но JSF обходил до сих пор стороной. Причина этому было то, что когда JSF только появился, то в своих первых инкарнациях выглядел устрашающе коряво — по сравнению с теми же Tapestry и Wicket.

Время шло, JSF не собирался умирать, а появился уже в версии 2.1. И я решил попробовать использовать его для одного из своих экспериментальных проектов, на которые я трачу примерно 3 месяца каждый год — для расширения кругозора и отвлечения от скучного консалтинга (которым зарабатываю детишкам на молочишко в остальные 9 месяцев).

Уж много воды утекло с тех пор, как мы пользовались мышами на com-у, модемами, играли «по нему» в игры за неимением сети, перекидывали файлики и …, чего только мы с ним не делали.

Всё, на дворе 21 век, USB 3.0 подмял по себя всё и вся, com-ы вымерли и теперь «новорожденные» программисты смотрят на этот разъём с недоумением и укоризной. Но, умерли не все, кое-кто всё-таки остался… Эти бравые парни шлют байты по трём проводам и с со снисходительной улыбкой смотрят на «новорожденных». И о том, чем эти парни пользуются выполняя свою работу я и хочу поведать в этой небольшой статье. Речь в ней пойдёт о маленькой библиотечке по имени jSSC.

Недавно в Oracle блоге Brian Goetz опубликовал ссылку на презентацию с Devoxx talk on Language / Library / VM Co-Evolution in Java SE 8.
В статье я попытаюсь вкратце раскрыть основные проблемы, которые будут решены в восьмерке, а также пути их решения, которые были избраны компанией Oracle. Остальные аспекты можно посмотреть в оригинале.

Читайте дальше:
Расширение существующих API с обратной совместимостью;
Java становится еще более объектно-ориентированной;
Лямбда-выражения в Java;
Упрощение многопоточности.

Всем привет!

Чего хотим

Хотим чтобы работала проверка орфографии в NetBeans для русского языка.

Как сделать

КО: Чтобы работала проверка орфографии для русского языка, надо установить словарь для русского языка!

Поскольку найти словарь сходу не удалось, пришлось сделать его самому. Под катом рассказ как сделать свой словарь для NetBeans. Для тех кто не хочет морочиться, в конце статьи приведены ссылки на готовые словари.

UPDATE
В комментариях подтвердили работоспособность словарей в IntelliJ IDEA и Eclipse IDE.