«

Hi,

I hope someone can help with an architecture/infrastructure strategy
question that is a lot less philisophical then it might originally sound.
(It looks long but the question(s) is straight-forward)

The immutables are: -

1) I'm running in a Web browser and and am using a combo of html and
Javascript for the user interface.
2) There is an Applet that has established and authorized a Socket
connection back to a non-Java server
3) Data/Messages are exchanged in the form of Byte Arrays (ie Records)
4) The customer doesn't want to "Just do it all in Java"
5) I am not interested in hearing about XDR or IDL, and if a given
application wants to use XML then good-luck to them, I will not stop them,
but for those of you left who are willing to think outside of the box,
please continue.

An example of what might happen is, the user enters an Employee Number and
as part of the validation a "Get Employee" message is sent to the server and
in response either an "Employee Details" or an "Error" message will be
returned. (For argument's sake let's adopt the convention that the first two
bytes of the message will be reserved for Message Id follow by a
message-specific body. "10" is Employee request, "11" is Employee Details
response and "99" is Lookup Error)

Anyway, if a "11" message comes back then we know 200 bytes of data will
follow which might have a Surname in a specific Character set, an integer
(little-endian) for base salary, and all the other crap that we all have.

Am I correct in assuming that there is simply no way that Javascript, and
its "var =" semantics, can deal with the complexities of character-set an
integer-endian issues, and that one must call back to Java-proper with the
document.applet.method() functionality?
(The rest of this post assumes that the answer to that question is a
rsounding "YES". If the answer is in fact "NO" then please ignore the rest
of this post and just show me how to do it in Javascript/html

The problem I'm faced with now is that I'm the infrastructure/middleware guy
and I have no idea about an individual or specific Application's message
passing and formatting requirements. I have established an application
neutral, or generic, link to the host and authorized application access and
I have made available the conduit for interacting with the server code, but
I simply don't know what your subsequent messages will look like or what
they with contain. I give you a read method and a write method (and a
lovely sendUrgentData() method) but you have to provide the Class for
packing and unpacking the messages How do I make your lovely
application-sepcific scatter/gather methods available to your Javascript/htm
when I insist on controlling/owning the Applet?

The short answer is obviously let the Application-specific code own the html
object tag and the applet definition and just let them include/import my
Package into their classes, but I'd rather not, if that's all the same with
you

Can my Applet dynamically load a Class? If I get an Applet Parameter that
says PAYROLL can I not load codebase()payroll.class? OK, forget about my
applet loading the PAYROLL class; is there another way for the
Application-specific programmers to load their PAYROLL class into the JVM
and make them available to Javascript/html (who in turn will call my
send/recieve)?

Perhaps a second Applet? How do they know about each other? Is there
something in DOM that let's them share context? Is dynamic scripting the
answer?

If I don't get any worthwhile advice other than "Simply relinquish control
of the Applet and ship a normal Class" then I'm just gonna pout and
reproduce the same infrastructure (Socket and authorization) code with
*every* package that wants to use it! Cos' that's the kind o' guy I am

Cheers Richard Maher

PS. I really like the look of nio sockets and the endian and charset
qualities of the buffers! But I have taken good advice and have stuck with
the IO class and .net sockets. I am using getbytes(charset) for strings and
will REVERSE() work the endian magic or will I have to do that myself?
Data*Stream also looked good! (But only if they talk to each other, right?)

PPS. It's a bit scary that I haven't stumbled across a Scaled Integer
class/primitive/necessity! Please don't tell me that Java uses floating
point primitives for Money. (Note to self: - What does Number class do?)

PPPS. Sorry, I know even less about Javascript than I do about Java. Doh!

Richard Maher wrote:

> Am I correct in assuming that there is simply no way that Javascript, and
> its "var =" semantics, can deal with the complexities of character-set an
> integer-endian issues, and that one must call back to Java-proper with the
> document.applet.method() functionality?

There is some discussion of handling binary data directly from JavaScript on
the Web. Googling for
(javascript OR ecmascript) "binary data"
finds a number of hits.


> The problem I'm faced with now is that I'm the infrastructure/middleware
> guy and I have no idea about an individual or specific Application's
> message passing and formatting requirements. I have established an
> application neutral, or generic, link to the host and authorized
> application access and I have made available the conduit for interacting
> with the server code, but I simply don't know what your subsequent
> messages will look like or what they with contain.

Seems fair enough, but I'm a little puzzled by the rest of your architecture
(snipped). Wouldn't it make more sense (assuming you've got JavaScript and
Java talking to each other in the first place) to leave the formatting of
messages entirely up to the JavaScript code ? You could do that in at least
two ways (without messing around with custom Java code for each message type):

