Uwagi na temat wersji Java do uruchomienia w środowisku produkcyjnym

Niektórzy ludzie używają najnowocześniejszych technologii - aktualizując dzień, w którym coś jest aktualizowane. W produkcji nie jest to właściwe.

Badanie, czy obecna wersja (Java 7) jest gotowa do produkcji, generuje znaczną ilość starego materiału, który może już nie być poprawny (w chwili pisania tego tekstu Java 7 była dostępna od półtora roku, co wydaje się dość długie) .

Jakie kwestie należy wziąć pod uwagę, aby określić, czy należy zaktualizować środowisko produkcyjne do nowszej wersji Java?

Pierwsze pytanie, które należy zadać, to: „Czy wersja Java jest obsługiwana na tym komputerze?” Chociaż aktualizacja środowiska JRE jest jedną rzeczą, może się zdarzyć, że system operacyjny nie jest obsługiwany w nowej wersji Javy (obsługiwane certyfikaty i umowy pomocy technicznej itp., Które wiele firm chce mieć).

Wiele środowisk produkcyjnych Java działa na serwerze aplikacji . To byłaby kolejna kwestia. Porównanie serwerów Java EE w Wikipedii pokazuje, która wersja Java EE jest obsługiwana. Można to również zobaczyć w przeglądzie zgodności Oracle JavaEE z Oracle . Testowana konfiguracja JBoss Enterprise Application Platform 6 jest zgodna z aktualizacją Java SE 6.0 6u30. Aktualizacja 6u30 Java SE 6.0 to także przetestowana konfiguracja dla JBoss Application Server 7.1.0 Final . Mogą działać w Javie 7, ale nie są testowanymi konfiguracjami.

Rozwijając się na serwerze aplikacji, istnieją narzędzia analizy kodu na żywo , które są używane do debugowania po fakcie. Wszechwiedzący debugger (patrz także) i Dynatrace to dwa przykłady tego. Te aplikacje działają poprzez instrumentowanie (modyfikowanie) kodu bajtu na żywo uruchomionej Javy, aby zgłosić się do niego. Ponieważ te aplikacje działają poprzez modyfikację kodu bajtu, jeśli kod bajtu zmieni się w sposób, z którym nie są w stanie współpracować (na przykład w nowym środowisku JRE), nie będą działać.

Dalej w dół są ramy . Jednym z przykładów jest JAXB, który jest dostarczany z Javą i Spring, który go używa. Zmiana na Java 7 zaktualizowała JAXB, który wygenerował kod, który był niekompatybilny z niektórymi frameworkami (co wymaga ich aktualizacji, a ich zależności musiałyby zostać zaktualizowane ...).

Narzędzia do budowania są następne na liście. Trzeba się upewnić, że środowisko kompilacji korzysta z odpowiedniej wersji Java. Pisanie kodu dla Java 7, ale nie aktualizowanie wersji używanej przez Maven lub Ant spowodowałoby wówczas problemy. Czasami same narzędzia do budowania są silnie powiązane z jedną wersją z konkretnymi wtyczkami.

Narzędzia do testowania . Rzeczy takie jak PMD, findbugs i checkstyle mogą nie rozpoznawać nowych struktur w nowej wersji Java - mogą się bardzo mylić z instrukcjami zamiany łańcuchów lub złożonymi chwytami. Narzędzia wchodzące w skład oprzyrządowania, takie jak pokrycie kodu, mogą nie działać w nowej JVM. W kontekście Java 7 Cobertura i Emma nie zostały zaktualizowane do nowego środowiska JRE (ponownie, te aplikacje modyfikują kod bajtów, aby zobaczyć, który kod jest uruchamiany, a który nie) (zobacz biblioteki pokrycia kodu open source dla jdk7 ). Może to wymagać zmiany skryptów kompilacji w celu przełączania się między nimi.

Następnie jest IDE . Trzeba będzie zaktualizować IDE do wersji, która jest świadoma nowych struktur w języku. Ogłoszenie Eclipse o wsparciu dla Java 7 pokazuje te problemy.

Ostatnim i na pewno nie najmniej ważnym jest programista . Twórcą kodu jest napisanie nowego kodu i świadomość, w jaki sposób można go zrestrukturyzować. W wersji Java 1.4 do 1.5 wprowadzono szablony i adnotacje, a deweloperzy zajęli trochę czasu, aby poznać nowe dostępne struktury. Podobnie kolekcje przerabiają z powrotem w 1.2 i odciągają programistów od używania HashTable i Vector. Aktualizacji wersji powinna towarzyszyć pewna ilość szkoleń w zakresie nowych struktur językowych.