Dlaczego często w firmach można spotkać soft pisany w javie 6 i przez długi czas nie jest ona aktualizowana do np 8? Czy głównym powodem są serwery aplikacyjne?
0
0
Po co ruszać, jeśli działa?
0
ktos musi zaplacic za prace wymagana przy upgrade
2
Bo kompatybilność wsteczna czasami nie jest prawdą i trzeba wprowadzić zmiany w kodzie. A jeszcze lepiej jak brak kompatybilności zabija jakąś bibliotekę/framework i trzeba użyć nowej wersji która powoduje lawinę zmian w kodzie.
0
Jest kilka powodów:
- "bo nie" - wbrew pozorom dosyć często spotykany. Występuje wtedy, gdy istnieje wystarczająca liczba osób, którzy sprzeciwiają się zmianom JDK z irracjonalnych powodów
- "bo serwery" - serwery bardzo często są pisane pod konkretne JVMy. Upgrade Javy musi pociągnąć z sobą zmianę serwera. A to już nie jest taka sprawa prosta, bo np. serwer był postawiony dawno temu, i nikt do końca nie wie jak jest skonfigurowany.
- "bo biblioteki" - połączone z poprzednim. Zmiana serwera pociąga z sobą zmianę bibliotek dołączonych do serwera. Lub innych. Zmiana bibliotek może skończyć się zmianą kodu.
- "bo dostawcy" - bo wszyscy dostawcy piszą w Java 6, tak mają w kontraktach i trzeba by im płacić za zmianę.
Generalnie:
Im większa korporacja tym większe prawdopodobieństwo pisania w JDK7-
Im mniej technologiczna korporacja (np. finanse), tym większe prawdopodobieństwo pisania w JDK7-
0
JDK 6 nie było złe. Pamiętam jak przesiadaliśmy się z Javy 5 na 6 właśnie w pewnym projekcie, który nie miał prawa nie działać. Generalnie zabawa polegała na przetestowaniu aplikacji pod kątem wszystkich znanych przypadków gdzie mieliśmy bugi. Na całe szczęście mieliśmy taki "superrun" na Jenkinsie gdzie trafiały wszystkie problematyczne przypadki. W momencie przesiadki chodził on prawie 2 doby (apka operowała na plikach płaskich), ale dopiero mając podkładkę w postaci "przeszło wszystkie testy" mogliśmy zmienić JDK na maszynie prod-testowej (przed wykonaniem raportu na prod puszczano na testach by sprawdzić czy na pewno będzie OK).
Podsumowując, problemem jest obawa przed ujawnieniem się pewnych błędów związanych z samym JDK. Do tego dochodzą błędy regresywne w ramach zależności i np. serwera aplikacji.