La revisione codice Procedure ottimali J2EE consiste in una sola categoria; essa è anche denominata Procedure ottimali J2EE.
Non sono supportati JSP, strut e EJB.
Alcune regole nella revisione codice richiedono analisi del flusso di dati per individuare alcuni risultati. L'analisi del flusso di dati registra il percorso di un risultato. Di conseguenza, la revisione del codice richiede più tempo quando vengono applicate tali regole.
La seguente tabella elenca tutte le categorie e sottocategorie nella revisione codice Prestazioni ottimali J2EE, insieme alla descrizione delle regole in ciascuna di esse. Nella colonna a sinistra, le categorie sono in grassetto e le sottocategorie in testo normale.
Categoria o sottocategoria | Descrizione |
---|---|
Procedure ottimali J2EE | Contiene regole basate sulle procedure ottimali di sviluppo J2EE e supporta i progetti Web destinati a server WebSphere |
Correttezza | Contiene regole per rilevare chiamate ai metodi non corrette |
Velocità dati | Contiene regole per rilevare chiamate dei metodi che possono determinare le condizioni della velocità dati nelle applicazioni J2EE |
Raccolta dei dati non utilizzati | Contiene regole per rilevare chiamate dei metodi che possono ritardare la raccolta dei dati non utilizzati |
Gestibilità | Contiene regole per rilevare un codice che può essere difficile da gestire nelle applicazioni J2EE |
Prestazione e scalabilità | Contiene regole per rilevare chiamate ai metodi che ostacolano le prestazioni o limitano la scalabilità di un'applicazione J2EE |
Gestione risorse | Contiene regole di procedure ottimali J2EE per utilizzare risorse in applicazioni J2EE |
La revisione codice Procedure ottimali J2EE applica regole che sono di due tipi: regole rapide e regole profonde. Le caratteristiche che distinguono i tipi di regole sono la quantità di tempo richiesta perché vengano applicate e il tipo di informazioni che presentano in un risultato.
Regole J2EE rapide
Le regole J2EE rapide richiedono meno tempo per essere applicate nella revisione codice Procedure ottimali J2EE rispetto alle regole profonde. Le regole rapide presentano le stesse informazioni per un risultato rispetto alle regole nelle altre revisioni codice.
Regole J2EE profonde
Le regole J2EE profonde richiedono l'analisi del flusso di dati, per cui impiegano più tempo per produrre risultati rispetto alle regole rapide. Le regole J2EE profonde non solo producono risultati, ma mostrano anche i percorsi che conducono ai risultati. Tali regole richiedono l'analisi del flusso dei dati, il metodo che registra i percorsi, per cui impiegano più tempo per produrre risultati rispetto alle regole rapide. Le regole profonde forniscono le seguenti informazioni aggiuntive:Esistono 36 regole J2EE profonde. La colonna sinistra della seguente tabella elenca le sottocategorie che le contengono. La colonna destra elenca o descrive quali regole nella sottocategoria sono regole J2EE profonde.
Categoria o sottocategoria | Regola J2EE profonda |
---|---|
Correttezza | Non memorizzare oggetti che non implementano java.io.Serializable in javax.servlet.http.HttpSession |
Velocità dati | Non assegnare al servlet campi di istanze, da javax.servlet.Service.service(), senza utilizzare un blocco condiviso |
Prestazione e scalabilità | Richiamare sempre javax.servlet.http.HttpSession.invalidate() in seguito a javax.servlet.http.HttpServletRequest.getSession() |
Gestione risorse | Tutte le 32 regole in questa sottocategoria sono regole J2EE profonde. |
Questa sezione contiene un esempio di ciascun tipo di regola che viene applicata nella Revisione codice Procedure ottimali J2EE.
Esempio di regola rapida
La seguente regola rappresenta un esempio di regola rapida della sottocategoria Prestazione e scalabilità.
Non richiamare java.lang.Runtime da un servlet
Esempio di regola profonda
Richiamare sempre java.io.FileInputStream.close() in seguito a una nuovaj ava.io.FileInputStream(java.io.File)
Questa sezione documenta i problemi noti con la Revisione codice Procedure ottimali J2EE.
Falso positivo: un flusso di input non è stato chiuso
Riepilogo: la Revisione codice Procedure ottimali J2EE produce un risultato che indica che un flusso di input non è stato chiuso. In realtà, non esiste un altro flusso di input da chiudere.
public static int readFirstByte(String fileName) { int firstByte = -1; FileInputStream fis=null; BufferedInputStream bis = null; try { fis = new FileInputStream(fileName); bis = new BufferedInputStream(fis); firstByte = bis.read(); } catch (FileNotFoundException fnfe) { LogUtility.log(fnfe); } catch (IOException ioe) { LogUtility.log(ioe); } finally { if (bis!=null){ try { bis.close(); } catch (IOException ioe){ LogUtility.log(ioe); } } } return firstByte; }
Soluzione provvisoria: fare clic con il pulsante destro del mouse sul risultato e fare clic su Ignora.
Informazioni insufficienti: il risultato viene riportato rispetto a un file .classpath
Riepilogo: la Revisione codice Procedure ottimali J2EE produce un risultato sul file .classpath anziché su una risorsa del workbench.
Descrizione: la revisione codice rileva un problema con un tipo binario, che non ha una risorsa corrispondente nel workbench perché è contenuto in un JAR esterno.
Riferimenti: RFE RATLC00038795
Soluzione provvisoria:
Filtri risorsa: non hanno effetto per regole profonde
Riepilogo: nella pagina Filtri risorsa vengono specificati i file per cui non si desidera applicare una regola profonda durante una revisione codice. Tuttavia, il filtro non funziona e la regola viene ancora applicata ai file specificati.
Descrizione: le regole J2EE profonde lavorano in maniera differente quando specificano file per cui non si desidera che una regola venga applicata durante una revisione codice. Le regole profonde non riconoscono file specificati nella pagina Filtri risorsa, ma riconoscono file nella pagina Escluso, dove per impostazione predefinita sono elencati file JAR. Tali regole riconoscono due tipi di file da escludere, un servlet completamente qualificato o un file JAR, e ignorano tutti gli altri.