Jak zvládnout čas (nejen) do 2. kola prezidentských voleb

Už po 1. kole prezidentských voleb musel snad každý aspoň tušit, že období do 2. kola nebude vypadat jako jiné obyčejné 2 týdny. Reklamy, meetingy, debaty jedou na plné obrátky. V této záplavě mne ale zaujaly dva do jisté míry protichůdné postoje: na jednu stranu afektované prožívání situace ("cítíte to svrbění? cítím to taky! sametová revoluce č. 2 se blíží!"), na druhou stranu lhostejný postoj ("je to jedno, kdo tam bude"), který sám může mít široké spektrum důvodů – realistickým vnímáním skutečných pravomocí prezidenta počínaje a "důchody nám stejně nezvedne" konče. Oba postoje jakožto extrémy odmítám. Jak ale mezi nimi najít zlatou střední cestu?

Předně se na rovinu přiznávám k tomu, že jsem příznivec Jiřího Drahoše. Znám se s člověkem, který se osobně zná s Jiřím Drahošem a na jehož chalupě jsme při jedné víkendové návštěvě měli večer u ohně dost prostoru na to, aby nám o něm vyprávěl. Jsem přesvědčen, že je to člověk nejen slušný, ale i schopný a rozhodný a na základě toho si i troufám říct, že nevolím Jiřího Drahoše jen ze vzdoru vůči Miloši Zemanovi.

Nechci tímto článkem zlehčovat práci těch stovek dobrovolníků, kteří roznášejí letáky, vyvracejí dezinformace, spravují weby typu popravde.cz a denně nás vyzývají: agitujte, šiřte letáky, bojujte proti lžím. To je potřebná a nelehká činnost. Komentáře, že volby rozhodnou nerozhodnutí voliči, bych nepodceňoval, i když posoudit jejich reálnou vážnost bych přenechal politickým analytikům a jako amatér se do toho pouštět nebudu. Mně záleží spíš na jiné věci, kterou může řešit i naprostý laik, a ve které osobně cítím rezervy: vztahy.

Nahlíženo zjednodušenou optikou dvou znepřátelených táborů je dobře, když se někomu teoreticky povede přesvědčit voliče Zemana, aby volil Drahoše. Potřebujeme se přeci přehoupnout přes 50%. Z pohledu oné polarizace a z dlouhodobé perspektivy to ale dobře není a tak to nefunguje. Lidské vztahy jsou mnohem rozmanitější fenomén, do kterého představa dvou znepřátelených táborů nezapadá. Příklad z mého okolí: mám vzdálené příbuzné v Ostravě (starší manželé čerstvě v důchodu), v Plzeňském kraji (rodina středního věku), u nás na Písecku (řada lidí, kteří pracují v továrně). V roce 2013 jsem se s nimi bavil o volbách a buď explicitně řekli, nebo mám z jiných indicií důvod věřit, že volili Zemana. Od té doby jsem se s nimi viděl jen párkrát, někdy jen napsal mail, u někoho jsem za 5 let dokonce zcela bez kontaktu. Se všemi vycházím v dobrém, nicméně kdo z čtenářů by na mém místě k nim teď šel "agitovat za Drahoše"? Bylo by to jednoduše trapné. A protipříklad: podobně jako ti lidé je na tom i můj táta. Ale tím, že se navštěvujeme a bavíme se o všem možném, byl prostor pro otevření tohoto tématu mnohem přirozenější.

Je snadné být v bublině lidí se shodným názorem (pěkný článek Tomáše Zdechovského na toto téma). Navštěvovat meetingy svého favorita. Je to potřeba, když člověk potřebuje vzpruhu. Ale samo o sobě to hodnotu nemá. Začal jsem se cíleně vyhýbat čtení různých rozhovorů s Drahošem, sledování záznamů z meetingů s občany. Je to ztráta času – přesvědčen jsem, fakt je o něm dostupných i tak dost a nějakou zpestřující maličkost nepovažuju za důležitou pro oslovení ani sebe ani lidí v okolí (tátu víc osloví, že umím stáhnout králíka já než Drahoš). Mnohem těžší je udržovat vztahy s lidmi jiného názoru. Trvale, ne stylem "přemluv bábu".

