Dúvidas diversas sobre SCJP

Programação Java
#1

Pessoal,

Meu voucher está pra chegar essa semana e pretendo fazer a prova assim que ele chegar (no máximo 1 semana depois).

Esse fim de semana dei uma revisada no livro. Estou fazendo uma leitura dele novamente para ver se ficaram alguns pontos que eu possa ter esquecido. Estudei até o capítulo 5 e seguem algumas dúvidas que tive(ainda bem que não foram muitas):

  1. Mesmo se uma classe tem nível de acesso default, seu construtor pode
    ser tanto public quanto protected. Mas por que isso? Acredito que não seja
    possível chamar o construtor de uma classe com acesso default através de
    uma classe fora do pacote, já que fora do pacote é como se a classe não
    existisse. Se eu estiver certo, não deveria dar erro de compilação quando
    uma classe tiver acesso default e tentarmos escrever um construtor public
    ou protected?

  2. Existe especificação quanto à forma que a JVM carrega as classes? Se
    algum subconjunto ao iniciar, ou se à medida que vai precisando usar uma
    classe que ainda não foi carregada, ou alguma outra forma? Essa
    informação é necessária para responder questões que envolvem 2 ou
    mais classes com blocos de inicialização static, para sabermos se é
    possível dizer qual dos blocos será executado primeiro.

  3. Eu aprendi que não podemos acessar membros de instância antes de
    chamar this() ou super() ou nem mesmo passando como um argumento a this(meuAtributo) ou super(meuAtributo) dentro de um construtor (Ver
    página 79 do livro). Mas qual o motivo dessa restrição? Antes eu achava que talvez fosse porque o atributo não teria sido inicializado, mas segundo
    a página 260 (lá no final, onde mostra a ordem de execução na construção de um objeto) os atributos de instância são inicializados com o
    valor default antes da chamada a super(). Assim sendo, não vejo motivo
    para o compilador não permitir acessarmos atributos de instância antes de
    chamada a super();

  4. Se os wrappers são imutáveis, porque não posso colocar a seguinte
    variável em uma cláusula case, do switch: final Integer i = 10; ? (já
    aprendi que apenas constantes podem ser colocadas em case, mas
    concordam que o valor de i sempre será 10? Só não entendi porque não é
    possível fazer isso)

  5. Qual a saída (essa eu respondi, mas achei interessante colocar aqui)?

public static void main(String[] args) {
   int b = 1;
   if(b-->b+2==((b=1)==b--)){
      System.out.println("true: " + b);
   }else{
      System.out.println("false: " + b);
   }
}

Tirando a dúvida do item 2, acredito que as demais não são cobradas com esse nível de detalhe na prova, mas fiquei curioso pra conhecer as explicações.

Estou meio apertado essa semana, mas se comnseguir um tempinho, acredito que até sexta terei terminado de revisar o livro e colocarei as próximas perguntas.

[]'s

#2

Vamos lá :smiley:

1 - Bem, realmente não sei :oops:

2 - Parece que carrega quando precisa. Tenta criar três classes, compilá-las e após executar a classe principal, que usa as outras duas, apague uma delas. Dentro da sua classe principal vc pode ter uma condição para mostrar qual classe será instanciada. Se vc entrar com um valor q usa a classe que foi apagada vai gerar uma excessão (um erro na verdade) NoClassDefFoundError

Por exemplo:

[code]
import java.util.*;

public class Principal {

public static void main( String[] args ) {
	
	Scanner s = new Scanner( System.in );
	int n = s.nextInt();
	
	if ( n % 2 == 0 ) {
		new Teste1();
	} else {
		new Teste2();
	}
	
}

}

public class Teste1 {

public Teste1() {
}

}

public class Teste2 {

public Teste2() {
}

}[/code]

3 - O motivo é garantir que TODOS os contrutures (até chegar em Object) sejam executados antes de mecher com os campos da classe.

4 - Pq “i” pode ser null.

5 - false: 0

#3

Faltou um detalhe na 4

Os cases só podem ser usados com primitivos ou enumerações. Falei do null pq o objeto que “i” referencia é final em sí, mas a referência pode apontar para outro lugar concorda? Como null por exemplo.

Até mais!

#4

Então,

Em relação a 1, é uma pergunta interessante mesmo e continua pendente hehehe

Em relação a 2, com todos os testes que eu fiz até agora realmente daria pra assumir que a classe é carregada quando precisa, mas eu gostaria de saber com certeza se isso é especificação ou se eu e vc, por exemplo, não estamos usando uma mesma implementação de JVM que, por coincidência, usa essa maneira de carregar as classes.

Em relação ao 3, eu entendi agora… achei que não teria nenhum mal em acessar a variável de instância antes de chamada a super()… Em relação a leitura não teria problema, mas se pudéssemos atribuir valores antes do construtores das classes pais serem invocados, seria uma confusão.

Em relação a 4, na verdade a explicação dada no livro é que apenas constantes de tempo de compilação podem ser usadas em case (inclusive tb é essa mensagem que o compilador dá se vc tentar usar outra coisa). Acredito que quando a gente cria final Integer i = 10; o compilador teria condições de ver que o valor de i é 10 e nunca mudará, por ser final. A referência nunca vai apontar pra outro objeto, pois a variável é final, e seu valor nunca vai ser alterado, pois wrappers são imutáveis. Portanto, contanto que o valor dele não seja null no momento da declaração, não vejo outro motivo para não permitir wrappers final serem usados em case.

Em relação a 5, sem comentários hehehe, mas que é um saco ficar analisando toda aquela bagunça pra descobrir a saída e a inda o valor final de b, é imagina uma danada dessa na prova… hehehe

[]'s

#5