🚀 go-pugleaf

Wyrażasz bardzo radykalne opinie.
Co do ogłupiania slajdami, to cóż - ja mam inne doświadczenia i w
możliwość przekonania kogoś do technologii w taki sposób nie wierzę.
Co do SOA - jeśli tak rozumiesz SOA, to widać nie masz takich
problemów, jakie SOA próbuje zaadresować. Ale wielu innych ludzi ma i
próbuje szukać jak te problemy wyeliminować albo przynajmniej
zminimalizować. Im to jest potrzebne.
Co do Eclipse - widzisz - słyszę różne opinie od klientów. Dla jednych
jest to krok wstecz, bo - jak twierdzą - znacznie trudniej jest im
budować aplikacje. Zdaniem innych - zwłaszcza deweloperów - był to
bardzo dobry krok, bo mogą budować aplikacje w znanym środowisku.
Opinie są różne.
Co do OpenJPA - tu znowu bardzo radykalnie to widzisz - ja mam inne
zdanie. Kodo było (i jest) całkiem dochodowym biznesem. Na pewno nie
było tak popularne jak Hibernate i nic dziwnego - Kodo (podobnie jak
TopLink) zawsze były przede wszystkim skierowane do rynku enterprise.
Rynek enterprise to jest inny świat i kieruje się moim zdaniem zupełne
innymi kryteriami wyboru - to co napisałem we wcześniejszym poście -
cena nie jest jedynym kryterium wyboru. Twoje oczekiwania mogą być
zupełnie inne - OK, ale oczekiwania innych trzeba uszanować. Java nie
jest monokulturowa jak choćby środowisko Microsoft-u i zakłada wielość
implementacji rozwiązania tego samego problemu oraz wolność wyboru - w
czym mają pomóc m.in. standardy (zarówno de jure - np. JCP, jak i de
facto - np. Spring). Ja osobiście się z tego cieszę, że jest wiele
implementacji i ludzie mają możliwość wyboru, choć wybór jest
trudniejszy. OT - inna filozofia.
Co do JBoss - pewnie zdziwisz się, ale mi oni nie przeszkadzają (przez
te ostatnie 5 lat może ze 3 razy się spotkaliśmy). Powiem więcej -
widać branża jest zdrowa - są i Fiaty i Mercedesy - jest kilka low-
end'owych app serwerów, kilka high-endowych i to dobrze. Fiat jest
bardziej popularny od Mercedesda ? Na pewno. I co z tego ? Inne są
potrzeby kupujących Fiaty, inne Mercedesy.
Co do Apache - wielu ludziom (także spoza świata komercyjnego) właśnie
ta merytokratyczność Apache podoba się - i mają problemy, żeby
odnaleźć ją w innych społecznościach, mimo iż ASF nie jest ideałem
(czy cokolwiek jest ?). Ale taki jest ich wybór i trzeba to uszanować.
Co do JTA i clusteringu - zobaczymy, jeśli opisane wcześniej "okno
zmian" przesunie się to kto wie.

Co do dynamicznego typowania w Grooviem - to co mi się podoba, to
możliwość wyboru :-), bo Groovie dopuszcza zarówno statyczne, jak i
dynamiczne typowanie. Dodatkowo, dzięki integracji z Java, zawsze
można skorzystać z tego co Java oferuje (i to jest także wielki atut
JRuby). To co pewnie się zmieniło przez te ostatnie kilka lat, to to,
że już nawet do mainstream'u trafiło przekonanie o absolutnej
krytyczności tworzenia unit testów (i innych form testowania) i
traktowania testowania na równi z kodowaniem. Bez takiego podejścia,
to rzeczywiście można się bardzo pokaleczyć o dynamizmy. Z takim
podejściem, to pewnie za jakiś czas kompilacja bardziej będzie
przypominać unit test - jeden z wielu.
Zgadzam się z Tobą, że wykorzystanie Grooviego, Grailsów (i podobnych)
DZISIAJ to dodatkowe ryzyko dla projektu - podobnie było z Java 10 lat
temu, czy wcześniej z C++ . Pobawić się i poeksperymentować warto -
ostatnio rozmawiałem z jednym znajomym, który powiedział, że - zabawne
- ale dzięki Grailsom lepiej zrozumiał MVC i IoC - cóż wiele dróg
prowadzi do celu.

Co do wymienionych przez Ciebie JSR - absolutna zgoda - choć pewnie
droga będzie wiodła poprzez OSGi, a potem usankcjonowanie w postaci
standardów JCP. Jaskółki zmian i stosowania OSGi już widać - choć
ciągle chce się więcej.

Pozdrawiam,
Waldek Kot
BEA