1) Represent messages as Java objects (com.mystuff.Message), which had methods
for accessing the data contained therein (a java byte[] array which is never
itself visible to the JavaScript code) like getSignedInt32AtOffset(int o), or
setDoubleAtOffset(int o), or setUnsignedByteAtOffset(int o, int value).

2) Allow the JavaScript code to define the layout of each message type to your
Java code (perhaps by passing in a list of <name, size, type> triples); and for
your Java code to use those definitions to convert between JavaScript objects
and raw binary data.

Maybe I'm missing something ?

-- chris

Richard Maher wrote:
> The immutables are: -
>
> 1) I'm running in a Web browser and and am using a combo of html and
> Javascript for the user interface.
> 2) There is an Applet that has established and authorized a Socket
> connection back to a non-Java server
> 3) Data/Messages are exchanged in the form of Byte Arrays (ie Records)
> 4) The customer doesn't want to "Just do it all in Java"
> 5) I am not interested in hearing about XDR or IDL, and if a given
> application wants to use XML then good-luck to them, I will not stop them,
> but for those of you left who are willing to think outside of the box,
> please continue.
>
> An example of what might happen is, the user enters an Employee Number and
> as part of the validation a "Get Employee" message is sent to the server and
> in response either an "Employee Details" or an "Error" message will be
> returned. (For argument's sake let's adopt the convention that the first two
> bytes of the message will be reserved for Message Id follow by a
> message-specific body. "10" is Employee request, "11" is Employee Details
> response and "99" is Lookup Error)
>
> Anyway, if a "11" message comes back then we know 200 bytes of data will
> follow which might have a Surname in a specific Character set, an integer
> (little-endian) for base salary, and all the other crap that we all have.
>
> Am I correct in assuming that there is simply no way that Javascript, and
> its "var =" semantics, can deal with the complexities of character-set an
> integer-endian issues, and that one must call back to Java-proper with the
> document.applet.method() functionality?

There are certain possibilities in JavaScript, but I would do that
part in Java.

> The problem I'm faced with now is that I'm the infrastructure/middleware guy
> and I have no idea about an individual or specific Application's message
> passing and formatting requirements. I have established an application
> neutral, or generic, link to the host and authorized application access and
> I have made available the conduit for interacting with the server code, but
> I simply don't know what your subsequent messages will look like or what
> they with contain. I give you a read method and a write method (and a
> lovely sendUrgentData() method) but you have to provide the Class for
> packing and unpacking the messages How do I make your lovely
> application-sepcific scatter/gather methods available to your Javascript/htm
> when I insist on controlling/owning the Applet?

You could extend your protocol to be flexible enough to convert
to and from a text format.

What you have now is:

applet->server:
10 (req emp info)
177 (emp id)

server->applet:
11 (resp emp info)
"Jones" (name)
80000 (salary)
or:
99 (resp err)

And that info is really not that easy to do js->applet and applet->js.

But look at:

js->applet:
"rec=10,narg=1,arg1=177"