Ano, okolí mne uklidňuje: máš rodinu, práci, bydlíš jinde. Je to lidsky pochopitelné, že některé vztahy ochabnou. Ale jindy jsem měl čas a ten jsem proprokrastinoval. Teď je mi to líto. A nejen kvůli volbám, ale i kvůli těm lidem samotným. Oni totiž mají také svá zranění, své frustrace, svou zátěž z rodiny (např. větší sklon hledat vůdce tam, kde v dětství chyběl otec), zátěž z doby komunismu. Prožívají objektivní či subjektivní chudobu, která jak známo je jedním ze spouštěčů radikalizace. Cestu vidím v tom – nepřerušit s těmito lidmi vztahy. Nikoli ve sdílení hanlivých protizemanovských stránek, ať už jsou to hry, countdown, trička, fake účty a co vše jsem ještě neviděl.

Pokud si tedy na Hradě přejete změnu, vybodněte se na konzumaci materiálu, kde se jen poplácává po zádech a který se hezky čte. Najděte si ve svém okruhu přátel někoho, kdo nevypadá na "stejný tábor". Může to být třeba známý, s nímž se často vídáte, ale o politice jste spolu nemluvili, nebo paní, které doučujete dítě nebo někdo z rodiny, s nímž je třeba se nejdřív smířit. Důležité není, zda je rozhodnut či ne, důležitá je kvalita vašeho vztahu. Podstatné je vztah rozhovorem o politice nezhoršit, to je lepší změnit téma. Ať už váš protějšek prožívá volby afektovaně nebo lhostejně, vztah je to, co vám pomůže jít dál.

Co říct na závěr? Článek není vhodný k poslání příznivcům Zemana, že? Když jsem po několika zážitcích z minulého týdne dospěl k názoru, který zde prezentuji, vrátil se mi jistý druh pokoje, že život půjde dál. Pokud souboj Drahoš:Zeman skončí 49:51, budu to brát jako výzvu pro práci na zanedbaných vztazích. A pokud skončí 51:49, pak ho kromě obrovské radosti přijmu i s velkou pokorou, že tu šanci, aby se těch 49% necítilo zadupáno do země, jsme dostali už teď a ne v roce 2023.

Čitelný toString na method reference

Začalo to nenápadnou souhrou několika drobných okolností za poslední dobu: Nedávno jsem se na twitteru trochu otřel o PowerMock. Nikdy jsem si pořádně nesáhl na problematiku classloaderů. Baví mě pohybovat se na hraně oblasti, kdy se má mezi javisty obecně za to, že něco nejde (objev setAccessible(true) v čase začátků s Javou, objev triku, jak přepsat final referenci v době, kdy jsem žral blog Petera Lawreye, a teď je čas se posunout dál). A konečně brzy po přechodu na Javu 8 jsem asi jako většina javistů poznal, že lambdy a method references jsou nový živočišný druh a je potřeba se je naučit zkrotit. Jedna nepříjemná drobnost při debugování byla absence vypovídající toString() reprezentace.

Motivace

Např. máme-li třídu com.Cat a definujeme objekt Function<Cat,String> fn = Cat::getName;, hodnotou fn.toString() bude něco jako com.Cat$$Lambda$534/1037477394@38071cdb.

V našem reálném projektu je sada testů ověřujících určité properties nebo jejich kombinace na určitých POJO classách. Testy se opírají o predikáty resp. kompozici predikátu a funkce. Např. k otestování property Cat.name postačí jednoduchá helper metoda

static Predicate<Cat> catName(String expectedCatName) {
    return cat -> Objects.equals(expectedCatName, cat.getName());
}

