>
>
> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 6
> Date: Mon, 4 Dec 2000 13:19:54 -0500
> From: "Leyne, Sean" <InterbaseArchitecture@...>
> Subject: RE: UDF and null
>
> Ann,
>
> While I share some of your cynicism and concerns about the current UDF
> functionality, there does come a point where that developers must take
> responsibility for their work and for their systems/installations.
>
> I think you would agree that:
>
> Given that IB is now open-source, what would prevent someone from
> putting a virus into the source and compiling it? The answer is:
> Nothing at all

You just try and get that past Reed :-). Seriously quite a few people
review the source as changes as they pass through firebird-checkins
something would be fairly hard to slip through, say at least as hard as
a disgruntelled Inprise employee slipping something into a proprietory
version.

> Should the engine be extended to support a greater number of built-in
> functions/statements (any thus minimize the need for 95% of UDFs)? Yes
>
> Should the support for the current UDFs implementation continue? Yes
>
> Should developers be given fair warning about the dangers of UDFs? Yes

I agree strongly with Jim, Java is a better alternative and has a lot to
offer in todays paranoid (and safety focussed) programming model. So
it is likely to be the future in the area.

Having said that, there is no dictatorship on ideas/directions/or
wants. So if someone feels strongly enough to add these functions for
their own needs at Firebird it's unlikely that anyone is going to object.


Would java include a large footprint. The JVM's you want are provided
independantly. Initially you only load them up if you want them, if it
progresses that way (and I suspect it would ) then Java would become a
more integral part of the system.

How much extra code?

Well to start up the JVM:

#include <jni.h>

#ifdef _WIN32
#define PATH_SEPARATOR ';'
#else /* UNIX */
#define PATH_SEPARATOR ':'
#endif

#define USER_CLASSPATH "." /* where Prog.class is */

main() {
JNIEnv *env;
JavaVM *jvm;
JDK1_1InitArgs vm_args;
jint res;
jclass cls;
jmethodID mid;
jstring jstr;
jobjectArray args;
char classpath[1024];


/* IMPORTANT: specify vm_args version # if you use JDK1.1.2 and beyond */
vm_args.version = 0x00010001;

JNI_GetDefaultJavaVMInitArgs(&vm_args);

/* Append USER_CLASSPATH to the end of default system class path */
sprintf(classpath, "%s%c%s",
vm_args.classpath, PATH_SEPARATOR, USER_CLASSPATH);
vm_args.classpath = classpath;

/* Create the Java VM */
res = JNI_CreateJavaVM(&jvm,&env,&vm_args);



Then to call a method (static in this case).

cls = (*env)->FindClass(env, "Prog");

mid = (*env)->GetStaticMethodID(env, cls, "main", "([Ljava/lang/String;)V");

jstr = (*env)->NewStringUTF(env, " from C!");
args = (*env)->NewObjectArray(env, 1,
(*env)->FindClass(env, "java/lang/String"), jstr);

(*env)->CallStaticVoidMethod(env, cls, mid, args);



Then to shut it down.


(*jvm)->DestroyJavaVM(jvm);

}

I've skipped a few lines about checking the return error codes for out
of memory, (full text see:
http://www.javasoft.com/docs/books/tutorial/native1.1/invoking/invo.html

No code bloat, up to you to provide the JVM (This is the C examples the
C++ one is a little more elegant).


For the interested a more detailed way of using the reflection api to
navigate through a class and its methods in order to validate the args
parameters on the procedure call see examples at:

http://www.javasoft.com/docs/books/tutorial/reflect/index.html


I also agree that providing the layer back into the current transaction
would make it particularly useful.

Cheers

Mark


--
Your database needs YOU!
http://firebird.sourceforge.net