Il compilatore visualizza gli avvisi se si utilizzano le classi Java proprietarie di Sun. Sono dell'opinione che sia generalmente una cattiva idea usare queste classi. Ho letto questo da qualche parte. Tuttavia, a parte gli avvertimenti, ci sono dei motivi fondamentali per cui non dovresti usarli?È una cattiva pratica utilizzare le classi Java proprietarie di Sun?
Perché sono le API interne: essi sono soggetti a modifica in un non documentata o supportato strada e sono legati ad una specifica JRE/JDK (Sun nel tuo caso), che limita la portabilità dei tuoi programmi.
Cercare di evitare gli usi di tali API, preferire sempre una classe pubblica documentata e specificata.
Alcune API in 'com.sun. *' Sono sperimentali (l'API APT originale era ad esempio). IIRC, Alex Buckley ha un blog sui vari stati di queste API. Ma sì, in generale possono cambiare o sparire nelle versioni di aggiornamento e tra i fornitori. –
Ho impostato il mio editor java (IntelliJ Idea) per escludere com.sun dai suggerimenti di intellisense.Grazie per il tuo suggerimento. – skiabox
Sì, perché nessuno garantisce che queste classi o API saranno uguali alla prossima versione di Java e scommetto che non è garantito che tali classi siano disponibili nelle versioni Java di altri fornitori.
Quindi si associa il codice alla versione Java speciale e si perde almeno la portabilità.
Le classi Java proprietarie di Sun fanno parte dell'implementazione Java non inclusa nell'API Java, il loro uso è non documentato e non supportato. Poiché sono interni, possono essere modificati in qualsiasi momento per qualsiasi motivo decida dal team che lavora su Sun JVM.
Anche l'implementazione Java di Sun non è l'unica là fuori! Il tuo codice non potrebbe essere trasferito su JVM da altri fornitori come Oracle/BEA e IBM.
provare ad eseguire il codice con un non-Sun JVM e vediamo cosa succede ...
(Il tuo codice avrà esito negativo con un'eccezione ClassNotFound)
Recentemente ho avuto un caso che ha mostrato un mondo reale problema che puoi colpire quando usi queste classi: avevamo codice che non veniva compilato perché un metodo che usava su una classe sun. * semplicemente non esisteva in OpenJDK su Ubuntu. Quindi suppongo che quando si usano queste classi non si possano più dire cose come 'funziona con Java 5', perché funzionerà solo su una determinata implementazione Java.
Posso fortemente consigliare di eseguire gli unittest su una piattaforma e JVM diverse da quelle utilizzate per lo sviluppo. Molte cose interessanti tendono ad apparire. –
Il JDK 6 Documentation include un collegamento dal titolo Note About sun.* Packages. Questo è un documento dai Java 1.2 documentazione, in modo da riferimenti a sun.* dovrebbero essere trattati come se avessero detto com.sun.*
I punti più importanti da esso sono:
Le classi che Sun include il Java 2 SDK, Standard Edition, caduta in gruppi di pacchetti
java.*,javax.*,org.*esun.*. Tutti tranne i pacchetti sono una parte standard della piattaforma Java e saranno supportati in futuro. In generale, pacchetti comesun.*, che sono al di fuori della piattaforma Java, può essere diverso in tutto piattaforme OS (Solaris, Windows, Linux, Macintosh , etc.) e possono cambiare in qualsiasi momento senza preavviso con le versioni SDK (1.2, 1.2.1, 1.2.3, ecc.).I programmi che contengono chiamate dirette ai pacchetti non sono Java puro al 100%.
e
Ogni azienda che implementa la piattaforma Java lo farà nel proprio strada privata. Le classi in
sun.*sono presenti nel SDK per sostenere l'attuazione Sun della piattaforma Java: isun.*classi sono ciò che rende il classi Java Platform lavoro "sotto le coperte " per lo SDK Sun Java 2. Queste classi non saranno in genere presenti sulla piattaforma Java di un altro fornitore. Se il tuo programma Java richiede una classe "sun.package.Foo" per nome, potrebbe non riuscire con ClassNotFoundError, e avrai perso uno dei principali vantaggi dello sviluppo di in Java.
Come commento "diversi anni dopo": non è garantito che 'com.sun. *' Non cambierà in 'com.oracle. *' Dato che Sun non esiste più. – Powerlord
Non è corretto. Molti pacchetti 'com.sun. *' Fanno parte delle specifiche documentate. Sarebbe impossibile scrivere codice JNDI LDAP o COSNaming senza di essi. Il problema sono i pacchetti 'sun. *', Che sono una questione completamente diversa e specificamente documentati come tali. – EJP
btw, cercando di usare le classi 'sun. *' E 'com.sun. *' Fallirà in modo spettacolare su Java 9. – Powerlord
Ecco la risposta di Oracle: Why Developers Should Not Write Programs That Call 'sun' Packages
Mentre questo può teoricamente rispondere alla domanda, [sarebbe preferibile] (http: // meta. stackexchange.com/q/8259) per includere qui le parti essenziali della risposta e fornire il link per riferimento. – BoltClock
Qualsiasi funzionalità che è sufficientemente generale sarà incarnata nella API ufficiale di Java. C'è davvero qualcosa nelle classi Sun che è necessario e non può essere fatto attraverso l'API Java standard? Puoi fare un esempio? –
(A volte mi sono accorto utilizzando xerces interno per l'elaborazione xml) –
Well xerces è l'implementazione XML predefinita durante l'elaborazione di XML utilizzando JAXP. Non è necessario raggiungere e utilizzare direttamente xerces. –