Arquivo Discussoes de Programacao e Tecnologia Alguém poderia me dar um exemplo ? Eu entendi que isso ocorre porque o método é definido como final mas, ficou no ar, ainda, o que seria: “a remoção das chamadas aos métodos final e a sua substituição pelo código expandido(?!?!?) em cada localização de chamada de método”.
Põe só um trechinho de código aí por favor ?
Obrigado.
Simples...
public class Teste {
public static void main(String[] args) {
teste();
}
public static final void teste() {
System.out.println("...");
}
}
Vira
public class Teste {
public static void main(String[] args) {
System.out.println("...");
}
}
hmmmm… e isso é útil… pra ??? 
Valeu mermo ein Bani tais me ajudando pra cacete 
Bom, não sei como fica o assembly disso (louds?!??), mas inlining serve para que você empilhe uma chamada a menos de um método, tornando seu código mais, hmmm, eficiente (talvez eficiente não seja a palavra correta, mas fica assim até eu pensar em um sinônimo).
Inlining de metodos e’ uma tecnica usada pelo HotSpot (ou outro JIT, just-in-time compiler) pra evitar fazer mais uma chamada de metodo. Considerando que uma chamada de metodo, quando repetida diversas vezes dentro de um loop, pode se tornar um pouco cara, o JIT “enfia” o codigo do metodo chamado dentro do chamador. Mas isso, definitivamente, nao e’ algo que acontece o tempo todo, e nao e’ necessario so marcar o metodo como final - sao os algoritmos do JIT que dao a palavra final se o metodo devera ser colocado inline ou nao.
Ou seja, isso e’ um detalhe de otimizacao beeem desconsideravel, a menos que vc esteja absolutamente paranoico com performance… e, nesse caso, tem coisas mais custosas pra vc otimizar 
dúvida, a opção -O (optimize) do javac atualmente está servindo pra alguma coisa? ela nem aparece na documentação http://java.sun.com/j2se/1.4.1/docs/tooldocs/windows/javac.html
Se ela ainda serve pra alguma coisa, eu realmente nao consegui achar nada. A unica razao que eu vejo pra ela ainda estar lá é pra dizer pro compilador “nao, eu nao quero os simbolos de debugging (numeros de linha e nomes de variaveis no meu .class!”)
O uso de inline pode fazer você chegar num erros meio chatos de achar.
Exemplo:
public class A {
public static final String str = "teste";
}
public class B {
public static void main(String args[]) {
System.out.println(A.str);
}
}
Colocando essas classes em dois arquivos diferentes e compilando tudo ocorre bem. Agora muda o código de A.java para:
public class A {
public static final String str = "não é mais teste";
}
Se vc recompilar só o arquivo A.java e mandar executar B vc vai ver que vai ser impresso “teste”
O motivo é bem óbvio, mas eu tava usando uns membros estáticos em um projeto com muitas classes. Quando mudei um desses membros o meu sistema pirou de vez. Até achar que o problema tava no inline deu um trabalho imenso, sem contar que eu tive que recompilar tudo.
É bom tomar cuidado com isso.
Métodos final ou private, se não estiver ocorrendo overwrite no segundo, são uma excelente diga para a JRE de “faça inline desse método, se preciso”. Porem como o cv mesmo falou, as boas VMs são suficientement espertas para ‘desvirtualizar’ e fazer inline de muitas chamadas sem precisar auxilio do programador.
Ou seja, use final com fins de espressar melhor o contrato da tua classe, esse método não pode ser overwritten, essa classe não permite sub-tipagem, etc.
Eu imagino que o único lugar onde final faça uma real diferença seja em campos estáticos, uma vez que ‘static final’ é uma constante, ai talvez os JIT’ers falhem.
Isso não seria o mesmo que utilizar a opção -g:none ?