Bies, no i po co tak się od razu denerwować? :)
Volatile nie było i nie jest nagminnie używanym feature'm języka. Rozmawiamy o twórcach aplikacji w końcu czy o twórcach frameworków, specjalizowanych bibliotek albo wręcz "bogach" kodujacych trzewia JVM? Ci ostatni to nawet nie w Javie piszą, zresztą. Wydawało mi się, że rozmawiamy o "programistach aplikacji", których jedynym celem powinno być skupienie się na spełnieniu wymagań projektowych przy zastosowaniu wszelkich możliwych środków jakie mogą to zadanie ułatwić. Pozwoliłem sobie wcześniej powołać się na taką właśnie "większość".
Jeśli volatile przed 1.5 zachowywało się odrobinę inaczej niż teraz i dodamy do tego, że było może słabo udokumentowane, a do tego jest to ciężki kawałek chleba w ogólności - to trudno. Tak jest i koniec. Ale ten jeden przykład nie pokazuje nijak, że cały język jest trudny. Bo nie jest. 99% zastosowań (że tak sobie z własnego doświadczenia oszacuję) wymaga od programisty znajomości bardzo prostych rzeczy. Piszę w Javie zawodowo bez mała już 6 lat i do tej pory miałem może jeden raz (no, niech dwa, już trudno) konieczność użycia volatile. Przyczyna? Grupy projektowe siedzą i myślą i zadają zęby tylko po to, by reszta mogła pisać komponentowe aplikacje uruchamiane w gotowych, wyspecjalizowanych serwerach aplikacji, które mają wyznaczony standardem obowiązek zapewniania bezpieczeństwa wątków, jeśli takie są wymagania. I nie dotyczy to tylko volatile. Z pozostałymi rzeczami - a zaczęło się od refleksji - jest podobnie.
W Javie schody zaczynają się zazwyczaj nie na poziomie języka, a na poziomie architektur. To jest największa bolączka javowego świata. Ale i na to są sposoby.
Jeszcze kwestia legacy code / legacy systems...
Jak masz legacy system chodzący na jakimś archaicznym/egzotycznym sprzęcie/sofcie i musisz go rozwijać o nowe feature'y, to lepiej pakuj walizki i wiej gdzie pieprz rośnie. Jedyne uzasadnienie biznesowe dla utrzymania takich systemów to ich (najczęściej wątpliwej już jakości) funkcjonalność, której "obecnie nie ma czym zastąpić". Bzdura - zawsze są lepsze alternatywy. Lub też "nie da się, bo wymiana jest za droga". Następny bullshit - utrzymanie starego gówna i tak w końcu okazuje się droższe, zaś decyzja o wymianie zapada, gdy najwyższy management zorientuje się łaskawie, jak bardzo jest w d..pie i że trzeba było tą decyzję podjąć trzy lata temu. Jeśli właściciel systemu nie ma poczucia beznadziejności sytuacji i ciągle wymaga łatania i dokładania nowych feature'ów, optymalizacji i Bóg wie czego jeszcze, wtedy patrz: uwaga o walizkach.
W moim skromnym doświadczeniu zawodowym jeszcze nie spotkałem nikogo, komu na zdrowie wyszło by w perspektywie tuningowanie GC pod jakieś dziwactwa czy łatanie jakichś choćby dziur w bezpieczeństwie tylko dlatego, że management nie chce wyłożyć kasy na przebudowę. Nie po to mamy ciągle rozwijające się standardy, żeby tkwić w średniowieczu. Albo używać produktów niszowych. Zobacz, co robi Google w kwestii serwerów - nawet serwerów nie używa, tylko ogólno dostępne, zwykłe klocki. I współczesny soft.
A jeśli nawet - są jeszcze ludzie, którzy te stare systemy pisali. Niech oni się martwią, jak to dzisiaj łatać. A jeśli sam chcesz się o to martwić - po to masz dokumentację i soft właściwy dla danego przypadku. Jeśli nie masz -> walizki.
Mówię tu oczywiście o Javie EE. Jeśli ktoś chce w SE pisać jakiś zaawansowany system, to pozostaje mu tylko współczuć. Zdecydowanie nie do tego to służy. A próba maintenace'u czegoś o wieloletniej historii to już zwyczajne proszenie się o seppuku. Przez umpa - pumpa, żeby nie było za łatwo.
