Czy używanie przestarzałych metod lub klas w Javie jest złe?

Używam eclipse do tworzenia aplikacji internetowych. Właśnie dzisiaj zaktualizowałem moją wersję kolumny, zmieniając plik JAR. W niektórych miejscach pojawiają się ostrzeżenia, że ​​metody są przestarzałe, ale kod działa poprawnie.

Chcę wiedzieć kilka rzeczy

1. Czy używanie przestarzałych metod lub klas w Javie jest złe?

2. Co się stanie, jeśli nie zmienię żadnej metody i uruchomię aplikację z ostrzeżeniami, czy spowoduje to jakiekolwiek problemy z wydajnością.

1. Czy używanie przestarzałych metod lub klas w Javie jest złe?

Z definicji przestarzałe :

Element programu z adnotacją @Deprecated to taki, którego programiści nie powinni używać, zwykle dlatego, że jest niebezpieczny lub ponieważ istnieje lepsza alternatywa.

Metoda jest przechowywana w interfejsie API w celu zapewnienia zgodności z poprzednimi wersjami przez nieokreślony czas i może zostać usunięta w przyszłych wersjach. To znaczy nie, to nie jest złe , ale istnieje lepszy sposób na zrobienie tego, który jest bardziej odporny na zmiany w API.

2. Co się stanie, jeśli nie zmienię żadnej metody i uruchomię aplikację z ostrzeżeniami, czy spowoduje to jakiekolwiek problemy z wydajnością.

Najprawdopodobniej nie. Będzie nadal działać tak, jak przed wycofaniem. Umowa metody API nie ulegnie zmianie. Jeśli jakaś wewnętrzna struktura danych zmieni się na korzyść nowej, lepszej metody, może to mieć wpływ na wydajność, ale jest to mało prawdopodobne.

Deprecation najśmieszniejsze w Java API, to IMO FontMetrics.getMaxDecent. Przyczyna wycofania: błąd ortograficzny.

Przestarzałe. Od wersji JDK 1.1.1 zastąpione przez getMaxDescent ().

Nadal możesz używać przestarzałego kodu bez zmiany wydajności, ale głównym celem wycofania metody / klasy jest poinformowanie użytkowników, że teraz jest lepszy sposób na ich użycie i że w przyszłej wersji przestarzały kod prawdopodobnie zostanie usunięty.

Terminologia

Z oficjalnego słownika Sun:

przestarzałe : Odnosi się do klasy, interfejsu, konstruktora, metody lub pola, które nie są już zalecane i mogą przestać istnieć w przyszłej wersji.

Z przewodnika „jak i kiedy wycofać”:

Być może słyszałeś termin „humor samodeprecjonujący” lub humor, który minimalizuje znaczenie mówiącego. Taka jest przestarzała klasa lub metoda. To już nie jest ważne. W rzeczywistości jest to tak nieważne, że nie należy go już używać, ponieważ został on zastąpiony i może przestać istnieć w przyszłości.

@DeprecatedAdnotacja poszedł o krok dalej i ostrzegają o niebezpieczeństwie:

Element programu z adnotacją @Deprecatedto taki, którego programiści nie powinni używać, zwykle dlatego, że jest niebezpieczny lub ponieważ istnieje lepsza alternatywa.

Bibliografia

• java.sun.com Glosariusz
• Przewodnik językowy / Jak i kiedy wycofać interfejsy API
• Wycofany interfejs API typu adnotacji

Prawda czy fałsz?

Kwestię, czy używanie przestarzałych metod jest dobre, czy złe, będzie musiało być rozpatrywane indywidualnie. Oto WSZYSTKIE cudzysłowy, w których słowo „przestarzałe” pojawia się w Effective Java 2nd Edition :

Punkt 7: Unikaj finalizatorów : jedyne metody, które obiecują zagwarantować finalizację, to System.runFinalizersOnExiti jej zły bliźniak Runtime.runFinalizersOnExit. Te metody mają fatalne w skutkach błędy i zostały wycofane.

Punkt 66: Synchronizuj dostęp do udostępnionych danych podlegających zmianom : Biblioteki zapewniają Thread.stopmetodę, ale ta metoda została dawno przestarzała, ponieważ jest z natury niebezpieczna - jej użycie może spowodować uszkodzenie danych.

Punkt 70: Bezpieczeństwo wątków dokumentów : System.runFinalizersOnExitMetoda jest nieprzyjazna dla wątków i została wycofana.

Punkt 73: Unikaj grup wątków : Pozwalają na jednoczesne zastosowanie pewnych Threadprymitywów do kilku wątków. Kilka z tych prymitywów zostało wycofanych, a pozostałe są rzadko używane. [...] grupy wątków są przestarzałe.

Tak więc, przynajmniej w przypadku wszystkich powyższych metod, używanie ich jest ewidentnie niewłaściwe, przynajmniej według Josha Blocha.

