Atunci când sunt metode API marcate „depreciat“ de fapt de gând să plece?

voturi
24

Sunt cod de revizuire o schimbare unul dintre colegii mei tocmai a făcut, și a adăugat el o grămadă de apeluri Date.toMonth(), Date.toYear()precum și alte dezaprobat Datemetode. Toate aceste metode au fost depreciate în JDK 1.1, dar el insistă că este ok să le folosească pentru că nu au plecat încă (folosim JDK 1.5) si eu spun ca s - ar putea să dispară în orice zi acum și el ar trebui să utilizeze Calendarmetode.

A Sun / Oracle a spus de fapt , atunci când aceste lucruri se întâmplă departe, sau nu @deprecateddoar înseamnă că pierde puncte de stil?

Întrebat 24/11/2008 la 14:48
sursa de către utilizator
În alte limbi...                            


10 răspunsuri

voturi
13

Ei nu merg departe. Acestea fiind spuse, acestea sunt de obicei depreciate, deoarece a) sunt periculoase Thread.stop ala (), sau b) există o mai bună sau cel puțin mai acceptat mod de a face acest lucru. De obicei, metoda depreciată javadoc vă va da un indiciu cu privire la modul în care mai bine. In cazul tau, Calendar este recomandat mod de a face acest lucru.

Deși este posibil ca acestea vor fi eliminate la un moment dat în viitor, nu aș paria pe ea. Dacă cineva Forks vreodată Java cu toate acestea, ele vor fi, probabil, primul lucru pentru a merge ...

Publicat 24/11/2008 la 14:49
sursa de către utilizator

voturi
2

Dacă metodele dezaprobat a plecat, acestea ar putea sparge codul existent.

Menținând în același timp un API curat este important, metodele dezaprobat nu primesc în mod nimănui. Sigur, există modalități mai bune de acum de a face lucruri, asa ca noi metode de a înlocui pe cele vechi. Dar nu ar fi nici un câștig realizat (în afară de un API mai curat) de a scăpa de cele vechi.

Gândiți-vă la „depreciat“ în sensul „învechit“, dar nu neapărat „pe blocul de tocare“.

Publicat 24/11/2008 la 14:52
sursa de către utilizator

voturi
4

Ei bine, „nu a plecat încă“ și „nu merge departe“ sunt două lucruri foarte diferite. Asta e tot punctul de dezaprobare. Ei pot merge departe cu orice versiune viitoare. Utilizarea lor este o propunere pe propriul risc. Doar să fie conștienți de faptul că unele versiune viitoare a JDK poate părăsi codul într-o stare inutilizabilă.

Publicat 24/11/2008 la 14:54
sursa de către utilizator

voturi
2

Retrasă caracteristici caracteristici care sunt înlocuite și ar trebui evitată. Cu toate acestea rămân în JDK, ei sunt descurajați, deoarece există metode mai bune disponibile. Metodele sunt lăsate în API pentru a sprijini compatibilitatea cu versiunile anterioare, dar ar trebui să fie evitate, în general, deoarece acestea ar putea fi eliminate în versiunile viitoare ale API-ului.

Este OK punct de vedere tehnic să utilizeze metode învechite, dar, în general, motivul pentru care a fost descurajată în primul rând a fost că un / mai rapid / API-ul mai curat mai bine a fost dezvoltat.

Publicat 24/11/2008 la 14:57
sursa de către utilizator

voturi
1

Soare tind să fie extrem de paranoic atunci când vine vorba de modificări care afectează și înapoi compatibilitate, așa că nu s-ar aștepta să vadă metodele dispar în orice moment în curând.

Dar metodele perimate ar putea să dispară în orice moment , în viitor, și sunt în mod normal depreciate pentru un motiv - fie că sunt nesigure, deoarece acestea au efecte secundare neplăcute, sau pur și simplu pentru că există o modalitate mai bună sau mai elegant de a face lucrurile. Javadoc pentru metoda va fi în mod normal , în detaliu , care dintre acestea este cazul și care este modul acceptabil de realizare aceeași operațiune este în aceste zile. Destul de frecvent metoda depreciată va fi înlocuită cu o punere în aplicare care apelează metoda „corectă“ , oricum, pentru ca tu esti doar adăugarea unui nivel de indirectare oricum.

Vei avea, de asemenea, o mulțime de avertismente de compilare dacă utilizați aceste metode, care ar putea fi un motiv suficient pentru a le evita, în sine, ...

Publicat 24/11/2008 la 14:58
sursa de către utilizator

voturi
24

În ceea ce privește API-urile, ... nu este specificat acestea vor fi eliminate în orice moment în curând.

Incompatibilități în J2SE 5.0 (din 1.4.2) :

Compatibilitate Sursa

[...]
În general, politica este după cum urmează, cu excepția eventuale incompatibilități enumerate mai jos:

API - uri sunt învechite interfețe care sunt acceptate numai pentru compatibilitate. Compilatorul javac generează un mesaj de avertizare ori de câte ori este folosit unul dintre acestea, dacă nu se utilizează opțiunea de linie de comandă -nowarn. Se recomandă ca programele să fie modificate pentru a elimina utilizarea de API - uri depășite, deși nu există planuri de curent pentru a elimina astfel de API - uri - cu excepția JVMDI și JVMPI - în întregime din sistem.

Chiar și în ei Cum și când să Dezaprobați API - uri , nimic nu se spune despre o politică în ceea ce privește de fapt , eliminarea API - urilor deprected ...


