se voce usar o java 1.4, voce pode fazer isso pela API de preferences do java.util
soh que eh o seguinte, voce nao ve que edita o registro, mas no windows, ele vai editar o registro, no linux vai editar um arquivo bizarro, no soalris vai fazer outra coisa, assim por diante.
Realmente nao tem. Isso vem da propria concepcao da linguagem. Ela nao tem por alvo principal ser uma linguagem para tratamento de hardware, para criacao de sistemas operacionais. Entao ela nao se atem a peculiaridades de uma ou outra arquitetura. Java eh voltada a portabilidade. Desta forma detalhes dos hardwares atuais sao escondidos, como o sistema de interrupcoes. Talvez daqui a dez anos tenhamos computadores sem o uso de interrupcoes, mas java podera ainda estar la, visto que tudo eh abstraido pela maquina virtual.
A possibilidade sempre existe, na JNI, de fazer extensoes em C e C++, mas ai claro, o tratador, ou pelo menos uma ponte pode ser feita nessa linguagem, sacrificando a portabilidade.
Acho que JNI foi construida de uma maneira muito ruim, pessima mesmo, para ninguem usar. Para nao sacrificar portabilidade. Eh realmente uma maneira horrivel de se extender uma linguagem. Acho estranho ainda ser a unica opcao(fora o cni da gjc) que a sun fornece para extender o java, visto que outras linguagens tem usado com muito sucesso extensoes. Posso citar por exemplo o python, com o utilitario swig, que permite que C/C++ e python convivam em uma grande harmonia, sem muita dor de cabeca.
Mas como quem manda eh a sun e seus amiguinhos, temos que fugir sempre de implementacoes nativas, e quando nao ha saida, ter que amargar o uso do JNI
tanque, swig também funciona com JNI. Nunca testei, mas se funcionar tão bem como para as outras linguagens, ajuda muito.
Agora, voce já tentou usar diretamente a API do python? Pq eu acho ela tão ruim, se não pior, que JNI. Ter que ficar se preocupando com contagem de referencia por todo canto alem de ser um saco costuma produzir montes de bugs dificeis de achar.
Uma API muito bem feita foi a para embedding com lua. Simples e poderosa, não tem tanta frescura quanto jni.
Já existiram outras apis para chamar código nativo com java. Nas primeiras VMs da Sun tinha a tal da raw interface, que deixava a VM muito mais exposta ao código nativo que jni faz.
Realmente parece que o Swig evoluiu bastante, suportando muito bem a linguagem java. Talvez o ponto que eu queira colocar que nao ficou claro eh relacao a afinidade da linguagem com C/C++. Java possui pouca ou nenhuma afinidade com extensoes em C/C++. Ele soh define que para chamadas de coisas em C/C++ a chamada tem que ser por intermedio de funcao estatica. Alem disso nao existe um mapeamento direto entre ponteiros nas duas linguagens , visto que java nao tem ponteiros.
Ja o python (python original) eh uma linguagem muito mais proxima de C/C++. Ela permite que haja um mapeamento praticamente direto entre classes em C++ para classes em Python, Eh possivel, talvez, ate termos uma classe python que extende uma classe C++. Nao que isso seja algo positivo, mas isso eh feito com muito menos custo no python que no java.
Eh questao de concepcao da linguagem mesmo. Nao tem o que fazer. O python realmente foi feito para permitir que um grande numero de extensoes fosse realmente feito em C/C++. Ja o java possui grande parte do seu core escrito em java mesmo, como o java.lang, java.util. No python, muita coisa ta em C/C++. As vezes existem ate as duas opcoes, por exemplo, a biblioteca pickle (suporte a serializacao) tem uma versao chamaca cPickle, que implementa a mesma interface em C, com maior performance.
Meu objetivo aqui nao eh gerar um flame, eh simplesmente apresentar a diferenca entre as linguagens. Python eh uma linguagem com maior afinidade com C/C++. A primeira e a mais proxima que pude imaginar. POderia ter citado pascal, onde voce poderia definir na interface um metodo native, vindo de uma dll, ou o vb, que com a diretiva declare voce pode dizer que a funcao se encontra implementado numa dll.
Isso você tem toda razão, java nunca foi concebido para ser uma linguagem de extensão, mas sim uma linguagem ponta-a-ponta.
No python, assim como em outras linguagens, você consegue facilmente mapear um objeto C++, em java isso exige 1 enorme quantidade de glue-code.
Integrar código nativo com java é 1 grande pé no saco. Nesse ponto a MS deu um show com o C#. Em questão de meia hora consigo mapear todas funções de uma liblioteca simples e utilizá-la dentro do c#, com java vou torrar um dia inteiro escrevendo 1 porrilhão de glue-code.