Nepovedený zimmerit - díl třetí

Po mnoha večerech, kdy jsem si hrál s novým tmelem jsem nakonec vyměkl koupil plechy od eduarda. Nejhorší bylo ten starý tmel dostat dolů. Myslím ale, že výsledek je tak o 100% lepší, než s použitím tmelu.

Testing blocking operation

Sometimes I have a luck and I can write multi-threaded application. I like testing all my classes with JUnit but it has no support for concurrency.

During studding an excellent book Java Concurrency in Practice which explains all new features added in JSE5 regarding to concurrency, I was looking forward to chapter about testing with JUnit.

The author recommends - if you need to test, that your operation blocks the calling thread, it is similar pattern as testing that your operation throws Exception.

void testTakeBlocksWhenEmpty() {
    final BoundedBuffer bb = new BoundedBuffer(10);
    Thread taker = new Thread() {
        public void run() {
            try {
                int unused = bb.take();
                fail();  // if we get here, it's an error
            } catch (InterruptedException success) { }
        }};
    try {
        taker.start();
        Thread.sleep(LOCKUP_DETECT_TIMEOUT);
        taker.interrupt();
        taker.join(LOCKUP_DETECT_TIMEOUT);
        assertFalse(taker.isAlive());
    } catch (Exception unexpected) {
        fail();
    }
}

While I was watching funny video about java puzzles I was surprised, that the example from the book does not work !!!

JUnit framework all exceptions and errors which are thrown from user thread does not interprets as failure! Fortunately, it logs stack trace to the console at least.

Try this simple example - what colour does your test - green or red ?

    public void testFail() throws InterruptedException {
        final Thread t = new Thread(new Runnable() {
            public void run() {
                assertEquals(2, 5);
            }
        });
        t.start();
        t.join();
    }

My is green and I expect, it should be red, because in my world, two does not equal to five.

How to fix it? You need to catch the exception or error in your user thread and forward it to JUnit normal thread. For example in this way.

    private volatile Exception eException = null;
    private volatile Error eError = null;

    public void testEquals() throws InterruptedException {
        final Thread t = new Thread(new Runnable() {
            public void run() {
                try {
                    assertEquals(3, 5);
                } catch (Exception e) {
                    eException = e;
                } catch (Error e) {
                    eError = e;
                }
            }
        });
        t.start();
        t.join();
    }
 
    protected void tearDown() throws Exception {
        if (eException != null) throw eException;
        if (eError !=null) throw eError;
    }

    protected void setUp() throws Exception {
        eException = null;
        eError = null;
    }

return ve finally ?

Na certifikačním serevru javablackbelt jsem narazil na otázku, jak se chová fuknce, pokud má více návratových míst. Docela mě zarazilo, že návratovou hodnotu lze přepsat ve finally bloku.

public class FinallyExample {

    public static void main( String[] args ) {
        System.out.println( test(true) );
        System.out.println( test(false) );
    }

    public static String test(boolean e) {
        try {
            if (e) throw new RuntimeException();
            return "A";
        } catch ( Exception ex ) {
            return "B";
        } finally {
            return "C";
        }
    }
}

Bez ohledu na to, jestli v metodě dojde či ne k vyjímce, hodnota ve finally bloku nakonec vyhrává - program tedy vypíše dvakrát C C.

Inu, ne nadarmo je v idei automaticky zapnutá inspekce, která ihned varuje.

This inspection reports any instances of return statements inside of finally blocks. While occasionally intended, such return statements may mask exceptions thrown, and tremendously complicate debugging.

Konec aplikačních serverů tak jak je známe?

Po shlednutí přednášky Roda Johnsona se nemůžu ubránit dojmu, že koncept Spring application platform totálně převálcuje stávající implementace aplikačních serverů, tak jak je známe dnes.
Na druhou stranu, jak znám stávající konzervativní zákazníky, kteří ještě ani nepřešli na Javu 5, mě optimismums opouští.
Která banka bude první, a postaví svoje aplikace na springu?

Jak jsem se nechal certifikovat – SCBCD

