L'origine contenuta nei seguenti pacchetti non verrà revisionata da alcune delle regole delle migliori procedure J2EE.
1. com.ibm
2. COM.ibm
3. sun
4. sunw
5. java
6. javax
7. org.apache
8. com.sun
9. org.omg
10. org.ietf
11. org.w3c
12. org.xml
Nella vista Revisione codice, il numero di riga non viene sempre visualizzato per alcuni rilevamenti rilevati dalle regole delle migliori procedure J2EE. Facendo doppio clic sul rilevamento, viene visualizzato il numero di riga corretto.
I percorsi dei flussi di dati mostrano la cronologia delle dipendenze delle modifiche ai dati che creano un problema, a sua volta evidenziato da una rilevazione regola. I percorsi dei flussi di dati sono visualizzati nella scheda Percorso. A volte il percorsi dei flussi di dati mostrano strutture di dati interne presenti nelle classi JSDK o J2EE. Ad esempio, piuttosto che indicare che una variabile di tipo java.lang.Vector è stata modificata, verrà indicato che è stata modificata la variabile java.lang.Object[]variable. Questo è un campo interno dell'implementazione java.lang.Vector e la visualizzazione di questa informazione privata nella scheda potrebbe causare confusione.
Nella categoria di regole Principi di progettazione, è possibile impostare la profondità delle regole di complessità. Ad esempio, è possibile impostare la regola "Impedisci nidificazione a più di 1 classe" su "Impedisci nidificazione a più di 3 classi". Affinché la regola funzioni correttamente, è necessario indicare la profondità mediante un numero positivo. Tuttavia, le regole di complessità attualmente non assicurano, che la profondità sia impostata su un numero positivo. Per evitare questo problema, non immettere input non validi, ad esempio zero o un numero negativo.
Quando si crea una regola da un modello che utilizza caratteri non US ASCII nei rispettivi parametri, si verificano problemi di codifica. Questo accade, ad esempio, quando viene selezionato un tipo o un metodo con caratteri locali. Poiché si tratta di un problema di codifica, quando vengono eseguite le regole create con queste proprietà e con caratteri non US ASCII, viene prodotta un'eccezione.
Il processo della revisione del codice non viene riportato correttamente per le regole dell'analisi strutturale (ovvero, la finestra dello stato delle attività indica sempre un progresso del 100%). Sarà necessario attendere il completamento della revisione del codice.
A volte, all'avvio della revisione del codice, il pulsante Avvia/Arresta mostra un'icona che rappresenta una combinazione dei due pulsanti.
La correzione rapida per la regola "Evitare l'uso di java.langString.compareTo () per confrontare le stringhe che rilevano la differenza tra le impostazioni internazionali" propone due soluzioni per correggere il problema indicato dalla regola. La soluzione che suggerisce di <Utilizzare com.ibm.icu.text.Collator> non è corretta. La soluzione dovrebbe essere <Utilizzare java.text.Collator>.
Se si crea una nuova regola con il modello regole J2EE "Richiama sempre [methodA] dopo [methodB]", se [methodB] è un costruttore predefinito nello spazio di lavoro, quando la regola viene eseguita in una revisione codice, non produrrà alcun rilevamento.
Quando si crea una nuova regola per un'istanza di un oggetto specifico dalla regola di modello delle migliori procedure J2EE: "Richiama sempre [methodA] dopo [methodB]", potrebbero essere generati rilevamenti di regola non corretti nel caso specifico successivo per il quale si definisce la regola. Selezionando i metodi dal modello "Richiama sempre [methodA] dopo [methodB]" dove, nel codice J2EE, le istanze dell'oggetto dei metodi hanno un ciclo vitale più lungo del ciclo vitale del server analizzato, è possibile che si incontrino rilevamenti di regole non corretti. Ad esempio, considerare il seguente codice:
public void doGet( HttpServletRequest request, HttpServletResponse response ) throws ServletException, IOException {
// Some code here.... final ServletOutputStream outStream = response.getOutputStream(); //... No call to response.flushBuffer after. }
per il quale è stata creata la regola: "Richiama sempre ServletResponse.flushBuffer() dopo ServletResponse.getOutputStream()". Poiché l'oggetto di risposta è un'istanza con un ciclo vitale più lungo dello stesso servlet, potrebbe verificarsi un problema per l'analisi della revisione del codice. È possibile che vengano visualizzati alcuni rilevamenti in altri servlet che riportano il problema del servlet corrente. Tenere presente che la creazione di regole per queste specifiche istanze di oggetti sono ambigue.
Se si crea una nuova regola utilizzando il modello regole "Evita definizione metodo" e si seleziona un metodo con un nome completo, nella revisione del codice verrà utilizzato solo il nome e i parametri del metodo. La parte attiva del modello di regole si trova nella firma dei metodi, quindi le informazioni sul pacchetto e non classe non hanno significato.
Quando si crea una nuova regola da un modello di regole fornito, non immettere il nome del metodo. Selezionare il metodo utilizzando il browser.
Durante la configurazione dei dati del server, se viene visualizzata una finestra di errore, chiudere la pagina del file .java corrispondete (codice pagina) e tentare nuovamente a configurare i dati.
In Linux, nella pagina Preferenze, potrebbe non essere possibile visualizzare tutte le categorie di regole e i dettagli quando la revisione di codice selezionata contiene un elevato numero di regole. Per risolvere questo problema, nella pagina Preferenze, selezionare la revisione codice rapida, chiudere la pagina Preferenze e riaprirla. Selezionando adesso la revisione codice, verrà visualizzata correttamente.
Visualizza il file Readme principale