Predikáty je možné pak dále skládat pomocí .and(), .or() a .negate().

Poznámka: ano, totéž by jistě šlo vyjádřit přímo pomocí logických operátorů, ať přímo v kódu testovací metody, nebo v lambdě. Mám ale rád kód, který se koncentruje na co nejčistší vyjádření úmyslu bez balastu okolo (za předpokladu, že existuje helper metoda verify(Predicate<?>... conditions), zápis verify(catName("Tiger").and(catAge(2))) u mne suverénně vede) a v tomto smyslu považuju testy i za něco, na čem si to mohu s použitím funkcionálního paradigmatu vyzkoušet.

Jak ale reportovat, pokud takový test zfailuje? Máme k dispozici pořadí podmínky a případně řádek ze stacktracu. Osobně mi taková informace stačí, nicméně feedbacku od kolegy, že příčina není z chybové zprávy intuitivně vidět, se nedivím – ta defaultní toString hodnota, která je ve zprávě použita, opravdu čitelnosti nepřidá.

Definice cíle

Samotnou kompozici predikátu a funkce řeší Guava. Zatímco v Javě jsou od verze 8 tisíce programátorů okouzleny interfacem java.util.function.Predicate a tím, jak elegantně jsou pomocí lambd implementovány defaultní metody .and(), .or() nebo výše zmíněná kompozice, Guava už od Javy 5 nabízí v třídě Predicates metody and, or, not i compose. Poslední zmiňovaná má tvar compose(predicate, function) a vrátí predikát volající predicate.test(function.apply(input)). Od Guavy 21 navíc guavácký interface Predicate extenduje ten defaultní z Javy, což umožňuje jej volně používat všude, kde se očekává ten javovský.

Guavácká metoda compose, stejně jako ostatní metody pro logické operátory, není implementována lambdou, ale obyčejnou třídou, která překrývá toString() čitelnou implementací – řetězec "<p>(<f>)", kde <p> resp. <f> jsou hodnoty toString() vnitřního predikátu resp. funkce. Je tedy fajn, že použití metody compose() výsledný řetězec "nezkazí", ale za to, co vrátí toStringy skládaných konstruktů, samozřejmě neodpovídá.

Jako predikát testující rovnost by v našem případě šla použít method reference navázaná na instanci – expectedCatName::equals. To ale jednak trpí stejnou nečitelností toString() reprezentace, jednak neřeší porovnání s null. Obě nevýhody se dají sfouknout opět použitím Guavy, v tomto případě metodou Predicates.equalTo(...). A stejně jako u ostatních metod z třídy Predicates i zde je predikát implementován plnohodnotnou třídou s vlastním čitelným toStringem "Predicates.equalTo(<a>)", kde <a> je toString() argumentu, což už je zpravidla jednoduchý typ, v němž je metoda toString() opět překryta.

Při implementaci

Predicate<Cat> catName(String expectedCatName) {
    return compose(equalsTo(expectedCatName), Cat::getName);
}

má takový predikát hodnotu toString() rovnu Predicates.equalTo(Tiger)(com.Cat$$Lambda$534/1037477394@38071cdb).

Zbývá něco udělat s funkcí. Ideální (vyžadující minimální zásah líného uživatele kódu) zápis by vypadal:

Predicate<Cat> catName(String expectedCatName) {
    return compose(equalsTo(expectedCatName), enrichWithToString(Cat::getName));
}

Cílem je implementovat metodu enrichWithToString, aby výsledný zápis byl "Predicates.equalTo(Tiger)(Cat::getName)". Dá se to?

Základní idea

Akceptovaná odpověď na SO otázku sice zní "nedá", to bychom ale nesměli znát, jak to chodí na SO! Jiné odpovědi nebo komentáře už ukazují příznivější odpovědi, i když řešení mají omezení. Trik spočívá v tom, že musí vzniknout proxy instance pro třídu Cat, na ní se definuje interceptor, v jehož těle se zaznamená název volané metody, a nakonec se metoda na proxy instanci vyvolá skrze Function.apply.

