I have a question to ask: suppose I create a extensible software application with a plug in architecture, so that new applications can be integrated in this tool. If a new application is written in a different language and needs to be integrated in this application of mine, do I need to use tools such as SWIG and the Java Native Interface (depending of the languages used of course)? If not, what do I need?
I have a question to ask: suppose I create a extensible software application with
Share
Okay. You’ve written some code. I’ll pretend it’s in Java because you mention SWIG and JNI.
How did this happen?
You planned for it. In which case, your application had an API that supported at least one additional language. "different language" doesn’t mean much because you — as developer — need to decide what languages you’ll tolerate. New languages aren’t a random event. They’re something you designed for.
You didn’t plan for it. In which case, someone else — contrary to your design — is demanding another language. A language you did not design for.
Choice 1 is the most common. You planned for specific languages, and wrote specific API libraries for those languages. You wrote — in those other languages — the necessary API library that would make those languages work with your application.
You probably don’t use tools such as SWIG and the Java Native Interface to create this API. If you want to support Python, you’d use a bunch of Python tools to permit Python programmers to use your application.
Choice 2 is less common. Either you didn’t plan, or you have someone who insists on writing their own API library based on their choice of language.
You probably don’t use tools such as SWIG and the Java Native Interface to create this API. If someone else wants to support Python, they’ll use a bunch of Python tools to use your application.
The real question is not "do I need to use tools such as SWIG and the Java Native Interface (depending of the languages used of course)?" Or anything like it.
The real questions are
How do I choose an additional language to support above and beyond the implementation language? You appear to be using Java. You want to support more languages than Java. [Just guessing — your question is incomplete.]
Answer: Toss a coin. Whatever languages you think the marketplace will demand. C is popular. So is C#. So is Python. Pascal not so popular.
How to I write my framework to permit "foreign" languages?
Answer: This is challenging.
To write application which allows multiple language interfaces you have to do a bunch of things.
Know a bunch of languages well enough to know their limitations.
Write your application so that the API can be successfully used by all your various languages.
Have very, very clear use cases and unit tests to prove that the application really works that way.
Avoid language-specific features. Avoid hardware-specific features. This means avoid all "native" or "primitive" data types in the API, and use real standard types. Often Unicode strings represented in UTF-8. The kind of thing that is universal and ubiquitous.
Avoid quirky non-standard protocols. HTTP, FTP and the like are so widely adopted that you can’t go too far wrong with these as an interface. They can be slow. For better speed, you’ll can create named pipes between the "foreign" code and your application. If you want the foreign code to have "direct" access to your framework, think twice.
Or, do what many API’s do and embrace C as the "lingua franca" of interfaces. Design everything to be callable from C programs. Use C conventions and C-friendly data types. This has limitations, but many people do it.