Java vs C
 

Am in need to write some code to retrieve some information from an application via an API (available in either C or Java) to feed a system's input.

My line of thoughts are either of the following:
C
1) Write the code in C using the C API.
2) Compile this C code into shared library (.so format) or program (.lx format).
3) Have the downstream system to call this shared library (ie polling) to retrieve information and spit it out.

Java
1) Write the code in Java using the Java API.
2) Compile this Java code into a .jar file.
3) Have the downstream system to call this via something like "java <name>.jar".

In either case, the code will be written to exit after returning the information required (kind of like a script). However, my understanding is the Java program needs to start the JVM, which means there is a start up penalty (ie delay in providing information). Is this significant to be of concerned? And can we compile Java programs into shared libraries (.so format)? Is there any difference in performance between calling .lx and .so?

It depends what is significant to you. Can you not find more concrete info around loading time of a shared library vs JVM startup? Or make a simple prototype that returns hard-coded data for you to test with your downstream system?
There may something about going either implementation route that is easier to develop, or more efficient to process the data once started, we can't tell.

JAVA?
 

Java is fancy, powerful interpreter, and the startup overhead CAN be significant. If your application is small and does not force the load of many additional files, I doubt if the startup time will be a problem.

For maximum performance (and scalability) I would recommend doing it in C or C++. For speedy prototyping or a test case, java should suffice.

Decide where you think this project is going. If it becomes permanent, which would you prefer to spend the next five years supporting?

Sorry, if the application is running under an OS, how from another application can you call function the application for which you have that .so library ?

I.e. to me something doesn't add up at the architectural level, i.e. at the level of who the initiator is, is there an IPC between the applications, if yes, how the IPC in detail is implemented, etc.

The same exact questions apply to the Java possibility with the conceptual overhead of having JVM in the way.

Sorry for the late reply. Essentially there will be 3 processes:
Process A
-Program from which information will be retrieved from via either a C or Java API

Process B
-Either the C .so library or C .lx executable or Java process written to retrieve information from Process A

Process C
-Program that either calls the C .so library at run time, or calls the C .lx or Java executable as a child process to gather information from Process A.

You still haven't answered the question: 'How "Process B" is going to retrieve information from "Process A" ?'. The intent of an OS is to isolate/insulate the processes, i.e. normally one process can not retrieve information from another, and special programs like debuggers (e.g. 'gdb') are created in order to be able to retrieve information from unmodified process, and debuggers modify binary code of the program to be debugged in order to be able to retrieve information.

So, your "Process A" needs some means of IPC to be built in from the getgo, i.e. you have to first think of IPC mechanisms to be used, of thread model (single thread, multiple threads), of data consistency, i.e., for example, will "Process B" be protected from retrieving data currently being modified by Process A" and thus invalid data, etc.

So, use an existing API to create another API that does the same thing for the same language?

So, use an existing API to create another API that does the same thing for the same language?

Are you sure you don't mean to create an application, using one of the provided APIs, that exports data at runtime, in some portable way? If so, I assume your real question is about how to export the data portably. To answer that would require more information about both the producer(s), the consumer(s), the data and runtime requirements. What kind of data source are you using? What kind(s) of application(s) need the data? What kind of data is it?

--- rod.

No it's not like that. Basically Process C is not able to retrieve information from Process A directly as it can only read from say a file, or receive information via an RPC method that is not supported by Process A. So there's a need to write something else (either in C or Java) to retrieve the details from Process A and feed it to Process C in a format that Process C supports.

Essentially yes it needs to be portable but that's going to be the case anyway if I use either Java or C. The real question is whether I should choose Java or C based on performance. While I do know I can compile C into .so library, I don't know if the same can be done with Java source code. If I can't compile Java into .so library, I most likely won't consider the use of Java given the penalty involved with the JVM start up.

You are confusing two unrelated issues. Creating shared object libraries with C or jar files with Java are not part of the solution of run-time data export. Chances are, the API you speak of is already implemented as a shared object library or jar file, which you link/import into your application.
Runtime data export is not necessarily portable simply because of the implementation language. Much of the export mechanism will be dictated by the OS platform, and Linux is very rich is capabilities for this. Off the top of my head I can think of close to a dozen methods that may be applicable, but without knowing more details of your circumstance, it is impractical to suggest one or two. I do suggest that you start some research at Beej's Guide to Unix Interprocess Communication, a good primer on one class of IPC.
Please do give some more details of your 'Process A' and 'Process C'. What kind of performance parameters are important to you: net throughput, latency, peak throughput, etc.? Do you have one or many producers? One or many consumers? Does data flow in one direction only, or bidirectionally? If multiple consumers, do consumers share data, or do they get exclusive subsets? These are the kinds of questions that are probably more important than implementation languages.

--- rod.

The only thing I can say is Process C supports the specification of a .so library with a function that it can call. Now Process A offers an API either via C or Java. I know C can be compiled into a .so but I'm not sure whether Java can.

But you stubbornly evade the fundamental problem: process B can not call a function from process A directly. Regardless of .so objects (dynamic linking) or static linking. Period.

Process B can not see data belonging to process A unless the data is made shared, and this shared data has nothing to do with .so objects (dynamic linking) or static linking. Period.

Unless you have an idea how IPC can be/is realized in the OS of your choice, don't even start with this task.

All the above issues are not language-specific, i.e. you face them regardless of "C"/Java/any_other_language.

The terms you are using are unconventional, to the point of being nonsensical. What does 'supports the specification of a .so library with a function that it can call' mean, specifically?
The object code format (shared-object '.so' vs java '.jar') has nothing to do with runtime data exchange. You need to get past any misconception you're having about that. To get useful answers, you will need to supply more details. You can answer the questions I've posed already, without revealing private details of your application.

And, no, java cannot be compiled into shared-object libraries. Java only compiles to Java byte-code .jar library files.

--- rod.

Probably it can - using 'gcj' - the GCC Java compiler. I am not sure though. But you are right it has nothing to do with the fundamental IPC issues the OP is facing.