applet->sever:
10 (req emp info)
1 (# args)
1 (type = int)
177 (int value)

server->applet:
11 (resp emp info)
2 (# args)
2 (type = string)
"Jones" (string value)
1 (type = int)
80000 (int value)
or:
99 (resp err)
0 (# args)

applet->js:
"rec=11,narg=2,arg1='Jones',arg2=80000"
or:
"rec=99"

The JavaScript guys should not have any problems formatting and
parsing those strings.

You can come up with a zillion different formats. But a single
method in the Java applet that receives a string as argument and
return a string with data packed in some format should work.

And the wire overhead is not that big.

> Can my Applet dynamically load a Class? If I get an Applet Parameter that
> says PAYROLL can I not load codebase()payroll.class? OK, forget about my
> applet loading the PAYROLL class; is there another way for the
> Application-specific programmers to load their PAYROLL class into the JVM
> and make them available to Javascript/html (who in turn will call my
> send/recieve)?

> Perhaps a second Applet? How do they know about each other? Is there
> something in DOM that let's them share context? Is dynamic scripting the
> answer?

You applet can easily load a class from the server.

The JavaScript code could generate a new applet tag, but
I think that could get messy.

Let the JavaScript send something to the Java applet that makes
it load a class from the serfer, if that is what you want.

> PS. I really like the look of nio sockets and the endian and charset
> qualities of the buffers! But I have taken good advice and have stuck with
> the IO class and .net sockets. I am using getbytes(charset) for strings and
> will REVERSE() work the endian magic or will I have to do that myself?
> Data*Stream also looked good! (But only if they talk to each other, right?)

DataInputStream/DataOutputStream always uses net order (big endian).

If you use them for byte arrays and 2/4/8 byte integers, then any
C sprogrammer should be able to communicate with them. Just avoid
using them directly for strings (instead you send 1 or 2 bytes
with length and N bytes with the bytes from the string).

> PPS. It's a bit scary that I haven't stumbled across a Scaled Integer
> class/primitive/necessity! Please don't tell me that Java uses floating
> point primitives for Money. (Note to self: - What does Number class do?)

It does not.

java.math.BigDecimal is what you are looking for.

java.lang.Number is a base class for various classes containing
numeric values.

Arne

Hi Chris,

Thanks for the reply.

> 1) Represent messages as Java objects (com.mystuff.Message), which had
methods
> for accessing the data contained therein (a java byte[] array which is
never
> itself visible to the JavaScript code) like getSignedInt32AtOffset(int o),
or
> setDoubleAtOffset(int o), or setUnsignedByteAtOffset(int o, int value).

(1) Sounds like the winner to me. I'll give it a go.

> Maybe I'm missing something ?

No, it's obvious (now that you've told me Still a bit like getting an
egg to stand on its end, but this stuff is growing on me. Someone else had
already given me an example of what you describe, so I should be able to
muddle through.There's only so many conversions I'm looking at supporting,
and maybe a final getWholeMessage() for raw processing.)

> There is some discussion of handling binary data directly from JavaScript
on
> the Web. Googling for
> (javascript OR ecmascript) "binary data"
> finds a number of hits.

Intersting the number of people that are trying to do this. The few I
scanned looked like hard work and not very pretty to me, but then my
knowledge of Javascript is just about non-existant. Is there a good web
reference for a Javascript Tutorial with reference manuals along the lines
of Sun's Java site? The stuff I Googled up was mostly fee paying or brief
discussion sites.

Does any one have a quick Javascript example of Java methods returning
things other than strings (eg: int of bytes read, or a byte array for
something like blob = blob + readFullBuff() ?)

Yes, I will look it up myself

Thanks again.

Cheers Richard Maher

PS. Edith Cowan University (ECU Perth) looks to have a very good one
semester Java course starting in a couple of weeks for anyone who's
interested. I'd love to, but I can't aford the time off during the day at
the moment AUD$1000 on a non-award basis)