W przypadku innych metod należałoby rozważyć te kwestie indywidualnie i zrozumieć, DLACZEGO zostały one wycofane, ale ogólnie rzecz biorąc, gdy decyzja o wycofaniu jest uzasadniona, będzie to raczej skłaniać się ku złemu niż słusznemu dalszemu ich stosowaniu.

Powiązane pytania

• Różnica między wycofanym a starszym interfejsem API?

Oprócz wszystkich doskonałych odpowiedzi powyżej, odkryłem, że jest jeszcze jeden powód, aby usunąć przestarzałe wywołania API.

Badając, dlaczego wywołanie jest przestarzałe, często dowiaduję się ciekawych rzeczy o Javie / API / Framework. Często istnieje dobry powód, dla którego metoda jest przestarzała, a zrozumienie tych powodów prowadzi do głębszego wglądu.

Zatem z perspektywy uczenia się / rozwoju jest to również opłacalny wysiłek

Z pewnością nie powoduje to problemu z wydajnością - przestarzałe oznacza, że ​​w przyszłości prawdopodobnie funkcja nie będzie już częścią biblioteki, więc należy unikać używania jej w nowym kodzie i zmienić stary kod, aby przestać go używać, więc nie napotkasz problemów któregoś dnia, kiedy zaktualizujesz kolumny i stwierdzisz, że ta funkcja już nie jest dostępna

To nie jest złe, po prostu nie jest zalecane. Ogólnie oznacza to, że w tym momencie istnieje lepszy sposób robienia rzeczy i dobrze by było, gdybyś użył nowego ulepszonego sposobu. Niektóre przestarzałe rzeczy są naprawdę niebezpieczne i należy ich całkowicie unikać. Nowy sposób może zapewnić lepszą wydajność niż wycofany, ale nie zawsze tak jest.

Być może słyszałeś termin „samodeprecjonujący humor”. To jest humor, który minimalizuje twoje znaczenie. Taka jest przestarzała klasa lub metoda. To już nie jest ważne. W rzeczywistości jest to tak nieważne, że w ogóle nie powinno się go używać, ponieważ prawdopodobnie przestanie istnieć w przyszłości.

Staraj się tego unikać

1. Generalnie nie, nie jest absolutnie złe używanie deprecatedmetod, o ile masz dobry plan awaryjny, aby uniknąć problemów, jeśli / kiedy te metody znikną z biblioteki, której używasz. Z samym API Java to się nigdy nie zdarza, ale w przypadku prawie wszystkiego innego oznacza to, że zostanie ono usunięte. Jeśli konkretnie planujesz nie aktualizować ( chociaż najprawdopodobniej powinieneś na dłuższą metę ) bibliotek obsługujących oprogramowanie, nie ma problemu z używaniem deprecatedmetod.
2. Nie.

Tak, to źle.

Przestarzałe metody lub klasy zostaną usunięte w przyszłych wersjach języka Java i nie powinny być używane. W każdym przypadku powinna być dostępna alternatywa. Użyć tego.

Istnieje kilka przypadków, w których musisz użyć przestarzałej klasy lub metody, aby osiągnąć cel projektu. W takim przypadku naprawdę nie masz innego wyjścia, jak tylko z niego skorzystać. Przyszłe wersje Javy mogą złamać ten kod, ale jeśli jest to wymagane, musisz z tym żyć. Prawdopodobnie nie jest to pierwszy raz, kiedy musiałeś zrobić coś złego, aby spełnić wymagania projektu, iz pewnością nie ostatni.

Podczas aktualizacji do nowej wersji języka Java lub innej biblioteki czasami używana metoda lub klasa staje się przestarzała. Przestarzałe metody nie są obsługiwane, ale nie powinny dawać nieoczekiwanych wyników. Nie oznacza to jednak, że tak się nie stanie, więc jak najszybciej zmień kod.

Proces wycofywania ma na celu upewnienie się, że autorzy mają wystarczająco dużo czasu na zmianę swojego kodu ze starego interfejsu API na nowy. Wykorzystaj ten czas. Zmień swój kod jak najszybciej.

Nie jest źle, ale niektóre z przestarzałych metod zostaną usunięte w przyszłych wersjach oprogramowania, więc prawdopodobnie kod nie będzie działał.

Czy używanie przestarzałych metod lub klas w Javie jest złe? ”

Nie jest źle, ale może zaoszczędzić trochę kłopotów. Oto przykład, w którym zdecydowanie odradza się używanie przestarzałej metody:

http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html

Dlaczego Thread.stop jest przestarzały?

