public class Display {

    public void printTime(int hour, int minute, int second) {
        String fullHour = "";

        fullHour += (hour > 9) ? ":" + hour : "0" + hour;
        fullHour += (minute > 9) ? ":" + minute : ":0" + minute;
        fullHour += (second > 9) ? ":" + second : ":0" + second;

        System.out.println(fullHour);
    }
}

import java.util.Timer;
import java.util.TimerTask;

public class Timeout {

    private int hour = 0;
    private int minute = 0;
    private int second = 11;
    private Timer timer;
    private boolean isTimerRunning;
    private Display display;

    public Timeout() {
        timer = new Timer();
        display = new Display();
    }

    TimerTask task = new TimerTask() {
        @Override
        public void run() {
            isTimerRunning = true;
            if(second > 0) {
                second--;
            } else {
                second = 59;
                if(minute > 0) minute--;
                else {
                    minute = 59;
                    if(hour > 0) hour--;
                    // si segundo = 0, minuto = 0 y hora = 0,
                    // cancelamos el timer
                    else {
                        isTimerRunning = false;
                        timer.cancel();
                        timer.purge();
                    }
                }
            }
            if(isTimerRunning)
                display.printTime(hour, minute, second);
        }
    }; // fin timertask

    public void start(int timeout, int interval) {
        timer.schedule(task, timeout, interval);
    }

} // fin clase

• Un objeto TimerTask
  
• Un timeout (tiempo de espera para que empiece a ejecutarse)
  
• Un intervalo (la tarea se ejecutará cada X tiempo)
  
  Los dos últimos parámetros se debe especificar en milisegundos, así, 1000 es equivalente a 1 segundo. Por último, hagamos nuestra clase principal.
  
  

  
  public class TimerTest {
  
      public static void main(String[] args) {
          Timeout timeout = new Timeout();
          timeout.start(0, 1000);
      }
  }

  
  
  En la clase principal decimos que el timer tendrá un delay de 0s y un intervalo de 1s. Si compilamos y corremos:
  
  

  javac Display.java
  javac Timeout.java
  javac TimerTest.java
  
  java TimerTest

  
  
  Obtendremos lo siguiente:
  
  
  
  
  
  ¿Posibilidades? La que puedas imaginar, así que piensa como sacarle provecho en tu próximo proyecto.

<visibilidad> <modificador> <nombre> (<parámetros>) { ... }

public String createCar(String brand) {
    return "Auto " + brand + " creado";
}

public String createCarWithColor(String brand, String color) {
    return "Auto " + brand + " color " + color + " creado";
}

public String createCar(String brand) {
    return "Auto " + brand + " creado";
}

public String createCar(String brand, String color) {
    return "Auto " + brand + " color " + color + " creado";
}

public String createCar(String brand, String color, String hp) {
    return "Auto " + brand + " color " + color + " y " + hp + " caballos de fuerza creado";
}

• Un método sobrecargado debe cambiar los parámetros del método a sobrecargar(menos o más).
  
  El siguiente ejemplo muestra una sobrecarga errónea de un método:
  
  

  
  public int sumar(int x, int y) { ... }
  
  public float sumar(int x, int y) { ... } // error, debe cambiar parámetros

  
  
  
  SOBRECARGA DE CONSTURCTORES
  
  La sobrecarga de constructores es igual que la de los métodos. Veamos un ejemplo para más detalle:
  
  

  
  public class User {
  
      private String id;
      private String name;
  
      public User() {
  	this("", "");
      }
  
      public User(String id) {
          this(id, "");
      }
  
      public Usuer(String id, String name) {
   	this.id = id;
  	this.name = name;
      }
  
  }

  
  
  Vemos que hemos sobrecargado el constructor por defecto User(), el primero pasándole un String id, y el segundo un String id y un String name. Lo curioso aquí es la instrucción this(...). Veremos más adelante el concepto de this, pero como adelanto les diré. La palabra reservada this hace referencia a la instancia. Es decir, si hago: this(id, ""), -> this = objeto User -> objeto User(id, ""). Por lo tanto, como this hace referencia a la instancia, podemos acceder tanto a los contructores, métodos y atributos. Ya veremos más acerca de this un poco más adelante.

• @PostConstruct: un método anotado con esta anotación es llamado inmediatamente después que el contenedor haya inyectado el bean (instanciado).
• @PreDestroy: un método anotado con esta anotación es llamado justo antes que el recolector de basura elimine el bean.

public class BankLoan {
    @Inject
    private AccountChecker accountChecker;
    private Date dateOfLoan;

    @PostConstruct
    private void initializeDate() {
        dateOfLoan = new Date();
    }
}

• No debe ser una interna no estática.
  
• Tiene un constructor por defecto sin parámetros o debe declarar un constructor anotando @Inject.
  
• Es una clase concreta (no debe extender) o  es anotada con @Decorator
  
  Para mayor comprensión, veamos el siguiente diagrama de clases:
  
  
  
  
  ¿Cómo conectamos CDStore y CreditCard? La forma que todos conocemos es mediante el operador new:
  
  

  public class CDStore {
      private CreditCard creditCard;
      
      public CDStore() {
          creditCard = new Visa();
      }
      public void buyItems() {
          // pagar con la tarjeta
  	  creditCard.pay();
      }
  }

  
  
  El código anterior es bien simple  y es lo que nosotros hacemos y conocemos. Pero, ¿que pasaría si quisieras pagar con MasterCard?, ¿Necesitarías crear una (otra) instancia de MasterCard? Una solución pasar su dependencia por medio del constructor de una clase externa que haga uso de la clase CDStore:
  
  

  public class CDStore {
      private CreditCard creditCard;
  
      public CDStore(CreditCard creditCard) {
          this.creditCard = creditCard;
      }
      ...
  }

  
  
  En otra clase:
  
  

  CDStore cdStore = new CDStore(new MasterCard());

  
  
  Ésto es lo que se conoce como inversion of control (IoC) o inversión de control (en español). La dependencia se inyecta desde una tercera clase, de ésta manera no creamos un vínculo entre CDStore y CreditCard.
  
  Inyección (@Inject)
  
  Java EE es un entorno gestionado, así que quizás no necesitas construir las dependencias tú mismo, en su lugar, puedes dejar que el contenedor inyecte las dependencias de los beans por tí. CDI tiene la habilidad de inyectar dependencias de prácticamente lo que sea. Veamos un ejemplo:
  
  

  public class CDStore {
      @Inject
      private CreditCard creditCard;
      
      public void buyItems() {
          creditCard.pay();
      }
      ...
  }

  
  
  Como se puede observar, no necesitamos construir la dependencia de creditCard, se lo dejamos al contenedor. La implementación se vería así:
  
  

  public class Visa implements CreditCard {
      @Override
      public void pay() {
           // logica de negocio
      }
  }

  
  
  Nota que solo hemos especificado una implementación de la interface CreditCard. Si hubiéramos creado otra implementación, la inyección no se podría realizar porque el contenedor no sabría qué dependencia inyectar. Esto, lo resolveremos más adelante con calificadores (@Qualifier).
  
  

  ---

  
  
  ANEXO
  
  Puntos de inyección
  
  Una inyección puede llevarse a cabo en tres puntos:
  
  
• Por propiedad:
  
     

  @Inject
  	private CreditCard creditCard;

  
  
     Nota que no es necesario especificar setter para la propiedad.
  
• Por constructor:
  
     

  @Inject
           private CDStore (CreditCard creditCard) {
               this.creditCard = creditCard;
          }

  
  
     La regla aquí es que la inyección por constructor se puede realizar solo una vez (por    clase).
  
  
