Ceci pose problème car le processus de répartition des évènements peut notifier des écouteurs alors que pack() et validate() sont toujours en cours de traitement. Cette situation peut conduire à ce que deux processus essayent d'accèder en même temps au composant, ce qui est une faille sérieuse qui peut provoquer des interblocages et autres problèmes de synchronisation.

Un appel à pack() provoque l'initialisation du composant. Quand ils s'initialisent (sans être forcément visibles), les composants peuvent émettre des évènements vers le processus de répartition des évènements de Swing.

Si toutes les méthodes clone() appellent super.clone(), elles ont alors la garantie d'utiliser Object.clone(), qui retourne toujours un objet du type correct.

Joshua Bloch

Dans le passé, les cas où des personnes ont explicitement invoqué le ramasse-miettes dans des méthodes telles que close() ou finalize() ont creusés des gouffres dans les performances. Le ramasse-miettes peut-être très coûteux. Toute situation qui force des centaines ou des milliers de ramasse-miettes mettra à genoux une machine.

Si vous ne pensez pas que des instances de cette classe soient un jour insérées dans des HashMap/HashTable, l'implémentation recommendée de hashCode est :

public int hashCode() {
  assert false : "hashCode not designed";
  return 42; // any arbitrary constant will do 
  }

Si vous ne pensez pas que des instances de cette classe soient un jour insérés dans desHashMap/Hashtable, l'implémentation recommendée est du type :

public int hashCode() {
  assert false : "hashCode not designed";
  return 42; // any arbitrary constant will do 
}

Si vous ne souhaitez pas définir une méthode hashCode() et/ou ne pensez pas que l'objet puisse un jour être mis dans des HashMap/Hashtable, définissez une méthode hashCode() déclenchant une UnsupportedOperationException.

1. la classe contient un mélange d'accès verrouillés et non verrouillés,
2. au moins un des accès verrouillés est effectué par une des propres méthodes de la classe,
3. le nombre d'accès (lectures et écritures) non synchronisés ne représente pas plus d'un tiers de tous les accès, avec plus de deux fois plus d'écritures que de lectures.

Un bogue typique déclenchant ce détecteur est l'oubli de la synchronisation sur l'une des méthodes d'une classe qui essaye d'être sûre vis-à-vis des threads.

Vous pouvez sélectionner les noeuds nommés "Accès non synchronisés" pour avoir la position exacte dans le code où le détecteur pense qu'un champ est accédé sans synchronisation.

Notez qu'il y a diverses sources d'inexactitude dans ce détecteur ; par exemple, le détecteur ne peut pas repérer statiquement toutes les situations dans lesquelles un verrou est obtenu. En fait, même lorsque le détecteur repère effectivement des accès avec et sans verrou, le code concerné peut quand même être correct.

Cette description se réfère à la version "IS2" du détecteur, qui est plus précise pour détecter les accès avec et sans verrous que l'ancien détecteur "IS".

Ce bogue n'indique pas nécessairement une erreur puisque la modification de l'état de l'objet peut avoir eu lieu dans une méthode qui appelle la méthode contenant la notification.

public class CircularClassInitialization {
    static class InnerClassSingleton extends CircularClassInitialization {
        static InnerClassSingleton singleton = new InnerClassSingleton();
    }
    static CircularClassInitialization foo = InnerClassSingleton.singleton;
}

synchronized() {}

L'utilisation de blocs synchronisés vides est bien plus subtile et dure à réaliser correctement que bien des gens ne le reconnaissent, et de plus ne correspond que rarement à la meilleure des solutions.

1. la classe mélange les accès verrouillés et non verrouillés,
2. au moins des accès verrouillés est effectué par l'une des propres méthodes de la classe,
3. le nombre d'accès non synchronisés à un champ (lectures et écritures) ne dépasse pas un tiers de l'ensemble des accès, les écritures étant deux fois plus présentes que les lectures.

