Thread

SDK and Java (Sdk)

SDK and Java // Sdk

1  |  

thierry nabeth

Sep 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

esumerfd

Sep 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 vilett

Sep 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

3dmark

Sep 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 vilett

Sep 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]

3dmark

Sep 14, 1998, 7:21pm
Drat! Foiled Again!


[View Quote]

thierry nabeth

Sep 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 nabeth

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

1  |  
Awportals.com is a privately held community resource website dedicated to Active Worlds.
Copyright (c) Mark Randall 2006 - 2021. All Rights Reserved.
Awportals.com   ·   ProLibraries Live   ·   Twitter   ·   LinkedIn