Proxy instance je fake objekt, který nemá a vlastně nesmí mít nic společného s jakoukoli užitečnou instancí třídy Cat. Je úplně jedno, co method interceptor vrátí (pouze to nesmí způsobit pád na nekompatibilitu s návratovým typem metody – ideální je proto vracet defaultní hodnotu pro daný typ, což pro primitivní i referenční typy řeší např. guavácká třída Defaults). Také je třeba dodat, že Cat je třída, nikoli interface, proto nestačí vestavěná java.lang.reflect.Proxy a musí se použít externí knihovna, typicky CGLIB.

Uvedený fígl používá (také odkazováno ze SO) např. Benji Weber pro fluent zápis SQL příkazu pomocí Javy, kde pomocí method reference specifikuje typově bezpečným způsobem sloupce v SQL příkazu. (BTW pokud vám to jméno připadá povědomé, ano, je to ten člověk, který přišel i s trikem, jak znásilnit lambdy pro zápis map pomocí šipky.) Vyskytl se i na blogu Hibernatu. Co všechno jsou lidi schopni udělat, jen aby nemuseli odkazovat na field přes řetězec...

Získání classy

První potíž je v tom, že jak Benji Weber, tak Hibernate třídu znají. Pro ně je získání názvu property jen dílčím usecasem zasazeným do širšího kontextu, jen jedním článkem v řetězu metod, na jehož začátku klient třídu (class objekt) explicitně sdělí. Náš případ je odlišný – utility metoda, která se od třídy nemůže odpíchnout. Můžeme udělat ústupek a metodu enrichWithToString definovat jako

<I,O> Function<I,O> enrichWithToString(Class<I> baseClass, Function<I,O> function) {...}

Neodbytnou otázku "šlo by to bez třídy baseClass?" ale takové řešení nezažene. Naštěstí si třídu lze zjistit. Method reference jako taková o třídě neví; pokud však příslušnou funkci serializujeme, lze serializovanou podobu obnovit do instance třídy java.lang.invoke.SerializedLambda. Ta už obsahuje signaturu volané metody (pouze typy, ne názvy!) ve tvaru obvyklém pro virtuální stroj, jak ho známe třeba z programu javap, v našem případě (Lcom/Cat;)Ljava/lang/String;. Protože se jedná o Function, spolehneme se na to, že mezi kulatými závorkami je pouze jeden argument (nenechme se zmást tím, že getter je bez argumentů - u instančních metod se this považuje za první argument) a několika řetězcovými úpravami z něj získáme název classy a Class objekt (související otázky na SO zde a zde, pro jednoduchost vynechávám cyklus přes předky lambda třídy).

Metoda enrichWithToString bude tedy dostávat SerializableFunction, což je jen

public interface SerializableFunction<I,O> extends Function<I,O>, Serializable {}

což na předání method reference nemá vliv. Finální podoba získání třídy je pak:

Class<?> resolveInputClass(Function<?,?> original) throws Exception {
    Method writeReplace = original.getClass().getDeclaredMethod("writeReplace");
    writeReplace.setAccessible(true);
    SerializedLambda lambda = (SerializedLambda)writeReplace.invoke(original);
    String className = lambda.getImplMethodSignature().replaceAll(".*\\(L(.*?);\\).*", "$1").replaceAll("/", ".");
    return Class.forName(className);
}

Instancování classy

Nyní když známe classu, stačí vzít CGLIB, vytvořit pomocný mock a odchytnout na něm volání metody:

String resolveMethodName(Class<?> clazz, SerializableFunction<?,?> original) {
    MutableObject<String> methodName = new MutableObject<>();
    Object proxy = Enhancer.create(clazz, (MethodInterceptor) (obj, method, args, methodProxy) -> {
        methodName.setValue(method.getName());
        return Defaults.defaultValue(method.getReturnType());
    });
    original.apply(clazz.cast(proxy));
    return methodName.getValue();
}

