V tom článku se nejedná přímo o fork/join, jestli to chápu správně. Tady právě někomu chybí podpora pro fork/join v parallel extensions a tady se fork/join řeší jedině přes CountDownEvent, což je klon třídy CountDownLatch z Javy, která tam je od verze 5. Ten fork/join framework od verze 7 by měl právě ještě více ulehčit řešení takových úloh.

Co se týká Catching Multiple Exception Types, tak tím není zrovna myšleno to, co máš v tom příkladu. Zachycování podle jednotlových typů je úplný základ v konceptu výjimek a nedokážu si představit, že by tomu bylo jinak. Jinak ten příklad by ani neměl jít zkompilovat. Na řádku throw new InvalidProgramException("Invalid program exception!"); by měl compiler hlásit něco ve smyslu unreachable code. Ale tak to si zbytečně rypu, protože zrovna ten příklad se dá dobře použít. Catching Multiple Exception Types se tady využije k eliminaci opakujícího se kódu: Console.WriteLine(ex.Message); a vypadalo by to takhle:

catch (InvalidProgramException | InvalidOperationException ex)
{
   Console.WriteLine(ex.Message);
}

Absence lambda expressions se řeší použitím anonymních tříd, ale pokud je jich někdy třeba použit na spoustě místech, začíná to být otravné. Kód by byl vždy čitelnější a méně ukecaný s lambda expressions.

Jinak Java vždycky z principu bude náročnější na paměť než přímo kompilované jazyky a proto třeba .NET na tom nebude o nic lépe a co jsem viděl v bývalé firmě, taky není. Pokud nějaké programy zabírají příliš moc paměti, nevím koho jiného by to měla být chyba, než programátorů. I v jazycích s automatickou správou paměti jde udělat hodně, aby programy žraly zbytečně moc paměti. Viz. třeba memory leaky. Jakýkoliv GC je ten poslední, koho lze vinit. Co může, to samozřejmě uvolnit musí. Při vylepšování GC se většinou soustředí na co nejmenší pauzy (stop-the-world) při jeho práci.