Java a statické metody

[JSH]

Ne, překladač JIT žádnou implementaci nevybere.

Fakt ne?

Unlike some of the numeric methods of class StrictMath, all implementations of the equivalent functions of class Math are not defined to return the bit-for-bit same results. This relaxation permits better-performing implementations where strict reproducibility is not required.

By default many of the Math methods simply call the equivalent method in StrictMath for their implementation. Code generators are encouraged to use platform-specific native libraries or microprocessor instructions, where available, to provide higher-performance implementations of Math methods. Such higher-performance implementations still must conform to the specification for Math.

[Reklama]

[Filip Jirsák]

Fakt ne?

Fakt ne. Zkuste si napsat svou vlastní implementaci Math.sin() a bez hackování bootclasspath docílit toho, aby ji vaši aplikace použila, když zavoláte java.lang.Math.sin().

[Ondra Satai Nekola]

Coz plati pro cokoli z java.util, java.lanf, javax atd, atp.

[Filip Jirsák]

Coz plati pro cokoli z java.util, java.lanf, javax atd, atp.

Platí to úplně pro cokoli. Pokud budete mít na classpath dvě třídy stejného jména, aplikace to sice přežije^*), ale použije je jen jedna třída a z aplikace nedokážete ovlivnit, která.

*) Pokud je to klasická aplikace s jedním classloaderem. Pokud tam bude složitější hierarchie classloaderů, třeba to bude nějaký aplikační server, nemusí to skončit dobře. I když to není problém tříd a classloaderů, ale obvykle používání globálních proměnných, které se používají právě v souvislosti se statickými metodami a pravými singletony.

[JSH]

Fakt ne?

Fakt ne. Zkuste si napsat svou vlastní implementaci Math.sin() a bez hackování bootclasspath docílit toho, aby ji vaši aplikace použila, když zavoláte java.lang.Math.sin().

Proč bych měl vůbec chtít psát vlastní implementaci? Bavíme se o sinu. Pro ten mají jedinou instrukci už stařičké pentia.

Takže můžu použít jednoduchou funkci, kterou mi překladač může triviální peephole optimalizací a inlinováním nahradit jedinou instrukcí.

Nebo můžu použít virtuální volání, které stojí řádově to samé co ten sinus. Navíc překladači zabráním jakkoliv to volání optimalizovat páč netuší co za objekt tam pak dostane, jaké to má vedlejší efekty a podobně.

[Reklama]

[Filip Jirsák]

Proč bych měl vůbec chtít psát vlastní implementaci?

Třeba proto, že budete mít procesor, který na to má jedinou instrukci.

Bavíme se o sinu. Pro ten mají jedinou instrukci už stařičké pentia.

Existují i jiné procesory.

Takže můžu použít jednoduchou funkci, kterou mi překladač může triviální peephole optimalizací a inlinováním nahradit jedinou instrukcí.

Bavíme se o Javě. Bytecode nemá instrukci pro sin.

Navíc překladači zabráním jakkoliv to volání optimalizovat páč netuší co za objekt tam pak dostane, jaké to má vedlejší efekty a podobně.

V případě Javy nedělá překladač skoro žádné optimalizace, drtivou většinu jich dělá JIT. A tohle JIT v optimalizaci nijak nebrání, naopak volání virtuálních metod s pouze jednou implementací umí JIT optimalizovat docela dobře.

[JSH]

...

Já už fakt nevím, jak to popsat jinak.

Současný stav : sinus je statická metoda (tzn. jednoduchá funkce). Code generátor ji už teď umí nahradit jedinou instrukcí, pokud ji instrukční sada procesoru má. Nemusím pro to dělat vůbec nic, protože to za mně všechno udělá překladač+runtime.

Proč bych si jako programátor měl komplikovat život nějakou továrnou na abstraktní sinovadla. Co mi to přinese v porovnání se současným stavem? Pokud se objeví nový procesor s novými instrukcemi, tak se pro něj stejně použije nový codegenerátor, který je bude umět. I tam kde se vybírá algoritmus v runtime na základě procesoru se to dělá na podstatně vyší úrovni, protože takhle nízko se to prostě nevyplatí.

[Filip Jirsák]

Bavíme se tu best practice. Best practice je udělat to tak, aby se implementace dala vyměňovat, a dělat to v celé knihovně/aplikaci jednotně. To, že zrovna sin() umí na některých platformách JIT optimalizovat, je podružná věc, protože obvykle zrovna tohle nebude kritické místo vašeho programu. Pokud zjistíte, že zrovna ve vašem programu je počítání sinu úzké hrdlo, teprve pak je správný čas na optimalizaci a teprve to je důvod jít proti best practice.

Proč bych si jako programátor měl komplikovat život nějakou továrnou na abstraktní sinovadla.

Protože to není komplikace, ale výrazné zjednodušení. Továrnu samozřejmě nebudete vymýšlet, protože na to máte framework, který vám dělá továrnu pro další desítky objektů – takže není důvod pro jeden jediný objekt to dělat jinak.

[Radek Miček]

Best practice je udělat to tak, aby se implementace dala vyměňovat

Proč myslíte?

[Ondra Satai Nekola]

http://i.imgur.com/j5b5JCr.jpg

[Filip Jirsák]

Best practice je udělat to tak, aby se implementace dala vyměňovat

Proč myslíte?

V Javě (až do verze 9) například proto, že jinak vzniká propletenec závislostí, který se za chvíli těžko udržuje a spravuje. Když váš kód závisí na rozhraní, nemusí vás zajímat, že implementace bude záviset ještě ne něčem dalším. Pokud závisí na implementaci, ta nejspíš bude záviset na něčem dalším, a tím na tom tranzitivně začne záviset i váš kód.  A také pak kód nejde rozumně testovat.

[Radek Miček]

Best practice je udělat to tak, aby se implementace dala vyměňovat

Proč myslíte?

V Javě (až do verze 9) například proto, že jinak vzniká propletenec závislostí, který se za chvíli těžko udržuje a spravuje. Když váš kód závisí na rozhraní, nemusí vás zajímat, že implementace bude záviset ještě ne něčem dalším. Pokud závisí na implementaci, ta nejspíš bude záviset na něčem dalším, a tím na tom tranzitivně začne záviset i váš kód.  A také pak kód nejde rozumně testovat.

Ano, to může nastat, nicméně jsou i situace, kde to nastat nemusí a kde je velmi nepravděpodobné, že bude třeba implementaci nahradit. V takových situacích je IMO lepší myslet na jednoduchost a přehlednost kódu - tj. klidně zvolit jednu pevnou implementaci.

[Jann]

Tyhle diskuse jsou krásnou ukázkou toho, jak OOP (a la Java apod.) vede k výrobě problémů z něčeho, kde vůbec žádné ve skutečnosti nejsou.

[Radek Miček]

Tyhle diskuse jsou krásnou ukázkou toho, jak OOP (a la Java apod.) vede k výrobě problémů z něčeho, kde vůbec žádné ve skutečnosti nejsou.

Jaké problémy máte na mysli?

[Ondra Satai Nekola]

Mně to spíś přijde jako braní javy jako záminky pro to si to pěkně overengineerovat. Na duhou stranu by takovéhle nenapadalo programátory, kde jsou first class nebo alespoň top level funkce.

Neřekl bych při tvorbě nějakého echtobecného veřejného API, ale dokud člověk může případně zobecnění dodat za pochodu (což většinou může).