Using JAVA inside VBA

[Ghislain]

Hello,
I have a compiled commercial jar that I want to use in VBA, something like :
Dim javaob As Object
Set javaob = CreateObject("MyJavaAPIObject")
result = javaob.doSomething()

Unforunately, I can't convert the API to a COM object. As far as I know, it was possible 10 years ago but it is no longer possible unless you use commercial products (like EZJCom).

Do you have any ideas ?
Thanks,
Ghislain

 

[Arne Vajhøj]

I have a compiled commercial jar that I want to use in VBA, something like :
Dim javaob As Object
Set javaob = CreateObject("MyJavaAPIObject")
result = javaob.doSomething()

Unforunately, I can't convert the API to a COM object. As far as I know, it was possible 10 years ago but it is no longer possible unless you use commercial products (like EZJCom).

Do you have any ideas ?

12-15 years ago wrapping Java beans as COM objects was hot.

Not any more.

But try and see if something like:

http://www.rgagnon.com/javadetails/java-0045.html

still works.

Arne

 

[Ghislain]

Le samedi 11 mai 2013 18:41:16 UTC+2, Arne Vajhøj a écrit :

12-15 years ago wrapping Java beans as COM objects was hot.



Not any more.



But try and see if something like:



http://www.rgagnon.com/javadetails/java-0045.html



still works.



Arne

Thanks Arne but I had tried it already and the packager used is not workinganymore. I think the article was written by the time it worked (a long time ago)
Ghislain

 

[Ghislain]

Le dimanche 12 mai 2013 11:02:02 UTC+2, Chris Uppal a écrit :

Buy the commercial product ?



Wrap the JAR up in an executable that makes the API available over TCP/IP, and

then create a COM object that uses that network interface ?



If you are capable of developing simple COM objects in C++, then it mightbe

simpler to use something like Jace:

http://code.google.com/p/jace/wiki/Overview

to create JNI-based wrapper code that your COM-server layer can talk to.



Open Office / Libre Office used to be able to talk to Java, as I understand it.

Maybe they still can, and it would be easier for you to use your existing

commercial component with one of them.



If you have the remarkably good sense, not to mention good fortune, to bea

Smalltalk programmer, then you could use Dolphin Smalltalk (which can generate

COM objects) + my very own (advt.) JNIPort to bridge between COM and Java....



But buying the commercial product seems the best bet to me. After all, you've

already paid for the two products you want to connect, why baulk at paying for

the bridge too ?



-- chris

Thank you Chris for these interestings ideas.
I already bought the awfully expensive software but it is only available injava.
I'll try jace but I understand it is not as simple as it used to be with the sun's packager.
Ghislain

 

[Real Gagnon]

Le samedi 11 mai 2013 18:41:16 UTC+2, Arne Vajhøj a écrit :

Thanks Arne but I had tried it already and the packager used is not
working anymore. I think the article was written by the time it worked
(a long time ago) Ghislain

ActiveX bridge is still there in 1.7.

http://docs.oracle.com/javase/7/docs/technotes/guides/beans/axbridge/develo
perguide/index.html

Bye.

 

[Arne Vajhøj]

Le samedi 11 mai 2013 18:41:16 UTC+2, Arne Vajhøj a écrit :

I had tried it already and the packager used is not working anymore. I think the article was written by the time it worked (a long time ago)

Could you elaborate on "not working"?

COM has not changed.

Java version X has not changed.

Why did it work once and no longer?

Arne

 

[Arne Vajhøj]

Buy the commercial product ?

Wrap the JAR up in an executable that makes the API available over TCP/IP, and
then create a COM object that uses that network interface ?

If you are capable of developing simple COM objects in C++, then it might be
simpler to use something like Jace:
http://code.google.com/p/jace/wiki/Overview
to create JNI-based wrapper code that your COM-server layer can talk to.

Open Office / Libre Office used to be able to talk to Java, as I understand it.
Maybe they still can, and it would be easier for you to use your existing
commercial component with one of them.

OOo/LO use UNO and there is an UNO binding for Java.

And it would very difficult to remove as certain parts of OOo/LO are
written in Java.

If you have the remarkably good sense, not to mention good fortune, to be a
Smalltalk programmer, then you could use Dolphin Smalltalk (which can generate
COM objects) + my very own (advt.) JNIPort to bridge between COM and Java...

But buying the commercial product seems the best bet to me. After all, you've
already paid for the two products you want to connect, why baulk at paying for
the bridge too ?

You get lots of money by not spending them.



Arne

 

[Ghislain]

Le lundi 13 mai 2013 02:28:39 UTC+2, Arne Vajhøj a écrit :

Could you elaborate on "not working"?



COM has not changed.



Java version X has not changed.



Why did it work once and no longer?



Arne

Hello Arne,
"not working" means that after this command :
"C:\Program Files (x86)\Java\jdk1.7.0_21\bin\packager" -clsid {c6d7e762-5c47-4385-882d-b4679a013bdf} -out "C:\Program Files (x86)\Java\jre7\axbridge\bin" "C:\Users\gbenrais\Documents\NetBeansProjects\PersonBean\dist\PersonBean.jar" org.netbeans.examples.person.PersonBean

I get the following result :
Processing C:\Users\gbenrais\AppData\Local\Temp\\PersonBean.idl
Processing C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\oaidl.idl
Processing C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\objidl.idl
Processing C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\unknwn.idl
Processing C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\wtypes.idl
Processing C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\basetsd.h
Processing C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\guiddef.h
Processing C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\oaidl.acf
midl\oleaut32.dll : error MIDL2020 : error generating type library : SetFuncAndParamNames failed : get_address (0x8002802C)
La génération de la bibliothèque type a échoué


I tried with different java apis and it failed at the very same step with the same error

Thanks for your help,
Ghislain