Re: Why JCOM, JACOB and JAWIN?

cyril <[email protected]>
Newsgroups gmane.comp.windows.devel.jawin
Message-ID <001701c54070$09e20790$0101c80a@Underground>
Try to use vtable with OLE Automation like it is done MS VB. But there are
two restrictions
- it should be STA,
- the interface should be IDispatch compatible.
I tested this.
Another option is to generate IDispatch for vtable in runtime. Remember
WIN32 function "CreateStdDispatch".

About wrappers, I have meant C++ JNI wrappers for java classes selected to
automate JNI code writing. With my tool I write this code fast. It helps me
to make effective memory management, reduce a number of java references. In
JNI code I use local heap as less as possible. You know that JVM also uses
local heap and JNI code can cause "Out of memory" exception. This was done
in my version of JAWIN. But in this case you should know what type of
allocation is allowed for proper data. Sometimes I use local heap because
this memory should local and freed by COM module. To test this I have made a
simple profiler for memory management and COM reference trace.

BTW what about named parameters in events (parameter order may be
arbitrary)? My JAWIN version (it is called OLEJA) supports this option. I
faced with this problem while writing examples for MS Office.

Vitaly

----- Original Message -----
From: "Robert Hastings" <[email protected]>
Newsgroups: gmane.comp.windows.devel.jawin
Sent: Wednesday, April 13, 2005 7:10 PM
Subject: Re: Why JCOM, JACOB and JAWIN?


> Hmm, the C++ wrapper gen of jSegue is just one part of the whole project.
> Most of the time we use tlb2java which generates java bindings to COM
> objects. In fact, I sometimes use it to verify that I can generate
bindings
> when I'm trying to debug jawin issues. Just recently I generated bindings
to
> the QuickBooks XML processor with both jSegue and jawin. They both worked
> fine. They both used IDispatch underneath to access the underlying COM
> objects.
>
> But, as I was saying in another post one of the COM servers we were
> targeting had their IDispatch interfaces broken, so only vtable bindings
> worked. jSegue supports vtable bindings for dual or IUnknown based
> interfaces.
>
> Robert
>
> -----Original Message-----
> From: Discussion of Java/Win32/COM integration with Jawin
> [mailto:[email protected]] On Behalf Of Vitaly Shelest(home)
> Sent: Tuesday, April 12, 2005 11:46 PM
> To: [email protected]
> Subject: Re: [JAWIN] Why JCOM, JACOB and JAWIN?
>
> The main problem of jSegue C++ Wrappper Gen. is that it is written in
java.
> And if it uses Reflection to parse a java class it would the worst idea.
> Because not all classes can be loaded with Class Loader (classes with
native
> methods, or they use Security Manager, etc.). The code in C++ generated is
> half-finished. So JAWIN's idea is better. Try to debug it as me.
>
>   ----- Original Message -----
>   From: Robert Hastings
>   Newsgroups: gmane.comp.windows.devel.jawin
>   Sent: Wednesday, April 13, 2005 12:33 AM
>   Subject: Re: Why JCOM, JACOB and JAWIN?
>
>
>   Actually, I did signup as a developer on jawin, but since it does not
meet
>   all of my requirements I end up spending most of my time on jSegue.
>
>   Robert
>
>   -----Original Message-----
>   From: Discussion of Java/Win32/COM integration with Jawin
>   [mailto:[email protected]] On Behalf Of Kai Klesatschke
>   Sent: Monday, April 11, 2005 7:13 AM
>   To: [email protected]
>   Subject: [JAWIN] Why JCOM, JACOB and JAWIN?
>
>   -----BEGIN PGP SIGNED MESSAGE-----
>   Hash: SHA1
>
>   Hello maintainers,
>
>   during my inquiry for Java-Com-Bridges I found almost 3 projects on
>   SourceForge they are dealing with the same issue. IMHO all three
>   projects have the same problem. Less maintainers and the status of
>   development does not meet MY and maybe others requirements. Immediately
>   I had an idea, why not pulling the projects together?
>
>   Greetings Kai
>
>
>   -----BEGIN PGP SIGNATURE-----
>   Version: GnuPG v1.4.0 (MingW32)
>   Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>   iD8DBQFCWoXRo6yr2Zy87e4RAj3GAKDCcPRtDsgeiaUTyFqwkK50FNHb4ACffVA+
>   kp4QKph6AwxhVAWfUgxpUFE=
>   =clKk
>   -----END PGP SIGNATURE-----
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.