• Por setter:
     

  @Inject
          public void setCreditCard(CreditCard creditCard) {
              this.creditCard = creditCard;
          }

  
  
  
  Ésto es un anexo, porque en realidad no importa en qué punto hagas la inyección. Por propiedad, constructor o setter, para el contenedor le da igual. Por lo tanto, escoger uno u otro, es simplemente opción personal.
  
  

  ---

  
  
  Injección por defecto (@Default)
  
  Tu puedes tener una dependencia para inyectar por defecto. Por ejemplo, nosotros tenemos solo una implementación, aquella, tendrá implícitamente el modificador @Default. Así, ésto:
  
  

  @Inject
  private CreditCard creditCard;

  
  
  Es igual que:
  
  

  @Inject @Default
  private CreditCard creditCard;

  
  
  Podemos apreciarlo en una imagen:
  
  
  
  
  Si tienes una implementación, el contenedor inyectará la única dependencia existente. Si por otro lado, tienes muchas implementaciones de una interface, el contenedor no sabrá cuál implementación debe inyectar, y aquí es cuando toman tanta importancia los calificadores.
  
  
  Calificadores (@Qualifier)
  
  Cuando el sistema inicia, el contenedor CDI debe validar que todos los beans satisfasgan cada punto de inyección existente. Si alguna dependencia de un bean no puede ser satisfecha por el contenedor CDI, entonces la aplicación no se podrá desplegar informando de una insatisfacción de dependencia. Si hay una sola implementación disponible, la inyección funcionará aplicando la dependencia única, que es marcada implícitamente con @Default.
  
  Si hay más de usa implementación y tratamos de desplegar, la aplicación no desplegará porque dectectará ambiguación en las dependencias, es decir, si hay 2 o más implementaciones, ¿cómo sabe el contenedor qué dependencia inyectar? Aquí es donde toman importancia los calificadores. Veamos el siguiente diagrama de clases que ilustra la situación actual:
  
  
  
  
  Podemos ver que hemos creado una nueva implementación, llamada MasterCard, la misma está anotada bajo el calificador MasterCardPay. Además, vemos como una nueva clase, CDStoreWithQualifier inyecta la nueva dependencia. Esto lo hará mediante el calificador. Veamos el ejemplo en código (solo las nuevas clases):
  
  Calificador MasterCardPay:
  
  

  @Qualifier
  @Retention(RUNTIME)
  @Target({FIELD, TYPE, PARAMETER, METHOD})
  public @interface MasterCardPay {}

  
  
  Implementación MasterCard:
  
  

  @MasterCardPay
  public class MasterCard implements CreditCard {
      private Logger logger = Logger.getLogger(MasterCard.class.getName());
      
      @Override
      public void pay() {
          logger.log(Level.INFO, "Pagando con MasterCard");
      }
  }

  
  
  La anotación @Retention, especifica el nivel de retención de la anotación. Existen 3 tipos:
  
  
• SOURCE: la anotación será visible en el código fuente, una vez que se compila la aplicación, es descartada. La anotación no será escrita en bytecode. Por ejemplo, @Override.
  
• CLASS: La anotación se descarta durante la carga de la clase por parte del ClassLoader. Sí se escribe en bytecode.
  
• RUTNIME: No se descarta. Ésta anotación estará siempre disponible por reflection en tiempo de ejecución.
  
  Las primeras dos anotaciones no podrán ser inspeccionadas en tiempo de ejecución, mientras que la última sí. Esta es la diferencia entre las 3.
  La anotación @Target, especifica que elementos podrán ser afectados por la anotación. Hay varias opciones:
  
  
• ElementType.ANNOTATION_TYPE
  
• ElementType.CONSTRUCTOR
  
• ElementType.FIELD
  
• No tienes permitido ver los links. Registrarse o Entrar a mi cuenta_VARIABLE
  
• ElementType.METHOD
  
• ElementType.PACKAGE
  
• ElementType.PARAMETER
  
• ElementType.TYPE
  
  Creo que la mayoría se explican solas. Las dos anotaciones que son un poco confusas son ANNOTATION_TYPE y TYPE. ANNOTATION_TYPE significa que la anotación solo podrá ser usada para anotar otras anotaciones, como @Retention. TYPE significa cualquier tipo de elemento (clases, interfaces, enums, anotaciones, etc).
  
  Comprendidos ya estos conceptos, vamos a ver la clase que inyecta la nueva implementación:
  
  

  public class CDStoreWithQualifier {
      @Inject @MasterCardPay
      private CreditCard masterCard;
      
      public void buyItems() {
          masterCard.pay();
      }
  }

  
  
  Observa lo sencillo que es inyectar múltiples dependencias, solo basta con indicar el calificador de la dependencia que debe ser inyectada. Es posible también anotar un elemento con múltiples anotaciones. Java no nos limita en este aspecto. Por ejemplo:
  
  

  @Inject @Visa @Gold
  private CreditCard creditCard;

  
  
  
  Productores (@Produces)
  
  Como ya hemos visto, podemos inyectar CDI beans dentro de otros CDI beans. Pero, si quisiéramos inyectar POJOs, o tipo de datos primitivos, ¿sería eso posible? La respuesta corta es no y la razón es la siguiente.
  
  Por defecto, no puedes inyectar clases como String o Date y la razón, es porque ellas están empaquetadas en el archivo rt.jar (Java runtime enviroment classes) y este no contiene un descriptor de beans beans.xml. Esto es importante tenerlo presente, si un archivo no tiene un descriptor beans.xml bajo el directorio META-INF, CDI no activará el descrubimiento de beans (bean discovery) y los POJOs no podrán ser tratados como beans y por ende, no podrán ser inyectados. Afortunadamente, podemos revertir esta situación con ayuda de los productores. Veamos un ejemplo:
  
  
  
  
  Veamos que la clase CDSerialProducer tiene 3 anotaciones, las cuales pasamos a describir:
  
  
• @Produces: utilizada para producir un bean listo para inyección.
  
• @CDSerialPrefix: anotación propia.
  
• @RandomNumber: anotación propia.
  
  Primer veamos nuestras anotaciones, serán igual que los calificadores que ya hemos visto:
  
  

  @Retention(RUNTIME)
  @Target({FIELD, TYPE, PARAMETER, METHOD})
  public @interface CDSerialPrefix { }

  
  
  

  @Retention(RUNTIME)
  @Target({FIELD, TYPE, PARAMETER, METHOD})
  public @interface RandomNumber { }

  
  
  Ahora, veamos como producimos beans para inyectar de tipo String e int:
  
  

  public class CDSerialProducer {
      @Produces @CDSerialPrefix
      private final String prefix = "T9-SK534";
      
      @Produces @RandomNumber
      public int generateNumber() {
          return new Random().nextInt(10000);
      }
  }

  
  
  La anotación @Produces, producirá una propiedad y un método para inyectar. Seguido de @Produces, debemos de especificar el calificador con el cual se va a inyectar la propiedad y el método. En este caso son @CDSerialPrefix y @RandomNumber. Ahora veamos como los inyectamos:
  
  

  public class CDService {
      @Inject @CDSerialPrefix
      private String prefix;
      @Inject @RandomNumber
      private int number;
      private Logger logger = Logger.getLogger(getClass().getName());
      
      public void createCD() {
          logger.log(Level.INFO, "Creando CD con serial: {0}", (prefix + number));
      }
  }

  
  
  Si ejecutamos el proyecto, podemos ver que se inyectan satisfactoriamente los valores de la propiedad y el método dentro de las propiedades de CDService. Gracias a los productores, podemos inyectar prácticamente lo que sea.
  
  

  ---

  
  
  ANEXO
  
  API de InjectionPoint
  
  Los atributos y propidades producidad por productores (@Produces) no necesitan saber ningún tipo de información acerca de donde ellos son inyectados. Sin embargo, hay ciertos casos  donde podría ser de utilidad que el bean a inyectar sepa en qué punto de inyección se ha llevado a cabo la inyección. Un ejemplo común de ésto, es generar una dependencia dinámica de Logger (para crear logs). Generalmente, siempre creamos un Logger así:
  
  

  Logger logger = Logger.getLogger(TuClase.class.getName());

  
  
  Lo anterior funciona correctamente, pero también podríamos generar depenencias dinámicamente. Veamos primero la API de InyectionPoint:
  
  
  
  
  Podemos usar esta API para generar una dependencia dinámica para Logger. Veamos un ejemplo:
  
  

  public class LoggerProducer {
      @Produces
      private Logger createLogger(InyectionPoint ip) {
          return Logger.getLogger(ip.getMember().getDeclaringClass().getName());
      }
  }

  
  
  Perfecto. Ahora tan solo debemos inyectar al logger de ésta manera:
  
  

  @Inject Logger log;

  
  
  ¿Cómo ocurre la magia? Bien, el contenedor CDI buscará cualquier bean de tipo Logger listo para inyectar, y lo encuentra gracias a que hemos anotado el método con @Produces, lo que deja ese método listo para su inyección (como con @CDSerialPrefix y @RandomNumber del ejemplo anterior).
  
  

  ---

  
  
  
  Trituradores (@Disposes)
  
  Ahora sabemos como producir beans o valores para inyectar, pero algunos beans podrían necesitar ser cerrados, como es el caso de conexiones JDBC o un EntityManager. Por lo tanto, algunos beans producidos deberían asegurarse de ser cerrados. Aquí es donde toman importancia los Disposers. Los Disposers son lo  contrario a Producers, éste último crea beans o valores para inyectar, mientras que el primero se encarga de destruirlo.
  Veamos un ejemplo con una clásica conexión JDBC:
  
  

  public class DerbyJdbcProducer {
      private final static String DRIVER = "org.apache.derby.jdbc.EmbeddedDriver";
      private final static String URL = "jdbc:derby://localhost:1527/CDI";
      private final static String USER = "duke";
      private final static String PASS = "1234";
      @Inject
      private Logger logger;
      
      @Produces
      public Connection createConnection() {
          Connection con = null;
          try {
              Class.forName(DRIVER).newInstance();
              con = DriverManager.getConnection(URL, USER, PASS);
              logger.log(Level.INFO, "Creando conexión JDBC con Derby");
          } catch(InstantiationException | IllegalAccessException |
                  ClassNotFoundException | SQLException e) {
              e.printStackTrace();
          }
          return con;
      }
      public void closeConnection(@Disposes Connection con) {
          try {
              con.close();
              logger.log(Level.INFO, "Cerrando conexión JDBC con Derby");
          } catch (SQLException e) {
              e.printStackTrace();
          }
      }
  }

  
  
  Un método disposer debe obligatoriamente recibir un parámetro @Disposes y el tipo del parámetro debe ser el mismo que el tipo devuelto con el método productor (@Produces) y su calificador (@Qualifier) en caso haya más métodos productores con el mismo tipo de retorno. Dado que el ciclo de vida de un bean inyectado depende del contexto en donde se inyecta, cuando se elimina el bean que contiene el bean inyectado, éste se destruirá también. Pero si no hubiésemos escrito el método disposer, la conexión nunca se hubiese cerrado por ser ésta independiente del contexto. Cuando el bean que contiene el bean inyectado es eliminado, antes que eso ocurra, se ejecutará el método disposer del bean inyectado, en este caso, cerrando la conexión JDBC.
  
  

  ---

  
  
  ANEXO
  
  Alcances (scopes)
  
  Todo objeto cuyo ciclo de vida es manejado por CDI tiene un alcance definido y un ciclo de vida que está ligado a un contexto específico. En Java, el alcance de un POJO es muy simple: tu creas una instancia de una clase usando la palabra reservada new y tu confías en el recolección de basura para deshacerse  de él y liberar alguna memoria. Con CDI, un bean es ligado al contexto y este lo mantiene en ese contexto hasta que el bean es destruido por el contenedor. No hay manera para remover manualmente un bean desde un contexto.
  
  CDI define los siguientes alcances y permite puntos de extesión para crear tu propio alcance:
  
  
