Re: Inquiry On Contributions From Java Programmer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Scott,

On Wed, 2008-10-29 at 11:45 -0700, Redefined Horizons wrote:
> I'm interested in gaining some experience in C programming, ... I'm
> curious if GNU Classpath is implemented in the C programming language

So any Java library that works with C code directly is going to use
something called JNI, the "Java Native Interface".* It's what you do to
set things up so that C code can accept calls from Java, and, once in C,
convert data as it crosses the boundary and/or (rather cumbersomely)
access Java objects or invoke Java methods.

It's quite comprehensive, but rather arcane. There are good reasons for
this, but no matter what you do it represents a steep learning curve.
After using it a long while you begin to realize that it's mostly the C
equivalent of having doing things Java-side with reflection, but there's
nothing to get around the fact that you're now in C and there are a hell
of a lot of extra things you have to take care of.

This is all germane to your question because a Java library (including a
one like the Classpath project which is acting as the "Standard" or core
or system library [why oh why we didn't use one of those terms in Java
land like everyone did in other languages?]) that is doing things in
native C code is mostly about navigating through these admittedly thick
waters usually in order to just invoke a functions call from some
underlying native library.

So while that is being done in C, and so yes, is "programming in C",
there's not really that much C programming about it. Most of it is
repetitive and done by rote.

++

That all said, there is a big difference between doing trivial comp sci
class programming and developing real applications. Any large codebase
is going to have enormous amounts of structure just to organize things,
especially if it is using a library stack like GLib and GTK, or
something from the Mozilla space, etc...

So learning to wade through such morass is actually a fairly realistic
part of learning to be proficient in C. And from that angle, sure,
looking at a project like Classpath

        [which does native calls to a) make system calls or b) talk
        directly to the Java Virtual Machine]

or say java-gnome

        [which is busy doing native calls in order to invoke things an
        underlying library (in this case GTK and friends) because it is
        a Java language binding for those libraries]
        
will teach you a fair bit of C by osmosis. But in order to see the "C
part", you'll need to learn a bit of JNI so you can realize what is just
Java-calling-native infrastructure, and a bit of the underlying library
being used, so you can realize what is the machinery of using that
library's API. After subtracting those bits, what is left over (if
anything) is "C" :)

Except, as mentioned, really, all that glue code *is* "C" too, and what
programmers spend most of their time doing. People tend not to think of
it that way, but there it is.

So sure, Classpath (or, the Open Java JDK itself) could be a place to
start learning about such things. A bit jumping in the deep end,
perhaps, but as described above, most any project you look at is going
to be just that.

AfC
Sydney


*[yeah, yeah, there are other ways to do it, notably GCJ's CNI, but
elegant a concept as that was, it's specific to GCC and more to the
point not usable by anything that targets Java generally instead of GCJ
specifically]


-- 
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management. We actively
carry out research and development in these areas on behalf of our
clients, and enable successful use of open source in their mission
critical enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

Attachment: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Linux Kernel]     [Linux Cryptography]     [Fedora]     [Fedora Directory]     [Red Hat Development]

  Powered by Linux