Is C Better At Dynamic Loading Than Java? 13
Mike McTernan asks: "I am about to start programming my final year project for my degree. I am aiming to write a lightweight application that will communicate with the user through some (yet to be dreamt up) novel speech interface. The program is to support the idea of applets that can be loaded and unloaded on demand, and should be reasonably lightweight. The target OS will be Linux on an ARM based board. My initial considerations were to use Java, since Reflection allows easy opening of new class files at runtime, but Blackdown are only upto 1.1.8 on arm, and this doesn't allow WeakReferences that I would very much need to use for the unloading aspect. I thought about using gcj but this isn't upto Java 2 either. I then though about C, and it seems tempting and would give a much finer grained control over the application. In particular I think can do anything with dlopen() that reflection can do for me in Java."
"Am I correct in thinking that C is probably more protable than Java since I can get it to compile on any Linux system, most Unix variants (with tweaks) and probably on Windows with some hacks ;) I can only run Java on a few supported platforms (downloads for Java seem only to be Solaris SPARC|x86, Linux x86 & Windows). So, in summary, should I bother with using an outdated JDK on arm and limit my self to a select range of platforms, or just dig in and enjoy the freedom of C?"
Yes. (Score:1)
Hold on (Score:2)
I'm waiting for C#
Re:Hell yes, C is better. (Score:2)
However, I'd still say C. Judging by the tone of the question, it seems the person already has decided on C, so adding a few yeahs is superfluous. Besides, C is has a lot less overhead. If you're running an ARM, you probably don't have much memory to bask in, and you'll need a fair deal of it for voice processing. A final comment is that C also gives you more control, but at the cost of more complexity. If you don't have much time, Java probably is the way to go. If you just like control (don't we all?
Depends on how you define better (Score:2)
Think about scripting, too... (Score:2)
However, if he is willing to learn a language, he should consider something like Perl. I know that Perl handles this problem in a fairly elegant way compared to the dlopen interface.
He might also consider building a system around some sort of multi-process communications system, such as COBRA (or even a simple blackboard communication system).
It sounds like you have already made your choice. (Score:4)
From a developers standpoint, the promise of Java (that has yet to materialize) outweighs that of C - the idea being that you can compile once on one platform, and as long as there is a VM or native execution of Java bytecode somewhere, your app will run. I am not sure why the promise hasn't been fulfilled, but I would imagine it is a combination of the stunt M$ pulled, combined with the control Sun exerts, combined with the slight disimilarities in third-party VMs, that are causing all the problems.
I would imagine, had Sun released a VM under GPL, coded in C/C++, for Linux - and had M$ been less power hungry, greedy, stupid - or just plain didn't exist - there wouldn't be the problems we have today, because porting the VM would be a relatively trivial thing.
With C/C++, however, one must compile (or cross-compile) on/for the platform one is aiming at - you can't just compile once, and run anywhere. Perhaps if someone could create a simple stub routine that somehow could be attached to a data package, such that when the "program" is executed, the stub would fire up a C/C++ compiler, creating a native app from the data package, which would then run - then we would have the power of C/C++ and the freedom of Java.
Java tried to do something similar to what was actually done with a database system known as PICK (starting in 1969). PICK had both native processor and virtual machine implementations (in Unix) for the database structure, and the language (PICK BASIC). It was relatively easy to move a program from one PICK box to another, and have it run (provided you moved the database tables and such). While it didn't support it natively (though it may nowadays), it was perfectly possible to create a system that could "auto compile" programs to the byte code for the VM. All of these implementations, from various companies, worked because they adhered to a "standard" (though I am not sure if this standard was open, or how it was available). PICK is still in wide use to this day.
So, don't disdain over the failing of the promise of Java - it can be done, but I think Java is having problems simply due to greed (both M$ and Sun)...
Worldcom [worldcom.com] - Generation Duh!
Java reflection will do it... (Score:3)
Probably the trickiest part is to indicate where the entry point of the code should be; what I had done was use the .jar manifest file to add a line that was specific for my program, which indicated the dynamic class to load. As this class had to be a subtype of a specific class (as so the plugin would work), this point would be where the 'completeness' of the plugin would be test and failed.
Sure, there's a lot more work; writing a class loader is not the easiest thing out there, but there's plenty of example code to go by. Keeping track of all dynamic objects created might be a bit harder, but if you use static elements that help to keep track of instances, that would work as well. But you gain an dynamic system that works on all platforms with Java Reflection which will happen RSN. Unfortunately, as this seems to be a priority now, your choice is limited.
Java will do just fine... (Score:3)
As far as your weak references case goes, while I don't know specifically what you are trying to accomplish, I've never needed weak references for any dynamically loaded modules I've done in Java. I've found that Java's ClassLoader allows you to neatly modularize your code so that modules can be easily and safely be loaded and unloaded.
When you compare this stuff to what's standardly available in C (let alone which is portable to a wide variety of platforms), and I'm hard pressed to think of how C could be advantageous in this situation.
You know what you need? You need.... (Score:1)
Re:Think about scripting, too... (Score:1)
Or Python. Honestly, I don't want to start a Perl/Python flame fest, it's just that Python has a very C/Java syntax. If you proficient at either, you should be up and running with Python in an afternoon, so learning curve wouldn't be much of a problem. (Of course YMMV.)
( N.B. There may already some Python code dealing in natural language. IIRC, currently there is a HMM thread running on comp.lang.python ).
However, there were some very astute comments in other posts, to the effect that on his system there will be memory/speed constraints. If that is the case, don't bother considering Perl/Python - you'll get much better size/speed control with C. (Although the trade off is that you'll spend more time on low level issues, and less on solving the high level issues.)
List of Java virtual machines (Score:2)
Where can I find info on dynamically loading? (Score:1)
Re:Think about scripting, too... (Score:1)