• Application scope(@ApplicationScoped): Se extiende por la duración entera de una aplicación. El bean es creado solo una vez por duración de la aplicación y es descartado cuando la aplicación se apaga. Este alcance es util para cases utilitarias o helpers, u objetos que guardan datos compartidos por la aplicación entera (pero deberías ser cuidadoso con los problemas de concurrencia cuando los datos tienen que ser accesados por muchos threads).
  
  
• Session scope(@SessionScoped): Se extiene a través de muchas peticiones HTTP o muchas invocaciones de métodos por una sola sesión de usuario. El bean es creado por la duración de una sesión HTTP y es descartado cuando la sesión termina. Este ámbito es para objectos que son necesarios a lo largo de la sesión como preferencias de usuario o credenciales de login.
  
  
• Request scope(@RequestScoped): Corresponde a una simple petición HTTP o a una invocación de un método. El bean es creado para la duración de una invocación a un métod y es descartado cuando el método termina. Esto es usado para clases de servicio o beans JSF que son solo necesitados durante la duración de una petición HTTP.
  
  
• Conversation scope(@ConversationScoped): Se extiende entre múltiples invocaciones dentro de los límites de una sesión con puntos de inicio y fin determinados por la aplicación. Este alcance es usado a través de múltiples páginas como parte de un flujo de trabajo de múltiplos pasos.
  
  
• Dependent pseudo-scope(@Dependent): El ciclo de vida es el mismo que del cliente. Un bean @Dependent es creado cada vez que este es injectado y la referencia es eliminada cuando el objetivo de la inyección es eliminado. Éste es el alcance por defecto para CDI.
  
  Como puedes ver, todos los alcances tienen una anotación que tu puedes usar en tus beans CDI (todas ellas están en el paquete javax.enterprise.context). Los primeros tres alcances son bien conocidos. Por ejemplo, si tu tienes un bean de alcance de sesión como de un carro de compras, el bean será automáticamente creado cuando la sesión inicia (primera vez que un usuario se loguea) y es  destruido automáticamente cuando la sesión termina.
  
  

  CitarNotas: El ciclo de vida de un bean @Dependent está ligado al ciclo de vida del bean que lo contiene. Se crea cuando el bean que lo contiene es instanciado y es eliminado cuando el mismo es eliminado. Es el scope por defecto.

  
  
  Conversation (@ConversationScoped)
  
  El alcande conversation es un poco diferente al resto. Este alcance mantiene estados asociados en un intérvalo de tiempo, a través de múltiples peticiones y es eliminado programáticamente (explícitamente) por la aplicación. Este alcance es usado mayormente en procesos  donde se requiere mantener valores durante múltiples peticiones HTTP pero sin extenderse demasiado, como un alcance @SessionScoped.
  
  API de Conversation:
  
  
  
  
  La principal diferencia con otros alcances, es que ellos son eliminados automáticamente por el contenedor al cabo de un tiempo cuando termina la petición, sesión, aplicación, etc. En Conversation, nosotros debemos encargarnos terminar su ciclo de vida. Por ejemplo, un bean @ConversationScoped puede ser usado para un asistence de registro de usuario. Deseamos mantener los datos que se van registrando del usuario a través de distintas páginas y que elimine el bean al terminar el registro:
  
  

  @Named
  @ConversationScoped
  public class UserRegistrationWizard implements Serializable {
      @Inject
      private Conversation conversation;
      @Inject
      private User user;
      @Inject
      private transient Logger logger;
      
      @PostConstruct
      public void init() {
          conversation.begin();
      }
      public User getUser() {
          return user;
      }
      public void register() {
          conversation.end();
          logger.log(Level.INFO, "Usuario registrado:");
          logger.log(Level.INFO, "Email: {0}", user.getEmail());
          logger.log(Level.INFO, "Password: {0}", user.getPassword());
          logger.log(Level.INFO, "Fecha Nacimiento: {0}", user.getBirthDate());
      }
  }

  
  
  Para probarlo, crea distintas páginas JSF y en cada una pon un formulario con un input text para el email, un input secret para el password y un input text para la fecha de cumpleaños:
  
  start.xhtml
  
  

  <h3>Inicio de registro</h3>
          <h:form>
              <h:outputLabel for="email" value="Email:"/>
              <h:inputText id="email" value="#{userRegistrationWizard.user.email}"/>
              <h:commandButton value="Siguiente" action="step2"/>
          </h:form>

  
  
  step2.xhtml
  
  

  <h3>Paso 2</h3>
          <h:form>
              <h:outputLabel for="password" value="Contraseña"/>
              <h:inputSecret id="password" value="#{userRegistrationWizard.user.password}"/>
              <h:commandButton value="Siguiente" action="end"/>
          </h:form>

  
  
  end.xhtml
  
  

  <h3>Paso 3</h3>
          <h:form>
              <h:outputLabel for="birthDate" value="F. Nacimiento:"/>
              <h:inputText id="birthDate" value="#{userRegistrationWizard.user.birthDate}">
                  <f:convertDateTime pattern="dd-MM-yyyy"/>
              </h:inputText>
              <h:commandButton value="Registrar" action="#{userRegistrationWizard.register()}">
                  <f:ajax execute="@form" />
              </h:commandButton>
          </h:form>

  
  
  Al llegar a la últma página y pulsar el botón registrar, se ejecuta el método registrar(), donde termina la conversación y se imprime toda la información del usuario recolectada durante la misma.
  
  
  Interceptores (@Interceptor)
  
  Los interceptores te permiten agregar conceptos a través de tus beans. Cuando un cliente invoca a un método en un Managed Bean (y por lo tanto a CDI beans, EJB, RESTful, ...), el contenedor puede interceptar la invocación y procesar lógica de negocio antes que el método del bean sea invocado. Los interceptores vienen en cuatro tipos:
  
  
