Jezisi kriste .. pred casem jsem narazil na oznam o UJO frameworku na theserverside.com a aspon podle precteni autor ponekud nepochopil pointu a naprogramoval reflektivni datovou knihovnu. Tedy misto toho, aby primarne pouzival v Jave silne typovani a reflexi jenom pro obecne operace pres vsechny (nezname) datove typy, pouziva primarne reflektivni pristup i pro specificka volani datoveho modelu se vsemi nectnostmi (bez kontrol, pomaly).
Posleze autor oznamoval kazdou dalsi mikroverzi tohoto veledila k mohutnemu pobaveni a pozdejsimu nastvani ctenarstva TSS
Viz puvodni diskusi zde: http://www.theserverside.com/news/thread.tss?thread_id=50604#268193
… pouziva primarne reflektivni pristup i pro specificka volani datoveho modelu
opak je pravdou, na rozdíl od konkurenčních ORM frameworků UJO-ORM se při vlastním zpracování SQL dotazu Java reflexe nepoužívá
… se vsemi nectnostmi (pomaly)
obejití reflexe je právě jeden z důvodů, proč je UJO-ORM rychlejší než jeho konkurence ;)
… nectnostmi (bez kontrol)
typové kontroly fungují nejen při zápisu/čten dat do objektu ale i při vkládání parametrů k dotazu
But Hibernate uses so much runtime reflection?
Many former C or C++ programmers prefer generated-code solutions to runtime reflection. This is usually justified by reference to the performance red-herring. However, modern JVMs implement reflection extremely efficiently and the overhead is minimal compared to the cost of disk access or IPC. Developers from other traditions (eg. Smalltalk) have always relied upon reflection to do things that C/C++ needs code-generation for.
In the very latest versions of Hibernate, „reflection“ is optimised via the CGLIB runtime bytecode generation library. This means that „reflected“ property get / set calls no longer carry the overhead of the Java reflection API and are actually just normal method calls. This results in a (very) small performance gain.