Sql de Estados/Cidades Brasil

Iniciei essa semana um projetinho independente. Como ainda não sei se vai dar “samba”, não vou comentar a respeito dele. Porém hoje, pela primeira vez, precisei de uma coisa super básica a lista de todos estados/municípios brasileiros para que eu possa carregar numa tabela. Tipo de coisa simples que gastasse tempo pra fazer.

Logo de cara meu amigo google me ajudou, porém muitos links quebrados, e informação torta. Até que percebi que o próprio site do ibge tem essa informação, porém não é num formato agradável, muito menos em sql.

No final das contas fiz um script. Sql claro. E vou disponibilizar, já que não sou egoísta .

http://rapidshare.com/files/342558441/script_estados_municipios_rj.sql.html

I’m Sun Certified Programmer Java 6 score 90%

Quase que expirando o retake, e um pouco desesperado achando que a prova poderia ser mais difícil do que imaginava, correu tudo bem e alcancei a aprovação na SCJP com 90% de aproveitamento.

Tempo total de estudo não sei ao certo, por motivos de trabalho e tudo mais. Porém, o livro da Katy Serra é de obrigatória leitura. Do mais é preciso fazer muitos exercícios, para isso usei o livro do Roberto Serson volume de prática que tem bastantes questões, o wizlabs e o MasterExam (vem com o livro da Katty).

No dia anterior da prova fiz o Master Exam e confesso que até fiquei assustado. Nível desse simulador é realmente mais alto que o da prova. Porém, serviu de um bom teste pré-prova, provou que estava preparado.

Encerrei a prova de 3hs em 2hs, com 90% de acertos. E por incrível que das 6 questões que errei, umas 2 foram de OO conceituais (ou seja, devo ter me enrolado no inglês..hauahuah)

Fica a dica, pra quem vai fazer. Em breve novos posts, sobre meus estudos da SCWCD.

[]s

Coleções e qual a melhor escolha!?

Na SCJP, fatalmente caíra uma questão, onde dado um problema, qual seria a melhor Coleção a ser aplicada. Geralmente, se vc conhece as diferenças de cada coleção, é questão para acertar em 2 segundos. Porém, para isso é bom conhecermos os detalhes de cada uma (só das que caem no exame, of course!).

Vamos lá:

• ArrayList: Como o nome já diz, é uma abstração de um array. Tem rápida iteração e rápido acesso rândomico. Os seus elementos possuem uma sequência natural por índice, porém essa coleção não é ordenada. Implementa java.util.List e extende de java.util.Collection.
• Vector: Igual a ArrayList em todos os sentidos, exceto que suas operações são mais custosas (lentas), pois todos seus métodos são sincronizados. Ou seja, ela é thread-safe.
• LinkedList: Possui seus elementos em sequência por índice, porém seus elementos são duplamente encadeados uns aos outros. Logo, é fácil inserir e remover do ínicio ao fim dessa coleção. Escolha em casos onde é preciso inserir e deletar rapidamente registros. Porém, a iteração é um pouco mais lenta do que comparado ao ArrayList. Implementa a interface Queue também.
• HashSet: Sem nenhuma sequência ou ordenação. Essa coleção é usada para elementos não-duplicados e a ordem não importa.
• LinkedHashSet: é uma Hashset com ordenação natural, ou seja, ao inserir na lista e depois iterá-la a ordem é mantida.
• TreeSet: é um Set com ordenação natural ou especificada. Comumente, se usa elementos com Comparable ou Comparator, para se inserir já de maneira ordenada. Internamente, a TreeSet usa e estrutura de árvore rubro-negra.
• HashMap: Mapeamento chave-valor, sem ordenação nenhuma. Aceita uma chave nula, e múltiplos elementos nulos.
• Hashtable: é a HashMap com duas diferenças: é thread-safe, e não possui elementos e nem chaves nulos.
• LinkedHashMap: similar ao LinkedHashSet é um HashMap com ordenação natural. Possui mais rápida iteração, porém nas operações de inserir e remover será mais lenta. Possui opção de ordenação natural ou LRU (por último acessado) em seu construtor.
• TreeMap: similar a TreeSet, é um Map com ordenação natural (caso um Comparable ou Comparator não seja especificado).
• PriorityQueue:  É uma Queue de prioridades. Os elementos são inseridos com ordenação natural ou especificada dado por um Comparable ou Comparator.