Ponieważ jest to z natury niebezpieczne. Zatrzymanie wątku powoduje odblokowanie wszystkich zablokowanych monitorów. (Monitory są odblokowywane, gdy wyjątek ThreadDeath jest propagowany w górę stosu). Jeśli którykolwiek z obiektów wcześniej chronionych przez te monitory był w niespójnym stanie, inne wątki mogą teraz wyświetlać te obiekty w niespójnym stanie. Mówi się, że takie obiekty są uszkodzone. Gdy wątki działają na uszkodzonych obiektach, może to spowodować arbitralne zachowanie. To zachowanie może być subtelne i trudne do wykrycia lub może być wyraźne. W przeciwieństwie do innych niezaznaczonych wyjątków ThreadDeath po cichu zabija wątki; w ten sposób użytkownik nie ma żadnego ostrzeżenia, że ​​jego program może być uszkodzony. Zepsucie może ujawnić się w dowolnym momencie po wystąpieniu rzeczywistej szkody, nawet w ciągu godzin lub dni w przyszłości.

Co jeśli nie zmienisz żadnej metody i uruchomisz moją aplikację z ostrzeżeniami, które mam, czy spowoduje to problem z wydajnością.

Nie powinno być problemów z wydajnością. Standardowy interfejs API został zaprojektowany z zachowaniem pewnej kompatybilności wstecznej, dzięki czemu aplikacje mogą być stopniowo dostosowywane do nowszych wersji języka Java.

Czy używanie przestarzałych metod lub klas w Javie jest złe? To nie jest „złe”, nadal działa, ale unikaj tego tak bardzo, jak to możliwe.

Załóżmy, że z metodą wiąże się luka w zabezpieczeniach, a programiści stwierdzą, że jest to wada projektowa. Mogą więc zdecydować o wycofaniu metody i wprowadzeniu nowego sposobu.

Więc jeśli nadal używasz starej metody, masz zagrożenie. Dlatego pamiętaj o przyczynie wycofania i sprawdź, czy wpłynie to na Ciebie.

co się stanie, jeśli nie zmienisz żadnej metody i uruchomisz moją aplikację z ostrzeżeniami, które mam, czy spowoduje to problem z wydajnością.

Jeśli wycofanie jest spowodowane problemem z wydajnością, wystąpią problemy z wydajnością, w przeciwnym razie nie ma powodu, aby mieć taki problem. Jeszcze raz chciałbym zwrócić uwagę, pamiętaj o przyczynie wycofania.

W Javie jest to @Deprecated, w C # jest to [Obsolete].

Myślę, że wolę terminologię C #. To po prostu oznacza, że ​​jest przestarzały. Nadal możesz go używać, jeśli chcesz, ale prawdopodobnie jest lepszy sposób.

To tak, jakby używać systemu Windows 3.1 zamiast Windows 7, jeśli uważasz, że system Windows 3.1 jest przestarzały. Nadal możesz z niego korzystać, ale prawdopodobnie w przyszłej wersji są lepsze funkcje, a przyszłe wersje prawdopodobnie będą obsługiwane - przestarzała nie będzie.

To samo dotyczy @Deprecated Javy - nadal możesz używać tej metody, ale na własne ryzyko - w przyszłości może ona mieć lepsze alternatywy i może nawet nie być obsługiwana.

Jeśli używasz kodu, który jest przestarzały, zwykle jest w porządku, o ile nie musisz aktualizować interfejsu API do nowszego - przestarzały kod może tam nie istnieć. Proponuję, jeśli zobaczysz coś, co używa przestarzałego kodu, aby zaktualizować go do nowszych alternatyw (zwykle jest to wskazane w adnotacji lub w przestarzałym komentarzu Javadoc).

Edycja: I jak zauważył Michael, jeśli powodem wycofania jest błąd w funkcjonalności (lub ponieważ funkcjonalność nie powinna w ogóle istnieć), to oczywiście nie należy używać przestarzałego kodu.

Oczywiście, że nie - ponieważ cała Java jest @Deprecated :-), możesz używać ich tak długo, jak długo Java będzie działać. I tak nie zauważę żadnej różnicy, chyba że jest to coś naprawdę zepsutego. Znaczenie - przeczytaj o tym, a potem zdecyduj.

Jednak w .Net, gdy coś zostanie uznane za [przestarzałe], idź i przeczytaj o tym natychmiast, nawet jeśli nigdy wcześniej tego nie używałeś - masz około 50% szans, że jest bardziej wydajne i / lub łatwiejsze w użyciu niż wymiana :-))

Ogólnie rzecz biorąc, w dzisiejszych czasach bycie konserwatystą technicznym może być całkiem korzystne, ale najpierw musisz wykonać swoje zadanie czytania.

Uważam, że przestarzała metoda oznacza; dostępna jest metoda alternatywna = ive, która jest lepsza pod każdym względem niż dotychczasowa metoda. Lepiej jest użyć dobrej metody niż istniejącej starej metody. W celu zapewnienia zgodności z poprzednimi wersjami stare metody są nieaktualne.