Quel est le nombre maximum de paramètres pour une méthode ?

• 127
• 255
• 256
• Il n'y a pas de limites
• Cela dépends du compilateur

Réponse : (cliquez pour afficher)

255

Explication :

Je n'ai malheureusement trouvé aucune référence à cette limite dans la JLS, mais cette limite a été révélée par un test avec le compilateur du JDK de Sun :

java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode)

J'ai également testé avec gcj (Ubuntu 4.3.2-1ubuntu2) 4.3.2. La sortie est un petit peu plus explicite :

Main.java:518: error: Too many parameters, parameter param255 is exceeding the limit of 255 words eligible for method parameters
	String param255
	       ^^^^^^^^
1 problem (1 error)

Question assez récurente lorsque des utilisateurs venant d'environnement .NET découvrent NetBeans :

Est-ce qu'il est possible de réduire un bloc de code dans une classe, comme le fait Visual Studio avec ses régions ?

La réponse est oui. cette fonctionnalité de NetBeans est basée sur une balise XML placée dans des commentaires, la balise <editor-fold>.

Petit exemple : public class Main { // <editor-fold> public static void main(String... args) { System.out.println("This is my program!"); } // </editor-fold> }
Il est maintenant possible de replier ce bout de code sur lui même, et il sera remplacé par le texte ....

Il est possible de configurer le texte qui sera affiché lorsque le bloc de code sera replié (au lieu de ...). Pour cela, il suffit de spécifier l'attribut desc dans la balise <editor-fold> : public class Main { // <editor-fold desc="This is my main method"> public static void main(String... args) { System.out.println("This is my program!"); } // </editor-fold> }

Est-ce que le code suivant compile ? public class MyException<T> extends Exception { } Réponse : (cliquez pour afficher)

Non.

Explication :

La spécification du langage précise explicitement : "It is a compile-time error if a generic class is a direct or indirect subclass of Throwable." (Traduction : "C'est une erreur de compilation si une classe générique hérite directement ou indirectement de Throwable").

En effet, le mécanisme de catch des exceptions en Java ne fonctionne qu'avec des classes non génériques. C'est pour cela que les classes héritant de Throwable ne peuvent pas être typées avec des generics.

Sources :

• Java Language Specification, §8.1.2

Ceci est le premier post d'une longue (j'espère) série de questions : l'Aperiquiz.

Le principe est simple : mettre en évidence un point précis de la spécification Java en se basant sur un exemple de code inhabituel, une question tordue ou une particularité peu connue du langage.

Prêts ? C'est parti !

Considérant le code suivant :

public class Main {

    public static String myMethod() {
        try {
            return "try";
        } catch (Exception e) {
            return "catch";
        } finally {
            return "finally";
        }
    }

    public static void main(String[] args) {
        System.out.println(myMethod());
    }

}

Quel est le résultat ?

• try
• catch
• finally

Réponse : (cliquez pour afficher)

finally

Sources :

• Stack Overflow : Questions to indicate competency in Java (merci à Martin pour le lien)

Avec une installation par défaut de GlassFish, l'utilisation de JMS au sein du serveur d'application amène souvent à l'erreur suivante :
DirectConsumer:Caught Exception delivering messagecom.sun.messaging.jmq.io.Packet cannot be cast to com.sun.messaging.jms.ra.DirectPacket

Cette erreur n'est pas fatale, l'application est tout de même déployée et les différents messages sont envoyés et reçus. Cependant, cette erreur est générée à chaque envoi de message, ce qui peut rapidement devenir encombrant dans les fichiers de log de GlassFish.

Cette exception viens du mode de configuration utilisé pour le lancement du service JMS dans GlassFish. Par défaut, le service est lancé en mode EMBEDDED. Le service JMS tourne dans le même processus que le serveur GlassFish, ce qui provoque ce genre d'erreurs.

Il est possible de changer ce mode de lancement du service JMS. Il suffit de lancer ce même service en mode LOCAL pour que le service tourne dans un processus séparé du serveur GlassFish (mais toujours sur la même machine). Le service JMS sera toujours contrôlé par GlassFish (lancement simultanés entre autre). Changer ce mode de fonctionnement du service JMS permet de résoudre ce problème de cast de messages.

Pour effectuer ce changement, il faut se rendre dans la console d'administration de GlassFish :

• Accéder à l'adresse http://localhost:4848/
• Se connecter avec les identifiants d'administration de GlassFish (par défaut : admin /// adminadmin)
• Cliquer sur "Configuration" -> "Java Message Service" dans le menu de navigation de gauche
• Modifier la propriété "Type" et lui donner la valeur de "LOCAL"