Toto je dost dobré, pokud je Cat obyčejná POJO třída (bean), jejíž konstruktor i gettery jsou public. Bohužel stačí malé omezení a řešení je nepoužitelné:

Instancování classy s privátním konstruktorem

V našem případě je třída Cat immutable a vytváří se s použitím builder patternu. Builder sám je vnitřní třída a aby byl jediným prostředkem, jak instancovat třídu, je konstruktor private. Principem CGLIBu je ale založení subclassy a jako u každé jiné třídy její konstruktor musí vidět na konstruktor předka (zajímavé overview zde). Příslušné zásahy by asi bylo možné udělat reflexí přímo; protože ale na projektu stejně máme PowerMock, nebudem si práci komplikovat a použijeme rovnou jeho nástroje. Proxy ve výše uvedené ukázce vytvoříme takto:

Object proxy = PowerMockito.mock(clazz, (Answer<Object>) invocation -> {
    methodName.setValue(invocation.getMethod().getName());
    return Defaults.defaultValue(invocation.getMethod().getReturnType());
});

Instancování classy s finálním getterem

Další špek nastává, když jsou gettery ve třídě Cat zabetonovány jako finální. Invocation handler se v takovém případě neprovolá, a to ani při použití PowerMocku, jak je uvedeno v poslední ukázce. Proč? Uvedené použití mocku sice zařídí "hacknutí" privátního konstruktoru, ale celkově nezapadá do způsobu, jak se od uživatele PowerMocku očekává, že framework bude používat (více info).

Bylo by tedy fajn nejdřív proniknout do toho, jak PowerMock funguje. Nemám v úmyslu tímto článkem soudit počínání programátorů, kteří ho z nějakého důvodu použijí, a zaměřím se pouze na fakta. Pokud se nějaký test potřebuje provrtat do jinak nepřístupné třídy, ať už kvůli viditelnosti, final modifikátoru nebo static modifikátoru, uživatel frameworku musí spustit test pod PowerMockRunnerem a pomocí anotace PrepareForTest zadat seznam tříd, jejichž omezení chce po frameworku překonat. Framework pak v rámci runneru inicializuje izolované prostředí, jehož základním stavebním kamenem je speciální classloader. Pak tímto classloaderem nahraje všechny classy potřebné pro test (tj. nejen testovací classu, ale i classy ze samotného PowerMocku, CGLIB atd.) s výjimkou hackovaných tříd. Ty předtím pomocí Javassistu upraví tak, že odstraní překážející modifikátory (neplatí pro static metody – ty mají vlastní proces, který jsem moc nezkoumal, ale i ten v zásadě stojí na classloaderu). A pak se test (včetně jednotlivých kroků předepsaných JUnit frameworkem) spustí v prostředí speciálního classloaderu.

Aby bylo jasno, řeknu to ještě jinými slovy a explicitně. PowerMock na jednu stranu obsahuje neuvěřitelné reflexní hacky (např. zasahuje i do tříd na pomezí Mockita a CGLIBu – taková reflexe na reflexi). Na druhou stranu je toto kouzlení s reflexí nepochopitelně těsně svázáno s featurami testovacího frameworku jako např. právě runnery, notifikace, before/after apod., což komplikuje až vylučuje použití samotné reflexní magie zvlášť. Pokud tedy chceme činnost PowerMocku napodobit pro náš usecase, máme dvě možnosti: buď přistoupit na jeho hru a poštvat ho na uměle vytvořenou potěmkinádu oanotovaných pomocných testovacích tříd, anebo pochopit, co framework interně dělá a napodobit to. První možnost uvádím jen pro úplnost, asi všichni intuitivně cítíme, jaká by to byla prasárna. Výsledné řešení je tedy druhá varianta, která upřímně není od PowerMocku zcela odstřižena, ale používá z něj pouze třídy a metody s izolovanou odpovědností a už se nepodřizuje mašinérii okolo testovacího frameworku.

