Ano passado eu poste, inocentemente, que Java 1.7 iria ter ponteiros. E muita gente acreditou. Meses depois dessa postagem eu ainda recebia emails perguntando detalhes ou via em outros foruns gente desesperada (ou maravilhada) com essa feature.
Decidi não postar nenhuma pegadinha. De fato existe uma proposta de ter algo como os blocos unsafe do C# em java ( veja aqui) mas nada confirmado.
Bom primeiro de abril para todos!
XStream é a maneira mais fácil de trabalhar com XML em Java. Para trabalhar com JSON então, é ainda mais facil
Listas de x coisas só servem para lembrar de tudo o que ficou de fora, portanto, IMHO, as 10 coisas que todo o programador deveria saber são:
0 – usar o google
1 – fazer um hello world em pelo menos 5 linguagens de programação diferentes (sendo uma funcional e uma script)
2 – instalar o wordpress e tudo o que é necessario para que o mesmo execute.
3 – instalar e configurar o Ubuntu, ou outro *nix, incluindo configuração de rede e impressão
4 – entender o que é CLASSPATH
5 – saber a diferença entre HTTP e FTP, entre TCP e UDP e qual camada OSI eles atuam. bonus: saber como funciona um GET ou POST (é possivel ver usando o live http headers do firefox).
6 – conhecer o comando grep e algumas opções como -c, -v, -A
7 – SQL: entender o que é select,update,insert, delete, commit, rollback
8 – como ler e gerar XML
9 – entender o que é NULL, \0, **qqcoisa do C e quais os seus usos (principalmente em strings)
10 – a diferença entre licença BSD e GPL veja aqui.
Alem disso é bom seguir alguns blogs, frequentar foruns, listas de discussão e ler muito. Mesmo um texto “chato” como A Catedral e o Bazar traz informações relevantes e outras referencias.
Boa sorte e que começe a flame-war 
Lendo sobre testes unitarios, imagine o caso onde o seu teste é complexo: um objeto que chama outro e, então, realiza as suas tarefas. Um bom caso é um DAO que acessa o banco de dados para fazer alguma coisa: se vc pensa em testar esse codigo de forma unitaria teria que subir um banco de testes e, se encontrasse um problema, poderia ser dificil dizer se é problema do DAO ou dos objetos que ele depende (como a conexão com o banco, ou o banco em si).
A solução para estes casos pode ser trabalhar com mocks: objetos “burros” que podem não ter nenhuma função alem de responder ao que vc especificou. A abordagem mais utilizada é vc programar estes objetos para responder a um ou mais metodos com argumentos especificos, assim como as respostas esperadas. No caso do DAO eu posso esperar um determinado SQL e especificar uma determinada resposta, tudo de acordo com o meu cenario de teste.
É claro que Mock Objects em excesso podem atrapalhar, mas é tudo uma questão de bom senso: costumo dizer para quem esta começando a focar os testes nas partes mais importantes do sistema, o core do modelo e regras de negocio e, então, incrementar estas praticas caso veja necessidade. Sem falar que volta e meia surge algo novo.
Para java existe o excelente framework JMock. Logo de cara o site oficial traz um exemplo de como utilizar um mock bem simples (incluindo a integração do mesmo com JUnit 4)
http://www.jmock.org/getting-started.html
Para entender, imagine esta interface
interface Subscriber { void receive(String message); }
Imagine que eu tenho um objeto do tipo Publisher que, ao invocar o metodo publish(message), ele envie esta mensagem para um Subscriber (que recebe com o metodo acima). Para testar o publish eu teria que me certificar que o metodo receive deste objeto Subscriber foi invocado com a mensagem especificada, mais ou menos assim:
import org.jmock.integration.junit4.JMock; import org.jmock.integration.junit4.JUnit4Mockery; import org.jmock.Expectations; @RunWith(JMock.class) class PublisherTest { Mockery context = new JUnit4Mockery(); @Test public void oneSubscriberReceivesAMessage() { // set up final Subscriber subscriber = context.mock(Subscriber.class); Publisher publisher = new Publisher(); // objeto que vou testar publisher.add(subscriber); // tenho que adicionar o mock! final String message = "message"; // aqui eu programo o que eu espero do teste context.checking(new Expectations() {{ oneOf (subscriber).receive(message); }}); // aqui eu executo! publisher.publish(message); } }
Facil?
Quem nunca passou por isso: ter que gerar e/ou ler arquivos xml e teve que escolher dentre diversas tecnologias e frameworks diferentes. Seja carregar tudo pra memoria ou ler aos poucos, se é um parser push ou pull, etc, é possivel dizer que para cada situação existe uma boa escolha.
Se o seu caso é trabalhar com arquivos cujos elementos podem ser mapeados em objetos java, uma boa escolha é o XStream
XStream xstream = new XStream(new DomDriver()); Person pac = new Person("Tiago", "Pac Man"); String xml = xstream.toXML(pac); /* Simples. É, para fazer o contrario, basta */ Person newPac = (Person)xstream.fromXML(xml);
Este e outros exemplos podem ser conferidos aqui:
http://xstream.codehaus.org/tutorial.html
É claro que o xml gerado assim, cru, nem sempre serve. Para isso vamos usar algumas linhas a mais para trabalhar com os recursos de alias, annotations e os Converters.
xtream.alias("pessoa",Person.class);
Dessa forma, para se livrar do nome.do.pacode.Person e trabalhar com algo mais expressivo como pessoa, basta adicionar este alias antes de converter de/para xml. Para trabalhar com aliasing de atributos (e coleções implicitas) o ponto de partida é este:
http://xstream.codehaus.org/alias-tutorial.html
É possivel trabalhar com annotations no seu modelo de classes, evitando toda essa configuração manual
http://xstream.codehaus.org/annotations-tutorial.html
Para trabalhar com o maximo de flexibilidade do XStream, entretanto, vc precisa trabalhar com Converters – Veja o exemplo da classe Birthday
http://xstream.codehaus.org/converter-tutorial.html
XStream trabalha muito bem com classes imutaveis, pois não recria os objetos usando o construtor e sim de maneira semelhante ao mecanismo de serialização de objetos, fazendo um bypass do construtor. Sem falar que traz um pensamento menos voltado a “tags” e mais OO.
Para ilustrar a sintaxe de uma linguagem, é comum o primeiro exemplo ser o hello world, no qual o programa realiza um aceno breve e fugaz (valeu zED9h) para o mundo exterior. Vejamos em C:
#include <stdio.h>
int main (int argc, const char* argv[]){
printf("hello world!\n");
return 0;
}
Aparentemente é um codigo simples, vamos olhar a execução
peczenyj@XXX:~$ gcc -Wall hello.c -o hello.exe
peczenyj@XXX:~$ ./hello.exe && echo "ok" || echo "nok"
hello world!
ok
Testar um hello world sob condições normais não é dificil: ele vai escrever uma mensagem fixa na stdout e vai retornar 0 para o bash (que pode ser recuperado via $? ou então encadear && e || como eu fiz no exemplo acima.
Agora vejamos o strace:
peczenyj@XXX:~$ strace ./hello.exe
execve("./hello.exe", ["./hello.exe"], [/* 35 vars */]) = 0
brk(0) = 0x804a000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f9c000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=81298, ...}) = 0
mmap2(NULL, 81298, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f88000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260a\1"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=1339816, ...}) = 0
mmap2(NULL, 1349136, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e3e000
mmap2(0xb7f82000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x143) = 0xb7f82000
mmap2(0xb7f85000, 9744, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f85000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e3d000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e3d6b0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb7f82000, 4096, PROT_READ) = 0
munmap(0xb7f88000, 81298) = 0
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f9b000
write(1, "hello world!\n", 13hello world!
) = 13
exit_group(0) = ?
Process 6344 detached
Vejamos só: uma grande preparação para, no final, mostrar um hello world e sair (com sucesso). Isso mostra que qualquer coisa, mesmo a mais simples, esta envolta em muitas camadas de abstração até ser corretamente executada. Aqui estamos ignorando o sistema de arquivos, sistema operacional, memoria, cpu, etc. Com linguagens interpretadas ou que rodam sob uma JVM a coisa é mais complexa ainda.