Perché isJavaLetterOrDigit è deprecato?

Question

Perché il metodo isJavaLetterOrDigit in java.lang.Character è deprecato?

I documenti dicono che il metodo isJavaIdentifierPart dovrebbe invece essere utilizzato, ma non indicare perché. La documentazione per i due metodi è altrimenti identica. Googling l'oggetto non ha rivelato alcuna spiegazione.

Infatti, una ricerca del codice sorgente mostra che al giorno d'oggi si chiama l'altro, quindi non c'è differenza di comportamento. Era solo deprecato perché aveva un nome più confuso? Sembra una decisione piuttosto strana.

@Deprecated 
public static boolean isJavaLetterOrDigit(char ch) { 
    return isJavaIdentifierPart(ch); 
} 

Answer 1

Il vecchio nome (obsoleto) non riflette correttamente l'effettiva esecuzione dell'implementazione; per esempio. accetta caratteri che non sono né lettere né cifre. Immagino che questo avrebbe portato a pochi report "bug" e richieste di supporto da parte di sviluppatori confusi. IMO, questa è la ragione più probabile per cui hanno preso il passo (significativo) di creare un nuovo metodo e deprecare quello vecchio.

(Altri motivi proposti da @HuiZheng sono punti validi a livello intellettuale, ma NON sufficienti a giustificare la deprecazione di un metodo. lavoro per gli sviluppatori e Oracle non vuole alienare le aziende che pagano gli stipendi di questi programmatori. Java ha guadagnato tanta trazione nel mondo Enterprise grazie alla sua reputazione come piattaforma stabile!)

Ad ogni modo, questo metodo sembra deprecato (per me) come una decisione di progettazione dell'API ovvia e ragionevole presa per le giuste motivazioni. Ad ogni modo, le nostre opinioni sono discutibili.

Answer 2

Motivo 1:

Un buon nome API dovrebbe essere abbastanza astratta (ma non troppo astratto). isJavaLetterOrDigit è troppo orientato all'implementazione. Se sei quello che vuoi veramente, usa invece isLetterOrDigit.

Motivo 2:

Un buon nome API dovrebbe esattamente specificare il suo scopo e deve essere implementato correttamente. isJavaLetterOrDigit non è corretto perché consente effettivamente caratteri non di tipo ORDigit come "_" o "$".

Motivo 3:

Un buon nome API deve essere armonica con gli altri. isJavaIdentifierPart è coerente con altre API come isJavaIdentifierStart, isUnicodeIdentifierPart, isIdentifierIgnorable.

Infine, solo perché non c'è differenza di comportamento tra queste due API non significa che siano identiche. I nomi delle API fuorvianti avvelenano il tuo codice. Inoltre, scaricare sempre le API deprecate ASAP, poiché alla fine (o molto probabilmente) verranno scaricate dai provider di librerie.