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

Yes.

[micromoog]

Yes, it is.

Hold on

[Anonymous Coward]

I'm waiting for C#

Re:Hell yes, C is better.

[Marsell]

Don't be too quick. There is an ARM chip out there that can run Java bytecode (native). If it can run it native, why bother with runtime?

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? ;-) go with C. Besides, which language are you more familiar with? You make your move.

Depends on how you define better

[stilwebm]

Many find the dynamic nature of Java better suited to dynamic loading. It is quite easy to do dynamic loading with Java. And, for most people Java applications can be implemented much more quickly than in C. But, if speed is what you're after, C beats the hell out of Java on any platform. Generally C will produce smaller object files, especially if add the JRE/JVM to the total size of a Java app. If one of these characteristcs has higher priority, then it should be an easy pick. If they are equal priority, then you might just pick the one you are most comfortable with. After all, they are both great languages, each with their own strengths and weaknesses.

Think about scripting, too...

[jmaslak]

I don't know why the poster limited himself to just C and Java. Perhaps it was due to the learning curve, in which case he probably should stick with C or Java (probably C since it doesn't seem that there is a good Java for his target platform).

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

Re:Think about scripting, too...

[Anonymous Coward]

I don't know why the poster limited himself to just C and Java. Perhaps it was due to the learning curve. ... However, if he is willing to learn a language, he should consider something like Perl.

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

Re:Think about scripting, too...

[cronio]

Note he didn't say natural language, he said speech.

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.

You know what you need? You need....

[Sir Rhosys]

Python!

List of Java virtual machines

[harmonica]

Maybe you can find a better VM on this list of Java VMs and compilers. The page has also links to other VM lists.

Where can I find info on dynamically loading?

[EMIce]

Is there a place where I can find basic information on dynamically loading classes and libraries? This is something I have wanted to do for a project, but I don't know where to start. I want to be able to dynamically add data stream sources at runtime, where each data stream is accessed by the same interface, regardless of the source, be it network TCP/IP, serial, file, etc... I'd imagine the necessary "plugins" would have to be linked to the main code at runtime. Sounds a little tricky to me. Preferrably a web site or a book suggestion would be great.