Existem algumas maneiras de implementar o Singleton. A maneira mais comum é a seguinte:

public class SingletonUm {
	private static final SingletonUm instance = new SingletonUm();
	private SingletonUm() {
	}
	public static SingletonUm getInstance() {
		return instance;
	}
}

O construtor privado (linha 3) impossibilita a criação de novas instâncias, pois, por ser privado, só pode ser referenciado dentro da mesma classe. O método getInstance() (linha 5) fornece o acesso à instância criada na linha 2. Ele é estático para poder ser acessado sem ter a instância (já que o construtor é privado e queremos que a instância seja única). Então para obtermos acesso à classe é só chamar: SingletonUm.getInstance();

O problema dessa abordagem é que se não formos utilizar a instância ou se formos utilizar ela posteriormente, a aplicação terá um objeto desnecessário em memória. Então para termos uma instanciação tardia, devemos adotar outra abordagem. Outra implementação bastante comum é a seguinte:

public class SingletonDois {
	private static SingletonDois instance;
	private SingletonDois() {
	}
	public static SingletonDois getInstance() {
		if (instance == null) {
			instance = new SingletonDois();
		}
		return instance;
	}
}

Com essa verificação  a instância só será criada após chamado o método getInstance(). Para torná-lo thread-safe, é só colocar o modificador synchronized no método. O problema dessa inclusão é o gargalo que teremos ao transformar o método em synchronized, além de outros possíveis problemas. Nesse link tem maiores descrições desses problemas. Para resolver, o Bill Pugh (um dos autores do artigo citado), desenvolveu a seguinte solução:

public class SingletonBillPugh {
	private SingletonBillPugh() {
	}
	private static class SingletonHolder {
		public static final SingletonBillPugh instance = new SingletonBillPugh();
	}
	public static SingletonBillPugh getInstance() {
		return SingletonHolder.instance;
	}
}

Baseado no modelo de inicialização do Java, o código da linha 05 só é chamado após a invocação do método getInstance() (linha 07). Dessa maneira garantimos instanciação tardia e o código ser thread-safe.

Outra maneira mais elegante de se fazer Singleton é o citado no livro Effective Java:

public enum SingletonEnum {
	INSTANCE;
	// Operações do Enum aqui!
}

O enum não pode ser instanciado, só tem uma instância única, que é o nosso Singleton. O único problema dessa abordagem é que temos alguns limitantes no enum, como a impossibilidade de se fazer herança e não temos instanciação tardia.

As dúvidas agora permanecem quando utilizar uma solução ou outra. Minha recomendação é a seguinte. Se não é necessário ter inicialização tardia, utilizar a solução SingletonEnum, desde que a classe alvo não tenha problemas com os limitantes do enum, caso contrário, utilizar a solução SingletonUm. Se é necessário ter instanciação tardia utilizar a solução SingletonBillPugh, desde que não seja necessário realizar tratamento de erros ao chamar o getInstance(), caso contrário, utizar a solução SingletonDois.

Primeiro eu busco por arquivos JAR recursivamente:

	protected void searchForJars(File path, List<String> resultado) {
		for (File f : path.listFiles(filter)) {
			if (breakIfFound && found)
				return;
			if (f.isDirectory()) {
				searchForJars(f, resultado);
			} else {
				List<String> res = searchInsideJar(f);
				if (res != null) {
					resultado.addAll(res);
					found = true;
				}
			}
		}
	}

Se eu encontrar um arquivo JAR, eu busco dentro dele a informação que eu quero:

	protected List<String> searchInsideJar(File f) {
		List<String> resultado = null;
		try {
			JarFile jar = new JarFile(f);
			Enumeration<JarEntry> entries = jar.entries();
			while (entries.hasMoreElements()) {
				String entry = entries.nextElement().getName();
				if (entry.contains(classToFind)) {
					if (resultado == null) {
						resultado = new ArrayList<String>();
					}
					resultado.add(f.getPath() + ":" + entry);
					if (breakIfFound) {
						return resultado;
					}
				}
			}
		} catch (IOException e) {
			e.printStackTrace();
		}
		return resultado;
	}

