Pois é pessoal,
la vou eu com mais um desafio, só para variar um pouco 
Pois bem, o desafio de hoje é :
Como sobreescrever a classe java.lang.Thread do java?
sendo esse um pacote proibido pelos classloaders…
colocar no bootclasspath vale, mas…
como fazer com que as threads continuem funconando normalmente?!?!
Objetivo : Fazer um sandbox para outra app java.
Quem disse?
primeiro o source do ClassLoader.java
depois o metodo native defineClass(0,1 e 2)
Qual o Premio do Desafio ???
Vale o premio “Hacker da JVM” do ano
eu julgo que ficara sem resposta,
igual o meu outro desafio http://www.guj.com.br/posts/list/133607.java
estou virando campeão de inventar esse tipo de pergunta.
uma ideia seria vc fazer o override dos metodos que vc precisar nao??
http://www.java2s.com/Code/Java/Threads/TestOverrideThread.htm
na verdade este codigo só da pra fazer override do UncaughtExceptionHandler
Sim, seria a melhor maneira
porem…
quem tentar instanciar a classe Thread dentro do meu sandbox
acabaria instanciando a minha que extends a Thread do java.
porem, não esta sendo possivel fazer esse “roteio”
com classloaders.
a duvida do topico é justamente essa…
como “enganar” uma app de terceiro entregando pra ela
uma Thread customizada.
[quote=dyorgio]primeiro o source do ClassLoader.java
depois o metodo native defineClass(0,1 e 2)
:)[/quote]
Pois bem, acabei indo vasculhar o código fonte e ClassLoader.java, pelo menos na VM da Sun, não tem javadoc para os métodos que você citou. E, a propósito, é perfeitamente possível fazer
[code]public class MyThread extends Thread {
…
}
[/code]
Se bem que, acredito que, da mesma maneira que seu outro post, a idéia deste é criar uma gambiarra sem sentido. Então, porque ao invés de tentar elaborar coisas sem sentido, você simplesmente não gasta o tempo pensando em coisas elegantes?
P.S: Quanto ao outro post, dos objetos do stack, não sei se você sabe, mas todas as linguagens de programação são implementações de autômatos a pilha. Recuperar um objeto do stack é uma típica capacidade de Máquinas de Turing, que estão à frente dos autômatos a pilha e, portanto, é impossível de fazer com qualquer linguagem atual.
[]´s
O objetivo do post é clarificar o porque não ser possivel injetar uma classe Thread customizada no java,
e não o quanto isso é ruim ou sei la mais oque,
mais obrigado pela resposta, apesar que vc só falou ser possivel e não disse como,
pelo menos vc se deu o trabalho de
responder
Para vc ver que não é possivel, basta vc implementar um classloader customizado
e tentar carregar outra classe do pacote java.*
PAM!! exception…
os metodos native não tem javadoc porque são private,
baixo nivel java.
Edit : Ja ia me esquecendo, pegar um objeto do stack ao meu ver não tem a ver com a linguagem
pois o java possui o objeto em memoria, possui o stack, e o mais importante de tudo
se tu rodar uma app java em modo debug, tu tens isso, vide DEBUG do eclipse.
A resposta para aquele post vai passar por esse caminho…como conseguir essa info fora do modo debug.
[quote=dyorgio]O objetivo do post é clarificar o porque não ser possivel injetar uma classe Thread customizada no java,
e não o quanto isso é ruim ou sei la mais oque,
mais obrigado pela resposta, apesar que vc só falou ser possivel e não disse como,
pelo menos vc se deu o trabalho de
responder
Para vc ver que não é possivel, basta vc implementar um classloader customizado
e tentar carregar outra classe do pacote java.*
PAM!! exception…
os metodos native não tem javadoc porque são private,
baixo nivel java.
[/quote]
Quanto a isso, não sei, nunca tentei… Aliás, porque tentar, mesmo?
Sim, mas veja o conceito aqui: o Eclipse intercepta a stack, mas não a possui. Por isso, pra ele, é possível pegar esses objetos. Aí, entra aquele problema que te disse: uma linguagem de programação implementa um autômato a pilha e, portanto, não pode voltar na pilha de execução ao seu bel prazer (precisa voltar do estado em que se encontra). Por isso que um objeto só se torna disponível novamente quando está no escopo de um método, entende?
[]´s
O porque , vou repedir, não é o importante…
o desafio é fazer, pois ainda não julgo impossivel, apenas BEM dificil.
quanto ao objeto do stack, realmente o eclipse intecepta, não o possui…
provavelmente via JDI(Java Debug Interface) masssssss, tudo tem um mas,
a JDI sim, essa sim possui, afinal, ta tudo ali, sem o programa ter que voltar ao stack.
mas cara, apenas linkei os posts para fazer ligação de “desafio”,
a sua resposta foi bem vinda, e sim, da uma ideia do porque o java por padrão
não tem o object do stack disponivel.Mas acho melhor responder la naquele topico,
esse ficou poluido :(, saiu do objetivo dele 
Alguem mais que saiba customizar classloaders e ja fez esse tipo de “hack”
na VM pode nos responder?