Pokud bychom inlinovali veškerý kód, který v PowerMocku při testu běží a ořezali ho jen na věci související s naším usecasem, pak dostaneme:

interface MockLoaderWork {
    String getMethodName(MockClassLoader mockLoader, String className, byte[] functionSerializedInParentClassLoader) throws Exception;
}

class MockLoaderWorkImpl implements MockLoaderWork {
    private String methodName;
    public String getMethodName(MockClassLoader mockLoader, String className, byte[] functionSerializedInParentClassLoader) throws Exception {
        Class<?> classLoadedByMockLoader = Class.forName(className, false, mockLoader);
        Object mock = PowerMockito.mock(classLoadedByMockLoader, (Answer<Object>) invocation -> {
            methodName = invocation.getMethod().getName();
            return Defaults.defaultValue(invocation.getMethod().getReturnType());
        });
        Function<Object,Object> functionDeserializedInMockClassLoader = SerializationUtils.deserialize(functionSerializedInParentClassLoader);
        functionDeserializedInMockClassLoader.apply(mock);
        return methodName;
    }
}

String resolveMethodName(Class<?> clazz, SerializableFunction<?,?> original) throws Exception {
    MockClassLoader mockLoader = new MockClassLoader(new String[] {clazz.getName()}, new String[] {MockLoaderWork.class.getName()}, null);
    mockLoader.setMockTransformerChain(singletonList(new MainMockTransformer()));
    mockLoader.addClassesToModify(clazz.getName());
    Class<MockLoaderWorkImpl> mockClassLoaderWorkClass = (Class<MockLoaderWorkImpl>)Class.forName(MockLoaderWorkImpl.class.getName(), false, mockLoader);
    MockLoaderWork mockClassLoaderWork = mockClassLoaderWorkClass.getConstructor().newInstance();
    ClassLoader originalClassLoader = Thread.currentThread().getContextClassLoader();
    Thread.currentThread().setContextClassLoader(mockLoader);
    try {
        byte[] functionSerializedInParentClassLoader = SerializationUtils.serialize(original);
        return mockClassLoaderWork.getMethodName(mockLoader, clazz.getName(), functionSerializedInParentClassLoader);
    } finally {
        Thread.currentThread().setContextClassLoader(originalClassLoader);
    }
}

MockClassLoader je již zmíněný pomocný classloader PowerMocku. Je v hierarchii classloaderů potomkem hlavního classloaderu, pod nímž se spouští test. Ponechávám ho, protože má interně dobře vyřešenou delegaci na parent classloader.

Poznámka ke classloaderům: Classloadery fungují jako izolovaná prostředí, v jejichž rámci se obvykle pohybujeme, když hovoříme o třídě a její identitě. Mohou tedy existovat dvě třídy stejného názvu, ale pokud jsou každá nahraná jiným classloaderem, mohou se vyskytnout zdánlivě bizarní chyby jako ClassCastException: com.Cat cannot be cast to com.Cat, nefunguje přiřazení mezi odpovídajícími instancemi nebo má každá svoji instanci, přestože ctí GoF design pattern Singleton. To vše až v runtimu, překladač žádnou z uvedených chyb nepozná. Jak tedy může jeden classloader pracovat s třídami známými pouze druhému classloaderu? Odpověď zní: přes interface. Parent naloaduje interface, child classu, která interface implementuje. Parent nepotřebuje znát konkrétní classu, přistupuje na objekt přes interface, které zná.

V případě PowerMocku je touto dvojicí interface PowerMockJUnitRunnerDelegate a třída PowerMockJUnit44RunnerDelegateImpl, pro náš případ stačí implementovat jednodušší MockLoaderWork a MockLoaderWorkImpl reprezentující práci vykonanou v child classloaderu. Druhý parametr konstruktoru MockClassLoader jsou třídy a package, které se nahrávají parent classloaderem (přesněji: které se nahrávají parent classloaderem nad rámec tříd vestavěných v PowerMocku – takže PowerMockJUnitRunnerDelegate tam být nemusí, náš interface však ano).