Se eu encontrar algum arquivo que tenha a String que eu quero, adiciono o resultado numa lista. Para quem só precisa do utilitário, vou disponibizá-lo aqui. Para usar é necessário Java 7 e depois é só digitar:

 java -jar thiago-vespa-utils-classfinder.jar <CAMINHO> <CLASSE COMPLETA OU TRECHO> <BREAK>

Por exemplo:

 java -jar thiago-vespa-utils-classfinder.jar /opt/Oracle111150/Middleware/Oracle_SOA1/soa/modules Record

Ou

 java -jar thiago-vespa-utils-classfinder.jar /opt/Oracle111150/Middleware/Oracle_SOA1/soa/modules oracle.tip.adapter.api.record.RecordElement break

O break serve para informar que é para parar ao encontrar o primeiro. Se não digitar break ele vai encontrar todas as referências da classe especificada.

Nas versões anteriores de Java quando queríamos relançar os erros ocorridos fazíamos da seguinte maneira:

	public void metodoQueLancaExcecao() throws AException, BException {
		try {
			int a = 0;
			if (a == 0) {
				throw new AException();
			} else {
				throw new BException();
			}
		} catch (AException e) {
			throw e;
		} catch (BException e) {
			throw e;
		}
	}

Ou quando tínhamos  várias possíveis exceptions, podíamos capturar com uma mais genérica e relançar ela. Por exemplo:

	public void metodoQueLancaExcecao() throws Exception {
		try {
			int a = 0;
			if (a == 0) {
				throw new AException();
			} else {
				throw new BException();
			}
		} catch (Exception e) {
			throw e;
		}
	}

O problema dessa última solução é que o tratamento da classe que chama esse método se torna pior, pois não sabemos qual erro poderá ocorrer, e na primeira solução se tivermos um número muito grande de exceções a serem re-lançadas o código se torna extenso. Para resolver esse problema, no Java 7 podemos fazer da seguinte maneira:

	public void metodoQueLancaExcecao() throws AException, BException {
		try {
			int a = 0;
			if (a == 0) {
				throw new AException();
			} else {
				throw new BException();
			}
		} catch (Exception e) {
			throw e;
		}
	}

Esse código não compila no Java 6 e inferiores, pois o compilador irá informar que a exceção Exception não está sendo tratada. No Java 7 ele “percebe” que as única exceções que estão sendo lançadas são a AException e a BException e portanto não obriga o tratamento de nenhuma outra.

Entretanto esse novo recurso pode trazer problemas de incompatibilidades na compilação de códigos feitos nas outras versões de Java, por exemplo:

	public void metodoQueLancaExcecao() throws A {
		try {
			throw new FilhaDeA();
		} catch (A e) {
			try {
				throw e;
			} catch (OutraFilhaDeA anotherException) { // Não alcançável
				System.out.println("Deu pau!");
			}
		}
	}

Esse código compila na versão Java 6 e inferiores, mas não compila na versão 7. Isso pra mim é um perigo muito grande. Pois no Java 7 o último catch nunca será executado, pois eu sei que o “throw e” é do tipo FilhaDeA e como o tratamento é mais preciso, eu sei que nunca vou capturar erros do tipo OutraFilhaDeA. Já no Java 6 e inferiores isso não ocorre (eu posso tratar erros mais específicos).

Segundo a especificação do Project Coin/JSR 334:

An examination of millions of lines of code in a diverse set of projects, including dozens of members of the Qualitas Corpus and the JDK, found no instances where these conditions occurred.

Ou seja, eles nunca encontraram código em que isso ocorria. Se por acaso ao tentar compilar um programa existente do Java 6 ou inferior em Java 7 e tiver um erro parecido com esse:

Unreachable catch block for OutraFilhaDeA. This exception is never thrown from the try statement body

Já sabe o que pode ser.

Na prática, a gente transforma código assim:

		List<String> listaStringDiamante = new ArrayList<String>();
		Map<String, Integer> dicionario = new HashMap<String, Integer>();

Em código assim:

		List<String> listaStringDiamante = new ArrayList<>();
		Map<String, Integer> dicionario = new HashMap<>();

Você pode se perguntar, mas antes eu podia fazer assim:

List<String> listaString = new ArrayList();