• Interceptores a nivel de constructor: el interceptor es asociado con un constructor de la clase objetivo (@AroundConstruct)
  
• Interceptores a nivel  de método: el interceptor es asociado con un método de negocio específico (@AroundInovke)
  
• Interceptores por tiempo límite: el interceptor se interpone en el tiempo límite de los métodos (@AroundTimeout (usado solo con EJB timer)
  
• Interceptores de ciclo de vida: el interceptor se interpone en las llamadas de eventos del ciclo de vida del objetivo (@PostConstruct y @PreDestroy).
  
  Un método anotado con @AroundInvoke, debe tener el siguiete patrón de firma:
  
  

  @AroundInvoke
  Object <Método> (InvocationContext ic) throws Exception;

  
  
  Las siguientes reglas aplican a un método @AroundInvoke:
  
  
• El método puede tener cualquier modificador de visibilidad pero no debe ser static o final.
  
• El método debe tener un parámeto InvocationContext y debe retornar Object, el cual es el resultado del método objetivo invocado.
  
• El método debe lanzar una excepción comprobada.
  
• El objeto InvocationContext permite a los interceptores controlar el comportamiento de la cadena de invocaciones. Si muchos interceptores son encadenados, la misma instancia de InvocationContext es pasada a cada interceptor, quien puede agregar datos contextuales para ser procesador por otros interceptores.
  
  Echememosle un ojo a la API de InvocationContext:
  
  
  
  
  Otra forma de trabajar con interceptores, es que estos pueden estar en una clase y luego ser referenciada por la clase que los necesite:
  
  

  @Interceptors(MisInterceptores.class)
  public class MiClase { ... }

  
  
  O en algún método:
  
  

  @Interceptors(MisInterceptores.class)
  public void doSomething() { ... }

  
  
  Si queremos que un método no sea interceptado, lo anotamos con @ExcludeClassInterceptors.
  
  Veamos un ejemplo:
  
  
  
  
  Vamos con nuestro interceptor:
  
  

  public class LoginInterceptor {
      private @Inject Logger logger;
  
      @AroundConstruct
      private Object init(InvocationContext ic) throws Exception {
          logger.log(Level.INFO, "--- ConstructInterceptor ---");
          logger.log(Level.INFO, "Entrando al constructor");
          try {
              return ic.proceed();
          } finally {
              logger.log(Level.INFO, "Saliendo del constructor");
          }
      }
      @AroundInvoke
      private Object interceptMethod(InvocationContext ic) throws Exception {
          logger.entering(ic.getTarget().toString(), ic.getMethod().getName());
          try {
              logger.log(Level.INFO, "método interceptado");
              return ic.proceed();
          } finally {
              logger.exiting(ic.getTarget().toString(), ic.getMethod().getName());
          }
      }   
  }

  
  
  Y nuestra clase que se verá afectada por nuestro inteceptor:
  
  

  @Interceptors(LoginInterceptor.class)
  public class LoginService {
      private @Inject Logger logger;
      
      public void login() {
          logger.log(Level.INFO, "Haciendo login");
      }
  }

  
  
  Cuando se instancie ésta clase y cuando llamemos al método login(), se ejecutarán los interceptores que hemos definido en LoginInterceptor, que son uno a nivel de método y otro a nivel de constructor.
  
  

  CitarTambién se pueden proporcionar más de un interceptor, deben separarse por comas:

  
  

  @Interceptors(LoginInterceptor.class, AccountcheckerInterceptor.class)
  public class LoginService { ... }

  
  
  Los interceptores serán ejecutados en el orden que son escritos.
  
  
  Vinculación de interceptores (@InterceptorBinding)
  
  Una manera más práctica y que es la más aconsejada por su bajo acoplamiento, es Interceptor Binding. Es muy fácil de hacer, solo basta crear un Interceptor Binding que es muy parecido a un calificador:
  
  

  @InterceptorBinding
  @Retention(RUNTIME)
  @Target({METHOD, TYPE})
  public @interface Loggable { }

  
  
  El interceptor cambia muy poco, solo debemos anotar con @Interceptor y el interceptor binding que hemos creado, en nuestro caso, @Loggable:
  
  

  @Interceptor
  @Loggable
  public class LoginInterceptorBinding { ... }

  
  
  Ahora, en nuestra clase objetivo (donde se interceptarán los métodos), solo debemos anotar la clase o los métodos/constructor que queremos interceptar. Por ejemplo:
  
  

  public class LoginServiceBinding {
      @Loggable
      public void Login() {
          ...
      }
  }

  
  
  Como se puede observar, es mucho más práctico de esta forma y además, más agradable a la vista. Para poder utilizar ésta manera, debemos de agregar nuestro interceptor binding en el descriptor de beans (beans.xml):
  
  

  <beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
         http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
         bean-discovery-mode="all">
      <interceptors>
          <class>com.acme.interceptors.binding.LoginInterceptorBinding</class>
      </interceptors>
  </beans>

  
  
  Prioridad de interceptores
  
  Los interceptores sigue el orden en el que los hemos escrito en la clase interceptada, pero podemos crear nuestro propio orden. Por ejemplo, tenemos dos interceptores con prioridad diferente:
  
  

  @Interceptor
  @CdDisponibility
  @Priority(200)
  public class CdDisponibilityInterceptor {
      @Inject
      private Logger logger;
      
      @AroundInvoke
      public Object checkCdDisponibility(InvocationContext ic) throws Exception {
          try {
              logger.log(Level.INFO, "Ejecuando método interceptor checkCdDisponibility");
              return ic.proceed();
          } finally {
              logger.log(Level.INFO, "Terminando ejecución método interceptor checkCdDisponibility");
          }
      }
  }

  
  
  

  @Interceptor
  @DvdDisponibility
  @Priority(300)
  public class DvdDisponibilityInterceptor {
      @Inject
      private Logger logger;
      
      @AroundInvoke
      public Object checkDvdDisponibility(InvocationContext ic) throws Exception {
          try {
              logger.log(Level.INFO, "Ejecutando método interceptor checkDvdDisponibility");
              return ic.proceed();
          } finally {
              logger.log(Level.INFO, "Terminando ejecución del método interceptor checkDvdDisponibility");
          }
      }
  }

  
  
  Ahora, nuestra clase interceptada:
  
  

  @CdDisponibility @DvdDisponibility
  public class SellService {
      public void checkDisponibility() {
          ...
      }
  }

  
  
  Si ejecutamos, veremos la siguiente salida:
  
  

  Información:   Ejecuando método interceptor checkCdDisponibility
  Información:   Ejecutando método interceptor checkDvdDisponibility
  Información:   Terminando ejecución del método interceptor checkDvdDisponibility
  Información:   Terminando ejecución método interceptor checkCdDisponibility

  
  
  Como vemos, el primer interceptor (menor prioridad) se ejecuta primero y el segundo (mayor prioridad), se ejecuta después de éste, pero el segundo termina primero. Luego que termina el interceptor de mayor prioridad, el flujo vuelve hacia el de menor prioridad.
  
  
  Decoradores (@Decorator)
  
  Decorador es un patrón de diseño muy común, originalmente acuñado por Gang of Four (la banda de los cuatro). La idea detrás de este patrón es tomar una clase y envolverla con otra (se dice que esta la decora). De esta manera, cuando tu llamas a una clase decorada, debes pasar a través del decorador antes que alcances la clase objetivo. Los decoradores son usados para añadir lógica a un método.
  
  Tomemos como ejemplo un registro para una tienda de CDs online. Hay la membresía básica, que los permite acceder gratis a 15 CDs. Luego, cuando hay ofertas, viene el decorador que lo que hace es incrementar la cantidad de CDs a 40 (+25 del decorador).
  
  interface Membership
  
  

  public interface Membership {
      public int freeCDs();
  }

  
  
  Implementación BasicMembership
  
  

  @Basic
  public class BasicMembership implements Membership {
      @Inject
      private Logger logger;
      
      @Override
      public int freeCDs() {
          logger.log(Level.INFO, "[+] Clase BasicMembership");
          logger.log(Level.INFO, "Gratis 15 CDs");
          return 15;
      }
  }

  
  
  @Basic es un calificador, que como ya sabemos sigue ésta anatomía:
  
  

  @Qualifier
  @Retention(RUNTIME)
  @Target({FIELD, TYPE, METHOD, PARAMETER})
  public @interface Basic { }

  
  
  Ahora, veamos nuestro decorador:
  
  Decorador MembershipGiftDecorator
  
  

  @Decorator
  public class MembershipGiftDecorator implements Membership {
      @Inject @Delegate @Basic
      private Membership membership;
      @Inject
      private Logger logger;
      
      public int orderGift() {
          logger.log(Level.INFO, "[+] Clase decoradora para Membership");
          logger.log(Level.INFO, "Regalo momentáneo de 25 CDs");
          return membership.freeCDs() + 25;
      }
      @Override
      public int freeCDs() {
          return orderGift();
      }
  }

  
  
  Lo primero que vemos, es que hemos anotado el decorador con @Decorator. Esta anotación le dirá al contenedor que es decorador. Un decorador debe implementar a la interface de la implementación que quiere decorar, es por eso que el decorador implementa también a Membership. Dentro del decorador, vemos que inyectamos la implementación BasicMempership (@Basic) y la anotamos con @Delegate para indicar que ese bean será decorado. A continuación, sobreescribimos el método de la interface y añadimos la lógica de negocio que deseamos. En nuestro caso, agregar 25 CDs gratis.
  
  Por último hacemos uso del decorador:
  
  

  @Named
  public class MembershipBean {
      @Inject @Basic
      private Membership gift;
      
      public void orderGift() {
          gift.freeCDs();
      }
  }

  
  
  Vemos que NO inyectamos al decorador, si no al bean normal (@Basic). El contenedor se encarga de añadir la lógica del decorador al método del bean. Si ejecutamos, vemos ésta salida:
  
  

  Información:   [+] Clase decoradora para Membership
  Información:   Regalo momentáneo de 25 CDs
  Información:   [+] Clase BasicMembership
  Información:   Gratis 15 CDs

  
  
  El orden es porque yo he ejecutado primero la lógica del decorador y al último del bean. Si hubiera sido al revés, el resultado hubiera sido invertido.
  Los decoradores no están activados por defecto en CDI, así que debemos listarlos en el descriptor beans.xml:
  
  

  <decorators>
          <class>com.acme.decorator.MembershipGiftDecorator</class>
  </decorators>

  
  
  Eventos
  
  Los eventos permiten a los beans interactuar con sus dependencias en tiempo de no-compilación. Cuando un bean define un evento, otro bean puede disparar el evento e incluso otro bean puede manejar el evento. Los beans pueden estar en paquetes y capas distintos dentro de la aplicación. El esquema que siguen éstos eventos es el observer/observable, de Gand of four.
  
  Los productores de los eventos disparan los eventos usando la interface Event (javax.enterprise.event.Event). Un productor eleva eventos llamando el método fire(), pasando el objeto asociado al evento.
  
  Veamos un ejemplo. En nuestra tienda online de CDs, cada vez que se quiera agregar un ítem al carro, deseamos disparar un evento CDI que envíe el ítem que se desee agregar al método observador addItem y reciba el ítem elegido por el usuario para que se agrege al carro.
  
  Vamos con nuestro bean CDShopCart:
  
  

  @Named("cdShopCart")
  @RequestScoped
  public class CDShopCart {
      @Inject
      private Event<CD> cdAddedEvent;
      
      public void addItem2cart() {
          List<String> songs = new ArrayList<>();
          Collections.addAll(songs,
                  "The day that never comes",
                  "Enter Sandman",
                  "The fourth horseman",
                  "Whiskey in the jar");
          CD cd = new CD("Metallica", songs);
          cdAddedEvent.fire(cd);
      }
  }

  
  
  Este bean tendrá un alcande de petición (@RequestScoped), es decir que su ciclo de vida será igual al de una petición HTTP. Esto es así porque solo vamos a utilizar este bean para agregar un ítem (CD) al carro. Vemos que hemos definido una propiedad tipo Event que acepta datos tipo CD. Cuando se ejecute el método addItem2cart, se ejecutará el evento CDI y se enviará un bean CD para que sea procesado por el método observador, que lo define la siguiente clase:
  
  

  @SessionScoped
  public class Cart implements Serializable {
      @Inject
      private transient Logger logger;
      private List<CD> items;
      
      @PostConstruct
      public void init() {
          items = new ArrayList<>();
      }
      
      public void addItem(@Observes CD cd) {
          logger.log(Level.INFO, "Nuevo CD añadido al carro");
          logger.log(Level.INFO, "Autor: {0}", cd.getAuthor());
          logger.log(Level.INFO, "Canciones:");
          for(String song : cd.getSongs()) {
              logger.log(Level.INFO, song);
          }
      }
  }

  
  
  El método addItem() es el método observador. Este método escucha el evento y cuando se lanza lo captura y recibe el objeto asociado con el evento lanzado, en este caso CD. Es conveniente que la entidad CD sea pasivada (implemente Serializable). Además, vemos que el carro de compras está marcado como @SessionScoped ya que el carro de compras estará ligado siempre a la sesión de un usuario.
  
  Para disparar el evento, podemos usar JSF, por ejemplo:
  
  

  <h:form>
              <h:commandButton value="Agregar CD al carro" actionListener="#{cdShopCart.addItem2cart()}">
                  <f:ajax execute="@form"/>
              </h:commandButton>
          </h:form>

  
  
  Cuando se haga click en el botón, se ejecutará el método y se lanzará el evento. Si hacemos click, veremos lo siguiente en el log:
  
  

  Información:   Nuevo CD añadido al carro
  Información:   Autor: Metallica
  Información:   Canciones:
  Información:   The day that never comes
  Información:   Enter Sandman
  Información:   The fourth horseman
  Información:   Whiskey in the jar

  
  
  Ahora, para hacer más interesante nuestro ejemplo, podemos crear calificadores llamados @Added y @Removed para identificar a cada evento: Agregar y Eliminar. Para esto, debemos hacer unos pequeños cambios:
  
  Debemos cambiar el alcance de CDShopCart de @RequestScoped a @SessionScoped:
  
  

  @Named("cdShopCart")
  @SessionScoped
  public class CDShopCart implements Serializable {
      @Inject @Added
      private Event<CD> cdAddedEvent;
      @Inject @Removed
      private Event<CD> cdRemovedEvent;
      @Inject
      private CD cd;
      
      public void addItem2cart() {
          List<String> songs = new ArrayList<>();
          Collections.addAll(songs,
                  "The day that never comes",
                  "Enter Sandman",
                  "The fourth horseman",
                  "Whiskey in the jar");
          cd.setAuthor("Metallica");
          cd.setSongs(songs);
          cdAddedEvent.fire(cd);
      }
      public void removeItemFromCart() {
          cdRemovedEvent.fire(cd);
      }
  }

  
  
  Los métodos observadores del carro, se verán así:
  
  

  public void addItem(@Observes @Added CD cd) {
          logger.log(Level.INFO, "Nuevo CD añadido al carro");
          logger.log(Level.INFO, "Autor: {0}", cd.getAuthor());
          logger.log(Level.INFO, "Canciones:");
          for(String song : cd.getSongs()) {
              logger.log(Level.INFO, song);
          }
      }
      public void removeItem(@Observes @Removed CD cd) {
          logger.log(Level.INFO, "CD Removido");
          logger.log(Level.INFO, "Autor: {0}", cd.getAuthor());
      }

  
  
  Prestar atención al calificador después de @Observes. Esto identifica al evento disparado, @Added representa un nuevo CD agreado y @Removed eliminará un CD del carro.
  
  Nuestra web, se verá así:
  
  

  <h:form>
              <h:commandButton value="Agregar CD al carro" action="#{cdShopCart.addItem2cart()}">
                  <f:ajax execute="@form"/>
              </h:commandButton>
              <h:commandButton value="Eliminar CD del carro" action="#{cdShopCart.removeItemFromCart()}">
                  <f:ajax execute="@form"/>
              </h:commandButton>
          </h:form>

  
  
  
  
  
  

  ---

  
  
  Eso es todo lo que quería compatirles acerca de CDI. Es un tema muy importante y que pocos entienden y comprenden cómo funciona. Espero que el presente documento es ayuda a entender un poquito mejor cómo funciona CDI y sus nuevas características.
  
  Nos vemos en otra oportunidad, hasta la próxima.

public class Carro {

}

• Constructor o constructores (sobrecarga)
  
• Propiedades (o atributos, campos, como suelen llamarles también) (características)
  
• Métodos (comportamientos)
  
  Además, tiene las siguientes características:
  
  
• Se le asigna un modificador de acceso (public, private, por defecto)
  
• Modificador de estado (static, final)
  
• Notación PascalCase (La primera letra de cada palabra en mayúscula)
  
  PROPIEDADES, ATRIBUTOS O CAMPOS
  
  Son como ya dijimos las características de un objeto. Las propiedades de una clase en Java tienen las siguientes características:
  
  
• Modificador de acceso (public, private, protected, por defecto)
  
• Tipo de dato (String, int, float, doublé, byte, short, etc)
  
• Modificador de estado (static, final)
  
• Notación camelCase (la primera letra de la primera palabra en minúscula y las primeras letras de las palabras siguientes en mayúsculas)
  
  Ej:
  
  

  public class Carro {
  
      private String color;
  
  }

  
  
  MÉTODOS O FUNCIONES
  
  Los métodos en Java son los comportamientos del objeto. Estos cumplen las siguientes características:
  
  
• Modificador de acceso (public, private, protected, por defecto)
  
• Valor de retorno (void, String, int, float, etc)
  
• 0 o más parámetros (variables pasadas a un método)
  
• Notación camelCase (la primera letra de la primera palabra en minúscula y las primeras letras de las palabras siguientes en mayúsculas)
  
  Ej
  
  

  
  public class Carro {
  
      private String color;
      private int velocidad = 150; // km/h
  
      public void acelerar() {
          System.out.println("Acelerando...");
      }
  
      public int obtenerVelocidad() {
          return velocidad;
      }
  
  }

  
  
  La palabra reservada return se usa para devolver valores desde un método. Si el tipo de retorno es void y se usa return, entonces la ejecución del método terminará automáticamente.
  
  Para pasar datos a un método, basta pasarlos entre los paréntesis, separados por comas si hay más de uno:
  
  

  public void establecerVelocidad(int nuevaVelocidad) {
      velocidad = nuevaVelocidad;
  }

  
  
  CONSTRUCTOR
  
  Un constructor es un método especial, el cual sirve como inicializador y creador de nuevas instancias de un tipo de objeto (clase). En cada creación de objetos, se llama al constructor implícitamente; sin él, no sería posible la creación de objetos. Un constructor tiene las siguientes características:
  
  
• No tiene un valor de retorno
  
• Debe llamarse exactamente como la clase
  
  Ej:
  
  

  
  public class Carro {
  
      public String color;
      public int velocidad = 150;
  
      public Carro() {
  
      }
  
      ...
  
  }

  
  
  Generalmente se aprovecha el constructor para inicializar propiedades del objeto. Por ejemplo:
  
  

  public Carro(String nuevoColor, int nuevaVelocidad) {
      color = nuevoColor;
      velocidad = nuevaVelocidad;
  }

  
  
  CREACIÓN DE OBJETOS
  
  Como ya dijimos, la creación de objetos se lleva a cabo por medio del constructor de la clase. Para crear un objeto de tipo Carro basta con hacer:
  
  

  
  Carro miCarro = new Carro();
  Carro miOtroCarro = new Carro("Blanco", 250);

  
  
  Ahora podemos llamar a los métodos de Carro, así:
  
  

  int velocidad = miCarro.obtenerVelocidad(); // retorna null porque no tiene un valor definido
  int velocidad2 = miOtroCarro.obtenerVelocidad(); // retorna 150

  
  
  ¿Cómo se lleva a cabo la creación de objetos?
  
  La palabra reserva new instancia (crea un nuevo objeto de la clase) y la coloca en memoria asociándose a una dirección. Allí, se le asigna un identificador único y por medio de este, podrá ser ubicado y llamado desde su dirección en memoria.
  
  

  CitarPlus: Cada vez que se crea un objeto, éste se guarda en el Stack, que es un apartado donde Java almacena los objetos, mientras que las variables y llamadas a métodos, se almacenan en el Heap.

  
  El código de la clase Carro quedaría así:
  
  

  
  public class Carro {
      private String color;
      private int velocidad;
  
      public Carro() {}
  
      public Carro(Sring nuevoColor, String nuevaVelocidad) {
          color = nuevoColor;
  	velocidad = nuevaVelocidad;
      }
  
      public int obtenerVelocidad() {
  	return velocidad;
      }
  
      public void establecerVelocidad(int nuevaVelocidad) {
  	velocidad = nuevaVelocidad;
      }
  
  }

  
  
  Fíjate que hemos definido dos veces el constructor de la clase, a esto se le llama sobrecarga y puede aplicarse tanto a métodos como a constructores. Esto lo veremos en el próximo capítulo.

• Aro de Llantas
  
• Asiento
  
• Número de cambios
  
• Tipo (montañera, etc)
  
• Color
  
  Todas esas características son las propiedades de una bicicleta. Tiene una medida de aro de llanta, un asiento, número de cambios de velocidad, un tipo que determina si es montañera o de otro tipo y un color.
  
  Métodos/funciones de un objeto:
  
  Por otro lado, una bicileta tiene muchos comportamientos, como por ejemplo:
  
  
• Acelerar
  
• Frenar
  
• Cambiar de velocidad
  
  Todos esos comportamientos, son los métodos o funciones de una bicicleta. Éstos comportamientos describen las cosas que puede hacer la bicicleta.
  
  Por lo tanto, un objeto es una abstracción o representación de una entidad real que tiene características (propiedades) y ciertos comportamientos (métodos o funciones) que lo describen.

<h1>Subir archivos</h1>
    <form method="post" action="upload" enctype="multipart/form-data">
    <fieldset>
    	<legend>Formulario de subida</legend>
    	<input type="file" name="files" id="files" multiple/>
        <button type="submit">Subir</button>	
    </fieldset>
</form>

@WebServlet(name = "UploadServlet", urlPatterns = {"/upload"})
@MultipartConfig(location="D:/uploads")
public class UploadServlet extends HttpServlet {
    private static final long serialVersionUID = 1L;
    
    protected void processRequest(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        response.setContentType("text/html;charset=UTF-8");
        Collection<Part> parts = request.getParts();
        for(Part part : parts) {
        	part.write(getFileName(part));
        }
    }

    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        processRequest(request, response);
    }

    @Override
    protected void doPost(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        processRequest(request, response);
    }

    public String getFileName(Part part) {
        String contentHeader = part.getHeader("content-disposition");
        String[] subHeaders = contentHeader.split(";");
        for(String current : subHeaders) {
            if(current.trim().startsWith("filename")) {
            	int pos = current.indexOf('=');
                String fileName = current.substring(pos+1);
                return fileName.replace("\"", "");
            }
        }
        return null;
    }
}

