Štítek: Java

Informace specifické pro Javu

Effective Exception

Občas je možné slyšet, že kontrolované výjímky v Javě (checked exceptions) jsou experiment, který se nepovedl. Bruce Eckel je ve svém článku (Does Java need Checked Exceptions?) odsuzuje a říká, že by Java byla lepší bez nich.

Autor říká, že kontrolované vyjímky obvykle nedokážeme ošetřit namístě a proto je pošleme „výš“ – buď je zabalíme do jiné (obecnější) vyjímky nebo naší metodu označíme, že vyvolává tuto vyjímku (to ovšem znamená porušení abstrakce – proč by volající měl vědět něco o tom, že čtu ze souboru nebo z databáze?).

Důkazem tvrzení, že s kontrolovanými vyjímkami není něco v pořádku, je i změna HibernateException z kontrolované na nekontrolovanou (mezi verzemi hibernate 2.x a 3.x).

Článek
Effective exception ovšem říká, že kontrolované vyjímky nejsou tak úplně špatné. Jen jsou špatně použité v základních Java API.

Myslím, že autor v tomto článku to vystihl správně. Doporučuji k přečtení. Toto je také důvod, proč se kontrolované vyjímky nejeví jako problém už u malých ukázkových programů – prostě u nich chápeme jinak chybu programu (contingency) a selhání systému (fault), než u velkých projektů.

Automatická správa zdrojů

V C++ existuje jedna velmi používaná technika pro získávání/uvolňování zdroje (zamykání, alokaci paměti, vrácení databázového spojení do connection poolu, apod.) – používají ji např. autopointery (auto_ptr<> a Smart Pointers z boost.org).

Základní myšlenkou je, že vytvoříte jednoduchý objekt na zásobníku. V jeho konstruktoru získáte zdroj a v destruktoru opět uvolníte. Celé je to velmi efektivní, protože dojde k alokaci paměti jen na zásobníku. Pokračování textu Automatická správa zdrojů

FCKFaces

Součástí JSF implementace MyFaces je i balík rozšiřujících komponent Tomahawk. Ten obsahuje i komponentu pro wysiwyg editaci (<h:inputTextarea/>). Ta je celkem otřesná, pokud ji porovnáte třeba s FCKEditorem. Narazil jsem ovšem na FCKFaces – JSF plugin, který používá FCKEditor.

Instalace je jednoduchá. Stáhnete jar, přidáte do classpath (např. do pom.xml, nainstalujete do repository) a v JSP stránce můžete použít:

<ui:composition xmlns:fck="http://www.fck-faces.org/fck-faces">

<fck:editor value="#{akce.obsah}" width="100%" toolbarSet="Basic"/>

Aby ovšem modul fungoval správně (totiž všechny JavaScript soubory a obrázky jsou součástí jaru), musíte ještě použít FCKServlet a přidat jej do web.xml:

<servlet>
        <servlet-name>FCKServlet</servlet-name>
        <servlet-class>org.fckfaces.util.Servlet</servlet-class>
</servlet>

<servlet-mapping>
        <servlet-name>FCKServlet</servlet-name>
        <url-pattern>/fckfaces/*</url-pattern>
</servlet-mapping>

Začínám si myslet, že by bylo dobré, aby součástí JSF specifikace byl způsob exportu souborů potřebných pro JSF komponenty (MyFacesExtensions, FCKServlet, …). A přitom se jedná jen o poskytnutí souboru při požadavku.

How to use Java6 in Ubuntu edgy/dapper

I was looking on internet for simple way how to use Java6 (aka Mustang) in edgy/dapper. I wanted to use it same way I do with Java5. So I looked for Java6 debian package. Finally I found solution:

  1. Visit http://packages.ubuntu.com/feisty/source/sun-java6 and download all three source files (bottom of the page. They ends with .dsc, .tar.gz and .diff.gz).
  2. Put them in same directory (like /tmp/java6).
  3. Run dpkg-source -x *.dsc
  4. Enter the newly created directory (in my case sun-java6-6-00)
  5. Run fakeroot debian/rules binary
  6. Debian packages will be created in upper directory. Install them.
  7. To use Java6 by default run: update-alternatives --config java

I hope that soon we will have Java6 in edgy backports or at least binary packages.

Maven Archetype: JBoss Seam

Pokud si chcete zjednodušit integraci Mavenu 2 a Seam zkuste si přečíst článek Maven Archetype for JBoss Seam. Generuje kostru pro použití Seamu s MyFaces, Facelets a EJB 3.0.

Archetype je název pro generátor kostry aplikace pro Mavenu.

Měl jsem problémy aplikaci rozběhnout. Pomohlo až ruční stažení a umístění do lokální cache.

Aktualizace: Můžete také vyzkoušet Seam Archetype, který jsme vytvořili pro naše potřeby.

Začínáme s Webovými stránkami v Javě

K napsání tohoto záznamu mně inspirovala diskuse, že vývoj jednoduchých webových stránek v Javě je příliš složitý. Chtěl bych tedy ukázat, že i v Javě je to jednoduché

Nechci se pustit do srovnávání jazyků. Chtěl bych jen ukázat, že i Javu lze snadno používat v prostředí, kde tak kraluje PHP – a to je tvorba jednoduchých webových stránek.
Pokračování textu Začínáme s Webovými stránkami v Javě

Rychlejší vývoj webových stránek v Javě

Když se podíváte na způsob vývoje u kompilovaných jazyků, vždy vidíte cyklus úprav, přeložení a spušťění. Naštěstí na rozdíl od C++ jsou překlady v Javě ďábelsky rychlé. Pomalejší už je bohužel deploy do servletového kontejneru (o čase pro EJB už raději nemluvím). Pokud tedy sečtete dohromady čas pro kompilace a redeploy, dostanete čas minimálně několik vteřin, obvykle však i desítky vteřin (u některých aplikačních serverů to může být i 5 minut), což v porovnání s PHP, kde uložíte soubor a obnovíte stránku, snižuje produktivitu a tím zvyšuje náklady projektu. U mně osobně platí, že i krátké přerušení práce mne dokáže dostat z koncentrace, a tím ještě zhoršit celý problém.
Pokračování textu Rychlejší vývoj webových stránek v Javě

Tomcat a leaky

Při práci s Tomcatem jsme narazili na memory leaky. Tato chyba nastává při reloadu aplikace v Tomcatu. Nejčastěji se problém projevuje tak, že se zaplní část paměti heap a PermGen, která je použivaná pro načítané třídy (class).

Když tomcat načítá novou webovou aplikaci, uvolní všechny reference na původní ClassLoader a nechá GC, aby paměť uvolnil. Problém ovšem nastane, pokud na tento ClassLoader stále existuje reference. Pokud třída v rodičovském ClassLoaderu (např. část JDBC přímo v JDK) obsahuje odkaz na třídu v našem původním ClassLoaderu, a tím i přímo na na něj, nastane problém.

Problémy mohou způsobovat např. tyto knihovny:

  • JDBC DriverManager
  • Jasper (JSP compiler)
  • CGLIB – v nové verzi již opraveno

My jsme problém vyřešili tak, že v ostrém provozu Tomcat restartujeme a při vývoji jsme zvýšili paměť pro tomcat – -Xmx a
-XX:MaxPermSize=128m. Tím jsme minimalizovali riziko vzniku problému.

Více informací v článku Memory leak – classloader won’t let go.