I need to call a RPC client which is implemented in C from a Java class.
The interaction is one way only(i.e) Java has to invoke specific functions in C, while C need not return anything to the calling Java code.
Can someone explain me the pros & cons in using either of the types (JNI/Runtime.exec)?? and which is the best option for my case?
Runtime.exec() will launch a separate process for each call. Your Java caller needs to consume the output of each process.
JNI would require a native, dynamically linked library. Depending on your operating system, you may need to explicitly export functions. You would define a Java class with "native" methods, generate a C header/stub file with javah, and implement the native methods by calling your C client functions.
Runtime.exec() probably consumes the most resources. I personally would use an in-process call to native code.
Instead of JNI, consider using JNA, which makes it easy to call C functions from Java without an ad hoc native glue layer. Your C functions would need to be in a native, dynamically linked library. In Java, you declare their signatures, load the library, and call the functions.
For Windows DLLs, be aware that you need to export functions for them to be available from outside the DLL.
Related
Is there a way how I can call golang functions from jsonnet?
Now that there is a go port of jsonnet and for example ksonnet is adding custom native functions I am wondering if there is a way how to extend jsonnet with more native functions?
I have many packages written in golang (with unit-testing, etc) and now it seems like I will need to rewrite some of them into jsonnet.
As discussed in the go-jsonnet's issue Custom builtin functions #223, you can introduce your custom golang functions but a pluggable support is not available - you cannot directly use the functions in a jsonnet binary.
You need to compile your own binary/library that creates an instance of vm.NativeFunction jsonnet VM and then add your native functions there.
I was looking here:
http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28395/toc.htm
but everything looks like C or C++. Can I use any other language to use the OCI?
Thanks.
EDIT: I need to use direct path for LOB object (blob, clob, etc.) I believe I have to use the OCI to do that.
EDIT: I base my OCI assumption on this: Can a direct path insert into a LOB column?
According to Oracle
"Oracle Call Interface (OCI) is the most comprehensive, high
performance, native 'C' language based interface to the Oracle
Database that exposes the full power of the Oracle Database."
However, there are different ways to work with an Oracle database. What sort of language do you want to use, and what do you actually want to achieve?
If you want to use Java, you can use JDBC OCI. I believe that there are also ways to acess OCI through Perl, Python, and Ruby, if you want (though I've never used them).
Theoretically, every language that can call standard C functions should be able to use OCI. This includes languages such as C++ and Delphi, but also includes managed languages such as C# (that can access these functions through P/Invoke) or Java (with Java Native Interface).
However, if your goal is simply to access the Oracle, but don't care to do it specifically through OCI, it is much better to use whatever library is specifically geared towards your language of choice. For example, use ADO.NET under C# or JDBC under Java.
Most of these libraries use OCI internally anyway (with notable exception of some direct-to-wire ADO.NET and JDBC drivers).
You will find that most Oracle APIs in other languages are really bindings to the OCI using whatever mechanism that language normally uses to interoperate with C libraries. Examples include cx_Oracle for Python, OCI*ML for OCaml and Oratcl. These typically abstract the OCI which is very low level, into something easier to use from a high-level langauage (e.g. connecting to a database is one line in those langauges, but it is a page of code in OCI as everything must be set up explicitly).
What is the difference between a Win32 or DirectX wrapper and a Win32 or DirectX framework?
A wrapper is typically a family of functions that contain the function calls for a library or API like win32, DirectX, etc., in some sort of abstracted way to the end-user. Many times they are customized so that the functions you call in the wrapper is not exactly the same as the original API, or some default parameters have been setup for you to make working with the API a bit easier. Also in the specific instance of a language wrapper, the functionality has been embedded in the language's run-time API, and then exposed to the end-user. For example, one could expose the win32 calls to a Python user by creating a C-library plug-in for python with the win32 API calls, and then creating a python library that may have customized python functions that call the win32 functions exposed by the C-library plugin. In this case the Python library "wraps" the native C-based win32 library.
A framework is like a wrapper, but in its most-typically used definition, it's a little different in that it works by creating some type of run-time environment that you create callbacks to plug into, so that when the frame-work wants to-do some task, you've written a function that is called for that task. This is called the "Hollywood Principal" of programming, which basically says, "don't call us, we'll call you". So in working with this model, you create functions, register them with the frame-work, and your function is called when the frame-work needs to call it, and the framework passes its own internal parameters as your function arguments. A good example is a GUI-framework, where you create callbacks for buttons and other events, and the GUI-framework calls those functions as it processes its runtime event-loop.
So I guess one way to think of the primary differentiation between the two is that wrappers tend to be static (i.e. exposing libraries and functions with customized function calls either that fill-in default values for you or translate them to a different language), whereas a framework tends to be dynamic (i.e. its a runtime system that you create callbacks for, and register it with the framework that are then called during some time of runtime event loop or kernel, etc., like a GUI toolkit).
Wrappers tend to make it possible (oftentimes easier) to access complex systems, complex code or combinations of calls from multiple classes and so forth. For example, you may create a Facebook wrapper in C# or Java to interact with getting user data from the Facebook API, which has many REST-based functions which return JSON. A framework is a set of related objects, functions, and so forth to provide a particular functionality, or enhance a particular functionality, so you wouldn't use either a wrapper or framework. Oftentimes you'll use a both, using a wrapper to access a framework. This is especially true with legacy systems :)
I'm working on a program that read arp cache from machine. I'm using Cocoa. There's a library called libdnet (libdnet.sourceforge.net) which has arp reading function. But I don't know how to write a code to use that function. Please help.
You'll need to know C and apply that knowledge to call the library's functions. See this question for links to C-learning resources.
Objective-C is a superset of C, so you'll be able to integrate the C code to call those functions into your Objective-C methods just fine once you know both languages.
I have an ATL C++ in-proc COM component. This component is not for external use - I only need it for use in our application.
Once in a while users put it into COM+ and this leads to all sorts of weird errors - "Access denied", etc which I'd like to just never hear about. The best way would be to do something that would prohibit putting the component into COM+ so that it can only be used as an in-proc server. Is there a way to do this?
Do you implement only your own interfaces? If so, you should be able to mark them "[local]" in the IDL, and then strip the module of all marshalling information (type library, P/S), etc.
If there's no basis for marshalling available, COM+ shouldn't be able to register the module. COM+'s mechanism for interception relies on forcing objects into a remote context and getting in between the proxy and stub and their corresponding parties. So, if you remove every opportunity for marshalling, it shouldn't be able to intercept your interface methods.
Prevent registering your module is finalized and then use your DLL as described in this article Creating COM objects directly from the dll.