2011-01-29 7 views
5

Sembra che ogni progetto java a cui mi unisco o che ricomincio abbia sempre il commons-lang come dipendenza - e per una buona ragione. commons-lang ha tonnellate di classi e metodi di utilità che sono abbastanza standard con le API più standard in altre lingue. Perché Sun/Oracle/JCP non ha adottato alcune delle cose in comune con l'API standard?Perché non è commons-lang nell'API standard java?

+5

Sono sicuro che * alcuni * di commons-lang sono arrivati ​​a Java 7. –

+4

Vedo che non usa generici, che dire invece di usare Guava? – maaartinus

+0

in realtà, parte dell'intento del progetto guava doveva essere incluso in jdk 7. non so se sarà la realtà o no. – jtahlborn

risposta

5

Come già sottolineato, alcune funzionalità dell'API commons sono state introdotte in Java, spesso implementate (IMHO) meglio di quanto non fossero originariamente nella libreria Commons. Enums è l'esempio classico.

In termini di perché non adottano più di "comune-lingua", bene con alcune classi c'è l'elemento di confusione. Prendiamo ad esempio StrBuilder, è più potente di Java StringBuilder ed è estensibile. Ma non sono sicuro di voler aggiungere una classe di questo tipo all'API di base Java, StringBuilder/StringBuffer sono perfettamente validi per la maggior parte degli scopi e avere un altro in quello sarebbe davvero un po 'confuso. Non potevano davvero alterare StringBuilder in un modo che potesse accogliere tutte le modifiche sia perché potrebbe rompere il codice esistente. Anche se ne hanno aggiunto uno, e quando qualcuno è arrivato con un'altra versione più potente? StrBuilder2? In poco tempo tutto un gran casino (alcuni sostengono che l'API nucleo è già, figuriamoci con tali aggiunte.)

E come sempre con queste cose, il grande punto è quello dovrebbero essere inclusi da commons-lang. Alcune persone vorranno probabilmente vedere le classi MutableXXX aggiunte, altre le classi XXXUtils, altre il pacchetto temporale ... non esiste un consenso comune.

L'altra cosa importante è che gli sviluppatori Java devono essere molto più attenti a ciò che fa l'API Java principale rispetto agli sviluppatori Apache per commons-lang. Se un progetto di crappy in commons-lang viene sostituito in una versione futura, il vecchio può essere deprecato e successivamente rimosso (in realtà sembra essere ciò che accade.) Nell'API Java di base deve rimanere per ragioni di compatibilità all'indietro, causando solo più confusione.

Per quello che vale anche se penso che più probabilmente la funzionalità di common-lang dovrebbe essere inclusa. Posso solo vedere le ragioni, almeno in parte, perché non lo è.

1

Storicamente Apache Commons ha implementato alcune delle funzionalità che in seguito sono state introdotte in Java 5, come enumerazioni e annotazioni. La loro implementazione era sufficientemente diversa da rendere difficile l'integrazione.

Problemi correlati