Actualizați 10 ani mai târziu, noul JDK9 + consolidată neutilizare clarifică politica de amortizare.
A se vedea , Jens Bannmann nu a răspuns pentru mai multe detalii.
Acest lucru este , de asemenea , detaliată în acest articol de blog de Vojtěch Růžička , în urma criticilor privind JEP 277 .

Convenția pentru JDK este că , odată ce un JDK API este marcat ca fiind forRemoval=trueîntr - o anumită versiune Java, acesta va fi eliminat în următorul mod direct eliberarea majore Java .
Asta înseamnă că - atunci când ceva este marcat ca forRemoval=trueîn Java 9, acesta ar trebui să fie eliminate complet în Java 10.
Păstrați în minte atunci când se utilizează API marcate pentru ștergere.

Rețineți că această convenție se aplică numai pentru a se JDK și biblioteci terțe părți sunt liberi să aleagă orice convenție care le consideră potrivite.

Publicat 24/11/2008 la 14:59
sursa de către utilizator

voturi
1

Am văzut cu siguranță funcții dezaprobate du-te departe - de la versiunile vechi de Java la curent (am început la 1.1, iar unele lucruri nu au de lucru distinct în 1.4).

Alte limbi mâner dezaprobare diferit - Python a fost cunoscut în trecut, de exemplu, pentru a elimina funcționalitatea Retrasă după doar o eliberare sau două.

Publicat 24/11/2008 la 15:02
sursa de către utilizator

voturi
7

O problemă este că veți vedea o mulțime de avertismente cu privire la compilator folosind metode învechite. Dacă utilizați și deprecations pentru a elimina treptat propriul cod, avertizările compilatorul se vor pierde în zgomot și pierde semnificația.

Publicat 24/11/2008 la 15:03
sursa de către utilizator

voturi
3

Am o recomandare mai bună: mai degrabă decât spunându -i să folosească Calendar, ar trebui să treceți fie JodaTime sau JSR-310 versiune pre-lansare lui. Unele metode pe java.util.Datepot fi depășite, dar în opinia mea , ar trebui să fie depreciate întreaga clasă, împreună cu Calendar. Dezvoltatorii de JSR-310 par să fie de acord, deși mă îndoiesc că vor musca vreodată glonț și retrageți - l.

În nici un ordin special, iată ce e în neregulă cu Date:

  • Reprezentarea sa internă este de milisecunde de la începutul epocii; Prin urmare, nu poate reprezenta datele înainte de epoca.

  • Toate metodele sale utile ( de exemplu toString) normaliza prima data in functie de fusul orar local. Atunci când se lucrează cu UTC Datecazuri, acest lucru se poate obține într - adevăr enervant; ești forțat să utilizați Calendarsau vă va face erori foarte proaste.

  • Calendar. Doar pute. S-ar putea câștiga premiul pentru cel mai rău API vreodată.

  • Reprezintă întotdeauna un instant-in-time . Nici o modalitate de a reprezenta anumite zile, sau ani specifice. Nici o modalitate de a reprezenta valori date-fus orar mai puțin.

  • Are aproape nici metode utile. A se vedea, de exemplu, interfață fluent JodaTime pentru a face data de aritmetică.

  • Ar fi trebuit numit Datetime, având în vedere că este una.

Publicat 24/11/2008 la 20:47
sursa de către utilizator

voturi
4

tl; dr

Ca de JDK 10 , toate originale java.util.Dateexistă încă metode, dar acestea și alte API - uri pot fi acum marcate în mod explicit pentru eliminare. Alte API - uri au fost eliminate recent.

Răspuns complet

Înainte de Java 9, nu API depreciată în JDK a fost eliminat vreodată ( a se vedea 20 de ani de Java neutilizare ).

Cu toate acestea, ca parte a unei funcții numite consolidată neutilizare , JDK 9 a introdus @Deprecated(forRemoval=true)steagul și îl adăugați la zeci de API - uri depreciate anterior . java.util.Datemetode nu au fost printre ei, totuși.

De asemenea, pentru prima dată în istoria limbii, a JDK 9 îndepărtat API - urile depreciate anterior (așa cum este documentat în Java SE 9 Specification ). Acestea au fost un obstacol pentru modularizare și au fost depreciate în JDK 8.

JDK 10 marcate API perimate mai înainte pentru îndepărtarea . Încă o dată, java.util.Dateau fost cruțați metode.

JDK 10 , de asemenea , eliminate unele API - uri perimate-pentru-îndepărtarea în SecurityManagerși Runtimeclaselor (așa cum este documentat în Java SE 10 Specification ).

Deci takeaways sunt:

  1. Depreciată-pentru-îndepărtarea API - uri sunt foarte susceptibile de a fi eliminate în curând. Nu luați în serios acest lucru. În timp ce acestea nu pot fi eliminate în eliberarea după forRemovalmarcarea ( de exemplu , Thread.stop()marcate în JDK 9, dar a rămas în JDK 10), se poate întâmpla repede.
  2. Nici API Retrasă este sigur ca chiar și API - uri care au fost mult timp depreciate ar putea fi eliminate destul de repede acum: o versiune JDK stabilește forRemovalpavilion, cel următor elimină API. De exemplu, API - urile care au fost eliminate prin JDK 10 au fost depreciate timp de cel puțin 20 de ani ( de JDK 1.2), atât de mult încât unii oameni pot fi acum surprins.
  3. Cu ajutorul noului Oracle ciclu de 6 luni de presă , comunicate de JDK și, prin extensie, deprecations și îndepărtarea se întâmple mult mai repede acum.
Publicat 21/05/2018 la 08:21
sursa de către utilizator

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more