Ve firmě, kde právě pracuji jsem se nechal uvrtat do toho, že povedu školení o EJB3. Materiály jsem převzal po kolegovi, takže jsem s tím neměl moc práce. Horší bylo, že EJB3 jsem znal jen z rychlíku. Přesně podle hesla: “Ten kdo to neumí, ten to učí“. Takže jsem musel začít od začátku.

Pomohla mi knížka EJB3 in Action (mimochodem, knížky od
Manningu jsou vždy výborné). Je teda trochu obsáhlejší, asi 700 stran, takže na studium v tramvaji je to přece jen macek. Líbilo se mi, že se nesnaží obhajovat předchozí verze EJB a nevyhýbá se ani springu . Takže můžu jen doporučit.

Školení proběhlo v pohodě, a aby čas strávený studiem nepřišel vniveč, rozhodl jsem se, že se nechám ocertifikovat.

Jako studijní materiál jsem zvolil samotnou specifikaci. Původně jsem si myslel,že se nebude dát číst, ale opak byl pravdou. Dokonce jsem díky ní odhalil některé chyby v knize (mimochodem, autor odpovídá promptně).

Na java ranči doporučovali ještě poznámky Mikalai Zaikina. Ty se ukázaly jako velice užitečné, neboť popisují i to, co EJB neumí.

Abych nevyšel ze cviku, tak jsem si za těžce zdaněné peníze koupený tester od whizlabu. Ten mě ale velice zklamal. Nevím jak tester vyvíjejí, ale mě padal jak hrušky, a když spadl po 61 zodpovězených otázkách, tak jsem ho v rámci duševní hygieny smazal. U některých otázek byli dokonce špatné odpovědi! Takže rozhodně nebrat.

Naštěstí jsem od firmy dostal licenci na uCerify – super věc, rozhodně doporučuji.

Nakonec jsem zkoušku složil na 88%.

Jak jsem se nechal ocertifikovat - SCJP

Po několika letech kdy jsem dostudoval výšku a ještě víc letech co se živím (bavím) programováním v javě jsem se nechal ukecat na certifikaci (SCJP) - prý tím stoupne moje cena na trhu práce.

Nejdříve jsem si nabubřele myslel, že se nebudu muset nic učit - vždyť všechno už znám ne ;-) ? Kolegové, kteří už ono martýrium absolvovali mě varovali, že si mám zkusit alespoň nějaké cvičné testy, ať vím co čeho jdu - ještě že je mám (ty kolegy).

Testovací příklady jsou zejména o tom, jestli daný kód jde nebo nejde zkompilovat a proč. Přiznám se, že tuto práci za mě dělá počítač sám, takže jsem se moc nechytal. Druhý zádrhel byla znalost API - třeba v které package je DateFormat a tak. Přiznám se, že slovo klíčové import jsem nenapsal od doby co je za mě IDEA píše sama (minimálně 5 let).

Na druhou stanu abych jen nehaněl, dozvěděl jsem se i o některých záludnostech, o kterých jsem nevěděl, neb jsem se s nimi nesetkal - např. anonymní iniciátory.

Suma sumárum. Pokud se na certifikaci SCJP chystáte, určitě doporučuji nastudovat tuto knížku. Dále jsem měl k dispozici příklady testů od whizlabu. Poté test uděláte bez problémů (já jen na 90%).

Na co vše se dá certifikovat - link.

Poté, co jsem se nechal namočit do školení o EJB3 jako speaker, jsem se rozhodl, že si udělám i SCBCD, ale o tom až někdy příště.

commonj TimerManager

Trápil jsem se rozběháním commonj knihovny na BEA WebLogic 9.2. Potřeboval jsem rozběhat periodický timer a byl jsem nucen použít tuto feature (Quartz mi byl zakázán).
Postupoval jsem podle manuálu a světe div se, nefungovalo to.

Prý stačí vložit do web.xml následující konstrukci a je to

<resource-ref>
    <res-ref-name>timer/MyTimer</res-ref-name>
    <res-type>commonj.timer.TimerManager</res-type>
    <res-auth>Container</res-auth>
    <res-sharing-scope>Unshareable</res-sharing-scope>
</resource-ref>

Problém ovšem nastane při deploy !?!
Žádná package commonj.timer totiž není, zato existuje commonj.timers.
Chyba je tedy v jednom písmenku - s.