MainMockTransformer pak provádí transformaci Javassistem. Přiřazení proměnné mockClassLoaderWork zajišťuje viditelnost instance třídy v child classloaderu parent classloaderem. Pro vlastní práci se pak musí aktuální vlákno oblbnout novým classloaderem (to je opět jen kvůli těsnému provázání PowerMocku s testovacím frameworkem, kdy API pro výrobu mocku používá thread-local objekt pro ukládání stavu fluent chainu). Nakonec je nutné, aby funkci Cat::getName viděl i child classloader, což normálně nejde, ale díky serializaci i toto obejdeme a child classloader si tak vytvoří identickou funkci i u sebe. Zbytek už je stejný.

Závěr

Protože zjišťování je poměrně náročné, ještě výsledek zacachujeme proti identitě method reference. Finální řešení je pak třída implementující interface Function, která deleguje na původní SerializableFunction a implementuje toString() takto:

@Override
public String toString() {
    String result = toStringCache.computeIfAbsent(original, orig -> {
        try {
            Class<?> inputClass = resolveInputClass(original);
            String methodName = resolveMethodName(inputClass, original);
            return String.format("%s::%s", inputClass.getSimpleName(), methodName);
        } catch (Exception e) {
            return original.toString();
        }
    });
    return result;
}

Na poměrně banálním a do jisté míry umělém problému (jehož řešení nicméně do projektu commitnu, s odstupem se to už nezdá jako raketová věda) jsem si vyzkoušel řadu nových věcí.

Prvním přínosem bylo hlubší pochopení vlastností method references. Nalezení názvu metody je usecase učebnicového typu; z příkladů a API method interceptoru plyne, že tímto způsobem bychom mohli odchytnout celý objekt Method. V textu článku jsou zalinkovány odkazy na praktické aplikace, jak syntaxi method references využít pro psaní deklarativního a přitom typově bezpečného kódu. Method references rozostřují hranici mezi kódem a daty, na což jsou zvyklí uživatelé ryze funkcionálních jazyků. I když Java reflection API v tomto nedosahuje jejich elegance, přesto je fajn, že v Javě tento konstrukt existuje a je škoda, když se nějaký problém dá řešit jen s pomocí hacků.

Druhým neméně důležitým přínosem bylo proniknutí do vnitřností PowerMocku a činnosti classloaderů. Podařilo se mi pochopit PowerMock do té míry, abych z něj extrahoval podstatné části a obešel ty nepodstatné. Konstrukty použité z PowerMocku by samozřejmě šly dále "inlinovat" a dosáhnout tak úplné nezávislosti na PowerMocku, což bych pravděpodobně udělal, kdyby se jednalo o hlavní (src/main) kód.

Na konec stojí za zmínku pár drobných praktických zkušeností. Ukázalo se, že Guava není mrtvá ani po releasu Javy 8, neboť tam, kde experiment odhalil nepraktičnost lambd, si Guava s problémem poradila svým sice starým, ale lépe fungujícím způsobem. Zajímavostí byly také clashe s debuggerem při debugování uvedených kusů kódu – při zobrazení proxy instance v debuggeru se na ní provolal toString() pro účely debuggeru, což method interceptor ale také zachytil a tudíž zachycený název metody pak nesprávně vyšel "Cat::toString".

Další materiály:
PowerMock FAQ.
Objenesis - jednoduchá knihovna pro instancování nesnadno instancovatelných tříd.
ClassCastException z důvodu neviditelnosti přes classloadery a ještě jednou.
Jak zjistit, že třída je nahraná classloaderem.
ClassLoader tutorial na JavaWorldu.
Skvělý ClassLoader tutorial od ZeroTurnaround.