------WebKitFormBoundaryKZUc66kZeBth3nDc
Content-Disposition: form-data; name="files"; filename="jsf-scopes.png"
Content-Type: image/png


------WebKitFormBoundaryKZUc66kZeBth3nDc
Content-Disposition: form-data; name="files"; filename="navbar.png"
Content-Type: image/png

public String getFileName(Part part) {
        String contentHeader = part.getHeader("content-disposition");
        String[] subHeaders = contentHeader.split(";");
        for(String current : subHeaders) {
            if(current.trim().startsWith("filename")) {
            	int pos = current.indexOf('=');
                String fileName = current.substring(pos+1);
                return fileName.replace("\"", "");
            }
        }
        return null;
    }

• form-data
  
• name
  
• filename
  
  El que nos interesa es filename ya que éste almacena el nombre del archivo enviado. Comprobamos si la subHeader actual comienza con 'filename', si es así,  obtenemos la posición del caracter '=' para obtener todo lo que hay hacia la derecha, que es lo que nos interesa: el nombre del archivo. Por último, reemplazamos las comillas por nada (eliminar) y eliminamos los espacios en blanco al inicio/final del nombre del archivo. El resultado, el nombre del archivo solamente.
  
  Una vez que obtenemos el nombre del archivo asociado a cada part, los escribimos en el directorio especificado por el atributo location, que será D:/uploads:
  
  

  
  part.write(getFileName(part));

  
  
  Por último, verificamos si se han subido  los archivos:
  
  
  
  
  
  Eso es todo. ¿Quién dijo que Java es difícil?