Para demonstrar que isso é um problema, veja o seguinte código:

		List<String> listaString = new ArrayList();
		listaString.add("String");
		List<Integer> listaInteger = new ArrayList(listaString); // Sem uso de diamante
		List<Integer> listaIntegerDiamante = new ArrayList<>(listaString); // Com uso de diamante

Na linha 3 o compilador permite a inclusão de uma lista de String em uma lista de Integer. Já no caso do operador diamante o compilador infere que o novo ArrayList criado é do tipo Integer e portanto no construtor do generics só vai aceitar coleções que tenham elementos que herdam de Integer. Então na linha 4 temos um erro de compilação. Dessa forma evitamos códigos incorretos!

Outros exemplos possíveis:

		List<?> listaDeAlgo = new ArrayList<>();
		List listaSemGenerics = new ArrayList<>();

O último exemplo não é recomendado, mas é possível. Um outro ponto, é que não podemos utilizar o operador diamante em classes anônimas. Sem operador diamante isso é possível, por exemplo:

		new List<String>() {
		...
		}

Só implementar os métodos necessários para o List e a classe anônima funcionará corretamente. O mesmo não é possível com operador diamante:

		new List<>() {
		...
		}

Nesse caso temos um erro de compilação.

Pontos importantes:

1. Não pode ser utilizado em classe anônima, pois é impossível inferir os tipos.
2. Você pode colocar espaços no operador diamante, mas por questão de estilo não é recomendado.

		try {
			System.out.println(10 / 0);
		} catch (ArithmeticException e) {
			System.out.println("Erro: " + e.getMessage());
		} catch (IllegalArgumentException e) {
			System.out.println("Erro: " + e.getMessage());
		} catch (ArrayIndexOutOfBoundsException e) {
			System.out.println("Erro: " + e.getMessage());
		}

No seguinte código:

		try {
			System.out.println(10 / 0);
		} catch (ArithmeticException | IllegalArgumentException | ArrayIndexOutOfBoundsException e) {
			System.out.println("Erro: " + e.getMessage());
		}

Pontos importantes:

1. A variável declarada dentro do catch é sempre final. Ou seja, não podemos atribuir valores à ela.
2. Como nas outras versões do Java, as variáveis dentro do catch precisam ser filhas de Throwable
3. Se mais de uma variável for declarada, elas não podem ser do mesmo subtipo da outra. Por exemplo: se A está declarada FilhaDeA (extends A) não pode ser declarada no mesmo catch.

Portanto o seguinte código não compila:

		try {
			int a = 0;
			if(a==0) {
				throw new FilhaDeA();
			} else {
				throw new A();
			}
		} catch (FilhaDeA | A e) {
			System.out.println("Erro: " + e.getMessage());
		}

Como FilhaDeA é filha da classe A (extends A), todas as exceções do tipo A (inclusive FilhaDeA) já são capturadas com a declaração de A no catch. Por esse motivo o código não é compilável.

Dessa maneira o tratamento de erros se torna mais simplificado e melhora a legibilidade de código.

Antes do Java 7, para ler um arquivo tínhamos que fazer o seguinte:

		BufferedReader br = null;
		try {
			br = new BufferedReader(new FileReader("teste.txt"));
			String txt = null;
			while ((txt = br.readLine()) != null) {
				System.out.println(txt);
			}
		} catch (FileNotFoundException e) {
			e.printStackTrace();
		} catch (IOException e) {
			e.printStackTrace();
		} finally {
			if(br!=null) {
				try {
					br.close();
				} catch (IOException e) {
					e.printStackTrace();
				}
			}
		}

Com o uso do try-with-resources, podemos eliminar o “fechamento” do arquivo:

		try (BufferedReader br = new BufferedReader(new FileReader("teste.txt"))) {
			String txt = null;
			while ((txt = br.readLine()) != null) {
				System.out.println(txt);
			}
		} catch (FileNotFoundException e) {
			e.printStackTrace();
		} catch (IOException e) {
			e.printStackTrace();
		}

Dentro dos parênteses do try devemos colocar a declaração de uma ou mais variáveis de classes que implementam a interface AutoCloseable. Para garantir que isso funciona, vamos criar uma classe que implementa a interface AutoCloseable:

public class AutoFechavel implements AutoCloseable {
	@Override
	public void close() throws Exception {
		System.out.println("Fechou!!!");
	}
}

Agora vamos colocá-la dentro do novo try:

