якось у нас зайшла бодяга за hashCode.
oracle java та openjdk підтримують ёго стабільність через ліниве обчислення внутрішнёго поля сішного об'єкта.
алгоритм для get_next_hash задається ключем -XX:hashCode=n | n є [0, 5]
два - псевдо-випадкові генератори:

• за замовчуванням n=0 - PM RNG
• n=5 XorShift давно варто зробити за замовчуванням

XorShift і ( Read more... )

знову отримую питання "що відрізняє мідла від џуна та можливо сінора ( Read more... )

у пошуці по java.util.functions.Mapper (?:W|DEM)YRA впав зі 2 до 9 місця.
і вже ж не поправити, тож треба переходити на альтернативи (:
java.util.functions.Block

давайте закодуємо простенькі бізнес вимоги:
- Гей, малий,
скажи малому,
хай малий малому скаже,
хай малий теля прив'яже.

по старому це було б так:
lookup(Small)
  .getSmall()
  .getSmall()
  .bind( ( Read more... )

вкотре пролунало питання чому String використовує множення на 31, коли сумує hash.

інет не поможе:
- більшість пишуть просто про hash,
- хтось констатує що таки 31
- Блох некритично помиляється
- StackOverflow бреше, бо це попсовий ресурс, що вірить інету.

тому викладаю посилання на правду, аби воно піднялося (:
How the String hash function works (1) (2)
( Read more... )

здається мені, що ўся обчислювальна математика може обійтися функторами (без виокремлених даних):

• (arg -> res)
• Const(self) = (Nil -> self) | self Є Const
• Nil = Const(Nil)
• Scalar = Const(Scalar)
• Index Є Scalar