 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / February 2007Scatter/Gather in Java or Javascript & html (Dynamic class loading?)
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! > 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 [quoted text clipped - 3 lines] > 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 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 [quoted text clipped - 33 lines] > > -- chris > The immutables are: - > [quoted text clipped - 25 lines] > 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 [quoted text clipped - 7 lines] > 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 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. > > The immutables are: - > > [quoted text clipped - 139 lines] > > Arne > 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 > > 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 [quoted text clipped - 5 lines] > > - Lew >> 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. > [quoted text clipped - 4 lines] > 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 > >> You applet can easily load a class from the server. > > [quoted text clipped - 42 lines] > > Arne >> 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?) It looks in the definition in the class file (or in the memory structure created when loading the class file). >> 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: - 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 [quoted text clipped - 14 lines] > [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 [quoted text clipped - 3 lines] > 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 ! > 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 >> PS: If you wonder - Java has over 3000 classes with over 95000 methods >> as of 1.6 ! [quoted text clipped - 5 lines] > 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 > 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 >> 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). byte m() { } short m() { } int m() { } what should it do for: m(); or even: long v = m(); ? Arne [me:] > > 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 [quoted text clipped - 7 lines] > > 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 >> byte m() { } >> short m() { } [quoted text clipped - 7 lines] > 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 [quoted text clipped - 5 lines] > 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 > > > byte m() { } > > > short m() { } [quoted text clipped - 12 lines] > > 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). > > Incidentally, this isn't merely an academic technical issue (it is an > > academic technical issue, I admit, but it isn't /merely/ one ;-) The [quoted text clipped - 9 lines] > 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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.