Is C Better At Dynamic Loading Than Java?

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?"

Comments

It sounds like you have already made your choice.

[cr0sh]

For what you are doing, which sounds like basically an embedded voice-recognition project, I too would probably go with C or C++ (though I suck at both). However, don't be so quick to dismiss Java.

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 - Generation Duh!