• Patrones de diseño (puedes ver un post en el que puse algunos, está en el foro de Java)
  
• Principios de desarrollo de software (DRY, SRP, KISS, etc).
  
  Lo anterior es vital. Sin eso, dudo que tus aplicaciones sean eficientes, y no lo digo desde el punto de vista de funcionalidad, porque puede funcionar correctamente, pero, ¿qué pasa si el cliente pide ampliar funcionalidad?, ¿crees que un código mal escrito te permita escalabilidad? Por supuesto que NO, y aquí es donde vienen a tallar los puntos anteriores.
  
  Ahora, respecto a la interfáz gráfica, te recomiendo que te vayas con JavaFX. JavaFX te provee un patrón MVC en el cual te obliga a delegar responsabilidades. Ésto es muy bueno ya que, te exige un código mantenible.
  
  La parte gráfica de JavaFX se puede hacer mediante dos formas:
  
  
• Mediante código Java
  
• Mediante FXML (XML)
  
  Mediante código Java
  
  Ésto se usaba en el principio, pero desde que salió FXML se vió relegado por éste. La principal razón de utilizar la segunda forma es que con ésta forma tú eres el responsable de organizar tu aplicación para que sea MVC. Ejemplo:
  
  

  
  import javafx.application.Application;
  import javafx.event.ActionEvent;
  import javafx.event.EventHandler;
  import javafx.scene.Scene;
  import javafx.scene.control.Button;
  import javafx.scene.layout.StackPane;
  import javafx.stage.Stage;
  
  public class MiPrograma extends Application {
      @Override
      public void start(Stage stage) {
  	Button btn = new Button("Click me!");
  	btn.setOnAction(new EventHandler<ActionEvent>() {
  	    @Override
  	    public void handle(ActionEvent event) {
  		System.out.println("Hola mundo!");
  	    }
  	});
  	StackPane root = new StackPane();
  	root.getChildren().add(btn);
  	Scene scene = new Scene(root, 300, 250);
  	stage.setTitle("Demo JavaFX para Underc0de");
  	stage.show();
      }
      public static void main(String[] args) {
  	launch(args); // llama internamente a start
      }
  }

  
  
  Mediante código FXML
  
  

  
  <?xml version="1.0" encoding="UTF-8"?>
  
  <?import javafx.scene.effect.*?>
  <?import javafx.scene.image.*?>
  <?import javafx.geometry.*?>
  <?import javafx.scene.text.*?>
  <?import javafx.scene.control.*?>
  <?import java.lang.*?>
  <?import javafx.scene.layout.*?>
  
  <AnchorPane prefHeight="443.0" prefWidth="908.0" stylesheets="@css/style.css" xmlns="http://javafx.com/javafx/8" xmlns:fx="http://javafx.com/fxml/1" fx:controller="me.localtest.customersapp.controllers.MainController">
     <children>
         <!-- aquí pueden ir botones, tablas, textfields, ect -->
         <Button fx:id="btnGreet" text="Click me!" layoutX="100" layoutY="35" onAction="greetAction"/>
     </children>
  </AnchorPane>

  
  
  Fíjate en los atributos stylesheets y fx:controller. El primer atributo, hace referencia a un archivo de estilos (si has trabajado en web, lo sabrás). Ésto es muy bueno, ya que, le puedes dar el estilo que tú deseas a tu aplicación. El segundo atributo, especifica el controlador para esa vista. Debe ser su ruta completa, con todo y paquetes separados por puntos (.).
  
  Ahora fíjate en el botón que hemos definido, tiene los siguientes atributos:
  
  