package br.com.thiagovespa.sample.java7;
public class TryWithResources {
	public static void main(String[] args) {
		try (AutoFechavel af = new AutoFechavel()) {
			System.out.print("Ahh eu aqui. ");
		} catch (Exception e) {
			e.printStackTrace();
		}
	}
}

A saída desse código será: “Ahh eu aqui. Fechou!!!”. Demonstrando que após finalizar o bloco try, o método close() é chamado automaticamente.

Podemos também ter duas ou mais variáveis dentro do try. Juntando os dois exemplos, temos:

		try (AutoFechavel af = new AutoFechavel();
				BufferedReader br = new BufferedReader(new FileReader(
						"teste.txt"))) {
			System.out.print("Ahh eu aqui. ");
			String txt = null;
			while ((txt = br.readLine()) != null) {
				System.out.println(txt);
			}
		} catch (Exception e) {
			e.printStackTrace();
		}

Como as classes antigas também foram modificadas para implementar a interface AutoCloseable, podemos também utilizar essa funcionalidade em classes que realizam conexão com o banco (ResultSet, PreparedStatement, Connection, …) e com isso nossa vida fica bem mais fácil!

Pontos importantes:

1. As variáveis declaradas dentro do try-with-resources são marcadas como final.
2. A classe da variável declarada deve implementar a interface AutoCloseable
3. O escopo da variável é somente dentro do bloco try (completo)
4. As variáveis tem que ter nomes diferentes se estiverem dentro de um mesmo bloco try
5. Os recursos são iniciados da esquerda pra direita (de acordo com a declaração) e são fechados da direita pra esquerda.
6. Se o recurso for nulo ele não é fechado
7. Se um recurso lançar exceção ao fechar, os outros recursos continuarão a serem fechados (exceção suprimida).
8. Quando as exceções forem suprimidas, você pode recuperá-las utilizando o método: Throwable.getSuppressed()(normalmente dentro do catch)

Um dos problemas comum é atribuir um novo valor para a variável utilizada dentro do try-with-resources:

		try (BufferedReader br = new BufferedReader(new FileReader("teste.txt"))) {
			String txt = null;
			while ((txt = br.readLine()) != null) {
				System.out.println(txt);
			}
			br = new BufferedReader(new FileReader("novoArquivo.txt"));
		} catch (Exception e) {
			e.printStackTrace();
			if (e.getSuppressed() != null) {
				for (Throwable t : e.getSuppressed()) {
					t.printStackTrace();
				}
			}
		}

Na linha 6 estamos atribuindo para uma variável final. Isso vai ocasionar erro de compilação. Na linha 10 temos um exemplo de como recuperar as exceções suprimidas.

Pontos importantes:

1. O underscore não pode aparecer imediatamente após 0x, 0X , 0b ou 0B
2. O underscore não pode aparecer antes do primeiro dígito e nem após o último dígito
3. Um número binário começa sempre com 0B ou 0b e só aceita valores 0 e 1 (binário, duh! )
4. A utilizar o P, p , E ou e para representação com expoente (binário e decimal), pode-se utilizar underscore, mas seguindo a regra 2 para o expoente.

Exemplo de números válidos:

		int n1 = 1234_5678;
		long n2 = 1_2_3_4__5_6_7_8L;
		int n3 = 0b0001_0010_0100_1000;
		double n4 = 3.141_592_653_589_793d; // PI
		double n5 = 0x1.ffff_ffff_ffff_fP1_023; // Double.MAX_VALUE

Exemplo de números inválidos

		int n6 = _1234;
		int n7 = 0x_1234;
		int n8 = 1234_;
		int n9 = 0x1.0_p_-1022;
		int n10 = 0b12;

A linha 1 quebra a regra 2, pois está iniciando com underscore. A linha 2 quebra a regra 1, pois o inderscore está logo após o 0x. A linha 3 quebra a regra 2 pois o underscore está após o último dígito. A linha 4 quebra a regra 2 e a regra 4, pois o underscore está após o último dígito e antes do primeiro do expoente. A linha 5 quebra a regra 3, pois aparece o número 2 que não faz parte dos números binários.

Essa alteração no Java 7 ajuda na legibilidade do código, principalmente para trabalhar com valores grandes (p. ex: 1_000_000_000 – um bilhão) ou com números binários.

Pontos importantes:

1. É proibido o uso de null nas cláusulas case
2. O uso de null na verificação do switch irá gerar um NullPointerException
3. Os elementros utilizados nas cláusulas case tem que ter o modificador final
4. Não é permitido valores duplicados no case

Exemplo de código correto:

		String nome = "Thiago";
		final String SOBRENOME = "Vespa";
		switch (nome) {
		case "Thiago":
			System.out.println("Esse é o meu primeiro nome!");
			break;
		case "Galbiatti":
			System.out.println("Esse é o meu nome do meio!");
			break;
		case SOBRENOME:
			System.out.println("Esse é o meu sobrenome!");
			break;
		default:
			System.out.println("Não sei o que é isso!");
		}

Exemplo de código não compilável ao utilizar null no case:

		String nome = "Thiago";
		final String SOBRENOME = "Vespa";
		switch (nome) {
		case "Thiago":
			System.out.println("Esse é o meu primeiro nome!");
			break;
		case "Galbiatti":
			System.out.println("Esse é o meu nome do meio!");
			break;
		case SOBRENOME:
			System.out.println("Esse é o meu sobrenome!");
			break;
		case null:
			System.out.println("Null não pode!");
			break;
		default:
			System.out.println("Não sei o que é isso!");
		}

Exemplo de código que gera um NullPointerException:

		String nome = null;
		final String SOBRENOME = "Vespa";
		switch (nome) {
		case "Thiago":
			System.out.println("Esse é o meu primeiro nome!");
			break;
		case "Galbiatti":
			System.out.println("Esse é o meu nome do meio!");
			break;
		case SOBRENOME:
			System.out.println("Esse é o meu sobrenome!");
		default:
			System.out.println("Não sei o que é isso!");
		}

Exemplo de código não compilável por não possuir o modificador final e ser utilizado no case:

		String nome = "Thiago";
		String SOBRENOME = "Vespa";
		switch (nome) {
		case "Thiago":
			System.out.println("Esse é o meu primeiro nome!");
			break;
		case "Galbiatti":
			System.out.println("Esse é o meu nome do meio!");
			break;
		case SOBRENOME:
			System.out.println("Esse é o meu sobrenome!");
			break;
		default:
			System.out.println("Não sei o que é isso!");
		}

E por último, exemplo de um código não compilável por ter elementos duplicados no case:

		String nome = "Thiago";
		final String SOBRENOME = "Vespa";
		switch (nome) {
		case "Thiago":
			System.out.println("Esse é o meu primeiro nome!");
			break;
		case "Thiago":
			System.out.println("Esse é o meu primeiro nome novamente!");
			break;
		case SOBRENOME:
			System.out.println("Esse é o meu sobrenome!");
			break;
		default:
			System.out.println("Não sei o que é isso!");
		}

É isso. Agora só usar String no switch.

Como client de Telnet, iremos utilizar a biblioteca Commons Net da Apache. Faça o download nesse site, descompacte-a e localize o jar da biblioteca. Crie um projeto e adicione as duas libs (jars) no classpath (build path no Eclipse e libraries no JDeveloper e Netbeans). Crie um WebService (JAX-WS) conforme o exemplo abaixo:

package br.com.thiagovespa.ws.telnet;
import java.io.IOException;
import java.io.InputStream;
import java.io.PrintStream;
import java.net.SocketException;
import javax.jws.*;
import org.apache.commons.net.telnet.TelnetClient;
@WebService
public class TelnetService {
	private final static String HOST = "192.168.1.100";
	private final static String VALID_CHARS = " :-.,!?+=_'\"|\\/;@#$%&*()[]{}";
	private final static int TIMEOUT = 150000;
	@WebMethod
	public String executeCommand(String user, String password,
			String delimiter, String command, boolean showLogin)
			throws SocketException, IOException {
		if (hasSpecialChar(delimiter)) {
			return "Não utilize caracteres especiais como delimitador. Caracteres válidos: letras, espaço e números e "
					+ VALID_CHARS;
		}
		StringBuilder retorno = new StringBuilder();
		TelnetClient telnet = new TelnetClient();
		telnet.setDefaultTimeout(TIMEOUT);
		telnet.connect(HOST);
		if (!telnet.isConnected()) {
			return "ERRO: Não foi possível conectar na telnet";
		}
		telnet.setSoTimeout(TIMEOUT);
		InputStream in = telnet.getInputStream();
		PrintStream out = new PrintStream(telnet.getOutputStream());
		doLogin(user, password, (showLogin ? retorno : null), in, out);
		write(command, out);
		readValues(delimiter, in, retorno);
		return retorno.toString();
	}
	private void doLogin(String user, String password, StringBuilder retorno,
			InputStream in, PrintStream out) {
		readValues("login: ", in, retorno);
		if (retorno != null) {
			retorno.append("\n");
		}
		write(user, out);
		readValues("Password:", in, retorno);
		if (retorno != null) {
			retorno.append("\n");
		}
		write(password, out);
		readValues(">", in, retorno);
	}
	private void readValues(String endString, InputStream in,
			StringBuilder retorno) {
		try {
			char lastChar = endString.charAt(endString.length() - 1);
			StringBuilder sb = new StringBuilder();
			char ch = (char) in.read();
			while (true) {
				sb.append(ch);
				if (ch == lastChar) {
					if (sb.toString().endsWith(endString)) {
						if (retorno != null) {
							retorno.append(removeSpecialChars(sb.toString()));
						}
						return;
					}
				}
				ch = (char) in.read();
			}
		} catch (Exception e) {
			e.printStackTrace();
			if (retorno != null) {
				retorno.append("\nERRO: ").append(e.getMessage()).toString();
			}
		}
	}
	private void write(String value, PrintStream out) {
		try {
			out.println(value + "\n");
			out.flush();
		} catch (Exception e) {
			e.printStackTrace();
		}
	}
	private boolean isSpecialChar(char ch) {
		if (Character.isLetterOrDigit(ch) || ch == '\n'
				|| VALID_CHARS.indexOf(ch) >= 0)
			return false;
		return true;
	}
	private boolean hasSpecialChar(String str) {
		for (char ch : str.toCharArray()) {
			if (isSpecialChar(ch))
				return true;
		}
		return false;
	}
	private String removeSpecialChars(String str) {
		StringBuilder sb = new StringBuilder();
		for (char ch : str.toCharArray()) {
			if (!isSpecialChar(ch)) {
				sb.append(ch);
			}
		}
		return sb.toString();
	}
}

O serviço recebe como parâmetro cinco informações: o usuário, senha, um delimitador de comando, o comando a ser executado e um booleano para informar se é pra retornar todos os dados ou somente as informações após fazer o login. A conexão com Telnet é feita na linha 22 e 24. Após à conexão efetuada, informamos o usuário e a senha utilizando o método doLogin(). Na linha 48 utilizamos o caracter “>” como delimitador de fim do comando de login. Você pode substituí-lo pelo correspondente no seu server de Telnet.

Na linha 61 e 17 evitamos o uso de caracteres especiais para não termos problemas com o nosso cliente de WebService. Você pode utilizar outro tratamento, por exemplo: utilizar o CDATA ou realizar escape dos caracteres.

Agora é só executar o serviço passando os parâmetros adequados. O importante é passar corretamente o delimitador. Esse campo indica quando terminou a execução de um comando e quando o serviço pode retornar a resposta. Você pode inclusive executar os comandos com parâmetros e utilizar o operador && para executar mais de um comando. Abaixo temos o exemplo de uma requisição:

         usuario
         senha
         FIM
         <![CDATA[ ps && comandoQueImprimiFim ]]>
         false

Com essa execução, a resposta seria:

         ps && comandoQueImprimiFim
   PID  CLS PRI TTY      TIME COMD
  6626   TS  59 pts134   0:00 ps
  5867   TS  70 pts134   0:00 bash
FIM

Aí é só utilizar essa resposta em qualquer outro sistema que posso se comunicar via WebService SOAP.

Para visualizar a estrutura JNDI do WebLogic. Acesse o console (http://IP:PORTA/console) vá em Environment, Servers, selecione o servidor desejado e clique em View JNDI Tree. Está meio escondido, mas pela imagem abaixo fica mais fácil achar:

View JNDI Tree

Irá abrir uma nova janela onde você visualizar toda estrutura JNDI do server selecionado.