Listão - PRINCIPAIS PEGADINHAS SCJP

É uma boa postar os códigos usando as tags code:
http://www.guj.com.br/posts/list/50115.java

do método main, essa é pra q não sabe o q é var-arg:

public static void main(String... args){ }

isso compila normalmente…

Ae Pessoal,

Esta sobre thread’s nâo vi em simulados mas no blog do Raphael Rodrigues (que segundo ele estava num simulado) acho que vale a pena dar uma olhada:
http://raphaelrodrigues.wordpress.com/2009/11/25/java-threads-para-scjp-pegadinhas/

[]'s
Luiz Renato

isso aqui tbm pode gerar dúvidas quanto a compilação:

a instrução compila normalmente.

robsonsm:

isso aqui tbm pode gerar dúvidas quanto a compilação:

a instrução compila normalmente.

protected class Teste {

}

Classe só pode ser public ou default. Na minha apareceu essa pegadinha.

try{
}
int i = 10;
catch(Exception e) {
}

Sem códigos entre try/catch

try{
int i = 10;
}
catch(Exception e) {
i= 20;
}

scopo…

yastorm:

protected class Teste {

}

Classe só pode ser public ou default. Na minha apareceu essa pegadinha.

A menos q siga o conceito de classe interna daí pode:
veja o ex:
public class Teste1{

protected class Teste2{

}
}

Essa é padrão hem…

for(int i=0;i<10;i++)
                System.out.println(i);
                System.out.println(i); //aqui não pode usar o i

Muitas linhas antes e depois do for… confunde bastante.
uma vez que o código está cheio de outras coisas.

q legal… nessa eu erraria se caisse na prova…

fiz uns pequenos teste e descobrí q assim já pode:

public static void main(String[] args) { for(int i=0;i<10;i++) { System.out.println(i); System.out.println(i); } }

sulito:

robsonsm:

isso aqui tbm pode gerar dúvidas quanto a compilação:

a instrução compila normalmente.

ciclo infinito.

ciclo infinito não significa erro de compilação

int n1 = 07; //ok
int n2 = 08; // nao compila
int n3 = 09; // nao compila
int n4 = 010; // ok

System.out.println(n1); // imprime "7"
System.out.println(n4); // imprime "8"

Ou seja, se você ver o numero 0 antes de um número, saiba que está representando um número octal (base 8 ).

Galera se liga nessa do switch …

public static void main(String args[]){
		int i=30;
		switch (i) {
		case 10: System.out.println("Dez");			
			break;
		case 20: System.out.println("Vinte");			
			break;
		case default: System.out.println("Default");
			break;
		case 30: System.out.println("Trinta");			
			break;
		case 40: System.out.println("Quarenta");			
			break;
		case 50: System.out.println("Cinquenta");			
			break;	
		}
	}

Dá erro de compilação…a tag default não pode ter a palavra case !!!

Vou postar uma aqui:

public class Test {

	private String str; 
	
	public static void print() {
		System.out.print(str);

	}

}

Variáveis não static sendo acessados por um método static.

show…

Essa caiu no simulado ExamLab

public class Greek {
   int i = 1;
   
   public int getI() {
      System.out.println( "Super" );
      return i;
   }
   
   public static void main( String... args ) {
      Greek ga = new Arabik();
      
      System.out.print( ga.i + " " + ga.getI() );
   }
}

class Arabik extends Greek{
   int i = 2;

   public int getI() {
      System.out.print( "Sub" );
      return i;
   }
}

Eu achei que a saída seria "1 Sub2", já que chamada foi realizada sobre o tipo da super classe o valor da expressão "ga.i" seria 1 (classe Greek) e na invocação do método sairia o resultado da sub classe "Sub" e depois 2 na resposta do método.

Mas a resposta correta era "Sub1 2", pois antes de "printar" o valor a expressão inteira deve ser verificada e na verificação da chamada getI() já seria impresso o valor "Sub", depois disso o resto sairia conforme eu tinha previsto.

Bom, acho que essa é uma boa dica, já que nunca tinha passado por algo assim.

[]
Éberson

luiz_renato:

Ae Pessoal,

Esta sobre thread’s nâo vi em simulados mas no blog do Raphael Rodrigues (que segundo ele estava num simulado) acho que vale a pena dar uma olhada:
http://raphaelrodrigues.wordpress.com/2009/11/25/java-threads-para-scjp-pegadinhas/

[]'s
Luiz Renato

Essa caiu no meu simulado ExamLab… e pior… caiu na duas versões… eu achei que era repetido… acertei uma e errei a outra…

oi, blz?

adorei o exemplo só q não entendí muito bem...

vc quer dizer q o código abaixo tem duas saídas diferentes? pois no meu teste só deu AABB

public Test2(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());
		}
	}

Nesse caso não é possível prever o resultado, não é garantido que a Thread A vai sempre começar antes de B nem que o sleep de cada uma vai durar apenas 1 segundo.

Não sei se cai, pq nunca estudei para a certificação, nem fiz a prova.
Entretanto, é bom ter atenção com a precedência de operadores, como o exemplo desse tópico do dota:
http://www.guj.com.br/posts/list/219082.java

pq não é garantido? não foi setado o sleep? e o run() não executaria a primeira Thread com o método start()?

Quem te garante que vai ser o 1º Thread que deu start? Além do mais que nao existe sincronização nenhuma ai. Pois os monitores sao diferentes.

Quem decide por quanto tempo e em que ordem as threads irão rodar é o escalonador do SO.
Por isso não há qualquer tipo de garantia.

Os dois start() só iniciam as threads e as posicionam na lista de escalonamento. Mas um sistema single-thread, por exemplo, poderia terminar o main e depois executar as threads uma a uma, na ordem inversa das quais foram criadas.