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!

Java reflection will do it...

[Masem]

I had started an app yet to be finished that did use plugins (stored as .jars) that simply sat in a blessed folder; the plugin loader would simply iterate over the files in there, check for a valid plugin indicator, and loaded the class via a custom class loader. I know you can also unload such class assuming (the biggest stumbling block) all instances of that class (including any other loaded classes along with it) have been deleted.

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...

[X]

I think if you look around you'll find that Java is well supported on a wide variety of platforms. It will certainly require fewer source code changes as you move from one platform to another than C. You will find that most OS vendors will provide you with a Java VM for their platform, even for embedded OS's like VxWorks and QNX. The one area where Java is not well supported is on free operating systems, where if you stray much from x86 or PowerPC on Linux your choices are fairly limited (although Kaffe is a very nice VM).

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.