Typiquement, oublier de synchroniser une des méthodes dans une classe essayant d'être sûre vis-à-vis des threads est un bogue signalé par ce détecteur.

NB : il y a diverses sources d'inexactitude dans ce détecteur ; par exemple, le détecteur ne peut pas déterminer statiquement toutes les situations dans lesquelles un verrou est détenu. Ainsi, même lorsque le détecteur repère effectivement des accès verrouillés / non verrouillés, le code en question peut tout de même être correct.

String dateString = getHeaderField(name);
dateString.trim();

Le programmeur semble croire que la méthode trim() mettra à jour l'objet String référencé par dateString. Mais, les objets String étant constants, la fonction renvoi une nouvelle valeur qui est ici ignorée. Le code devrait être corrigé en :

String dateString = getHeaderField(name);
dateString = dateString.trim();

Notez aussi que FindBugs considère le choix par défaut d'un switch comme étant dans le chemin d'exception, puisque ce choix est souvent irréalisable.

Notez également que FindBugs considère le cas par défaut d'un switch comme faisant partie du chemin d'exception puisque ce cas est souvent inattendu.

Notez que la méthode avec l'annotation @NonNull peut être dans une sous-classe de l'objet appelé.

D'un autre côté, utiliser null signifie "il n'y a pas de réponse à cette question". Cela peut donc être approprié. Par exemple, File.listFiles() renvoi une liste vide si un répertoire donné ne contient pas de fichiers, et renvoi null si le fichier n'est pas un répertoire.

if (argv.length == 1);
    System.out.println("Hello, " + argv[0]);

• les deux valeurs sont définitivement à null
• une valeur est définitivement à null et l'autre ne pourra jamais l'être

Cette alarme signale généralement qu'une variable connue pour être différente de null est comparée avec null. Bien que le test ne soit pas nécessaire, ce peut-être un simple cas de programmation défensive.

Lock l = ...;
l.lock();
try {
    // do something
} finally {
    l.unlock();
}

Lock l = ...;
l.lock();
try {
    // do something
} finally {
    l.unlock();
}

public vida foo() {
  int x = 3;
  x = x;
}

De telles affectations sont inutiles et peuvent indiquer une faute de frappe ou une erreur de logique.

int x;
public void foo() {
  x = x;
}

De telles affectations sont inutiles et peuvent indiquer une faute de frappe ou une erreur logique.

En supposant que vous vouliez garantir que le résultat de votre opération ne soit pas négatif, vous devriez modifier votre code. Si le diviseur est une puissance de 2, vous pourriez utiliser un décalage binaire à la place (c'est-à-dire x.hashCode()&(n-1) au lieu de x.hashCode()%n). Cela est probablement plus rapide que de calculer le reste. Si le diviseur n'est pas une puissance de 2, vous devriez prendre la valeur absolue du reste (Math.abs(x.hashCode()%n)).

Typiquement, ce bogue arrive quand du code essaye d'effectuer un test d'apparition d'un bit mais utilise l'opérateur OU ("|") au lieu de l'opérateur ET ("&").

Notez que le compilateur javac de Sun génère fréquemment ce genre d'affectations à perte. FindBugs analysant le byte-code généré, il n'y a pas de façon simple d'éliminer ces fausses alarmes.

Pour savoir si la valeur contenu dans x est la valeur particulière "Not A Number", utilisez Double.isNaN(x) (ou Float.isNaN(x) si x est en simple précision).

int x = 2;
int y = 5;
// Faux: renvoi 0.0
double value1 =  x / y;

// Juste: renvoi 0.4
double value2 =  x / (double) y;

Le bug existe dans de nombreuses implémentations des recherches binaires et des tris fusion. Martin Buchholz l'a recherché et corrigé dans les librairies du JDK et Joshua Bloch a largement publié ce modèle de bug.

• javax.xml.parsers.DocumentBuilderFactory
• javax.xml.parsers.SAXParserFactory
• javax.xml.transform.TransformerFactory
• org.w3c.dom.Document.createXXXX