"Chris Uppal" <> wrote in message
news:45cdf06d$1$756$...
> Richard Maher wrote:
>
> > Am I correct in assuming that there is simply no way that Javascript,
and
> > its "var =" semantics, can deal with the complexities of character-set
an
> > integer-endian issues, and that one must call back to Java-proper with
the
> > document.applet.method() functionality?
>
> There is some discussion of handling binary data directly from JavaScript
on
> the Web. Googling for
> (javascript OR ecmascript) "binary data"
> finds a number of hits.
>
>
> > The problem I'm faced with now is that I'm the infrastructure/middleware
> > guy and I have no idea about an individual or specific Application's
> > message passing and formatting requirements. I have established an
> > application neutral, or generic, link to the host and authorized
> > application access and I have made available the conduit for interacting
> > with the server code, but I simply don't know what your subsequent
> > messages will look like or what they with contain.
>
> Seems fair enough, but I'm a little puzzled by the rest of your
architecture
> (snipped). Wouldn't it make more sense (assuming you've got JavaScript
and
> Java talking to each other in the first place) to leave the formatting of
> messages entirely up to the JavaScript code ? You could do that in at
least
> two ways (without messing around with custom Java code for each message
type):
>
> 1) Represent messages as Java objects (com.mystuff.Message), which had
methods
> for accessing the data contained therein (a java byte[] array which is
never
> itself visible to the JavaScript code) like getSignedInt32AtOffset(int o),
or
> setDoubleAtOffset(int o), or setUnsignedByteAtOffset(int o, int value).
>
> 2) Allow the JavaScript code to define the layout of each message type to
your
> Java code (perhaps by passing in a list of <name, size, type> triples);
and for
> your Java code to use those definitions to convert between JavaScript
objects
> and raw binary data.
>
> Maybe I'm missing something ?
>
> -- chris
>
>
>

Hi Arne,

Thanks for the reply.

> There are certain possibilities in JavaScript, but I would do that
> part in Java.

Looks like everyone's agreed on that.

> You could extend your protocol to be flexible enough to convert
> to and from a text format.
[Followed by application specific protocol example. . .]

I agree. I will provide a getString() method that returns all of the byte[]
array from the last read; what the client and server code put in there is
their business. (XML if they really have to) IE: No offset or length
arguments and I call the other method with 0 and array.length.

> You applet can easily load a class from the server.

With runtime discovery of the class name? How? What verb/method/incantation?
(Or just Jscript applet 2?)

> Let the JavaScript send something to the Java applet that makes
> it load a class from the serfer, if that is what you want.

I'll send it the class name or filename (eg: PAYROLL) how does one's Applet
now expose/surface PAYROLL's methods and constructors to Javascript and
html? (As well as making existing classes/methods available to PAYROLL)

> java.math.BigDecimal is what you are looking for.

That's a relief! I am now also looking at BigInteger to convert 2 or 4 bytes
of my server byte stream to an integer. Does this sound sensible to you as
opposed to the various ">>" but shift examples on the web? IE: I move bytes
[1] to [4] and [2] to [3] (Have to check that?) and then BigInteger them;
sound good? Just to show how; everything in example 1 will be strings
anyway.

BTW. Can you have two (or N) methods in the same class that have the same
name and accept the same parameters but vary only in what they return? (IE
One returns an int and another returns a small)

Cheers Richard Maher

PS. Dragging on a bit, I know Should finish this weekend.

