Es cierto que lo ideal es que la instrucción setVisible(true) sea la última en ejecutarse, cuando ya todos los componentes de la interfaz estén inicializados y maquetados.
Pero en este caso, no es ese el problema, y además cuando un JFrame ya es visible, se puede seguir añadiendo/retirando componentes de la interfaz, aunque puede ser algo arriesgado.
Aquí el problema es que en ningún momento está añadiendo el JLabel al JPanel.
Sin esta instrucción:
El JLabel llamado "saludo" nunca se mostrará porque no ha sido agregado (add()) a ningún contenedor de la interfaz, ya sea al JPanel o directamente al JFrame, que también se podría.
Pero es que además, puesto que el JPanel se declara en un método, y el JLabel en otro distinto, no hay "visibilidad" entre ellos.
Están fuera de alcance (scope), por lo tanto si le decimos al panel que añada el JLabel llamado "saludo", el compilador automáticamente nos lanzará un warning indicando que no sabe que es "saludo", a pesar de que están en el mismo código (pero distinto ámbito).
Por ejemplo, si retomamos este código:
Ese código compila y funciona bien. "panel" y "saludo" están declarados en el mismo método y por tanto, están dentro del mismo ámbito.
Pero si lo cambiamos de modo que el JLabel lo declaramos en un método separado:
Esto ya produce un warning en la línea donde he puesto el comentario explicando.
Porque el método initLabel() no tiene alcance para ver a "panel". Están en distintos ámbitos y no son visibles.
Si pruebo a cambiar el orden de los métodos e intento que sea el método initPanel() quien añada el JLabel al panel:
Me encuentro con un problema similar. initPanel() no puede ver al JLabel "saludo", es incapaz de
resolver a que variable estamos haciendo referencia:
Por esto, es necesario comprender bien que es el ámbito/alcance/scope (tiene varios nombres pero todo refiere a lo mismo) de un programa.
Si queremos que dos elementos sean visibles entre ellos y puedan interactuar, o los declaramos dentro del mismo método, ya sea un constructor, una función o lo que sea...
U otra opción, es declararlos como atributos de clase (hay quien lo llama variables globales) porque así son visibles en TODOS los distintos ámbitos que pueda tener el programa.
Elegir entre hacerlo de una forma u otra ya depende de nosotros y de cada caso.
Por mi parte, si un componente es poco "importante" y/o una vez puesto en pantalla no va a ser alterado ni va a recibir ninguna interacción, entonces los declaro en el método donde se vaya a maquetar y ya está.
Por ejemplo un JLabel que simplemente muestra un texto tipo "Introduzca su e-mail: ".
Esto no va a ser alterado ni nadie va a interactuar con él, solo necesito que se maquete y ya está. No es importante.
Pero si es un componente más importante, y que varios métodos van a querer interactuar con él, entonces si que los declaro como atributo de clase.
Por ejemplo el JTextField donde el usuario nos proporciona el e-mail.
Habrá un método que quiera recoger ese dato cuando el usuario se registra,
otro método querrá escribir en ese campo cuando el usuario quiera editar sus datos ya registrados,
otro método querrá borrarlo cuando el formulario se resetee,
quizás habrá otro método que quiera comprobar con una expresión regular que se ha escrito una dirección email bien formateada y si no es así, pues quizás cambié el color del campo de texto a color rojo para que el usuario sepa que ese dato no nos vale.
Este si es un elemento importante y que puede requerir ser visible para distintos métodos, así que mejor declararlo como atributo de clase.
Creo que con estos ejemplos ya queda claro qué es el ámbito de un programa y cómo nos afecta.
Si no, por la red hay montones de
explicaciones
