Scatter/Gather in Java or Javascript & html (Dynamic class loading?)

[Richard Maher]

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!

 

[Chris Uppal]

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

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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]

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)

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]

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.

 

[Lew]

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]

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

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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.

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

 

[Richard Maher]

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

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.

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

 

[Chris Uppal]

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


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 !)

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

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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

byte m() { }
short m() { }
int m() { }

what should it do for:

m();

or even:

long v = m();

?

Arne

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

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

It looks in the definition in the class file (or in the memory structure
created when loading the class file).

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: -

Data*putStream when using only simple data types is not Java specific.

You can talk with it using C sockets (or whatever language
the server side code doing the socket IO is written in).

Big endian is not native on VMS, but converting to bigendian
is common practice for networking (that is wgy big endian is called
network order).

C has ntohs, ntohl, htons and htonl for the same.

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

nio is new because it was added to Java late (1.4 if I
remember correctly).

I do not think you need nio at all.

The most important part of nio for socket programming
is that it support select.

Before nio you used one thread per socket.

With nio you can have one socket serve multiple sockets.

Not relevant for you.

There are some other goodies, but I still think you should
not spend time studying nio.

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?

No and yes and no.

As long as you only read and write simple data types then you are OK.

I have used it between Java and C#.

If you were using Java-Java you would be looking at stuff
like Object*putStream and RMI.

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.

You write the code => you decide.

By now you must have realized that the Java library is big.

There are often more than one way of doing certain things.

Arne

PS: If you wonder - Java has over 3000 classes with over 95000 methods
as of 1.6 !

 

[Chris Uppal]

Arne Vajhøj wrote:

[me:]

byte m() { }
short m() { }
int m() { }

what should it do for:

m();

No idea. Not my problem! That's the compiler's problem -- since it
super-imposes a limited syntax on the underlying semantics, it's /its/ fault if
that syntax is too limited.

Incidentally, this isn't merely an academic technical issue (it is an academic
technical issue, I admit, but it isn't /merely/ one ;-) The underlying
semantics are important to anything which interacts with a JVM from outside the
little fishbowl created by javac. This why I so much dislike the hacks upon
hacks which they keep adding to the language -- they seem to forget that Java
(the language) != code running on a JVM (or talking to a JVM). In this case,
the external code is in JavaScript and /it/ will see straight through any dirty
little cover-ups that javac has introduced (how the JavaScript/JVM interface
then exposes that at the JavaScript level is another matter).

-- chris

 

[Chris Uppal]

PS: If you wonder - Java has over 3000 classes with over 95000 methods
as of 1.6 !

How are you counting ?

I make it about 14K public classes with around 140K public or protected
methods. But then I'm counting stuff from all the JDK jars (includings tools
and extensions). Also I'm making no effort to filter out Sun's "private"
classes, nor any public nested classes.

-- chris

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

How are you counting ?

I make it about 14K public classes with around 140K public or protected
methods. But then I'm counting stuff from all the JDK jars (includings tools
and extensions). Also I'm making no effort to filter out Sun's "private"
classes, nor any public nested classes.

Only rt.jar and only java and javax.

Arne

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

No idea. Not my problem! That's the compiler's problem -- since it
super-imposes a limited syntax on the underlying semantics, it's /its/ fault if
that syntax is too limited.

If there are no obvious good choices, then I would conclude that
it is is not a good language feature to have.

BTW, I think C++ and C# behaves like Java for this issue.

Incidentally, this isn't merely an academic technical issue (it is an academic
technical issue, I admit, but it isn't /merely/ one ;-) The underlying
semantics are important to anything which interacts with a JVM from outside the
little fishbowl created by javac. This why I so much dislike the hacks upon
hacks which they keep adding to the language -- they seem to forget that Java
(the language) != code running on a JVM (or talking to a JVM). In this case,
the external code is in JavaScript and /it/ will see straight through any dirty
little cover-ups that javac has introduced (how the JavaScript/JVM interface
then exposes that at the JavaScript level is another matter).

Are you saying that JavaScript can distinguish beetween method with same
name and arguments but different return type ??

(that would surprise me considering how JavaScript is not "type
focused")

Arne

 

[Chris Uppal]

If there are no obvious good choices, then I would conclude that
it is is not a good language feature to have.

BTW, I think C++ and C# behaves like Java for this issue.

They do. I have never really understood why the JVM works differently (it also
allows overloading of fields by the type of the content -- so you can have lots
of fields all called 'f' but with different types).

Are you saying that JavaScript can distinguish beetween method with same
name and arguments but different return type ??

Yes and no. I don't know what techniques the JavaScript implementation uses to
talk to the embedded JVM. It more or less has to be based on JNI, but then
there's the question of how to map the semantics of runtime Java objects (as
exposed via JNI) to runtime JavaScript objects.

JNI itself works with "raw" JVM semantics, so that part of the code /cannot/
ignore the return type -- it is simply part of each method's signature, and you
have to know that to talk about the method at all (same goes for fields). So,
at that level the JavaScript stuff knows all about the possibility of having
two or more methods with the same name and argument types.

But now the designers have to represent a runtime Java object in JavaScript via
some sort of proxy which exposes the Java object's members as JavaScript
members (whatever the correct term is -- "slots" perhaps?). Here they face a
problem if they want to map a JavaScript expression like
javaobject.aMethod("hello", 22)
into a Java object method call. The problem is that Java has about eight
numeric types (counting char), whereas JavaScript has only one... Also the
expected return type is not implied by the JavaScript expression. So they have
to do some guessing. In many cases, they can (I presume) just scan down the
list of available methods looking for the best match, and then call that (with
any necessary coercions). But, of course, that is just a heuristic, and it
isn't guaranteed either to find a unique best match, nor to invoke the desired
Java method even if there /is/ a unique best match.

(As an aside: in my own bridge between Smalltalk and Java (architecturally
similar), I face exactly the same challenge, but have chosen to solve it in a
different way which avoids the ambiguity problem.)

-- chris