Problema - ActiveX Bridge / Java Bean windows 64-bits

Você pode rodar seu programa em uma versão do Java de 32 bits, que ela roda corretamente em um sistema operacional de 64 bits.

Sim, isso funciona perfeitamente.

O problema é o cliente que não quer instalar o JDK 32-bits de jeito nenhum.
Ele quer rodar tudo em 64-bits…e não esta funcionando.

Diga então que ele tem de usar uma outra solução que não envolva DLLs.
Talvez reescrever as aplicações VB 6 (que aliás é 32 bits, não? Nunca existirá um VB 6 de 64 bits) em Java. (Reescrever em VB.NET não é razoável porque chamar o Java a partir do VB.NET envolve usar uma solução como o J/Integra, que aliás nem sei se há em 64 bits, e isso talvez saia um pouco caro. Não conheço soluções “gratuitas” ou “baratas” para chamar o Java a partir do .NET de maneira simples.
Acho que ele vai mudar de ideia, já que isso vai sair bem caro.

É estranho, pesquisei bastante e não encontrei uma explicação do por que existe o arquivo packager.exe no JDK 32-bits e não existe no JDK 64-bits

thingol:

Diga então que ele tem de usar uma outra solução que não envolva DLLs.
Talvez reescrever as aplicações VB 6 (que aliás é 32 bits, não? Nunca existirá um VB 6 de 64 bits) em Java. (Reescrever em VB.NET não é razoável porque chamar o Java a partir do VB.NET envolve usar uma solução como o J/Integra, que aliás nem sei se há em 64 bits, e isso talvez saia um pouco caro. Não conheço soluções “gratuitas” ou “baratas” para chamar o Java a partir do .NET de maneira simples.
Acho que ele vai mudar de ideia, já que isso vai sair bem caro.

Bom, muito obrigado.
Estou começando a acreditar que não existe uma forma de gerar a dll diretamente no ambiente 64-bits.
Já pesquisei em tudo quanto é lugar e não encontrei nada a respeito.

Eu consigo gerar no ambiente 32-bits que é emulado no 64-bits…

Blz, valew!

A explicação é a seguinte.

Diferentemente da transição que houve entre o Windows de 16 bits e o Windows de 32 bits (onde era possível você carregar uma DLL de 16 bits em um programa de 32 bits e vice-versa, usando umas APIs de interoperabilidade), não há como você chamar uma DLL de 32 bits a partir de um programa de 64 bits e vice-versa. ( 64-bit Windows Programming - Running 32-bit Applications ). Como o “packager.exe” é na verdade algo que cria uma DLL ActiveX de 32 bits para poder chamar a JVM de 32 bits, se a Sun estivesse interessada, ela poderia criar um “packager64.exe” que criasse uma DLL ActiveX de 64 bits para poder chamar a JVM de 64 bits. Mas ela não deve ter feito isso, porque o caso de uso clássico (aplicações VB que querem chamar uma classe Java) não aceita DLLs ActiveX de 64 bits, somente de 32, e a outra maneira que isso iria funcionar (registrar a DLL de 64 bits no COM+ para poder ser acessada pelo VB 6) não é muito usada.

De qualquer maneira, se você for suficientemente corajoso, pode baixar os fontes do JDK em http://download.java.net/jdk6/source/ e ver se você consegue criar um “packager64.exe” - obviamente isso requer saber programar em C++, não exatamente Java, e você só conseguiria criar uma DLL de 64 bits, que teria de ser registrada no COM+.

thingol:

A explicação é a seguinte.

Diferentemente da transição que houve entre o Windows de 16 bits e o Windows de 32 bits (onde era possível você carregar uma DLL de 16 bits em um programa de 32 bits e vice-versa, usando umas APIs de interoperabilidade), não há como você chamar uma DLL de 32 bits a partir de um programa de 64 bits e vice-versa. ( 64-bit Windows Programming - Running 32-bit Applications ). Como o “packager.exe” é na verdade algo que cria uma DLL ActiveX de 32 bits para poder chamar a JVM de 32 bits, se a Sun estivesse interessada, ela poderia criar um “packager64.exe” que criasse uma DLL ActiveX de 64 bits para poder chamar a JVM de 64 bits. Mas ela não deve ter feito isso, porque o caso de uso clássico (aplicações VB que querem chamar uma classe Java) não aceita DLLs ActiveX de 64 bits, somente de 32, e a outra maneira que isso iria funcionar (registrar a DLL de 64 bits no COM+ para poder ser acessada pelo VB 6) não é muito usada.

De qualquer maneira, se você for suficientemente corajoso, pode baixar os fontes do JDK em http://download.java.net/jdk6/source/ e ver se você consegue criar um “packager64.exe” - obviamente isso requer saber programar em C++, não exatamente Java, e você só conseguiria criar uma DLL de 64 bits, que teria de ser registrada no COM+.

Entendi.
Muito Obrigado pela Ajuda!
Por enquanto vou debater com o cliente para ele instalar o Jdk 32-bits mesmo hehe…Ainda não tenho tanta “coragem” assim para baixar os fontes do Jdk e criar um “packager64.exe” hehe.

Obrigado!

Sim, você deve perguntar ao seu cliente para instalá-lo em 32 bits … 64 bits em vez …
Ele irá correr wihtout qualquer problema com isso.

Jack
Recovery Software