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?
suppose I create a extensible software application with a plug in architecture
Okay. You've written some code. I'll pretend it's in Java because you mention SWIG and JNI.
If a new application is written in a different language
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.
Related
This is a general "noob" question about software design, so I apologise if it seems vague,
but I would really appreciate the advice. Note the system described below is purely an example, not a specific product I have in mind.
I often have a need to combine the functionality of several libraries or utilities, written in different languages. For example, if I want to code a high-performance audio processing application for the desktop, I will write it in C / C++. Then, I want to add a nice GUI. But I don't want to learn Qt. I like the look and feel of Adobe Air, and would like to use that. Later, I have a need to access a USB device. But the USB library I have only has an API in Java. How can I combine all these elements together, to take advantage of their relative strengths?
Clearly, I cannot compile these various elements into one single executable. So I need to create and run them seperately, and give them a means to communicate. The most common way to do this seems to be using IPC (Inter Process Communication), eg shared memory or sockets. I prefer the idea of sockets, as the programs could potentially run on seperate machines on a network.
So I decide to create a local client / server system, with a custom API, to allow these elements to communicate. For example, the Air application will receive a message from the C application, telling it to update it's UI. The USB application running in Java will use the sockets to stream audio from the USB hardware, into the C application.
My question : is using local sockets in this way a typical way to design such a system?
Will the performance be much worse than a truly native application (e.g. everything in Java or C, in a single executable) ? It also seems likely that such an approach would be prone to bugs, and difficult to maintain?
I frequently find myself coming up against the limits of existing software libraries (e.g. a graphics library with a pretty, flexible UI but no way to access low-level hardware, or a media library that can mix many audio streams, but has no support for video playback), and find it very frustrating. If anyone could advise the best way to combine arbitrary software libraries like this, I would really appreciate it.
Thanks in advance!
As you have correctly identified, combining libraries from different language or platforms is hard. There are several ways to do it, but none are ideal. Examples:
Native call interfaces (e.g. JNI / JNA) - very fast but tricky to make work correctly, and you have the problem that the data types used typically don't map cleanly across different platforms. Adds native dependencies.
Socket based IPC with text protocol (XML, JSON, etc) - works OK and common formats are likely to be supported at both ends, but adds a lot of overhead. Can be a pain to maintain custom schema mappings etc.
Socket based IPC with binary protocol (e.g. Google protocol buffers) - quite efficient, needs a lot of work to get a custom protocol working correctly on both ends
Communication via a 3rd system (e.g. database, message queue, filesystem) - lots of overhead, can get fragile, introduces a major dependency on a 3rd system.
In my experience, it usually isn't worth integrating a new language / platform just to get one specific library or feature. Take your user interface example - no matter how nice Adobe Air looks, I doubt it is worth trying to integrate it with an existing C/C++ application.
Even if you get it to work, it will significantly complicate the future maintenance and devlopment of your application. Builds become more complex. You need to maintain additional communication / "glue" code. You need to manage more dependencies. Your users will get hit by many more configuration issues. Testing becomes more difficult. It becomes harder to teach someone new about how the whole system works. You need to maintain your skills in more languages / frameworks etc.
I'd recommend the following strategy:
Pick a primary platform
Whenever you need a new library or feature, look for something on your primary platform first. Hopefully (usually?) there is something good available - but even if not then it might be worth coding something yourself if the requirement is quite small.
Only if there is no reasonable option on the primary platform, then you can start to think about integrating a new language/platform
In terms of primary platform, I'd normally suggest a JVM language like Java, Scala or Clojure since the JVM is very well engineered, offers great performance, is highly portable and has the largest / most cohesive library ecosystem (most of which is open source). The JVM is therefore probably the best "general purpose" choice unless you have some very specific requirement which is unlikely to be possible on the JVM, e.g.:
If you are doing lots of embedded / realtime / systems programming wthat requires hardware access you probably need to go for C/C++
If you are coding purely for web-based clients, you probably want to use JavaScript (if you are also writing code on the server side you can consider JavaScript code generation frameworks/libraries that can work on the JVM, e.g. Vaadin or ClojureScript)
the answer is pretty much depends on the technologies you're using and there is no silver-bullet solution for this.
In general, this solutions will fall into one of the following categories:
Some interprocess communication techniques
Integrations provided by the language/platform itself
Database/some common storage (even files :) )
Example of the first:
Sockets/pipes/whatever you operating system allows.
CORBA - allows to write distributed code in different languages.
Google protobuf - allows serialization/deserialization of data-objects and its language agnostic
For the second it really depends on language/ecosystem you're using.
Examples for java:
JNI - Java Native interface - allow to execute code (dlls/so) outside the JVM.
JCA - if you're in the enterprise environment - you can write the integration with the legacy systems in this.
For languages that are compiled into the native code its less tricky - you can write and compile some code, say in Pascal, and then use the DLL in C.
Sometimes when we're talking about Java there is a plethora of languages that have their own syntax and compiler, but their compiler compiles into java binary code that can be run inside the jvm. So if your solution is based on these languages the integration will be easier. Languages like Scala, Groovy, Closure, Jython and so on are falling into this category.
The last but not the least technology to be mentioned is Web Services. This is a very popular tool for integration of different system, although its more used in enterprise environment.
Basically its an abstraction over the sockets layer that allows to send data objects in XML/JSON format between the processes/servers. Both of XML and JSON are language agnostic, so its not an issue to create an XML in a program written in C++ and then consume it in JAVA.
Hope this helps
I have a few modules of an application that have been written in Java. But now, I have been asked to write all the other modules in PHP.
Is there any tool that will permit me to make method calls from PHP to Java and vice versa?
If not, is it possible to develop one especially considering the fact that Java is a strongly typed language unlike PHP?
Without knowing more I would suggest that you expose the Java methods as a web service. This has a number of other benefits outside of just language independent consumption.
However, web services might not be the answer if your java modules are very granular.
You might find it easiest if you use one of the solutions that enables you to run PHP on the JVM. This should give you pretty good interoperability. e.g.
http://www.caucho.com/resin-3.0/quercus/
Having said that, if you're already using Java modules, I can't see a huge amount of value in adding PHP into the mix as well. Why not just stick with Java? Java is already pretty much the best all-round platform choice for server side applications once you consider things like library ecosystem, tools, portability, performance, maturity, maintainability etc.
You can use nice frameworks like Play (Java/Scala) or Grails (Groovy) or Noir (Clojure) if you want productive web development on top of the Java stack, I think I would choose these in preference to most of the PHP frameworks available.
Why is it that the C threading library (pthreads) not as popular as the java one when it comes to application development?
Is it just the memory management issue or are there other major advantages involved?
pthreads are not implemented natively on all OSes, such as Windows (there is a Win32 API for that). In fact, C as a language has no concept of threads.
Java was built with threads integrated into the language. C was not.
It's not entirely portable -- pthreads is parts of POSIX, and not normally provided under (for one obvious example) Windows.
C++ 0x adds threading primitives to the standard library (and they're mostly quite similar to pthreads) which is what most new code is likely to start using fairly soon (and some already does).
pthreads are also fairly low-level and kind of a pain to use well; many application programs will probably be better off using futures (roughly similar to the Java objects of the same name) for many of the relatively simple threading situations.
It depends completely on which type of application you have in mind writing. Perhaps the applications you're referring to are more convenient to write in a high level language such as Java.
In addition to the matter of (non-)portability mentioned by others, systems that implement pthreads often also implement cheap and easy multi-process programming, and that was how parallel unix programs were written for a very long time.
I'd say threading is too popular in Java, for example because it is hard to do asynchronous I/O. It looks to me like libraries in Java are designed with the attitude that threads are good. Library designers using C simply have the opposite attitude :)
The Qt framework offers a platform independent implementation for threads in C++.
It has borrowed extensively from java and is a lot newer than some the libraries mentioned earlier so its still gaining in popularity.
Surely this is a question about the popularity of Java vs C rather than one library over the other. I imagine most developers select the development language not the threading library. Once the language is selected this constrains the library choice; after all you cannot use pthreads in Java.
Another point is that in C there is no standard threading library, although pthreads is commonly available on many platforms.
I also doubt the premise; if we assume that you really mean that Java is more popular than C (since that is perhaps the implication), then I doubt it is true generally. In certain application domains maybe, but it is not an easy thing to measure. Depending on how you measure it, you can make Java, C, C++, PHP, JavaScript, Python, and even D look like the world's most popular programming language.
It is possible I suppose that if you choose to use multi-threading, this may lead to a decision to prefer Java (though I doubt that too), but that is a different decision process than choosing pthreads over Java threads.
Java is mainly application programming language so more people and companies are on to it, whereas c is more of a system level programming and core programming which is less popular compared to application programming.
Should I use Javascript or Java for my webapp's background? For Javascript, I could use sproutcore/gianduia (as Apple recommends.)
Is it possible to develop mid-scale webapps with Javascript despite the fact that Javascript is used mostly on the client-side?
Is Java better for server-side and object-oriented programming?
You can use either. Which you choose will bring with it a number of competing advantages and disadvantages. I'm not too familiar with Java frameworks though many exist. JavaScript server side frameworks such as Rhino, node.js, and platforms that make development on those easier are becoming more and more popular. Look up any of the many JavaScript conference talks to find out more.
If you are just getting started or have a history with JavaScript, that might be easiest to pick up, though you won't find a lot of documentation outside of the web. Java will give you a ton of books, media, etc, but you'll have a greater learning curve if you haven't done a lot of development.
You mentioned OOP specifically. Java follows OOP, but JavaScript uses prototype inheritance and can be difficult to use in an OO style without a framework. JavaScript lends itself to a more functional style, though, so if you are interested in that, you might gain some advantages there.
The question is a bit confusing as to what you're comparing java to, so I can't answer whether java is better or not. But Javascript is for client-side code only and should not be used for server-side for security reasons and you could use ajax/jquery to retrieve and send data to server but that depends on your needs and application. If the webapp is highly client-side then java, ajax and jquery are good ways to go.
Hope this is a start, let us know more a little about what you're trying to make/do.
Best
Java is a good server-side language. As user pst mentioned, JavaScript can apparently also be used as a server-side language, but this is extremely rare I would say. In regards to OOP, my opinion is that OOP is easier, more straight-forward, and better supported in Java compared to JavaScript. So my recommendation would be to use Java as your server-side language.
Typically a language like Java is been mainly for the server side and Javascript on the client side. On the client side you can write Java Applets, but for various reasons, they aren't used very often on websites. All modern web browsers support Javascript, so it is a natural choice for the client side.
These days Javascript can be run on the server. This would be a great solution for someone who is really good with Javascript. Though, java may be a better choice if you want the app to be highly performant and scalable.
Java can be used on the client side if you write your app with GWT. GWT takes Java code and compiles it into Javascript which will run natively in the browser. GWT does a lot of optimization of your code so it runs very efficiently in the browser. It also allows you to use the many development tools available for Java such such as IDE's which offer code completion and unit testing frameworks.
Java is statically typed and object oriented, javascript is dynamically typed and based functional language. They use very different paradigms despite having fairly similar syntax. Comparing them is a little bit like comparing apples and oranges. They both have their strengths and weaknesses.
It's possible to write an entire javascript that only lives on the client side but you sacrifice the ability to interact with extremely large datasources, share data with other users, or allow the user to save data and access it from another computer. You could also write an entire Java app that only lives on the server side, but you lose interactivity.
JavaScript is used for the server-side, and very successfully: see http://nodejs.org.
And whether "Java is better for OOP", what do you mean by OOP? JavaScript is actually much better for OOP, if you don't define it too loosely (something like Java/C#/C++, with static types and inheritance trees and polymorphism by inheritance) but broadly (using objects; where object is entity with identity, behaviour and state). Why is it better - because it is more powerful - it is duck-typed and it's model of OOP is prototypical, which is model of OOP broader than the classical class-based (you can have classes, but you can have more than that).
I have an open source Java database migration tool (http://www.liquibase.org) which I am considering porting to .Net.
The majority of the tool (at least from a complexity side) is around logic like "if you are adding a primary key and the database is Oracle use this SQL. If database is MySQL use this SQL. If the primary key is named and the database is Postgres use this SQL".
I could fork the Java codebase and covert it (manually and/or automatically), but as updates and bug fixes to the above logic come in I do not want to have to apply it to both versions. What I would like to do is move all that logic into a form that can be compiled and used by both Java and .Net versions naively.
The code I am looking to convert does not contain any advanced library usage (JDBC, System.out, etc) that would vary significantly from Java to .Net, so I don't think that will be an issue (at worst it can be designed around).
So what I am looking for is:
A language in which I can code common parts of my app in and compile it into classes usable by the "standard" languages on the target platform
Does not add any runtime requirements to the system
Nothing so strange that it scares away potential contributors
I know Python and Ruby both have implementations on for the JVM and CLR. How well do they fit my requirements? Has anyone been successful (or unsuccesful) using this technique for cross-platform applications? Are there any gotcha's I need to worry about?
Check out the Fantom programming language. It has its own Java-like/C#-like syntax but can target either the Java VM or .NET CLR.
Their "Why Fantom" page gives a high-level overview of their approach to portability versus dynamic languages running on a VM.
You might have some luck using IKVM.NET. I'm not sure on its exact status, but it's worth a try if you're insistent on running Java code on the .NET Framework. It includes a .NET implementation of the Java base class library, so it seems reasonably complete.
The only other option I might suggest is porting the code to the J# language, a full .NET language (although not first class in the sense that C# or VB.NET is). The language was designed so that the differences with Java were minimal.
If you are thinking about an emdedded approach, you might look at Lua.