ThreadBoard ArchivesSite FeaturesActiveworlds SupportHistoric Archives |
SDK and Java (Sdk)
SDK and Java // Sdkthierry nabethSep 14, 1998, 11:58am
Hello,
I prefer to start a new thread to address this question about interfacing SDK and Java. However, this message is an answer to a previous message "Re: multithreaded would be usefull if we want to interface it with java" language you I do not fully agree with you, even if when there is some equivalence beteween different languages, you can do with another language all you you can do with another one. For me a "better" language will allow you to implement an idea more easily than with a bad one. (I do not want here to enter into a debate about which are the language that are good, and which are the language that are bad). Practically, a "good" language will allow you to represent the system in a way that reflect in a high level way your ideas, and does not impose you to enter into (irrelevant) details. For instance, if multi-threading is not mandatory, on the other hand, it can make the implementation of different objects having concurent activities (such as bots) much easier. The difference will be reflected by the complexity of the architecture, and therefore its capacity to evolve before becoming a maintenance nightmare. Anyway I did not post this message to open a "religious" debate, but to contribute to the following: into Active Words, several people almost immediately offered to implement a Java wrapper. I personnaly do not have the time right now to do this wrapping. (when I will have more time, I will see if I can do something). Besides, I do not have right now a C compiler. On the other hand, I had the time to look a little bit at the difficulty to do this wrapping, and my first impression is that it should really not be too complicate to do for a programmer having already use JNI (Java Native Interface). The main documentation of Jana Native Interface can be found at: http://java.sun.com/products/jdk/1.2/docs/guide/jni/index.html Here is the idea: ---------------------------- The idea of JNI is to create a Java class with some function are tag as Native. such as: public native void myNativeFunction(Object[] args); Once the *.java file is compiled (javac), you have to run javah (http://java.sun.com/products/jdk/1.1/docs/tooldocs/win32/javah.html) on the *.class file to generate C stub. You then implement the C functions (in the case of AW SDK you call the API), compile them, and create a dll. ------------------------------ Another possiblility that could appear to be even easier to implement, is to use the Shared Stubs Example. http://java.sun.com/products/jdk/faq/jnifaq.html The idea in this example is to generate dynamically the function that call the C-code. ----- example: call of the sin() function in java ---- /* Caculate C's sin(2.0) with Math.sin(2.0). */ CFunc sin = new CFunc(libm, "sin"); double dres = sin.callDouble(new Object[]{new Double(2.0) }); System.out.println("\nC's sin(2.0) = " + dres); System.out.println("Math.sin(2.0) = " + Math.sin(2.0)); ---------------------- This code is extracted from the example. (jnistb10.zip ) Note: You still need to do a little bit of compilation to use this approach, but you do not need to wrap all the functions as in the previous approach. Well, That is all for now. (I have to work for the next 2 weeks on a more urgent project). I have not tried to answer the issues raised by esumerfd. Perhaps, the wrapping will not work, but the better is to try to do it, and solve the problem later. I hope that a future release of the library will be reentrant, since I still believe this is something very important (even if not mandatory). I also hope that in a not too far future, a complete java version will be created. (let me dream a little bit). Indeed, the advantage of a complete java version would be plateform independance and for instance the possibility to run some bots on a Unix or Linux computer. Bye, Thierry Nabeth (calt exec) Research Fellow, INSEAD CALT (the Centre for Advanced Learning Technologies) http://www.insead.fr/CALT/ ===================================================== Subject: Re: multithreaded would be usefull if we want to interface it with java Date: Fri, 11 Sep 1998 11:50:46 -0700 From: "Roland Vilett" <roland at lmi.net> Newsgroups: sdk References: 1 , 2 , 3 >In particular, multithreading would be very important if we want >to try to interface the SDK with java. But not required. If a Java class were created to encapsualate the current SDK, the SDK wrapper methods could just be declared as synchronized. If the SDK is used in asynchronous mode (i.e. with callbacks installed) all SDK methods return immediately so opportunities for one thread to block others while in the SDK would be minimal >(which appear to me as a better language for developing bots because >of the multithreading, the garbage collection, etc.). I think the "better" language for bot development is whatever language you the programmer happen to be comfortable and familiar with. >Note: Encapsulation of the SDK into java shouldn't be too difficult. >Anyone interested by the idea ? A couple of months ago when we first announced work on a C-level API into Active Words, several people almost immediately offered to implement a Java wrapper. I don't remember who they were though - are you guys still around, and if so, are you still interested? :) -Roland esumerfdSep 14, 1998, 1:10pm
Well, it appears that I was wrong. There is a way to call java methods from
a native function http://java.sun.com/products/jdk/1.2/docs/guide/jni/spec/design.doc.html and look at the "Access Fields and Methods" section. So to implement the wrapper we will need to go through the following development steps. 1. Create AW.java with method wrappers that call all the aw C functions. 2. Create AWCallBack.c with handler functions that are called by aw_wait and intern call java methods. One of these functions must be aw_set_callback_object( Java object ). It sets up a global object that contains the java callback methods. 3. Create AWCallBacks.java as a standard store for all the events objects that need to get notified. Of coarse all the callbacks are implemented as interface to allow flexability of implementation for the developer. So the pseudo code might look something like this: Java: // AW wrapper class. class AW { // Simple C function wrapper. aw_init(){ call aw_init C funtion } aw_create() { call aw_create C function } aw_wait() { call aw_wait C function } and so on. set_callback_object( awcb ) { // assign the global java callback object in the C callback wrapper aw_set_callback_object( awcb ); } } class myBotProgram { public static void main(String args[]) { AW aw = new AW(); aw.init() AWCallBacks awcb = new AWCallBacks(); awcb.setAvatarAdd( new myAvatarAdd() ); awcb.setAvatarChange( new myAvatarChange() ); aw.set_callback_object( awcb ); aw.create(...) aw.login(...) aw.enter(...) aw.wait() aw.destroy(...) aw.term(...) } class AWCallBacks() { AvatarAddIF avatar_add; AvatarChangeIF avatar_change; AvatarDeleteIF avatar_delete; setAvatarAdd( AvatarAddIF avatar ) { this.avatar_add = avatar_add; } setAvatarChaneg and so on. } interface AvatarAddIF { void AvatarAdd(); } class myAvatarAdd implements AvatarAddIF, AvatarChangeIF ... as necessary { void avatarAdd() { // do something } void avatarChange() { // do something } } C: global java object; void aw_set_callback_object( java object ) { object = java object; aw_event_set ( AW_EVENT_AVATAR_ADD, callback_avatar_add); aw_event_set ( AW_EVENT_AVATAR_CHANGE, callback_avatar_change); aw_event_set ( AW_EVENT_AVATAR_DELETE, callback_avatar_delete); } void callback_avatar_add(void) { // Call the java method via the global object and the interface pointer. java object -> avatar_add -> AvatarAdd(); } Edward Sumerfield, esumerfd at poboxes.com [View Quote] > Hello, > > I prefer to start a new thread to address this question about > interfacing > SDK and Java. > > However, this message is an answer to a previous message > "Re: multithreaded would be usefull if we want to interface it with > java" > > language you > > I do not fully agree with you, even if when there is some equivalence > beteween different languages, you can do with another language > all you you can do with another one. > For me a "better" language will allow you to implement an idea more > easily > than with a bad one. (I do not want here to enter into a debate about > which > are the language that are good, and which are the language that are > bad). > Practically, a "good" language will allow you to represent the system in > a > way that reflect in a high level way your ideas, and does not impose you > > to enter into (irrelevant) details. > > For instance, if multi-threading is not mandatory, on the other hand, it > can > make the implementation of different objects having concurent activities > > (such as bots) much easier. > The difference will be reflected by the complexity of the architecture, > and > therefore its capacity to evolve before becoming a maintenance > nightmare. > > Anyway I did not post this message to open a "religious" debate, but to > contribute > to the following: > > into > Active Words, several people almost immediately offered to implement a > Java > wrapper. > > I personnaly do not have the time right now to do this wrapping. > (when I will have more time, I will see if I can do something). > Besides, I do not have right now a C compiler. > > On the other hand, I had the time to look a little bit at the difficulty > > to do this wrapping, and my first impression is that it should really > not be too complicate to do for a programmer having already use JNI > (Java Native Interface). > > The main documentation of Jana Native Interface can be found at: > http://java.sun.com/products/jdk/1.2/docs/guide/jni/index.html > > Here is the idea: > ---------------------------- > The idea of JNI is to create a Java class with some function are tag > as Native. > such as: > public native void myNativeFunction(Object[] args); > > Once the *.java file is compiled (javac), you have to run javah > (http://java.sun.com/products/jdk/1.1/docs/tooldocs/win32/javah.html) > on the *.class file to generate C stub. > > You then implement the C functions (in the case of AW SDK you call the > API), > compile them, and create a dll. > ------------------------------ > > Another possiblility that could appear to be even easier to implement, > is to use the Shared Stubs Example. > http://java.sun.com/products/jdk/faq/jnifaq.html > > The idea in this example is to generate dynamically the function > that call the C-code. > ----- example: call of the sin() function in java ---- > /* Caculate C's sin(2.0) with Math.sin(2.0). */ > CFunc sin = new CFunc(libm, "sin"); > double dres = sin.callDouble(new Object[]{new Double(2.0) }); > System.out.println("\nC's sin(2.0) = " + dres); > System.out.println("Math.sin(2.0) = " + Math.sin(2.0)); > ---------------------- > This code is extracted from the example. (jnistb10.zip ) > > Note: > You still need to do a little bit of compilation to use this approach, > but you do not need to wrap all the functions as in the previous > approach. > > Well, > > That is all for now. > (I have to work for the next 2 weeks on a more urgent project). > > I have not tried to answer the issues raised by esumerfd. > Perhaps, the wrapping will not work, but the better is to > try to do it, and solve the problem later. > > I hope that a future release of the library will be reentrant, > since I still believe this is something very important (even if not > mandatory). > > I also hope that in a not too far future, a complete java version will > be created. > (let me dream a little bit). > Indeed, the advantage of a complete java version would be plateform > independance > and for instance the possibility to run some bots on a Unix or Linux > computer. > > Bye, > > Thierry Nabeth (calt exec) > Research Fellow, > INSEAD CALT (the Centre for Advanced Learning Technologies) > http://www.insead.fr/CALT/ > > ===================================================== > Subject: > Re: multithreaded would be usefull if we want to interface it with java > Date: Fri, 11 Sep 1998 11:50:46 -0700 > From: "Roland Vilett" <roland at lmi.net> > Newsgroups: sdk > References: 1 , 2 , 3 > > > But not required. If a Java class were created to encapsualate the > current > SDK, the SDK wrapper methods could just be declared as synchronized. If > the > SDK is used in asynchronous mode (i.e. with callbacks installed) all SDK > > methods return immediately so opportunities for one thread to block > others > while in the SDK would be minimal > > > I think the "better" language for bot development is whatever language > you > the programmer happen to be comfortable and familiar with. > > > A couple of months ago when we first announced work on a C-level API > into > Active Words, several people almost immediately offered to implement a > Java > wrapper. I don't remember who they were though - are you guys still > around, > and if so, are you still interested? :) > > -Roland > > > > > > roland vilettSep 14, 1998, 6:07pm
>(I do not want here to enter into a debate about which
>are the language that are good, and which are the language that are bad). I'm glad, because such debates are always unproductive and time consuming and in the end never resolve anything...it's like the perennial Mac. vs. PC debate, some people will always prefer Macs and will back up their preference with endless evidence of why Macs are superior, and others will prefer PCs with the same extensive library of reasons why PCs are better...and no one will ever change their opinion and nothing ever gets resolved, year after year after year... Just to make the point clear, I never meant to say C is better than Java or anything else. Java is a great language, no doubt about it. The simple truth was that I could produce a C-based Active Worlds SDK in the shortest amount of time since the rest of Active Worlds is written in C/C++, and by implementing the SDK in C I could reuse large amounts of the code in the SDK without having to port it to another language first. -Roland 3dmarkSep 14, 1998, 6:22pm
So I can dig out my out Dos Based C and compile the SDK?
[View Quote] >amount of time since the rest of Active Worlds is written in C/C++, and by >implementing the SDK in C I could reuse large amounts of the code in the SDK >without having to port it to another language first. > >-Roland > > > roland vilettSep 14, 1998, 6:33pm
Probably not, the SDK is 32-bit code and as such requires a C compiler that
can generate 32-bit applications. Presumably an old DOS C compiler would not be able to do this... -Roland [View Quote] thierry nabethSep 14, 1998, 7:54pm
Hello,
and in the end never resolve anything... I absolutely agree. amount of time. This is what I had assumed. This is also the reason why the wrapping of the SDK C-functions appear to be the best short time solution to have a "java" version. Note: I believe that wrappping the SDK library into java (or Visual Basic) make a lot of sense, since it open the use of the SDK to more people without requiring too much effort to implement. Besides, this implementation can typically by done by the community of the developpers and not Active World, at least in a first step. Bye, Thierry [View Quote] > > I'm glad, because such debates are always unproductive and time consuming > and in the end never resolve anything...it's like the perennial Mac. vs. PC > debate, some people will always prefer Macs and will back up their > preference with endless evidence of why Macs are superior, and others will > prefer PCs with the same extensive library of reasons why PCs are > better...and no one will ever change their opinion and nothing ever gets > resolved, year after year after year... > > Just to make the point clear, I never meant to say C is better than Java or > anything else. Java is a great language, no doubt about it. The simple > truth was that I could produce a C-based Active Worlds SDK in the shortest > amount of time since the rest of Active Worlds is written in C/C++, and by > implementing the SDK in C I could reuse large amounts of the code in the SDK > without having to port it to another language first. > > -Roland thierry nabethSep 16, 1998, 5:47am
Hello,
For your information, I wanted to mention the article: "Escape the sandbox: Access native methods from an applet", Javaworld, October 1998 http://www.javaworld.com/jw-10-1998/jw-10-apptowin32.html Summary: .... Several sources have shown how to use signed applets, which can bypass browser security limitations in both Netscape Communicator and Internet Explorer. This article takes the idea a step further, showing how signed applets, combined with JNI, can invoke the Win32 API directly. Using LiveConnect, these applets can even talk to the Win32 API directly from JavaScript! (2,000 words). This article open the perspective of launching a AW bot from an Internet Browser supporting java. I believe something similar can be done creating activeX Control embedded in a web page. (such as it as been done in the Active X control AW client). Thierry. [View Quote] > Hello, > > I prefer to start a new thread to address this question about > interfacing > SDK and Java. > > |