Posted by: Ivko | January 10, 2010

Избор на седмицата – 02/2010

Staying away from JSF API

Java шампионът Cay Horstman е доста активен от началото на годината. Тази седмица той ни показва как в Java EE 6 можем да си напишем нашите bean-ове без те да зависят от JSF API-тата.

Авторът започва с това, че много програмисти за по-лесно вкарват компилационни зависимости на техните session bean-ове към JSF API-то, въпреки че няма нужда от това. Той разглежда четири най-често срещани такива ситуации и ни показва как можем да избегнем пряката употреба на класове от javax.faces пакета. По този начин може по-лесно да сменим използваната view технология, както и да си напишем бързо тестове за bean-овете без да се мъчим да им осигуряваме някакъв application server.

Maven Mythbusters – part 1

Авторът на Java Power Tools John Ferguson Smart започна нова серия статии. Тя е вдъхновена от любимата на много от вас поредица на Discovery Chanel – Mythbusters. Авторът тук развенчава някои митове относно Maven.

Да припомним – Maven е инструмент, който се използва за управлението на артефактите в нашите проекти. С помощта на XML конфигурации (в предстоящата трета версия ще има възможност за това да се ползва Groovy) можем да укажем какво да правим с нашия проект – компилация, пускане на тестове, създаване дистрибуция на нашия software и нейния deploy и т.н. Нещо като ant, само че с инжектирани стероиди🙂

Естествено, най-използваната функция на Maven е управлението на dependency-тата на нашия проект. Това са външните библиотеки, на които разчита нашето приложение, за да се компилира и да работи (например log4j.jar). Вече не е необходимо да се грижим да ги сваляме от интернет, след това да сваляме dependency-тата на нашите dependency-та и т.н. С всичко това се занимава Maven.

Именно този мит се опитва да развенчае авторът – че Maven всеки път се връзва към интернет и сваля последните версии на външните библиотеки. Анализирайки output-а на процеса и времето за изпълнение, John Smart показва, че това наистина не е така. Естествено Maven сравнява локалната версия на библиотеката и тази в maven repository-то, но го прави само веднъж на ден. При това и тази опция може да бъде изключена.

Java vs. C++: the performance showdown

Тази статия е за всички любители на кой е по-по-най състезанията в областта на езиците за програмиране. Тук не става въпрос за модерните напоследък static vs dynamic и други подобни спорове (които твърдят в началото на всяка година, че Java ще умре до края на същата година). По-скоро може да прочетете за нещо, което го има още от началото на езика – кой е по-бърз Java или C++.

Доскоро битуваше митът, че такъв въпрос няма, защото един език като C++ винаги ще бъде по-бърз от Java-та. Авторът обаче решава да пробва няколко примерни програми включващи интензивни изчисления и работа с паметта (под Windows). Само за въведение ще ви разкажа набързо за първата: генерират се случайни числа и се пълнят в масив. След това тези числа се умножават последователно по числата от 2 до Y (Y е някакво произволно избрано от автора число, което е еднакво и за двата теста). Това нещо се пуска доволно много пъти като накрая се взима средното време за изпълнение на операциите.

В крайна сметка се оказва, че когато е включена пълна оптимизация на C++ компилатора и linker-а, Java-та е по-бавна около 2500 пъти. Но без никаква оптимизация по време на компилиране, C++ е по-бавен повече от два пъти.

Подобни са и резултатите с останалите тестове – операции с числа с плаваща запетая (floating point numbers), сравняване на числа, работа с паметта. C++ код, оптимизиран по време на компилация за бързодействие, е доста по-бърз от стандартно компилиран Java код.

И така, C++ печели, но с малко помощ😉

You should upgrade to Java EE 6

Това е съвет, който ни дава Gavin King. За тези, които не могат да се сетят веднага, става въпрос за автора на Hibernate, JBoss Seam и spec lead на Java Contexts and Dependency Injection спецификацията.

Тук авторът се опитва да отговори на няколко брадясали с времето критики защо не трябва да използваме application server-и. Това е за хората, които все още са убедени, че е по-добре за сложно enterprise приложение да ползват Tomcat плюс standalone библиотеки за persistence mapping, транзакции и някакъв third party presentation framework.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: