Agora sim, SCEA 5

Passei na prova do SCEA 5!!!!!

Definitivamente, foi uma prova pesadisima.

Estudei pelos seguintes livros:
Sun Certified Enterprise Architect for Java EE Study Guide (2nd Edition)
Design Patterns: Elements of Reusable Object-Oriented Software
Core J2EE Patterns: Best Practices and Design Strategies

Agora, é partir para o projeto do SCEA

Passei na SCBCD 5

Passei na SCBCD 5!!!!!!

Sem dúvida foi o exame que deu mais trabalho para estudar (em relação a SCJP e SCWCD).

Usei o livro Enterprise JavaBeans 3.0 5th edition de Richard Monson e Bill Burke .

Quebrando o java.util.Properties

A classe java.util.Properties foi concebida como um mapa de chave e valores de String, contudo, existe uma falha na construção da classe que permite violar a coesão.

Na API do Properties podemos observar que ela é uma java.util.Hashtable e pela herança podemos usar os métodos get(V key) e set(V key, K value) para inserir objetos que não são String. Isso é um problema de Design da classe. Segundo Joshua Bloch, quando os desenvolvedores da Sun Microsystems perceberam o problema já era tarde demais, pois, muitas aplicações já dependiam dessa herança.

Acredite, usando a imaginação podemos usar esse fato para quebrar uma aplicação

Por que o orkut conta errado?

Se você tem orkut já deve ter reparado que ele retorna algumas informações erradas no que se refere a contagem.

Hoje estava vendo um perfil e vi que o número de fotos marcadas estava em 4 quando na realidade haviam 5. Pensei:
"Como um sistema desse conta errado? Afinal, é só dar um SELECT com COUNT".

Mas aí, saquei, ele não conta errado...o orkut SIMPLESMENTE NÃO CONTA!!!!!

Isso mesmo, acredito o que vemos ali é um cache.

Como o sistema tem muitos usuários que fazem muitos acessos eles devem ter tido problemas de desempenho. Assim, as informações que não são vitais para a usabilidade do sistema (como o número de fotos marcadas) não são atualizadas em tempo real.

Memory Leaks por referência obsoleta.

Esse post tem como fonte original o livro "Effective Java" - second edition de Joshua Bloch.

Quando entramos no mundo do Java temos a sensação que não devemos nos preocupar com o recolhimento de memória, pois, existe o Garbage Collector. Contudo, isso não é bem verdade. Veja o código do link abaixo:

Stack

A classe stack é muito conhecida pelos programadores e pergunto, você seria capaz de identificar um memory leak (vazamento de memória)?

Quando damos um pop na pilha ele decrementa o size do array dando a impressão de que o objeto foi removido. Contudo, ele ainda está lá e nem é elegível ao Garbage Collector. Apesar do size truncar o tamanho da pilha o objeto ainda existe na memória. Se você fizer size++; ele ainda estará lá e você conseguirá acessa-lo.

Então, para remover essa referência obsoleta faça:
public Object pop() {
if (size == 0) {
throw new EmptySizeException();
}
Object result = elements[--size];
elements[size] = null;

return result;
}

Vale lembrar que isso não garante o recolhimento do objeto, veja o código abaixo:

Stack st;
...
Object ob = st.pop();
...

Apesar, da pilha destruir a referência ao objeto que é retornado do método pop, uma nova referência é criada para ele. Contudo, ainda vale apena aterrar a referência dentro do array.