Bom dia a todos, o tão sonhado dia chegou, o dia de relatar que passei na prova OCJP6 com 81% de score.
Em primeiro lugar agradecer a Deus e minha esposa Joseane que aguentou meu mal humor quando fazia os mocks e tirava
apenas 50%!, também agradecer a galera do Guj, em especial ao Viny(sei la como ele sabe tanta coisa deve ser de outro mundo) e principalmente a uma pessoa
que me mostrou todo o caminho, incluindo livros e que foi a maior inspiração - Roberto Platz(multi certificado).
Fiz a prova aqui em Curitiba na Softsell, marquei a prova para o dia 25/05/2012 mas não pude fazer, pois quando
sentei em frente a máquina, o servidor estava fora, em função de um apagão na região sul, pois uma máquina cortou a fibra
ótica parando tudo, conclusão, tive que remarcar.
Remarquei a prova para o dia 15, fui curtir o feriado e depois voltei para as revisões e testes(mock).
Comecei a estudar em Janeiro deste ano, já que fui mandado embora em Dezembro da empresa que trabalhava, tenho dois
anos de experiência, sempre trabalhando em Consultorias, mas nestes dois anos foram três delas, e em alguns destes lugares
parece que indiretamente minha qualidade como progamador foi colocada em “dúvida”.
Sendo assim os ultimos meses tem sido difíceis, estou fazendo Pós em Java, e sou casado, e estes resultados nos ultimos empregos não cooperaram muito para minha alto estima, sendo assim tinha dia que eu não tinha animo para estudar, tinha dia que eu virava a noite estudando… mas enfim passar na certificação foi um novo impulso para mim.
Usei o livro da Katy Sierra, o mock da Enthuare, o Test killer, e sempre tirava dúvidas aqui no Guj.
O que tirei de lição com a prova, é que você deve digitar muitos códigos, testar as questões que você erra nos testes, e o principal, ler o livro com muita calma, eu li o livro duas vezes, e na segunda estava entojado, percebi que você deve ler o livro com calma, escrever todos os códigos, e realmente fazer o seu resumo, vou falar de novo, faça o
seu resumo!. Digo isso por que eu sofri muito por ler o livro deitado as vezes… não anotar os pontos, dae quando ia fazer os testes não lembrava dos detalhes…, na Segunda vez eu anotei os pontos, e digitei os codigos… aquela imagem no Eclipse do x(erro) no canto e a mensagem de erro fica na sua cabeça.
Bom, eu sei o que todo mundo quer é saber o que mais caiu né…
Caiu muito, mas muito mesmo código envolvendo casting, ou seja o cara dava la um monte de classe uma herdando a outra implementando Interface, e depois coloca um monte de atribuição fazendo casting de tudo que e lado e perguntava:
Qual linha vai dar ClassCastingException?
Se retirarmos a linha tal vai compilar?
Se retirarmos mais de uma linha vai compilar?
Caiu também umas coisas, que acho que não tem no livro da Katy, por exemplo o que acontece se voce fizer
File dir = new dir("dir");
File f = new File(dir, "texte.txt");
e o diretório dir estiver “empty”?
Vai compilar?, vai criar um arquivo “texte.txt” em dir…
Bom ae você tem que saber o que acontece se o diretorio estiver “vazio”, se o diretório “dir” existir, pois ele também pergunta:
Se o diretório “dir” não exisitr vai criar o arquivo na raiz? vai dar rumtime?
Bom, resumindo, voce tem que saber todas as possibilidades, entende, se exisitir, se não existir, se fizer f.makeDir(); se criar
um PrintWriter passando um File que não existe,
Como você ja sabe o PrintWriter cria o arquivo se não existir mas o File não, porém na situação de dir não existir da uma
exception, mas se existir e for null, o arquivo será criado na “root” do projeto…
Veja esse código de exemplo:
import java.io.File;
import java.io.IOException;
public class TesteCoisa extends Teste{
public static void main(String[] args) {
doStuff();
}
public final static void doStuff()
{
File d = new File("d");
d= null;
File f = new File(d, "x.teste");
try {
System.out.println(f.createNewFile());
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
System.out.println("teste");
}
}
Isso cria um arquivo na raiz do projeto, mas e se voce retirar "d=null" e não existir o diretório "d"?, pior e se de exisitir mas for um arquivo e não um diretório?
Caiu também renomeação de arquivos, isso tem no livro da Katy, mas ler somente não adianta, tem que testar, pensar e se euf izer isso? e se fizer aquilo?, bom notei essa necessidade para muitos temas, como Collections, Formatação, IO, Serialização
Bom, como uma dica para estas bibliotecas, que tem muitos detales eu diria que ler o java doc é uma boa pedida, no meu caso eu cliquei com o Ctrl apertado em uma classe, como por exemplo String, e no "atach sources" linkei o source, ae fica mais fácil pois voce digita o codigo do metodo(ou construtor como é o caso do File), clica nele, pega o java doc, e ja tira
sua dúvida!
Bom isso ae foi interessante em vários pontos para mim, para fazer isso veja:
http://www.cavdar.net/2008/07/14/3-ways-of-jdk-source-code-attachment-in-eclipse/
Depois é so ler o java doc, por exemplo do construtor que vimos acima de File com dois argumentos:
/**
* Creates a new <code>File</code> instance from a parent abstract
* pathname and a child pathname string.
*
* <p> If <code>parent</code> is <code>null</code> then the new
* <code>File</code> instance is created as if by invoking the
* single-argument <code>File</code> constructor on the given
* <code>child</code> pathname string.
*
* <p> Otherwise the <code>parent</code> abstract pathname is taken to
* denote a directory, and the <code>child</code> pathname string is taken
* to denote either a directory or a file. If the <code>child</code>
* pathname string is absolute then it is converted into a relative
* pathname in a system-dependent way. If <code>parent</code> is the empty
* abstract pathname then the new <code>File</code> instance is created by
* converting <code>child</code> into an abstract pathname and resolving
* the result against a system-dependent default directory. Otherwise each
* pathname string is converted into an abstract pathname and the child
* abstract pathname is resolved against the parent.
*
* @param parent The parent abstract pathname
* @param child The child pathname string
* @throws NullPointerException
* If <code>child</code> is <code>null</code>
*/
public File(File parent, String child) {
///////////////////Resto do Construtor//////////////////////////////////
Caiu também muitas pegadinhas a respeito de variáveis sendo acessados fora do escopo, por exemplo declarado em um try
e tentando acessar:
try {
String escopo = "x";
} catch (IOException e) {
System.out.println(escopo);
e.printStackTrace();
}
Bom, da para ver que não compila né, mas na prova a questão parece pedir algo voltado a exception, ou modificador de acesso, para tirar
sua atenção do problema real!, o escopo da variável!..
Cairam algumas perguntas sobre exception, e eu errei! lembro de uma mais ou menos assim:
public class TesteException {
public static void teste()throws Exception{
try{
throw new Exception();
}finally{
System.out.println("finally");
}
}
public static void main(String[] args) {
try {
teste();
} catch (Exception e) {
System.out.println("erro");
}
System.out.println("end");
}
}
Ae a pergunta era a respeito da saída, bom agora parece muito simples, mais na hora eu me confundi…mas a saída seria:
finally
erro
end
mas e se você trocar o finally por um catch? tinha outras assim também…uma boa idéia é copiar esse código, ae e deixar
sua imaginação funcionar…e alterar com tudo que é bloco!
Cairam algumas coisas a respeito de coleções ordeandas, e a prova tentava te confundir a respeito das interfaces, SortedSet
List, as vezes dando new nelas, na verdade o que era correto era instanciar um TreeSet, para ordenação de uma coleção
por exemplo. Mas veja bem, não se engane, as resposta são maliciosas, sempre com muitos detales, que se você cochilar o
cachimbo cai!
Caiu uma a respeito de DateFormat, a prova procurava saber se você sabe como criar um, de novo não tem como dar new né em
uma Interface, então tem que saber como inicializar um DateFormat NumberFormat… isso tem que decorar não tem jeito!
Caiu o uso de atribuições usando variáveis de instancia não inicializadas, por exemplo
int x += a;
sendo a uma variavel wraper, sendo assim x + null é um NullPointer bem bonito…
Aquelas belas questões do tipo quem é um e tem, com um monte de código e depois dizendo escolha duas:
A é um B
B tem um X
Mas sempre com implicações mas detalhadas, como por exemplo B tem um A, mas A é um X, então B tem um X, entende?
neste caso um bom conhecimento de instanceOf garantiu umas questões…
bom vai mas uma dica, tinha também aquela história dos booleans literais passados para while e if
while(true){
System.out.println("compila");
}
if(true){
System.out.println("compila");
}
E se for assim?
boolean b = false;
while(b){
System.out.println("compila");
}
if(true){
System.out.println("compila");
}
Tambem a bizarrice abaixo caiu
Boolean b = new Bollean("TruE") //parece que não compila né? mas esse trem compila, veja o fonte do construtor usa o metodo abaixo:
private static boolean toBoolean(String name) {
return ((name != null) && name.equalsIgnoreCase("true"));
}
reparou no equalsIgnoreCase?
Classes internas também tinha duas questões com classe interna em duas classes, só que tipo classe dentro de classe dentro de classe…
com três niveis, ae perguntava como instanciar em um main… mas o main tava dentro de uma classe que tinha classe interna statica… praticamente um espaguete,
tem que brincar muito com esse negocio…
Threads foi baba, umas tres questões básicas, uma de GC(tentando enganar um metodo passava a referencia para uma variavel de instancia), perguntando depois de qual linha o objeto
era elegível.
Uma sobre subMap, tilMap,headMap, com aquelas diferenças entre os dois, onde começa o subConjunto e onde termina, ou seja inclusive ou não,
Obs: veja a diferença entre headSet e tailSet, um inclui o ultimo elemento no conjunto e o outro não, tem que codificar usando esses caras!!! Veja um exemplo do livro adaptado:
package treeSetTreeMap;
import java.util.Iterator;
import java.util.TreeSet;
public class Ferry {
public static void main(String[] args) {
TreeSet<Integer> times = new TreeSet<Integer>();
times.add(1205);
times.add(1505);
times.add(1545);
times.add(1830);
times.add(2010);
times.add(2100);
TreeSet<Integer> subset = new TreeSet<Integer>();
subset = (TreeSet<Integer>)times.tailSet(1830);
Iterator<Integer> itIntegerr = subset.iterator();
System.out.println("metodo tailsSet");
while (itIntegerr.hasNext()) {
Integer integer = itIntegerr.next();
System.out.println(integer);
}
subset = (TreeSet<Integer>)times.headSet(1830);
itIntegerr = subset.iterator();
System.out.println("metodo headSet");
while (itIntegerr.hasNext()) {
Integer integer = itIntegerr.next();
System.out.println(integer);
}
}
}
Observação no método headSet o elemento passado não é adicionado ao conjunto, enquanto que tailSet inclui o elemento no conjunto, considera-se esse fator de grande importância.
TreeSet<Integer>)times.tailSet(1830,false);
Exclui o elemnto passado do conjunto
TreeSet<Integer>)times.headSet(1830,true);
Acrescenta o elemento no conjunto…
Bom, é o que lembro, desculpe o post enorme…
Uma boa dica é visitar o blog do Pedro Abs, e também ler os resumos do Camilo Lopes:
Abraço a todos e muito obrigado por tudo.
