cp-tools-discuss
[Top][All Lists]
Advanced

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

Re: [Cp-tools-discuss] Gjdoc 0.6.1


From: Julian Scheid
Subject: Re: [Cp-tools-discuss] Gjdoc 0.6.1
Date: Sat, 08 Mar 2003 02:35:00 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2) Gecko/20021126


Brian Jones wrote:
Does the JNI wrapper mean generating javah type output?  We already
have a tool for this.

No, it is meant to generate C++ stubs that allow to transparently use
Java classes in JNI code. Java constructs like Exceptions blend with the
corresponding C++ constructs - i.e. you can catch Java exception
naturally in C++, and you can throw Java exceptions from C++ code.
You can also call methods and query/set fields in Java objects in a
very natural way. No more stuff like

env->CallVoidMethod(env->GetMethodID(env->FindClass("my/JavaClass"),
"printMessage", "(Ljava/lang/String;)V"), myJavaClassInstance,
env->NewStringUTF("What a pain"));
if (env->ExceptionOccured()) { // care about it }

More like:

myJavaClassInstance.printMessage("Neat!");

(possible exception is auto-thrown to appropriate handler. no need to
care.)

Of course, this comes at the cost of a small performance and memory
footprint penalty.

There are already products available that also provide this, but most
of them are targeted at legacy system integration, and all are
proprietary AFAIK (boy are they expensive.) I did it because I needed
it, because it is easy to generate the stub classes using a DocTranslet,
and last not least because it was fun.

"Intersections interesting I find" =P

                      One of the things that bothers me is that
cp-tools has a number of modules I'd like to distribute together under
a single build system, i.e. a cp-tools.jar and related scripts for
example.  Do I move gjdoc into cvsroot/cp-tools/cp-tools as originally
intended or is there another solution?

Sorry, I don't remember the previous discussion. Can you point me to some
archived mails?

While Gjdoc works fine as a bytecode application, I'd like to maintain
gcj compilability. But it's a pain to use gcj with ant, so I originally
planned to create an autoconf/automake based build for gjdoc in the next
step, works quiet well for LibxmlJ. Wouldn't this conflict with the other
cp-tools, which are ant-based?

I don't have a strong opinion about this, but I am quiet comfortable with
the status quo - i.e. the ability to download, compile and use gjdoc alone.
This enables me to tweak the build process as I seem fit. But if there are
good reasons for merging the modules, I'm probably easy to convince.

Julian





reply via email to

[Prev in Thread] Current Thread [Next in Thread]