Jsem zvědav. Javassist se mi nelíbilo. S BCEL zkušenosti mám, takže se mi taky nelíbí. (Hlavně bugy.) V cglib jsem se nedovedl zorientovat. A hlavně Byteman vypadá docela zajímavě, jako takový "sed" - nástroj, kterým se dá nahackovat mnohé během chvilky. Jen se trošku obávám toho použití instrumentation API.
> Poznate 'javac'?
LOL
> Na co to ludia pouzivate?
Například na https://is.muni.cz/th/374423/fi_b/ .
Ano, logovací frameworky a klasický debugger jsou k podobnému účelu, ale poskytnou na činnost programu trochu jiný pohled. Samozřejmě vím, co dělá iadd (Koneckonců, bez aspoň základní specifikace bych s tím nezvládl vůbec nic, protože bych nevěděl ani co chce na operand stacku.), ale chtěl jsem řict, že pomocí AspectJ bych ten nástroj asi opravdu nenapsal.
Treba AOP je na tom do znacne miry zalozeno; klasicky priklad je pridani logovani na vstupnich bodech metod, hodi se to pro testovani (fault injection testing...), opravu chybnych binarnich knihoven atd.
Taky spousta optimalizaci zacne davat smysl az kdyz clovek porozumi bajtkodu (ale to stejne plati pro C/C++ a instrukcni sadu daneho mikroprocesoru).
Pokud bych mel brat % Java vyvojaru, co to znaji a vyuzivaji, tak je to asi relativne male cislo, coz je na druhou stranu dobre :)
Takze mozem zabudnut na cele komplikovanie kniznice a pouzit rovno AspectJ.
V zivote som nic nepozeral na uroven bytekodu. To ze autoboxing je narocny, dokonca niekedy aj vypocet hash-u, na to nepotrebujem pozerat na bytekod.
Vacsina optimalizacii sa aj tak skryva v algoritme obvykle pamat vs. rychlost.
Urcite, pokud AspectJ vyhovuje pro dany ukol, proc ho nepouzit...
Ono tech zposobu optimalizace je cela rada a spousta jich souvisi s low-level vecmi. Fakt zalezi na zadani, jestli zakaznikovi je jedno co pouzije za masinu (ale i tady se optimalizacim neda vyhnout, spis zacinam mit despekt k lidem, co resi problem tak, ze na nej hodi silnejsi HW ;-), nebo jsou akceptacni testy nastaveny i s ohledem na vykon, dobu behu/cas odpovedi atd.
Hodit na to silnejsie zelezo je obvykle lacnejsi a istejsi sposob optimalizacie so zarucenym vysledkom nez najimat programatorov castokrat za nasobne vyssiu cenu ako je HW s neistym vysledkom. Tiez to nemam rad ale chapem klientov.
Vacsinou ja sa stretavam so zle vytvorenou architekturou, zlym vyberom frameworkov, zlym vyberov produktov. SQL vs noSQL, IO operacie, messaging, transakcie, ... tam si s bajtkodom nepomozete.
Zly vyber Collection, nepouzivanie late inicializacie, synchronizacia to robim spamati bez bytekodu.
jj chapu, no klienti jsou dost ruzni i ruzne projekty (navic hazeni silnejsiho HW na problem pokulhava v oblasti smartphonum at nechodime moc daleko).
Taky jde o to, jaky je obchodni model: prima zakazka vs napriklad nabidka produktu s nejrychlejsim messagingem, HTC, HPC atd. atd. V kazdem pripade na ten bajtkod vetsinou drive ci pozdeji dochazi :-) Ono se staci podivat na zoubek treba gridu nebo i nejake te noSQL databazi v Jave - tam je pekne videt, jak to borci optimalizovali se znalosti interni prace JVM.
Vsak ano, na kazde vrstve se resi trosku jine optimalizace. My si hrajeme s C1/C2 JITy aby to borci s noSQL, Hadoop atd. meli jednodussi, vy pouzijete napriklad hotovy Hadoop a nemusite znovuvynalezat mapreduce, nekdo dalsi Vasi aplikaci bude jednuse volat pres WS apod.
Nicmene i v Jave se narazi na problemy s vykonnosti odladenych algoritmu, ktere mnohdy jdou velmi jednoduse vyresit se znalosti bajtkodu (tableswitch vs. lookupswitch, zmineny autoboxing, neoptimalni pristup k polim, vubec uvedomeni si, jak vypada i ten nejjednodussi objekt na halde atd.)
Podobně by asi pomohlo zkusit si programovat ve starší verzi Javy. J2ME mi (i bez znalosti bytecode) pomohlo pochopit, jak jsou implementována generika. Trošku nečekaně mi pomohlo i PHP, kde jsem se pokoušel udělat inner class (plus přístup k privátním členům) a došel jsem k velmi podobnému řešení. Ale spíš než PHP bych asi doporučil Javu 1.0, ta prý taky nemá inner classes.
Ono to vůbec vypadá, že bytecode byl navržen tak, aby odpovídal první verzi Javy, a od té doby se už moc neměnil. Jen nějaké drobné změny (invokenonvirtual->invokespecial když byl problém, změna v lcd/ldcw, změny v memory modelu, StackMapTable pro rychlejší verifikaci v JVM) a pak snad až invokedynamic - snad první výraznější novinka, která vyloženě přidává něco nového.
Měnit parametry JVM mě nikdy nenapadlo. Snad proto, že dělám malé aplikace a nejni to třeba. A proto se možná naivně ptám, je možno, aby každá Java aplikace při svém spuštění zadala JVM své parametry? Předpokládám, že ano, ale jak?
Tento článek mě zaujal nejvíc. Optimalizace aplikací mě zajímá. Děkuji a těším se na další!
Neco zmenit za behu skutecne jde, ale zakladni nastaveni (client/server) ne, protoze treba ten client/server je ve skutecnosti vyber jine dynamicky linkovane knihovny (.so, .dll).
Ale to vetsinou neni takovy problem - serverove aplikace maji nejaky spousteci skript (ono se vetsinou stejne JVM predava spousta dalsich parametru typu -Dfoo=bar, definice agentu...), desktopove bud taky nebo byva zvykem na Windows to cele spoustet pres nejake stub exe (Eclipse a dalsi).