"Arne Vajhøj" <> wrote in message
news:45ce65b0$0$49203$...
> Richard Maher wrote:
> > The immutables are: -
> >
> > 1) I'm running in a Web browser and and am using a combo of html and
> > Javascript for the user interface.
> > 2) There is an Applet that has established and authorized a Socket
> > connection back to a non-Java server
> > 3) Data/Messages are exchanged in the form of Byte Arrays (ie Records)
> > 4) The customer doesn't want to "Just do it all in Java"
> > 5) I am not interested in hearing about XDR or IDL, and if a given
> > application wants to use XML then good-luck to them, I will not stop
them,
> > but for those of you left who are willing to think outside of the box,
> > please continue.
> >
> > An example of what might happen is, the user enters an Employee Number
and
> > as part of the validation a "Get Employee" message is sent to the server
and
> > in response either an "Employee Details" or an "Error" message will be
> > returned. (For argument's sake let's adopt the convention that the first
two
> > bytes of the message will be reserved for Message Id follow by a
> > message-specific body. "10" is Employee request, "11" is Employee
Details
> > response and "99" is Lookup Error)
> >
> > Anyway, if a "11" message comes back then we know 200 bytes of data will
> > follow which might have a Surname in a specific Character set, an
integer
> > (little-endian) for base salary, and all the other crap that we all
have.
> >
> > Am I correct in assuming that there is simply no way that Javascript,
and
> > its "var =" semantics, can deal with the complexities of character-set
an
> > integer-endian issues, and that one must call back to Java-proper with
the
> > document.applet.method() functionality?
>
> There are certain possibilities in JavaScript, but I would do that
> part in Java.
>
> > The problem I'm faced with now is that I'm the infrastructure/middleware
guy
> > and I have no idea about an individual or specific Application's message
> > passing and formatting requirements. I have established an application
> > neutral, or generic, link to the host and authorized application access
and
> > I have made available the conduit for interacting with the server code,
but
> > I simply don't know what your subsequent messages will look like or what
> > they with contain. I give you a read method and a write method (and a
> > lovely sendUrgentData() method) but you have to provide the Class for
> > packing and unpacking the messages How do I make your lovely
> > application-sepcific scatter/gather methods available to your
Javascript/htm
> > when I insist on controlling/owning the Applet?
>
> You could extend your protocol to be flexible enough to convert
> to and from a text format.
>
> What you have now is:
>
> applet->server:
> 10 (req emp info)
> 177 (emp id)
>
> server->applet:
> 11 (resp emp info)
> "Jones" (name)
> 80000 (salary)
> or:
> 99 (resp err)
>
> And that info is really not that easy to do js->applet and applet->js.
>
> But look at:
>
> js->applet:
> "rec=10,narg=1,arg1=177"
>
> applet->sever:
> 10 (req emp info)
> 1 (# args)
> 1 (type = int)
> 177 (int value)
>
> server->applet:
> 11 (resp emp info)
> 2 (# args)
> 2 (type = string)
> "Jones" (string value)
> 1 (type = int)
> 80000 (int value)
> or:
> 99 (resp err)
> 0 (# args)
>
> applet->js:
> "rec=11,narg=2,arg1='Jones',arg2=80000"
> or:
> "rec=99"
>
> The JavaScript guys should not have any problems formatting and
> parsing those strings.
>
> You can come up with a zillion different formats. But a single
> method in the Java applet that receives a string as argument and
> return a string with data packed in some format should work.
>
> And the wire overhead is not that big.
>
> > Can my Applet dynamically load a Class? If I get an Applet Parameter
that
> > says PAYROLL can I not load codebase()payroll.class? OK, forget about my
> > applet loading the PAYROLL class; is there another way for the
> > Application-specific programmers to load their PAYROLL class into the
JVM
> > and make them available to Javascript/html (who in turn will call my
> > send/recieve)?
>
> > Perhaps a second Applet? How do they know about each other? Is there
> > something in DOM that let's them share context? Is dynamic scripting
the
> > answer?
>
> You applet can easily load a class from the server.
>
> The JavaScript code could generate a new applet tag, but
> I think that could get messy.
>
> Let the JavaScript send something to the Java applet that makes
> it load a class from the serfer, if that is what you want.
>
> > PS. I really like the look of nio sockets and the endian and charset
> > qualities of the buffers! But I have taken good advice and have stuck
with
> > the IO class and .net sockets. I am using getbytes(charset) for strings
and
> > will REVERSE() work the endian magic or will I have to do that myself?
> > Data*Stream also looked good! (But only if they talk to each other,
right?)
>
> DataInputStream/DataOutputStream always uses net order (big endian).
>
> If you use them for byte arrays and 2/4/8 byte integers, then any
> C sprogrammer should be able to communicate with them. Just avoid
> using them directly for strings (instead you send 1 or 2 bytes
> with length and N bytes with the bytes from the string).
>
> > PPS. It's a bit scary that I haven't stumbled across a Scaled Integer
> > class/primitive/necessity! Please don't tell me that Java uses floating
> > point primitives for Money. (Note to self: - What does Number class do?)
>
> It does not.
>
> java.math.BigDecimal is what you are looking for.
>
> java.lang.Number is a base class for various classes containing
> numeric values.
>
> Arne

Richard Maher wrote:
> BTW. Can you have two (or N) methods in the same class that have the same
> name and accept the same parameters but vary only in what they return? (IE
> One returns an int and another returns a small)

Not in Java.

What is a "small"?

- Lew

Hi Lew,

> Not in Java.

Oh well.

> What is a "small"?

My instinctive knowledge of the Java nomenclature for primitive datatypes.
(But they do start with lowercase

Or it could be a short from out-of-town. Smallint? Bitcount challenged?
Anyway, I don't think it's right to be too judgemental or to start labelling
everybody

Cheers Richard Maher


"Lew" <> wrote in message
news:. ..
> Richard Maher wrote:
> > BTW. Can you have two (or N) methods in the same class that have the
same
> > name and accept the same parameters but vary only in what they return?
(IE
> > One returns an int and another returns a small)
>
> Not in Java.
>
> What is a "small"?
>
> - Lew

Richard Maher wrote:
>> You applet can easily load a class from the server.
>
> With runtime discovery of the class name? How? What verb/method/incantation?
> (Or just Jscript applet 2?)

Object o = Class.forName(clznam).newInstance();

should create an object based on the string clznam.

If you know that all classes will implement a given
interface (or base class), then you can cast to that.

Else you will need to use reflection to access
methods.

>> Let the JavaScript send something to the Java applet that makes
>> it load a class from the serfer, if that is what you want.
>
> I'll send it the class name or filename (eg: PAYROLL) how does one's Applet
> now expose/surface PAYROLL's methods and constructors to Javascript and
> html? (As well as making existing classes/methods available to PAYROLL)

Covered above.

It is the same the other way around: what is known at compile
time is normal - what is not known at compile time needs a
common interface or relflection.

>> java.math.BigDecimal is what you are looking for.
>
> That's a relief! I am now also looking at BigInteger to convert 2 or 4 bytes
> of my server byte stream to an integer. Does this sound sensible to you as
> opposed to the various ">>" but shift examples on the web? IE: I move bytes
> [1] to [4] and [2] to [3] (Have to check that?) and then BigInteger them;
> sound good? Just to show how; everything in example 1 will be strings
> anyway.

I would decide on network byte order and use the Data*putStream classes.

> BTW. Can you have two (or N) methods in the same class that have the same
> name and accept the same parameters but vary only in what they return? (IE
> One returns an int and another returns a small)

No. Return type is not part of method signature.

Arne

Hi Arne,

> Object o = Class.forName(clznam).newInstance();
>
> should create an object based on the string clznam.

Wow! Cool bananas.

> If you know that all classes will implement a given
> interface (or base class), then you can cast to that.
>
> Else you will need to use reflection to access
> methods.

Once I get the trainer-wheels off I'll revisit this; it sounds good. (Looks
in codebase right?)

> I would decide on network byte order and use the Data*putStream classes.

Yeah, see you say that now, but would you really? Don't forget I'm
constrained by the requirement to talk to a non-Java server here. FYI and
FWIW here are my thought processes whilst deciding which Java socket client
interface to use. Please point out where my thinking has been unclear: -

1) NIO ByteBuffers (and nio.channels) are the mutt's nuts! And are
undoubtedly what the well-dressed Java socket programmer should be wearing
this season. Surely that lovely order(LITTLE_ENDIAN) method is screaming out
to VMS die-hards like me and Intel based OSs all over the world? Are you
saying that subsequent getInt() etc method calls won't automagically change
the endian format for me?

The only problem I saw with NIO is that Esmond (EJP) has said "For example,
I would rarely if ever use it as a client.". Now Esmond clearly nows what
he's talking about with Java and I'm struggling to distinguish arse from
elbow, so I pay him maximum respect and hit the books to see what he's
alluding to. But at the end of the day I decided to back myself and call his
bluff. That is, until he subsequently provided and example of the
non-blocking + selector crap one must perform just to provide a simple
timeout on a connect call

[I thought the N in nio meant NEW? Therefore surely it should be a superset
of IO and not cherry-pick an leave out the bits someone didn't like?]

Anyway, scrub NIO 'cos that annoyed me.

2) I came to your conclusions here about Data*Streams. And sure the server
can just send everything in network byte order, why not? But statements such
as "An application uses a data output stream to write data that can later be
read by a data input stream." and the general tone of the docs led me to the
conclusion that if I tried to emulate and fudge all of the foibles and
idiosyncrasies of DataStreamOut then it would all end in tears. Surely these
classes are meant for homogenous Java everywhere environs?

3) Plain old sockets and Buffered*Streams, getBytes(charset) for the
strings, and handroll (or convention) the Integers. It's just an example to
show a couple of possibilities. What people actually do do is up to them.
Me? I prefer BigiIteger to bit shifting.

> No. Return type is not part of method signature.

Oh well, different name then.

Thanks again.

Cheers Richard Maher

"Arne Vajhøj" <> wrote in message
news:45d3ae8d$0$90262$...
> Richard Maher wrote:
> >> You applet can easily load a class from the server.
> >
> > With runtime discovery of the class name? How? What
verb/method/incantation?
> > (Or just Jscript applet 2?)
>
> Object o = Class.forName(clznam).newInstance();
>
> should create an object based on the string clznam.
>
> If you know that all classes will implement a given
> interface (or base class), then you can cast to that.
>
> Else you will need to use reflection to access
> methods.
>
> >> Let the JavaScript send something to the Java applet that makes
> >> it load a class from the serfer, if that is what you want.
> >
> > I'll send it the class name or filename (eg: PAYROLL) how does one's
Applet
> > now expose/surface PAYROLL's methods and constructors to Javascript and
> > html? (As well as making existing classes/methods available to PAYROLL)
>
> Covered above.
>
> It is the same the other way around: what is known at compile
> time is normal - what is not known at compile time needs a
> common interface or relflection.
>
> >> java.math.BigDecimal is what you are looking for.
> >
> > That's a relief! I am now also looking at BigInteger to convert 2 or 4
bytes
> > of my server byte stream to an integer. Does this sound sensible to you
as
> > opposed to the various ">>" but shift examples on the web? IE: I move
bytes
> > [1] to [4] and [2] to [3] (Have to check that?) and then BigInteger
them;
> > sound good? Just to show how; everything in example 1 will be strings
> > anyway.
>
> I would decide on network byte order and use the Data*putStream classes.
>
> > BTW. Can you have two (or N) methods in the same class that have the
same
> > name and accept the same parameters but vary only in what they return?
(IE
> > One returns an int and another returns a small)
>
> No. Return type is not part of method signature.
>
> Arne

Arne Vajhøj wrote:

> If you know that all classes will implement a given
> interface (or base class), then you can cast to that.
>
> Else you will need to use reflection to access
> methods.

He will if he's using Java to access them, but if he just passes instances over
to JavaScript then the JavaScript embedding mechanism (whatever it is,
presumably something built on JNI) will take over, and will make members
directly accessible in just the same way as members of any other classes. I.e.
the JavaScript code has no need to know (or any way of telling) whether the
class was loaded by class.forName().

Or so logic suggests....


> > > java.math.BigDecimal is what you are looking for.
> >
> > That's a relief! I am now also looking at BigInteger to convert 2 or 4
> > bytes of my server byte stream to an integer. Does this sound sensible
> > to you as opposed to the various ">>" but shift examples on the web?

Er, I don't think it is sensible. BigInteger (and BigDecimal) are useful for
handling numeric data which is, or which might be, out of range for "normal"
ints and longs. Since you are apparently getting binary data from a server
written in C (or similar) the range of integers in the messages will be ones
that normal Java can handle. (Though you may have to handle signed/unsigned
issues specially.) That's doubly true if you are passing the data over to
JavaScript, since I don't think it understands any kinds of numbers except
floating point (integers are converted automatically).

What I would do is make the people sending the data specify /exactly/ (at the
level of bits and bytes) what will be on the wire, and then decode that in
Java. It's not at all difficult (and there's no need to delve into the
mysteries of the NIO stuff just to avoid doing a bit of bit-shifting !)


> > BTW. Can you have two (or N) methods in the same class that have the
> > same name and accept the same parameters but vary only in what they
> > return? (IE One returns an int and another returns a small)
>
> No. Return type is not part of method signature.

Technically they can -- it's only the Java compiler that forbids user code from
doing so (it is happy to generate methods which differ only in return type
itself, but it thinks we humans can't be trusted).

But that's just a niggle.

The more important point I wanted to make is that it's probably a good idea for
any objects which are passed over to JavaScript to have different names for all
methods (not relying on the types of the arguments to distinguish them as we
would in Java proper). The mechanisms used for distinguishing between
overloaded method names in Java are not fully available to JavaScript since it
does not have the same collection of types.

-- chris