• fx:id: Este es su identificador único (igual que el id de html). Por medio de éste id se le ubicará en el contexto de la aplicación.
  
• layoutX/layoutY: Esto sirve para ubicarlos dentro de las dimensiones de la stage (ventana).
  
• text: Texto del botón.
  
• onAction: Método que se ejecutará cuando se pulse el botón.
  
  Teniendo ésto claro, hagamos el controlador que se verá así:
  
  

  
  public class MainController {
      @FXML Button btnGreet;
  	
      @FXML
      private void greetAction() {
  	System.out.println("Hola mundo!");
      }
  }

  
  
  Si recuerdas, el botón en el FXML se llamaba btnGreet, acá solo lo jalamos. Ésto es lo poderoso de JavaFX, que gestiona las dependencias por nosotros (CDI para Java EE), lo que se conoce como Inyección de dependencias. Localizamos el botón mediante la anotación @FXML. Ahora, en el FXML, pusimos que cuando se pulse el botón se ejecutaría un método llamado greetAction, que como ves está definido. También puedes especificar el parámetro ActionEvent por si se requiere.
  
  Conclusión
  
  En conclusión, te recomiendo a ojos vendados JavaFX. Sus ventajas sobre Swing son demasiadas (incluso, es el reemplazo de Swing, que muy posiblemente en un futuro sea marcada como deprecated).
  
  
• Inyección de dependencias.
  
• Modularización mediante MVC.
  
• Internamente, un código mejor que Swing.
  
• Soporte para CSS
  
• ...
  
  Recursos
  
  Afortunadamente, no necesitas escribir tú el código FXML. Tú solo arrastras los controles y JavaFX Scene Builder genera todo el código FXML por tí.
  
  Enlace de descarga: No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
  
  Puedes seguir un tutorial de JavaFX en español (click en la imagen):
  
  
  No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

CitarTodo el código fuente está en Github: No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

• CDN de fontawesome
  
• normalize
  
