Hi Bill, I could go on about how hard it is to call the DLL directly and the relative difficulty with marshalling data ... but the truth is there is only one reason: Convenience. :)
I normally go with the path of least resistance and the com interface (which I only use 3 methods, DO, SETB, GETB) is a well defined and consistent way of interfacing J with MS development tools/languages. One of the things that I worked on during the start of this decade was making a J application server. It's basically a C++ Windows Service that listens for incoming communication from clients and invokes J.DLL to execute server side operation. Later on I had to use J.EXE since I started needing some capabilities of the WD system so converted to OLE/COM interface. Well, it worked quite well until I had to hand-over the system to another team since I'm being moved to do another project. I am not belittling my colleagues but I sincerely believe that only a handful of us knows how to convert C-style DLL convention to .NET. They could probably google it but most of the new guys probably doesn't know how to make an ms-dos batch file or would care to. In the guide, I actually recommended Oleg's way of integrating J into .NET. It's actually better since you have a "direct" control on the JEXEServer use and lifetime. I created a wrapper class to support our companies development infrastructure. So most of the developers here uses the methods with no idea that it actually uses J underneath. Hmmm. Your asking for pros/cons: J using COM Interface: PROS: 1. A lot of support function already available like data marshalling, datatype management, etc. 2. Since there are only a limited methods available, you know where and why your code is failing 3. No more figuring out what to do since the interface is well defined 4. Really easy to start with if your a n00b CONS: 1. You have to go through the OLE/COM interface for better or for worse 2. DLL HELL 3. Windows ONLY J using direct DLL invocation (ala Linux) PROS: 1. No overhead, direct DLL function manipulation 2. Cross platform 3. Full control of memory allocation and instance lifetime CONS: 1. Really hard to start with if your a n00b 2. You have to marshall your data yourself. 3. No automatic datatype conversion. 4. You'll have to research and convert C-style DLL to a function that is usable by your language Your mileage may vary but the company I work for is a Microsoft Partner ... which means developers I work with are MS-Peons (not that it's a bad thing ... I'm one too) and easily becomes confused if theres no intellisense. Teeeheee. =)) r/Alex -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of bill lam Sent: Thursday, August 13, 2009 12:18 PM To: [email protected] Subject: Re: [Jprogramming] C# and JEXEServer On Thu, 13 Aug 2009, Alex Rufon wrote: > Oh, this was the main reason why I wrote the guide J VB.NET which > can be found here --> > http://www.jsoftware.com/jwiki/Guides/J%20VB.NET c# or vb.net should have no problem to call j.dll directly without the middleware of com interface, and jexe/jdll com interface only provides a limited functionalities. Anyway, j.exe or j.dll itself is not (or will never be) managed. From your experience what is pro/con regarding calling j from dotcom using com interface vs direct dll call? -- regards, ==================================================== GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