That`s all.

Blocos de Inicialização Estáticos e Não Estáticos

Esse post será rápido.

Existem 3 lugares numa classe java onde podem ser “escrito” código própriamente dito. Normalmente se escreve código dentro de construtores e métodos. Porém, existem os chamados “initialization blocks”, ou em português blocos de inicialização.

Podem ser de dois tipos: Estáticos ou de Instância.

Alguma regrinhas para variar:

• Blocos de inicialização não recebem nome, não recebem parâmetro e não tem tipo de retorno.
• Blocos de inicialização podem haver quantos quiserem. E a ordem na classe importa para a execução.
• Blocos de inicialização estático rodam apenas uma vez, e quando a classe é carregada pelo ClassLoader.
• Blocos de inicialização de instância, rodam uma vez, a cada instância criada.
• Blocos de inicialização de instância executam após a chamada de super() (seja ela implícita ou explícita).

Logo, a ordem é a seguinte:

1. Blocos estáticos na ordem em que aparecem na classe
2. Chamado ao super() da instância
3. Em seguida, bloco de inicialização da instância
4. Continuação no construtor da própria instância

Segue exemplo:

class Super{

{ System.out.print(” block super “);}

Super(){ System.out.print(” super “); }

}

class Teste extends Super{

static{ System.out.print(” static 1 “);}

{ System.out.print(” block teste “);}

static { System.out.print(” static 2 “);}

Teste(){

//super(); chamada já é implícita

System.out.print(” teste “);

}

public static void main (String… args){

new Teste();

}

}

Saída será: “static 1 static 2 block super super block teste teste”

That’s it!

Serialização em Java para SCJP

Assunto, que pelo simulado rápido que eu fiz não caiu. Mas, acho que vale a pena, até porque é um assunto interessante e que pode ser aplicado em muitos casos do cotidiano.

O conceito de serialização torna-se útil a partir do momento que deseja-se gravar um objeto seja ele num arquivo de qualquer formato, e depois restaurá-lo do estado em que foi gravado.

Fazer isso na prática não é muito simples quanto parece por várias razões. E é isso que a API do java de serialização pretende fazer por nós. Pontos a se considerar a respeito:

• Uma classe para ser serializável precisa implementar a interface java.io.Serializable. Esta por sua vez não expõe nenhum método.
• O método writeObject da classe java.io.ObjectOutputStream serializa objetos, e o método readObject da classe java.io.ObjectInputStream desserializa.
• As classes FileOutputStream e FileInputStream ambas do package java.io representam os arquivos a serem criados no disco para serem serializados ou desserializados.
• A palavra reservada transient , marca uma variável que não será serializada. Um objeto ao ser desserializado, todas suas variáveis transientes serão atribuídas aos seus valores padrões de tipo.
• Pode-se implementar no objeto a ser serializado os método defaultWriteObject e defaultReadObject(), o processo de serialização os chamará.
• Se uma superclasse implementa Serializable as classes filhas também são automaticamente.
• Se uma superclasse não implementa Serializable, ao desserializar o construtor da superclasse será invocado.
• Em casos de se tentar serializar um objeto que não implemente a interface Serializable, a exception java.io.NotSerializableException será lançada. Isso também acontecerá se o objeto a ser serializado contiver internamente algum objeto que também não é serializável, mesmo o principal sendo.
• Serialização é para objetos. Ou seja, variáveis de classe em nada participam do processo de serialização.

Vejamos o código abaixo , para fixar:

import java.io.*;

class Keyboard { }

public class Computer implements Serializable {private Keyboard k = new Keyboard();

public static void main(String[] args) {

Computer c = new Computer();

c.storeIt(c);

}

void storeIt(Computer c) {

try {

ObjectOutputStream os = new ObjectOutputStream(new FileOutputStream(“myFile”));

os.writeObject(c);

os.close();

System.out.println(“done”);

} catch (Exception x) {System.out.println(“exc”); }}

}

No programa acima, a saída será “exc”. Pois Keyboard é parte de Computer não é serializado, e assim o serializador lança a exception.

E outro código se tratanto de variáveis static e transient:

import java.io.*;

public class TestSer {

public static void main(String[] args) {

SpecialSerial s = new SpecialSerial();

try {

ObjectOutputStream os = new ObjectOutputStream(new FileOutputStream(“myFile”));

os.writeObject(s); os.close();

System.out.print(++s.z + ” “);

ObjectInputStream is = new ObjectInputStream(new FileInputStream(“myFile”));

SpecialSerial s2 = (SpecialSerial)is.readObject();

is.close();

System.out.println(s2.y + ” ” + s2.z);

} catch (Exception x) {System.out.println(“exc”); }

}

}

class SpecialSerial implements Serializable {

transient int y = 7;

static int z = 9;

}

Saída será “10 0 10″.  A variável estática z é atualizada e enquanto permanece ativa no programa imprimirá o que lhe foi atribuída, e nem participa do processo de serialização/desserialização. Já a variável y, é transiente. Ela não é inserida no objeto ao ser serializado. Logo, ao se restaurar o objeto, como não há inicialização, nem se é rodado o construtor, o valor da variável passa a ser padrão do tipo, para tipos primitivos inteiros esse valor é zero.

Inner Classes , Method Local Inner Classes, Anonymous Inner Classes, Static Nested Classes

Classes Internas (Inner Classes) são muito úteis, e existem algumas variações, que talvez um programador que não seja certificado nem saiba que exista (a não ser que já tenho programado com swing, geralmente as coisas feias foram programadas lá!rs) Enfim, no exame é comum não cair questões diretas sobre inner classes, mas sim uma mistura de coisas. Logo, é importante saber identificar se há algum erro de compilação por decorrência de classes internas.

Vamos listar os pontos chaves:

Inner Classes

• Uma classe interna é declarada sempre dentro de outra classes (entre as chaves)
• Uma classe interna é membro da classe que a envolve. Logo ela pode ser marcada com modificador de acesso e também como abstract ou final (os dois modificadores juntos dá erro… obviamente)
• Toda instância de classe interna compartilha um especial relacionamento com a instância da classes envoltória. Esse relacionamento dá a classe interna acesso a todos os membros da classe que a envolve, incluindo os privados (private)
• Para instanciar uma classe interna é preciso uma instância da classe que a envolve. Ex: MyOuter m = new MyOuter(); MyOuter.MyInner inner = m.new MyInner();
• De dentro da classe envoltória pode se instanciar a classe interna usando somente seu nome. Ex: MyInner in = new MyInner();
• Para referenciar de dentro classe interna a instância da classe envoltória, se usa a palavra reservada this com o nome da classe envoltória. Ex: MyOuter.this // retorna a instância da classe envoltória

Method-Local Inner Classes

• Classes Internas de Método são definidas como o próprio nome já diz, dentro de métodos da classe envoltória.
• Para usar uma classe interna de método deve-se instanciá-la dentro do mesmo método. Já que a classe foi criada de dentro de um método, ela só valerá dentro daquele método.
• Podem acessar membros da classe que envolve mesmo que sejam private.
• Não pode se usar dentro de uma classe interna de método, variáveis não final declaradas no método, apenas variáveis final. Ex:
  void go (){
  final int size = 5;
  int teste=2;
  class B{
  B(){
  System.out.println(size); //compila
  System.out.println(teste); // não compila
  }
  }
  }
• Os únicos modificadores que podem ser aplicados em classes internas de método são abstract ou final. Razão é óbvia, nenhum modificador de acesso (public, protected ou private) pode ser usado dentro de métodos.

Anonymous Inner Classes

• Classes anônimas como o próprio nome diz, não tem nome, normalmente ou são subclasses ou implementam uma interface.
• Uma instância anônima sempre será criada na declaração. Sempre termina-se com ; Ex:

public static void main(String[] args) {

Object o = new Object(){

public boolean equals(Object obj) {

return true;

}

}; //Atentem para o ponto-vírgula, sem ele não compila

}

 

Static Nested Classes

• Classes embutidas estáticas são classes internas marcadas com modificador static.
• Classes embutidas estáticas não compartilham nenhum relacionamento especial com a instância que a envolve. E para instânciá-la não é preciso da instância da classe que a envolve também.
• Exemplo : MyOuter.MyInner in = new MyOuter.MyInner();
• Classes embutidas estáticas não podem acessar membros não estáticos da classe que a envolve. Isso fere o conceito de que não pode se acessar a instância dentro de um contexto estático (a não ser que se crie uma instância e faça uso dela).

Agora vamos analisar o seguinte programa:

public class A {

public static void main(String[] args) {

String sa[] = new String[]{“a”,”c”,”b”};

Sorter sorter = new Sorter();

Arrays.sort(sa,sorter);

for (String string : sa) {

System.out.println(string);

}

}

class Sorter implements Comparator<String>{

@Override

public int compare(String arg0, String arg1) {

return arg1.compareTo(arg0);

}

}

}

Dando uma olhada rápida, vc responderia imprimi “c b a”. Quem pensou isso até acertaria, se ele compilasse. Olhe atentamente como foi instanciada a classe Sorter. Sorter é uma classe interna, e para ser instanciada precisa da instancia da classe que a envolve:

A a = new A();

Sorter sorter = a.new Sorter();

Ou podemos fazer a classe Sorter ser estática, e daí nada mais precisaria ser feito.

Java Threads para SCJP – Pegadinhas

Marquei o exame, agora é de verdade!rs Tenho 1 semana para recordar tudo que eu estudei, acho que é tempo suficiente. Logo, acho que vou começar a fazer dois posts por dia, pra abordar todos os perigos que vi.

Hoje, continuação sobre threads, vou falar de uma pegadinha braba que vi.

Analise o código:

public class Test extends Thread{

public Test (String name){

super(name);

}

public static void main(String[] args) {

Test  a = new Test (“A”);

Test  b = new Test (“B”);

a.start();

b.start();

}

public void run() {

String s = “literal”;

synchronized (s) {

System.out.println(Thread.currentThread().getName());

try {

Thread.sleep(1000);

} catch (InterruptedException e) {}

System.out.println(Thread.currentThread().getName());

}

}

}

Adianto que tudo compila e roda perfeitamente. Temos duas opções de saída:

1. AABB / BBAA

2. ABAB / BABA

Pensamento lógico seria: Bom a primeira thread (que eu não sei qual é , pode ser A ou B) ela rodando imprimirá A ou B, em seguida, dormirá por 1 segundo. Daí dando continuidade a outra Thread será escalonada e tentará passar pelo bloqueio, como o objeto pelo qual o bloqueio é realizado é uma String própria de cada instância, nada impede da outra thread entrar no método run e rodar. Se vc pensou assim, errou num detalhe. Strings literais quando iguais são compartilhadas pelas instâncias, java não cria outra String caso já exista um literal igual no pool , ele devolverá a referência para a mesma instância. Sendo assim, a bloqueio será realizado impedindo que se imprima ABAB por exemplo, e sim será impresso AABB ou BBAA.

Agora olhando para o outro código:

public class Test extends Thread{

public Test (String name){

super(name);

}

public static void main(String[] args) {

Test  a = new Test (“A”);

Test  b = new Test (“B”);

a.start();

b.start();

}

public void run() {

String s = new String(“literal”);

synchronized (s) {

System.out.println(Thread.currentThread().getName());

try {

Thread.sleep(1000);

} catch (InterruptedException e) {}

System.out.println(Thread.currentThread().getName());

}

}

}

Esse sim imprimirá ABAB ou BABA. Ué mais não é String também. A resposta é que o operador new cria com certeza uma nova referência para a variável. Ou seja, as duas strings são instâncias diferentes, logo o bloqueio será realizado de forma independente.

Pegadinha máxima, vale a pena ficar atento.

Java Threads para SCJP

Lembro que quando comecei a estudar para o exame, comentei com um amigo e ele disse: “Raphael, as questões de thread são muito dificeis, se garante nas demais”. Fiquei com isso na cabeça, meio que contrariado. Estudei o livro da Katy Serra, e vi nada demais, tirando a decoreba braba, porém o conceito de thread e sincronismo é um paradigma externo a linguagem.

Enfim, fiz um mapeamento do que o exame “gosta que caia”. Vamos lá:

• Uma thread só pode ser startada uma vez. Caso ocorra uma segunda tentativa de start da mesma thread ocorrerá um IllegalThreadStateException
• Os métodos sleep e yield são estáticos. Atuam em cima da thread corrente (em sistemas monoprocessados apenas uma thread ganhará a cpu por vez).
• Os métodos wait, sleep e join movem a thread do estado running para o estado blocked/waiting. E por isso todos os três lançam InterruptedException , caso sejam interrompidos.Logo ao chamá-los é necessário tratá-los com try/catch.
• Sleep é usado para dar um delay na execução da thread corrente. A thread não libera o bloqueio ao objeto quando está dormindo.
• Yield tenta escalonar para running outra thread de mesma prioridade que a corrente. A thread anterior volta para runnable. Não a nenhuma garantia que a thread eleita não seja a mesma thread que já estava rodando, ou outra específica.
• Quando uma thread chama o método join lê-se assim: b.join();  ”Eu (thread corrente) quero me unir ao fim da thread b, quando b terminar ou expirar eu volto para runnable.
• join() espera até a thread morrer . join (long miliseconds) timeout é setado, ou espera até morrer ou expira por timeout.
• palavra-chave synchronized só pode ser usada com métodos e blocos, não pode ser usada em classes ou variáveis.
• Métodos statics podem ser synchronized o bloqueio será feito na própria classe (java.lang.Class).
• Enquanto apenas uma thread pode acessar um método ou bloco synchronized por vez, várias thread podem acessar um método da mesma classe caso ele não seja synchronized.
• Os bloqueios são realizados por objeto. Logo num bloco syncronized vc deve passar um objeto, nunca primitivo.
• synchronized (this){} equivalente a public void syncronized method(){}
• Construtores não podem levar a palavra syncronized. Mas nada impede que tenha um bloco synchronized dentro deles.
• wait(), notify() e notifyAll(), devem ser chamados de dentro de contexto syncronized.
• notify notifica a primeira thread da fila de waiting, para ser liberada.
• notifyAll notifica todas as thread da fila de waiting
• um objeto ao chamar waiting, a thread que o disparou liberará seu lock para que outra thread possa entrar no contexto.

Em breve algumas questões com pegadinhas de thread. Até

Sobrescrevendo equals e hashCode Métodos em Java

Assunto muito batido, mas vi que é presença marcante no exame, e muito importante no dia-a-dia. Até porque todo projeto java usa API de Collection (nunca conheci nenhuma que não usasse), logo para fazer um bom uso de ordenação, mapeamento chave x valor, exclusão de repetição, etc.. , se faz necessário implementar pelo menos o método equals, e sempre é bom implementar o hashCode tb.

Pra começar, vamos ver a assinatura dos dois métodos:

public boolean equals (Object o)

public int hashCode()

Logo, a primeira coisa para sobrescrever esses métodos, a classe filha deve usar uma assinatura igual. Algo como abaixo, daria erro de compilação por violar a regra de sobrescrita.

protected boolean equals(Object o)

Outro perigo tb:

int a = 2;

Integer b = 2;

b.equals(a); //imprime true, compila perfeito, usa autobox

a.equals(b);//não compila, a é um primitivo não possui método equals

Continuando, equals tem uma única utilidade: Dizer se dois objetos são ou não iguais. Caso, vc não o sobrescreva o equals da classe Object por padrão testa a referência. Logo, se duas variáveis apontam para a mesma referência, equals retornará verdadeira.

hashCode também tem a sua implementação padrão, porém ela está intimimante ligada a perfomance. Imagina várias caixas numeradas, e dentro varias bolas. Se vc pretende inserir uma bola nova numerada, vc vai na caixa marcada e dentro vc ordena com mais facilidade e de forma mais rápida. O princípio é o mesmo, com hashCode, o int que o método retorna diz para o java em qual grupo deve-se achar aquele objeto, e daí roda o equals para todo elemento de dentro da caixa.

Para o exame, provavelmente algo falando sobre contrato do equals e hashCode vai cair. Contrato é o conjunto de regras que dizem se esse dois métodos foram implementados de maneira correta. Não necessariamente forma correta é estar só compilando.

A principal das regras é a que diz: “Caso dois objetos são iguais através do método equals, então seu hashCodes devem ser iguais” e “Se dois objetos pelo método equals são diferentes, nada pode-se dizer à respeito do hashCode”.

Coisas estranhas do tipo:

public int hashCode(){

return Math.random(x);

}

Violam também o contrato, pois imagine que pra cada vez que equals for chamado numa instância do objeto que o contém, ele terá um hashCode diferente…

Assunto Fácil! Acho que por hoje é só…

Importante, Caso vc nao sobrescreva equals ou hashCode:

A implementação padrão de equals compara duas referências. Duas referências são iguais se elas apontam para o mesmo objeto.

A implementação padrão de hashCode retorna um valor inteiro diferente para cada instância, ou seja, para que uma coleção como uma HashSet elimini elementos repetidos, se faz necessário a implementação dos dois métodos.

Cast Implicito e Explicito em primitivos no Java

E eu não me canso de ler assunto chatos, nada aplicados no dia-a-dia, mas que caiem no exame. E por isso tenho que documentar, porque sei que antes do exame vai ser aqui que vou olhar.

Mas então, pergunte para alguém que saiba java, mas que não seja certificado: “Fulano, quando vc é obrigado em aplicar cast atribuindo dois primitivos diferentes e quando não?

A resposta é:

• Não precisa de cast (implicita) quando ocorre ampliação. Em outras palavras vc atribui um tipo primitivo de menor tamanho para um tipo de maior.  Exs: int a = 100; long b = a; byte b1 = 2; int a1 = b1;
• Precisa de cast sempre que houver perda de precisão. Por exemplo: float a = 100.01f; int b = (int)a;

Outro detalhe importante, é que todo literal digito é do tipo inteiro, mesmo que este seja atribuído para byte, char ou int. Ex: byte b = 27; char c = 59;

Sendo assim, toda soma envolvendo literais, também serão inteiras. Porém existe uma armadilha com relação aos operadores.

byte a = 3;

byte b = 4;

byte c = a+b; //resultado é um int, deveria não ser problema atribui-lo de                                     //volta para um byte, porém compilador reclama, precisa de                                   //cast explicito

b += 7;      //esse caso funciona, pois o operador += já se encarrega de fazer o                       //cast

Fica a dica, já que ta brabo de decoreba!rs