• prefixfree (opcional)
  
  ESTRUCTURA
  
  La estructura del proyecto será la siguiente:
  
  
  
  
  MARCADO HTML
  
  El marcado HTML es realmente muy sencillo. Solo necesitamos crear un wrapper con dos botones, los cuales serán anterior y siguiente:
  
  

  
  <section class="slider" data-img-folder="img/">
      <button class="prevBtn"><i class="fa fa-2x fa-chevron-left"></i></button>
      <button class="nextBtn"><i class="fa fa-2x fa-chevron-right"></i></button>
      <img src="img/img1.jpg" alt="Image one" class="img" style="right: 0%"/>
  </section>

  
  
  Como vemos, el slider será el container y tendrá 2 botones que tienen un ícono (font awesome), que es una flecha en cada dirección. Además, por defecto  añadimos una imagen. El atributo data-img-folder contiene la ruta del folder que contiene las imágenes, en mi caso, img. Ahora pasemos a darle look and feel.
  
  CSS
  
  

  
  html {
    box-sizing: border-box;
  }
  *, *::before, *::after {
    box-sizing: inherit;
  }
  .slider {
    border-radius: 4px;
    box-shadow: 0 15px 25px rgba(0,0,0,.15),
      0 25px 60px rgba(0,0,0,.25);
    display: block;
    height: 360px;
    margin: 30px auto;
    overflow: hidden;
    position: relative;
    width: 650px;
  }

  
  
  El slider tendrá unas dimensiones de 650px x 360px. La posición será relativa para que los botones se puedan ubicar bien. Tiene una sombra y un overflow: hidden. El overflow: hidden lo que hará es ocultar cuando su contenido se desborde. Esto lo hacemos así, porque las imágenes estarán a la derecha del slider, y con una suave transición, se mueven hacia la izquierda ocupando el tamaño del slider o viceversa (izquierda a derecha y derecha a izquierda).
  
  Las imágenes tendrán unos estilos básicos:
  
  

  
  .slider .img {
    display: block;
    height: 100%;
    position: absolute;
    transition: all .6s ease-in-out;
    width: 100%;
  }

  
  
  Como ya habíamos dicho, las imágenes ocuparan todo el ancho y alto del slider. También tiene una posición absoluta para que se puedan desplaza hacia la derecha o izquierda fuera del slider, Por último, tiene un transition, para que el deslizamiento de derecha a izquierda o viceversa sea suave y con una duración de 0.6 segundos.
  
  Las imágenes podrán estar a la izquierda o derecha, de acuerdo al botón que se presione:
  
  

  
  .slider .img.left {
    left: -100%;
  }
  .slider .img.right {
    right: -100%;
  }

  
  
  Por último, hay que darle estilizar los botones de control:
  
  

  
  .slider > .prevBtn, .slider > .nextBtn {
    background-color: transparent;
    border: none;
    color: rgba(250,250,250,.8);
    outline: none;
    position: absolute;
    top: calc(50% - 25px);
    z-index: 1;
  }
  .slider > .prevBtn {
    left: 10px;
  }
  .slider > .nextBtn {
    right: 10px;
  }

  
  
  Los botones no tendrán borde ni fondo (transparente). Tienen una posición absoluta lo que nos permitirá centrarla con la propiedad top, que tiene un cálculo de 50% - 25px que es el tamaño estimado de los botones. También, estarán a 10px de los lados izquierdos y derechos respectivamente.
  
  JAVASCRIPT
  
  Para éste propósito, y aprovechando las bondades de EcmaScript 6, vamos a crear una clase llamada Slider, que represente al objeto, como en la POO que todos conocemos.
  
  Vayamos primero por el constructor:
  
  

  
  'use strict'
  class Slider {
    constructor(el) {
      this.slider = el
      this.prevBtn = el.querySelector('.prevBtn')
      this.nextBtn = el.querySelector('.nextBtn')
      this.images = []
      this.current = 0
      this.url = this.slider.getAttribute('data-img-folder')
      this.init()
    }

  
  
  El constructor recibe un parámetro, éste será el slider que hemos definido en el HTML. A partir de él, obtenemos los botones anterior y siguiente que controlarán el flujo del slider. También inicializamos la variable images como array y current con 0, que indicará la posición de la imagen actual dentro del array; también obtenemos la ruta del folder de las imágenes por medio del atributo especificado en el marcado HTML. Por último, llamamos al método init que vamos a describir a continuación:
  
  

  
  init() {
      this.prevBtn.addEventListener('click', function() {
        this.loadPrevImg()
      }.bind(this))
      this.nextBtn.addEventListener('click', function() {
        this.loadNextImg()
      }.bind(this))
      this.loadImages()
  }

  
  
  Lo único que hace el método init es escuchar por eventos click a cada botón y llamar a los métodos, loadPrevImg() y loadNextImg(). Por último, llamamos a loadImages(). Veamos que hace éste último método:
  
  

  
  loadImages() {
      let self = this;
      let imgUrls = [];
      let http = new XMLHttpRequest()
      http.open('GET', this.url, false)
  
      http.onload = function() {
        if(http.status === 200) {
          let html = document.createElement('html')
          html.innerHTML = this.response
          let links = html.querySelectorAll('a')
          for(let i=0; i<links.length; i++) {
            let content = (links[i].innerText).trim()
            if(self.isValidImg(content)) {
              imgUrls.push(self.url+content)
            }
          }
        } else {
          console.log('error: '+http.response)
        }
      }
      http.send()
      this.createImagesBlob(imgUrls)
  }

  
  
  Lo primero que hacemos es crear un objeto XMLHttpRequest para hacer una llamada AJAX. Abrimos la llamada con la ruta que especificamos en el atributo data-img-folder.
  
  Si la petición ha sido exitosa, creamos todo un documento html, ésto es, porque la petición a un folder, trae un documento html con cada elemento en un link (lo hace el browser). Por eso 'parseamos' el texto devuelto en un elemento tipo html para poder obtener los links y la ruta de la imagen allí embebida.
  
  Primero, obtenemos los links y los iteramos. Por cada link obtenemos el texto que tiene y le borramos los espacios con trim(). Luego, verificamos si contiene la extensión jpg, jpeg, png, o gif y si es cierto la añadimos al array de rutas de imágenes para luego precargarlas en blobs.
  
  El método para determinar su el objeto actual es válido es isValidImg:
  
  

  
  isValidImg(file) {
      let suffixes = ['.jpg', '.jpeg', '.png', '.gif']
      for(var i=0; i<suffixes.length; i++) {
          if(endsWith(file, suffixes[i])) {
            return true
          }
      }
      function endsWith(str, suffix) {
        return str.indexOf(suffix, str.length - suffix.length) !== -1;
      }
      return false
  }

  
  
  Aquí simplemente itera un array de sufijos de imágenes y verifica si el elemento pasado finaliza con algunas de esas extensiones. Si es así, se trata de una imagen y devolvemos una bandera de luz verde.
  
  Para crear blobs que representen a las imágenes, tenemos que hacer una llamada ajax por cada url de imagen y convertirla a blob. También es necesario, especificar que se devolverá un blob con la instrucción: http.responseType = 'blob':
  
  

  
  createImagesBlob(imgUrls) {
      let self = this;
      for(let i=0; i<imgUrls.length; i++) {
        let http = new XMLHttpRequest()
        http.responseType = 'blob'
        http.open('GET', imgUrls[i], true)
        http.onload = function() {
          if(this.status === 200) {
            self.images.push(window.URL.createObjectURL(this.response))
          }
        }
        http.send();
      } // end for
    }

  
  
  Lo único que hacemos en el punto anterior es, hacer una llamada AJAX por cada ruta de imagen y especificar que se deve devolver un blob. Luego, creamos el blob con createObjectURL de la constante URL de window.
  
  Sigamos con los métodos loadPrevImg y loadNextImg:
  
  

  
  loadPrevImg() {
      let self = this
      this.current = (this.current > 0) ? this.current - 1 : this.images.length - 1
      let img = this.createImage('left')
      this.slider.appendChild(img)
  
      setTimeout(function() {
        img.style.left = '0%'
        // 600 = .6s of slide animation
        setTimeout(function() {
            self.removeBefore(img)
        }, 600)
      },30)
    }
    loadNextImg() {
      let self = this
      this.current = (this.current < this.images.length - 1) ? this.current + 1 : 0
      let img = this.createImage('right')
      this.slider.appendChild(img)
  
      setTimeout(function() {
        img.style.right = '0%'
        // 600 = .6s of slide animation
        setTimeout(function() {
          self.removeBefore(img)
        }, 600)
      }, 30)
    }

  
  
  Los métodos son muy parecidos (tarea, si quieres modulariza). En primera instancia, comprobamos si el índice está dentro del rango, si no, reseteamos (caso siguiente) o volvemos a la última imagen (caso anterior). Luego llamamos al método llamado createImage y le pasamos dos tipos de parámetros: left y right (ya lo veremos a continuación). Éste método crea un elemento IMG, le asigna la ruta de la imagen actual y retorna el elemento.
  
  Una vez que ha retornado la imagen, le asignamos la propiedad left o right a 0%. Ésto lo que hará es mover la imagen de afuera hacia dentro del slider con la duración y transición que le hemos dado via CSS (¿recuerdas el transition: all .6s ease-in-out?). Por último, una vez que la imagen se ha mostrado, eliminamos la anterior creada. Importante, si no, agregarías la misma imagen una y otra vez y el HTML se haría enorme.
  
  Veamos el método createImage:
  
  

  
  createImage(side) {
      let img = document.createElement('img')
      img.src = this.images[this.current]
      img.classList.add('img')
      if (side === 'right') {
        img.classList.add('right')
      } else {
        img.classList.add('left')
      }
      return img
    }
  

  
  
  Simplemente creamos un elemento IMG y le asignamos la ruta de la imagen a mostrar. Aquí viene algo importante:
  
  
• El parámetro es left: la imagen se deslizará de izquierda a derecha.
  
• El parámetro es right: la imagen se deslizará de derecha a izquierda.
  
  Ahora veamos el método removeBefore:
  
  

  
  removeBefore() {
      let child = this.slider.querySelector('img');
      this.slider.removeChild(child);
  }

  
  
  Este método es sencillo. Obtenemos el primer elemento tipo img del slider (que será el elemento img creado antes del nuevo) y lo removemos. De ésta manera siempre habrá solo un elemento img. Problemas de rendimiento, creo que ninguno, porque el manejo del DOM será de 2 cambios para 5 segundos.
  
  Por último, una función para ponerlo en modo automático en caso quiera el usuario:
  
  

  
  setModeAuto() {
      setInterval(function() {
        this.loadNextImg()
      }.bind(this), 5000)
  }

  
  
  

  ---

  
  
  
  No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
  
  PD: Disculpen el delay al cargar las imágenes al principio. Lo que pasa es que Github no permite CORS y no pude obtener las imágenes como blob. En local, works like a charm.